✨ special treatment of file urls

[m0ppers]

I want relative file: urls in my application which are not allowed as per spec so I started searching for alternative implementations.

this parser ALMOST worked. I added what was missing for my usecase. Not sure what you think? Is it worthwhile to support it? do you even want an explicit divergence from the spec?

[chrmod]

@m0ppers very interesting case, thanks for raising it up!

It's unclear what's the best way to move but I think we should strive for correctness and unambiguity.

After looking at Wikipedia article on File URI scheme, URL Standard and your examples, I think we may want to support URLs like file://hostname/file but others may be problem as it is unclear how they should be interpreted.

Both other URLs fail the URL Standard due to an error special-scheme-missing-following-solidus, which could be avoided with different representation:

• file:/test -> file:///test
• file:test -> file://./test

What do you think?

[m0ppers]

thanks for getting back. yes I think you are right. I find the urlspec very difficult to read and I found https://www.rfc-editor.org/rfc/rfc8089#appendix-F which lists a few other possibilties to denote file urls and I liked it :)

Personally I find the authority stuff in file URLs super strange. I am not sure if there is a single implementation that will be able to resolve an URL like file://hostname/test to an actual file.

I am ok with using the WHATWGish approach (i.e. file:///test). however I am unsure if it is really a good idea to use file://./test (. could be interpreted as a hostname making it ambiguous. that is why I liked the RFC approach - they also do not allow relative file URLs but there is no ambiguity there imho).