32997 - file URLs that include a hostname don't work

Status: VERIFIED FIXED

(Core :: Networking: File, defect, P5)

Description

[Braden]

Entering a URL of the form

  file://localhost/

in the URL bar only results in Mozilla changing the URL to be

  file:///localhost/

...which is very likely (but not necessarily) invalid (that is, nothing on the
system corresponds to this identifier).

Of course, <URL:file://localhost/> is the same as <URL:file:///>, and Mozilla
handles the latter just fine.

Comment 1

[Warren Harris]

=> andreas

seems low priority -- why would anyone bother to type in localhost anyway

Comment 2

[Andreas Otte]

Currently the urlparser assumes that there is no authority component within a
file url. It's always local, even a UNC-filepath is a path not a host/path
combination. So for the urlparser it's save to assume that localhost is a
directory, it has no other meaning in that context.

I will mark this one "invalid".

Comment 3

[Braden]

This bug is not invalid. <file://localhost/> is a valid URL, check RFC 1738.

The problem here is that <file://localhost/> is getting converted to
<file:///localhost/>. That is simply wrong. <file://localhost/> is properly
converted to <file:///>. Really, that's the other way around: <file:///> is just
a shorthand for writing <file://localhost/>. And note, furthermore, that
"localhost" can be replaced by the actual machine name.

Also note that Internet Explorer gets this one right.

Comment 4

[Andreas Otte]

I reread the rfcs. You are right, this is allowed, but we dropped that support
currently in favour of being able to handle some malformed uris the right way.
Otherwise parts of the file-uri-path have a tendency to end up in the host
component, which is really bad. 

I will do some thinking if we can handle this without loosing the ability to
handle the malformed uris ---> very low priority.

Comment 5

[Braden]

Changed summary to properly reflect the scope of this bug; this isn't just about
"localhost", it covers any hostname other than special case of a zero-length
string allowed for by the RFC.

I don't agree with the priority. Not only does Internet Explorer get this right,
but so does Navigator 4.x, making this a regression.

Comment 6

[Andreas Otte]

Attachment: patch to fix the localhost problem

Comment 7

[Andreas Otte]

Okay, okay see the above patch to handle the localhost problem. I will try to
get that reviewed. As for other hostnames, that is not working in 4.x either (at
least on linux) and part of that problem is handled in bug 19174.

Comment 8

[Braden]

Okay, cool. Yes, my mistake re. hostnames and NN 4.x. What it actually does for
<file://myhost/> is treat it the same as <ftp://myhost/>. Oops.

Reading bug 19174, it looks like this one might should be made a blocker for
that bug; if I understand 19174 correctly, it seems this bug report encapsulates
the critical issue there. However, I'm not entirely certain.

Comment 9

[Andreas Otte]

fix for the localhost part checked in.

Comment 10

[Andreas Otte]

Attachment: patch to get urlparser working with unc paths on XP_PC

Comment 11

[Andreas Otte]

Fix to get urlparser working with unc paths on XP_PC checked in. I don't think
that more can be done here. Getting mozilla working with unc paths on XP_PC
depends now on the conversion to nsIFile which is beyond the scope of this bug.

As RFC1738 says:

   The file URL scheme is unusual in that it does not specify an
   Internet protocol or access method for such files; as such, its
   utility in network protocols between hosts is limited.

I don't think that more network support on the file protocol is necessary.

Comment 12

[Braden]

Sorry, but this is still a bug. If mozilla.org doesn't think Mozilla should
adhere to the standard on this point, then the proper resolution is "WONTFIX".

But I don't think that's the right thing to do. If IE5 can do this, I don't see
why Mozilla can't. I understand--and agree--that this is a low priority. But I
don't think it deserves to fall of the radar completely.

Comment 13

[Andreas Otte]

What exactly does IE5 in this case?

Comment 14

[Andreas Otte]

The standards give no information on how to procede with a file url that points
to a different host. The file protocol is in my opinion local by definition,
whatever additional information is there, it has to be in the path (like UNC
paths). IE5 can't handle a remote file protocol too, it changes the protocol
silently to ftp (by your description). That is as good or as bad as not
supporting remote file protocol. BTW: The current implementation would make it
very hard to change the protocol on the fly.

Comment 15

[Braden]

(Sorry, the only Windows box I have isn't on the network, so I couldn't say
exactly how it behaved in all circumstances. It does seem to work with
"file://hostname".)

I think we may have a misunderstanding here on what this bug's about. I am *not*
proposing that we accept non-local file URLs. All I am suggesting is that if I
am on "mymachine.mydomain.com", and I have resource "somefile" at the top level
in the hierarchy, these three file URLs all work identically:

  file:///somefile
  file://localhost/somefile
  file://mymachine.mydomain.com/somefile

The first two of these are working in Mozilla. The third one is not. Fixing that
is what should close this bug.

It seems to me that if Mozilla can check for "localhost" as a special case, it
can check for "mymachine.mydomain.com" as a special case, too.

Comment 16

[Andreas Otte]

Ahhh ... okay now we are getting closer. Okay, I will take a look if there is an
XP way for us to get to the hostname or (that should work to) the IP-Address).

Comment 17

[Andreas Otte]

Attachment: allow hosts in nsNoAuthURLParser

Comment 18

[Andreas Otte]

What about this? We allow hosts in NoAuthURLParser (contradiction in itself!)
but only to ignore them. I have done a special case for XP_PC, where we try to
identify a drive and then assume there is no host. We loose the error guessing
feature on unix and mac so that file://home/ao is no longer assumed to be
file:///home/ao but as I remember the main problem was XP_PC where we should be
able to parse file:c:/path, file:/c:/path and file://c:/path correctly.

Comment 19

[Andreas Otte]

=> M17

Comment 20

[Braden]

Well, wouldn't that mean that "file://anytexthere/someresource" would work? That
doesn't seem right. There should only be three possibilities for the host:

 1. The zero-length string.
 2. "localhost"
 3. The fully-qualified machine name.

We have two out of three. And two out of three ain't bad, especially in this
case. I don't think #3 is worth fudging if we can't really get it right.

Comment 21

[Andreas Otte]

Yes, that would happen, at least as far as the parser knows, because it simply 
breaks down the URL into it's parts. The parser does not know what a valid host 
is and it don't has to. The file protocol then only uses the path-component of 
the URL, ignoring the host. Depending on an existing path on the *local* machine 
the file operation will succeed or not. This is also 4.X behaviour I think. 

Comment 22

[Andreas Otte]

fix checked in

Comment 23

[benc]

qa to me.

I'll create a test case and then verify.

Comment 24

[benc]

V