- From: João Eiras <joaoe@opera.com>
- Date: Tue, 30 Oct 2012 23:41:30 -0000
- To: whatwg@lists.whatwg.org
On Tue, 30 Oct 2012 16:25:30 -0000, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Oct 29, 2012 at 4:24 PM, Boris Zbarsky <bzbarsky@mit.edu> wrote: >> On 10/29/12 10:53 AM, Anne van Kesteren wrote: >>> But at that point in a URL you cannot have a path. A path starts with >>> a slash after the host. >> >> The point is that on Windows, Gecko parses file://c:/something as >> file:///c:/something >> >> As in, it's an exception to the general "if there are two slashes after >> the >> "file:" then the next thing is a host rule. > > Thanks, I missed that. It seems however we could have that parsing > rule for all platforms without issue, no? After all, file://c:/ does > not parse currently on non-Windows platforms. > > >>> I suppose, I would hate it though for new URL(...) to depend on the >>> platform. >> >> I'm not sure there are great solutions here. :( > > Yeah, I'm willing to suck it up, but I would like to explore our > options before we go that route. > 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. I currently do not have Windows to test but I think I recall IE (or Opera?) opening file://server/share if there was a network share at \\server\share In a previous job I had, where the environment was a bit windows centric, there was a wiki with documentation with links to files on network shares. I recall the urls looked something like "file:\\server\some\path" in the HTML. IE opened the files (hence people continued to write them). The other browsers didn't. The point is that the file uri can and should have the authority part, or host, and that can be the local machine, or a network share.
Received on Tuesday, 30 October 2012 23:42:40 UTC