3 ms·

(and yeah, file: URLs most have three but lets ignore that for now) I don't want to be nitpicky but actually a file url still has two slashes, the third slash

by merb 11y ago

(and yeah, file: URLs most have three but lets ignore that for now) I don't want to be nitpicky but actually a file url still has two slashes, the third slash is actually the root path i.e.: file:///home where the two slashes are slash-slash-colon and there third is actually the start of the path. (actually it just emit's the host) Actually there is one exception, but just ignore this widly 'unused' operating system which doesn't seem to care about posix and rfc's anyway.

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.

by merb 11y ago

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.