-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
url.format does not postfix :// when parsed url is not fully qualified but a protocol is specified #4101
Comments
Seeing as how modifying the url module would be more drastic and could have unintended effects in userland, I'd say going with the doc fix is the safer approach, sent a PR. |
Fixing the docs def fixes confusion. Altering the url module would definitely effect many users, but the current behavior isn't very useful. I was hoping to use the url module to convert any partial/full url to a full url, eg:
Should I publish a module to perform this common operation? |
For your particular use case, isn't it sufficient to set "slashes" to true on the url object, then format? |
I didn't try with Unfortunately, when I set
So I guess my function will need to do this:
Of course, now if my original text had a path, it would never be parsed out. I guess moral of the story is prepend "http://" to any input url that doesn't have a protocol and parse from there. |
Yeah, the url module needs a breaking change to fix that stuff. After my PR for doc change lands, I'll get around submitting another one for this kind of stuff. |
👍 |
+1 is there a current workaround for this or an eta on completion? |
I'll close this out. url.format() is frozen for practical purposes, bugs and all, and superseded by the WHATWG URL implementation. |
Carried over from archived repo issue: nodejs/node-v0.x-archive#6100
In: https://nodejs.org/api/url.html#url_url_format_urlobj
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: