Open Bug 1507354 Opened 6 years ago Updated 1 year ago

URL parser discards host for file: URLs

Categories

(Core :: Networking, enhancement, P3)

Product:
Core
Component:
Networking
Type:
enhancement

Tracking

()

Status:
ASSIGNED
Tracking Flags:
Tracking Status
firefox65 --- affected

People

(Reporter: loganfsmyth, Assigned: twisniewski)

References

(Blocks 2 open bugs)

Details

(Whiteboard: [necko-triaged])

Attachments

(2 files)

Bug 1507354 - better follow URL spec file protocol parsing and serialization, including the hostname field; r?kershaw
(deleted), text/x-phabricator-request
Details
Bug 1507354 - update WPT expectations; r?kershaw
(deleted), text/x-phabricator-request
Details
For example: > var url = new URL("file://host/path") > url.host > // "" > url.pathname > // "/path"
This is due to our URL parser.
Blocks: url
Component: DOM: Core & HTML → Networking
Valentin, can you take a look?
Flags: needinfo?(valentin.gosu)
Ugh, this is behaviour we've had since forever. While it's probably not hard to allow hosts for file URIs, I don't fully understand the security implications of doing that. We currently treat file URIs as LOCAL_FILE and potentially trustworthy. Allowing them to have a host kinda changes those assumptions. Putting this in the backlog for now. [1] https://searchfox.org/mozilla-central/rev/647b9eb1099e373e079e16f147f74f3d1d65eed3/netwerk/protocol/file/nsFileProtocolHandler.cpp#156
Flags: needinfo?(valentin.gosu)
Priority: -- → P3
Whiteboard: [necko-triaged]
Summary: DOM URL object silently discards host value for file: URIs → URL parser discards host for file: URLs

The URL spec is somewhat confusing on this point. §4.1 has a table showing the host can be a domain or IP address, and there's a lot of parsing logic in §4.4 talking about how to get the host part, and then §4.2 says

A URL cannot have a username/password/port if its host is null or the empty string, its cannot-be-a-base-URL is true, or its scheme is "file".

"file" isn't a particular protocol, so how are you supposed to talk to the remote host? Why can't it require auth or a non-standard port? RFC 1734 was pretty clear that if there was a host part it had to be one of a few synonyms for the local machine (see bug 376502). When did arbitrary domains get into the picture, and has anyone ever implemented that? I thought multiple implementations was a requirement for WHATWG specs?

After a quick look it appears Firefox and Safari simply ignore a host part, and Chrome considers it an error. I'm with Chrome on that one.

From a security POV it would be terrible to support it in today's browsers because too much code has made assumptions about "file:" meaning "local" since the earliest specs for the WWW.

Based on https://jsdom.github.io/whatwg-url/#url=ZmlsZTovL3Rlc3QvdGVzdA==&base=YWJvdXQ6Ymxhbms= both Chrome and Safari allow a host, Firefox does not. As I understand it this can be important on Windows.

Severity: normal → S3

Just FYI, RFC 8089 is a more current standards document that solely covers the file URI scheme. It is much more thorough and detailed compared to the relatively spartan explanation offered in RFC 1734 (which was limited to a single section).

This is the root cause of us failing lots of web platform tests for interop2023, based on the kinds of failures I'm seeing after bug 1347459 comment 6:

new URL("file://hi/path").protocol = "s" will keep the protocol as "file" as expected, but will drop the "hi" part of the URL and add a root slash: file:///path

I've put together a candidate patch which changes our behavior to better-match the URL spec and related url WPTs, which builds on top of the patch in bug 1347459 (passing 160 more WPT checks). I'll upload it ASAP for comments.

Assignee: nobody → twisniewski
Status: NEW → ASSIGNED

Depends on D183061

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: