'.' and '..' are directory specs and resolving urls with or
without the hostname with '.' and '..' should add a trailing
slash to the end of the url.
Fixes: https://github.com/joyent/node/issues/8992
PR-URL: https://github.com/iojs/io.js/pull/278
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Many of the util.is*() methods used to check data types
simply compare against a single value or the result of
typeof. This commit replaces calls to these methods with
equivalent checks. This commit does not touch calls to the
more complex methods (isRegExp(), isDate(), etc.).
Fixes: https://github.com/iojs/io.js/issues/607
PR-URL: https://github.com/iojs/io.js/pull/647
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This commit replaces a number of var statements throughout
the lib code with const statements.
PR-URL: https://github.com/iojs/io.js/pull/541
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The copyright and license notice is already in the LICENSE file. There
is no justifiable reason to also require that it be included in every
file, since the individual files are not individually distributed except
as part of the entire package.
Fix regression introduced in 6120472036
that broke parsing of some ssh: urls.
An example url is ssh://git@github.com:npm/npm.git
PR-URL: https://github.com/iojs/io.js/pull/299
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
The url.parse() function now checks whether an escapable character is in
the URL before trying to escape it.
PR-URL: https://github.com/joyent/node/pull/8638
[trev.norris@gmail.com: Switch to use continue instead of if]
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Replace the call to Array#splice() with a faster open-coded version
that creates less garbage.
Add a new benchmark to prove it. With the change applied, it scores
about 5% higher and that is nothing to sneeze at.
PR-URL: https://github.com/iojs/io.js/pull/184
Reviewed-By: Chris Dickinson <christopher.s.dickinson@gmail.com>
Turn on strict mode for the files in the lib/ directory. It helps
catch bugs and can have a positive effect on performance.
PR-URL: https://github.com/node-forward/node/pull/64
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Match the behavior of the slow path by setting url.query to an empty
object when the url contains no query, but query parsing is requested.
Also add a test for this case, and update the documents to clearly
reflect this behavior.
Fixes: https://github.com/joyent/node/issues/8332
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
There is no need to split the host by hand in `url.js` – Punycode.js
takes care of it anyway. This not only simplifies the code, but also
adds support for RFC 3490 separators (i.e. not just U+002E, but U+3002,
U+FF0E, and U+FF61 as well).
Closes#6055.
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Fixes an issue that caused the first querystring to be parsed prepending
a "?" in the first variable name on relative urls with no #fragment
Reviewed-by: Trevor Norris <trev.norris@gmail.com>
This patch adds a fast path for parsing of simple path-only URLs, as commonly
found in HTTP requests received by a server.
Benchmark results [ms], before / after patch:
/foo/bar 0.008956 0.000418 (fast path used)
http://example.com/ 0.011426 0.011437 (normal slow path, no change)
In a simple 'ab' benchmark of a single-threaded web server, this patch
increases the request rate from around 6400 to 7400 req/s.
Reviewed-By: Fedor Indutny <fedor@indutny.com>
See https://code.google.com/p/chromium/issues/detail?id=25916
Parse URLs with backslashes the same as web browsers, by replacing all
backslashes with forward slashes, except those that occur after the
first # character.
Manual rebase of 9520ade
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
When using url.parse(), path and pathname usually return '/' when there
is no path available. However when you have a protocol that contains
non-lowercase letters and the input string does not have a trailing
slash, both path and pathname will be undefined.
In cases where there are multiple @-chars in a url, Node currently
parses the hostname and auth sections differently than web browsers.
This part of the bug is serious, and should be landed in v0.10, and
also ported to v0.8, and releases made as soon as possible.
The less serious issue is that there are many other sorts of malformed
urls which Node either accepts when it should reject, or interprets
differently than web browsers. For example, `http://a.com*foo` is
interpreted by Node like `http://a.com/*foo` when web browsers treat
this as `http://a.com%3Bfoo/`.
In general, *only* the `hostEndingChars` should be the characters that
delimit the host portion of the URL. Most of the current `nonHostChars`
that appear in the hostname should be escaped, but some of them (such as
`;` and `%` when it does not introduce a hex pair) should raise an
error.
We need to have a broader discussion about whether it's best to throw in
these cases, and potentially break extant programs, or return an object
that has every field set to `null` so that any attempt to read the
hostname/auth/etc. will appear to be empty.
`url.format` should escape ? and # chars in pathname, and # chars in
search, because they change the semantics of the operation otherwise.
Don't escape % chars, or anything else. (see: #4082)
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
The file:// protocol *always* has a hostname; it's frequently
abbreviated as an empty string, which represents 'localhost'
implicitly.
According to RFC 1738 (http://tools.ietf.org/html/rfc1738):
A file URL takes the form:
file://<host>/<path>
where <host> is the fully qualified domain name of the system on
which the <path> is accessible...
As a special case, <host> can be the string "localhost" or the empty
string; this is interpreted as 'the machine from which the URL is
being interpreted'.