Repository navigation
url.resolve() behaves differently depending on the protocol of the base url #8921
Description
Activity
Some protocols (http, https, file, ftp and, yes, gopher) are treated specially, to match browser behavior ca. 2010, when the url module was introduced.
I think it's confusing but it's probably hard to change because of backwards compatibility. It's more likely to simply be subsumed by WHATWG URL support, ref #7448.
EDIT: Forgot to mention, if the URLs end in a slash, you get uniform behavior. I'll add documentation tags.
Thanks @bnoordhuis. I believe that the information you give in your comment (the list of protocols which are treated specially and the uniform behavior when the URL ends with a slash) definitely has its place in the documentation.
Assigned to myself as placeholder for @minervapanda
Reacted by Minerva PandaAccording to my knowledge , the issue is pointing to the url.md to the following lines of url.resolve() : url.resolve('/one/two/three', 'four') // '/one/two/four'
url.resolve('http://example.com/', '/one') // 'http://example.com/one'
url.resolve('http://example.com/one', '/two') // 'http://example.com/two'It looks good to me. Please correct me if I am wrong.
@minervapanda Yes, the issue is pointing to these lines and the examples are correct. However, the documentation does not tell that:
- Some protocols are treated as special cases (http, https, file, ftp and gopher).
- The way in which these protocols are treated differently.
- The behavior of
url.resolve()differs whether the URL ends with a/or not.
Thank you for the clarification @rolinh . I was confused ,the example seemed correct.I will make a PR to update the documentation.Thanks.
I'm optimizing the new version of Chrome's settings UI written in Polymer.
The node-based tool I was using (vulcanize) calls
url.resolve()a bunch and wasn't working well for our funkychrome://URLs (the settings page lives atchrome://settings). We ended up needing to shift all our URLs around (i.e.src=for<script>,href=for<link>) to actually get things working.I tracked it back to unexpected results with
url.resolve()in node (we're using v6.9.2):> require('url').resolve('chrome://settings', '/page.html') chrome:///page.html
For what it's worth, I also messed around with adding a slash at the end of the
from(first) argument, but that doesn't always work as we expected either:> require('url').resolve('chrome://settings/', '/page.html') chrome:///page.html
I expected
chrome://settings/page.htmlif that wasn't clear. And yes: a slash at the end offromand not at the beginning oftodoes work, but it's not the same (doesn't resolve correctly for all URLs).When i change the protocol, I get more expected results:
> require('url').resolve('http://chrome.tld', '/blah.html') http://chrome.tld/blah.html
I assume this has to do with the whitelist of protocols in lib/url.js. Certainly things could be added to this list, but the returns are diminishing.
I also found this todo:
// v0.12 TODO(isaacs): This is not quite how Chrome does things.This got me thinking: is node interested in using an implementation from an open source browser like
KURLfrom chromium? This is the technology behind theURLconstructor exposed to DOM./cc @arv as an FYI
The current direction is to leave the existing
url.parse()andurl.resolve()behavior as is and focus efforts into the new WHATWGURLimplementation that is much more robust, correct, and complete in it's handling of URLs. The implementation matches (as closely as currently possible) the behavior and API available in browsers.@danbeam, indeed, in Node.js v7 you can already do:
const { URL } = require('url'); console.log(new URL('/page.html', 'chrome://settings/').href); // Prints 'chrome://settings/page.html'
Or if Node.js v7 is too high of a requirement, @domenic's whatwg-url would also work.
Reacted by Erik Arvidsson and Brandon BrownThis issue has been inactive for sufficiently long that it seems like perhaps it should be closed. Feel free to re-open (or leave a comment requesting that it be re-opened) if you disagree. I'm just tidying up and not acting on a super-strong opinion or anything like that.
The
url.resolve()function behaves differently depending on the protocol given in thefromparameter.See this example:
When reading this function's documentation, this is not a behavior that I could foresee. I would have expected
'wss://foo.tld/bar'and'ftps://foo.tld/bar'as results of the last two calls respectively.