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>
I was originally going to do this after the v0.11.15 release, but as
that release is three weeks overdue now, I decided not to wait any
longer; we don't want the delta to get too big.
Conflicts:
lib/net.js
test/simple/simple.status
PR-URL: https://github.com/iojs/io.js/pull/236
Reviewed-By: Bert Belder <bertbelder@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
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'.
The change for #954 introduced a regression that would cause
the url parser to fail on special chars found in the auth
segment. Fix that, and also don't create invalid urls when
format() is called on an object containing an auth member
containing '@' characters or delimiters.
