url.resolve() behaves differently depending on the protocol of the base url

[rolinh]

• Version: v4.5.0, v6.7.0
• Platform: Linux 3.16.0-76-generic x86_64, Linux 4.7.6-1-ARCH x86_64, FreeBSD 10.1-RELEASE-p26 amd64
• Subsystem: url

The url.resolve() function behaves differently depending on the protocol given in the from parameter.
See this example:

> var url = require("url");
undefined
> url.resolve("https://foo.tld", "bar");
'https://foo.tld/bar'
> url.resolve("wss://foo.tld", "bar");
'wss://bar'
> url.resolve("ftps://foo.tld", "bar");
'ftps://bar'

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.

[bnoordhuis]

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.

[rolinh]

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.

[fhinkel]

Assigned to myself as placeholder for @minervapanda

[minervapanda]

According 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.

[rolinh]

@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.

[minervapanda]

Thank you for the clarification @rolinh . I was confused ,the example seemed correct.I will make a PR to update the documentation.Thanks.

[danbeam]

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 funky chrome:// URLs (the settings page lives at chrome://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.html if that wasn't clear. And yes: a slash at the end of from and not at the beginning of to does 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 KURL from chromium? This is the technology behind the URL constructor exposed to DOM.

/cc @arv as an FYI

[jasnell]

The current direction is to leave the existing url.parse() and url.resolve() behavior as is and focus efforts into the new WHATWG URL implementation 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.

[TimothyGu]

@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.

[Trott]

This 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.