-
Notifications
You must be signed in to change notification settings - Fork 7.3k
url.format does not postfix :// when parsed url is not fully qualified but a protocol is specified #6100
Comments
For reference, here is a runnable asserting this behavior. It may be that this isn't actually a bug. RFC 3986#3 requires that URIs have a scheme, except in the case of relative URIs, defined in RFC 3986#4.2. A relative URI is required to have a leading '//'. Node's Without a defined host, L386 of url.js will not append slashes to the protocol. After a quick reading of the spec it appears this is the correct behavior. In the user's case, he could make this work by prepending '//' to his incoming URIs, or by setting |
RFC 2616#3.2.2 indicates that it is not possible to use the "http" scheme without using the double slashes. ("https" scheme follows the same rules. RFC 2818#2.4 ). There are some grounds to always postfix :// with some schemes. Not fussed if this isn't performed automatically, but it would be nice if the "slashes" property could be documented in url.parse and/or url.format. (Also, any chance we can rename this class to URI instead of URL? I know that they are often casually used interchangeably, but URL is technically a subset of URI). |
Even with There are 3 slashes, not two, with v0.10.26 |
Hey guys, Any news on this? Just bumped on this bug, behavior is definitely wrong and not in line with the doc ... |
We're moving to make |
See: nodejs/node#49 |
I find that this error is still present in Node v5.0.0, and the issue mentioned above seems unrelated. Should a matching issue be created? |
oh hey @Jonahss I think you totally should. Provided a minimal test case failing would help speed it up |
In:
It states that: "The protocols http, https, ftp, gopher, file will be postfixed with :// (colon-slash-slash)".
I'm unsure whether urlObjects are meant to be modified so they can be formatted again (although this seems reasonable).
It appears that if the parsed URL was not fully qualified then assigning a protocol doesn't postfix the :// (colon-slash-slash) as expected.
Code below demonstrates the problem:
The text was updated successfully, but these errors were encountered: