On Tue, 30 Oct 2012 16:25:30 -0000, Anne van Kesteren <ann...@annevk.nl>
wrote:
On Mon, Oct 29, 2012 at 4:24 PM, Boris Zbarsky <bzbar...@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.
