Windows drive letter uppercasing

[annevk]

Chrome uppercases the Windows drive letter (only on Windows) as part of its file URL parsing. No other browser engine, including IE6, IE8, IE10, and IE11, seems to do this. However, there is something to be said for doing this as the letters are supposed to be case-insensitive and we already perform some normalization.

A prerequisite should probably be Chrome successfully shipping this on all platforms.

[alwinb]

I found that IE and Edge actually lowercase the drive letter, and then incorrectly stick it to the host, e.g. file://somehost/C:/test becomes file://somehostc:/test.

Also it seems that Chrome on Mac does not support drive letters at all but treats them as ordinary path components.

[annevk]

FWIW, IE6 at least does not appear to do that (neither lowercasing nor making it part of the host), but I have observed making it part of the host in newer versions, indeed. And yeah, Chrome has a lot of Windows ifdefs unfortunately.

[annevk]

It seems Chromium has at least (partially?) been moving away from this: https://chromium-review.googlesource.com/c/chromium/src/+/2870630.

[alwinb]

How does chromium on windows canonicalise e.g. file:///./C| currently?

The linked discussion mentions:

Currently it only recognises drive letters appearing at the start of the path, optionally after a block of slashes.

That would suggest that it canonicalises to file:///C| which is also not canonical, similar to the problem that this commit tried to solve.

[domenic]

https://jsdom.github.io/whatwg-url/#url=ZmlsZTovLy8uL0N8&base=YWJvdXQ6Ymxhbms= on Chrome on Windows shows it matching the standard, with an output of file:///C: (protocol file:, pathname /C:).

Feeding that output back in is idempotent, so at least that case is not problematic. I'm not sure whether any non-idempotent cases remain, now that https://bugs.chromium.org/p/chromium/issues/detail?id=1083031 is closed.

[annevk]

Given that Chromium essentially reverted this and no other browser has this behavior either, closing this particular issue.

[domenic]

Chromium still uppercases drive letters...

[annevk]

Ah, I misunderstood. I guess it still does it when the drive letter occurs at the start.

[alwinb]

In what situations does it capitalise drive letters? Wouldn’t capitalising drive letters at the start incur the same problem?

There may be another solution that aligns well with chromium’s implementation.

• Drive letters would be recognised only at the start of the path. They can be normalised to upper case. (This is what chromium did till at least recently).

• The troublesome file:///foo/../s: and file:///./s: can be canonicalised to the latter. The ./ prefix then ensures that the s: part is interpreted as an ordinary path component and not as a drive letter.

  If that’s confusing to the eye then the colon can (also) be percent encoded.

Nb. There are only two test cases in WPT that disagree with that approach.

I don’t think it would be very hard to implement in the standard’s parser, nor in chromium, from what I’ve seen.

However, I do not know how \foo\..\S:\ as a file path is interpreted on windows. If the S: part is interpreted as the drive letter, then it makes sense to do that in the standard as wel.