Any path.join or path.normalize that starts with a / will not go "above" that after normalization. This is important because /../foo is almost *always* some sort of error, and doesn't match the corollary in sh: `cd $p; pwd`
At the worse, this can be a vector for exploits, since a static file server might do path.join(docroot, path.normalize("/"+req)) to get the file. If the normalized request path could be something like "/../../../etc/passwd" then bad things could happen.
Before there was this comment:
Can't strip trailing slashes since module.js incorrectly
thinks dirname('/a/b/') should yield '/a/b' instead of '/a'.
But now, such thinking is corrected.
- Buffer.toString('ascii', 0, 0) incorrectly returns the entire contents
of the buffer. Fix this.
- Provide similar behavior to Buffer.write() and Buffer.copy() when
dealing with 0-length in valid and invalid byte ranges.
This is ever so slightly less efficient than caching based on ID, since the
filename has to be looked up before we can check the cache. However, it's
the most minimal approach possible to get this change in place. Since
require() is a blocking startup-time operation anyway, a bit of slowness is
not a huge problem.
A test involving require.paths modification and absolute loading. Here's the
gist of it.
Files: /p1/foo.js /p2/foo.js
1. Add "/p1" to require.paths.
2. foo1 = require("foo")
3. assert foo1 === require("/p1/foo") (fail)
4. Remove /p1 from require.paths.
5. Add /p2 to require.paths.
6. foo2 = require("foo")
7. assert foo1 !== foo2 (fail)
8. assert foo2 === require("/p2/foo") (fail)
It's an edge case, but it affects how dependencies are mapped by npm.
If your module requires foo-1.2.3, and my module requires foo-2.3.4,
then you should expect to have require("foo") give you foo-1.2.3, and
I should expect require("foo") to give me foo-2.3.4. However, with
module ID based caching, if your code loads *first*, then your "foo"
is THE "foo", so I'll get your version instead of mine.
It hasn't yet been a problem, but only because there are so few
modules, and everyone pretty much uses the latest version all the
time. But as things start to get to the 1.x and 2.x versions, it'll
be an issue, I'm sure. Dependency hell isn't fun, so this is a way to
avoid it before it strikes.
Add NODE_MODULE_CONTEXTS env var
Only one test was modified to check that this works. NEED to go through all
tests and modify them so that
NODE_MODULE_CONTEXTS=1 make test
passes.
Done by not evaluating the code in the first tick.
This breaks one test in test-error-reporting.js but I believe this to be a
V8 error and I have reported it in
http://code.google.com/p/v8/issues/detail?id=764
C-Ares doesn't go through the Name Service Switch (NSS) and thus can't
resolve certain classes of names. Generally this doesn't matter and the
whole idea of NSS is rather annoying. Nevertheless until C-Ares gets better
support, adding this hack to go through getaddrinfo() for .local domain look
up.
This reverts commit 9926dacd14.