3 ms·
Actually, no. From RFC 1738, Section 3.10: A file URL takes the form: file://<host>/<path> where <host> is the fully qualified domain name
by phluid61 10y ago
Actually, no. From RFC 1738, Section 3.10:
A file URL takes the form:
file://<host>/<path>
where <host> is the fully qualified domain name of the system on
which the <path> is accessible, and <path> is a hierarchical
directory path of the form <directory>/<directory>/.../<name>.
And then in Section 5 (the BNF):
... elements may be preceded
with <n>* to designate n or more repetitions of the following
element; n defaults to 0.
fileurl = "file://" [ host | "localhost" ] "/" fpath
fpath = fsegment *[ "/" fsegment ]
fsegment = *[ uchar | "?" | ":" | "@" | "&" | "=" ]
So that first slash isn't part of the path, and the path starts with a directory name. The fact that the root directory in a UNIXy environment doesn't have a name (or has a zero-length name) is a source of much confusion. (Nobody would accept "file:////etc/passwd" as a URL, but that's how I read the spec.)
This is also why Firefox insists that there are five consecutive slashes when encoding a UNC string (a Windows/Samba share path, like "\\server\share\path\to\file.txt") into a URL (e.g.: "file://///server/share/path/to/file.txt")
And let us not even begin on the fact that file: URLs are specified in an "obsolete" spec, and explicitly allow characters in the path that are disallowed by RFC 3986. I'm working on fixing that [https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme https://tools.ietf.org/html/draft-ietf-appsawg-file-scheme] but it takes time.