Re: [whatwg/url] Are drive letters always invalid? (#612)

> The Writing section suggests that drive letters are allowed in file URLs only if they do not have a host.

I'm not sure if that is correct. Of the 4 kinds of paths Windows supports (yes, really), one of them is DOS device paths, for example: `\\.\C:\Windows\`. Since it has the same format as a UNC path, I wouldn't be surprised if some systems turned that in to `file://./C:/Windows/` (i.e. a hostname which is a single dot). Sometimes, it's the only way to refer to locations on disk (e.g. if you need to refer to a folder named "con", which is otherwise reserved for legacy reasons).

> Maybe the idea is that e.g. file:/c:/etc/ has a drive, whereas file:c:/etc/, file://c:/etc/ and file:///c:/etc/ do not. That makes sense as a way to disambiguate drive letters from path components that 'look like' drive letters. But the parser/resolver does treat the c: part as a drive letter in all of them.

The latter 2 URLs certainly _do_ have drives. The version with 2 slashes was used by legacy software that basically [just stuck `file://` at the front of a DOS path](https://web.archive.org/web/20130116070556/http://blogs.msdn.com/b/freeassociations/archive/2005/05/19/420059.aspx), and the version with 3 slashes is considered the modern way to express a Windows path as a file URL (it's what the Windows system APIs will give you, for instance). It's likely valuable to support the version with no slashes as well (`file:c:/etc`), given that Windows paths do not begin with a leading slash like POSIX paths do.

I don't think it's worth trying too hard to disambiguate drive letters from path components that look like drive letters. There are obviously some trade-offs that need to be accepted when trying to represent both Windows and POSIX paths in a single format.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/url/issues/612#issuecomment-861461446