- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Wed, 31 Oct 2012 14:52:01 +0100
- To: Mikko Rantalainen <mikko.rantalainen@peda.net>
- Cc: whatwg@lists.whatwg.org
On Wed, Oct 31, 2012 at 9:27 AM, Mikko Rantalainen <mikko.rantalainen@peda.net> 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/
Received on Wednesday, 31 October 2012 13:52:30 UTC