http2.js
protocols object to store defaults for http and https, and use as a switch for supported protocols.
options.hostname > options.host > 'localhost'
if I have an options.auth element and I do not have an Authorization header, I do basic auth.
http.request collapses to new ClientRequest since the defaults are handled by the protocol object
test-http-url.parse*
Fixes#1390
Conflicts:
lib/http2.js
added a .path property = .pathname + .search for use with http.request
And tests to verify everything.
With the tests, I changed over to deepEqual, and I would note the comment on the test
['.//g', 'f:/a', 'f://g'], which I think is a fundamental problem
This supersedes pull 1596
Fix#1484Fix#1834Fix#1482Fix#771
It's been a while now, and we've seen how this separate context thing
works. It constantly confuses people, and no one actually uses '.clear'
anyway, so the benefit of that feature does not justify the constant
WTFery.
This makes repl.context actually be a getter that returns the global
object, and prints a deprecation warning. The '.clear' command is gone,
and will report that it's an invalid repl keyword. Tests updated to
allow the require, module, and exports globals, which are still
available in the repl just like they were before, by making them global.
Squashed commit:
(- re tests) Cleaning up the `Script` test suite.
For whatever reason, there were several duplicate test files related to `Script`
and the `'vm'` module. I removed these, and fixed a few other small issues.
(More fixes coming in subsequent commits.)
Squashes: 19e86045a0..1e3dcff4eb
(api fix:1801 new:1801) `'vm'` module uses sandbox as prototype
As described in GH-1801, the `'vm'` module was handling the `sandbox` object
provided by the API consumer in a particularly terrible and fragile fashion: it
was simply shallow-copying any enumerable properties from the sandbox onto the
global context before executing the code, and then eventually copying any values
on the global context back into the sandbox object *afterwards*.
This commit removes all of that implementation, and utilizes the passed sandbox
object as the *prototype of the context* instead. A bit of a hack, but a very
effective one.
This no longer allows for new variables created in the global context to be
placed into your sandbox after execution has completed, but that’s for the best
anyway, as it’s not very in line with the concept of a “box of passed-in
context.” I’m planning to further implement an interface for API consumers to
acquire the *actual global* from within the VM soon, thus allowing for
separation-of-concerns: providing data *to* the VM via the sandbox-prototype,
and exploring the internal environment of the VM itself.
// GitHub cruft: closes#1801
Squashes: 43b8e3c..209ed86