url-parser
url-parser copied to clipboard
ghostery
✨ special treatment of file urls
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?
@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:///testfile:test->file://./test
What do you think?
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).