On Wed, Oct 31, 2012 at 9:27 AM, Mikko Rantalainen <[email protected]> wrote: > João Eiras, 2012-10-31 01:41 (Europe/Helsinki): >> In both Firefox and Chrome if you type file://aaa/some/path, or >> file://localhost/some/path, the aaa and localhost parts are ignored, and >> the rest of the path is interpreted as a local file path. In Opera, >> anything that is not localhost gives an error. > > How about following: > > (1) file://c:/foo tries to connect to server "c:" and request shared > entity "foo".
I think bz made it pretty clear we need to treat as if you typed "file:///c:/foo" (at least on Windows, my preference is all platforms). Not sure what the rules are exactly, but I believe they are if you have a single ASCII letter followed by ":" or "|". > (2) file://foo/bar tries to connect to server "foo" and request shared > entity "bar" I think we should stick for now to how it should be parsed. Interpretation is a different layer. So this would give host "foo" and path "/bar". E.g. on Mac it might well end up meaning that host does not matter and localhost is always used. I think we should not let that affect parsing or serialization however, because then we end up with platform-specific rules. > Some problematic URLs are still possible: > > (6) file:///foo/bar should refer to entity "/foo/bar" in > POSIX-compatible systems but I have no idea where it would map to with > windows-style drive letter naming at the start of the local path. It would probably not map to anything, but that's fine. Again, we want to treat parsing of file: URLs distinct from interpretation of file URLs. -- http://annevankesteren.nl/
