Reconsider fromBinaryFilePath support of UNC normalised device paths \\.\

[feltech]

I note that swift-url disallows construction of URLs from UNC file paths of the form \\.\, with an explanation in the code comments

  /// For instance, Windows UNC paths with the hostname "`.`" would be interpreted by the system
  /// as referring to a local device (e.g. `\\.\COM1`). These are not files, and creating such paths
  /// is prohibited by the ``FilePathFormat``.

However, from reading the Microsoft docs it looks like \\.\ is similar to \\?\

the DOS device path syntax, which is one of:
\.\C:\Test\Foo.txt \?\C:\Test\Foo.txt

but is subject to normalisation

Unless the path starts exactly with`\?\ [...], it is normalized

Perhaps the confusion comes from

If the path is a legacy DOS device such as CON, COM1, or LPT1 it is converted into a device path by prepending \\.\

I came across this because I'm in the middle of implementing a path<->URL converter in C++, and making use of the amazing giant JSON test case database (file_url_path_tests.json) from swift-url (thanks for that!).

[karwa]

Yeah, this is a bit of an arbitrary restriction, to be honest.

My recollection is that this was inspired by servo/rust-url, which intentionally blocks them (servo/rust-url#720). I asked why, but didn't get a response (perhaps nobody remembers). I'm open to revisiting this, certainly.

I came across this because I'm in the middle of implementing a path<->URL converter in C++, and making use of the amazing giant JSON test case database (file_url_path_tests.json) from swift-url (thanks for that!).

💜 You're welcome! I'm glad it's helpful for other projects. I tried to make it reusable, with half an eye towards maybe getting agreement on a specification one day (whatwg/fetch#1338)