file: URL with a port number through the host setter

[SimonSapin]

When the Url::host setter is invoked for an URL in the file scheme, the parser starts in the "host state" (not the "file host state") so the URL can (per spec) end up with a non-null port number, which otherwise never happens.

In this test case: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=3927 Firefox doesn’t change the URL at all, Chromium changes the host but not the port number.

[annevk]

@achristensen07 Safari appears to allow for host:port somehow through the host setter for file URLs. Would you consider that a bug?

I tend to think we should fix this by making file URLs use the file host state.

[achristensen07]

This is indeed a bug in my implementation. I had overlooked the fact that file URLs can't have ports and used the same host-and-port parser for file URLs as non-file URLs. We should also add a test like "new URL('file://host:45/path')" and make sure it fails.

[achristensen07]

We should definitely either change this or allow file URLs to have a port. I'm not sure why Safari allows ports on file URLs

[annevk]

The other question is what the setter should do. Should we fail on ":" or just end tokenizing there (as hostname does). And setting host and hostname should probably do the same thing.

If we special case file URLs in host and hostname they'd end up failing on ":", but it seems Chrome just ends tokenizing there, which is somewhat different behavior.

[annevk]

To be clear, I don't have strong opinions here on what is best. Allowing ports to end up in file URLs doesn't seem to be the end of the world, nor would failing on ":" be.

[annevk]

@sleevi do you have any thoughts here?

[annevk]

Note that Firefox doesn't appear to allow setting the host of file URLs at all.

[jasnell]

This is a bug in the Node.js implementation also. I'll get it fixed.
nodejs/node#10608

[jasnell]

Thinking it over a bit, the spec should likely be updated to treat specifying a port for the host in a file URL as an error. Parsing a URL such as file://example.net:81/foo or setting url.host = 'example.net:81' should likely throw.

[sleevi]

@annevk File URLs & ports/authority has a storied history in Chrome... attached are my notes from the last time I dug into this, to at least hopefully explain the behaviour to figure out where to align:

Can "file" have a host?

RFC 3986 Section 3.2.2 notes (in passing) that

For example, the "file" URI
scheme is defined so that no authority, an empty host, and
"localhost" all mean the end-user's machine, whereas the "http"
scheme considers a missing authority or empty host invalid.

If we dig back to RFC 1630, Page 18:

There is clearly a danger of confusion that a link made to a local
file should be followed by someone on a different system, with
unexpected and possibly harmful results. Therefore, the convention
is that even a "file" URL is provided with a host part. This allows
a client on another system to know that it cannot access the file
system, or perhaps to use some other local mecahnism to access the
file.

and

A void host field is equivalent to "localhost".

Can "file" have a port?

RFC 1738, Section 3.10, which updates RFC 1630 (and became the basis for RFC 3986) notes the file scheme as:

A file URL takes the form:
file:///

Unlike other schemes (such as prospero or wais), which explicitly list the :<port> construction in their ABNF, file:// lacks this.

So to what Chrome's behaviour is:

• When canonicalizing a file:// URL, our canonicalizer constructs it in the form of file://<host>/<path>?<query>#<ref> ( https://cs.chromium.org/chromium/src/url/url_canon_fileurl.cc?rcl=0&l=88 ), meaning ports (and the colon) are always omitted when reserializing a file URL (and if host is empty, an empty authority component, resulting in the expected file:/// triple-slash)
• When parsing a file:// URL, setting aside the 'windows' special logic (and the UNC path logic), our parser always ignores the port ( https://cs.chromium.org/chromium/src/url/url_parse_file.cc?rcl=1483532378&l=45 )
• file: schemed URLs always result in a PORT_UNSPECIFIED for the effective port, meaning it should not end up serialized

To your question about what's the right behaviour: I suspect failing on : would probably be ideal, but I wouldn't be in a place to change anytime soon, simply because I don't have the time to own any fallout/regressions that it might cause (however unlikely). It might be one of my colleagues can own this, if it's believed to be important for compat. Not allowing port is definitely a good thing (... and seems like it'd require no work on Chrome's side, since that's what we do).

Allowing ports on file URLs seems to have the largest back-compat issues, at least re: spec precedent - it's seemingly long been forbidden - and it's also something probably unlikely for Chrome, if only because that would require a lot more monkey-ing about with the UNC & drive-letter sniffing logic.

[annevk]

@sleevi if you do file://y/.hostname = "x:123" in Chrome you get file://x:123/. So the issues you allude to might already occur.

[annevk]

Using "file host state" as override is not a good idea as it doesn't really deal with the possibility of being a state override well.

Since a file host can be empty, setting to the empty string should work as well I guess if we care about making this fully functional...

[sleevi]

@annevk I'd be happy to treat that behaviour as a bug and see about fixing it in Chrome, if only because what the URL API exposes, the underlying implementation won't preserve (e.g. if you copy the object or send it across IPC boundaries, it will serialize/reparse differently)

[annevk]

I ended up finding quite a few issues while working through this. I hope I addressed them all in the PR. Have yet to write test coverage for all that.