Closed Bug 32997 Opened 20 years ago Closed 20 years ago

file URLs that include a hostname don't work

Categories

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

x86
Linux
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: braden, Assigned: andreas.otte)

References

()

Details

(Keywords: testcase)

Attachments

(3 files)

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.
=> andreas

seems low priority -- why would anyone bother to type in localhost anyway
Assignee: warren → andreas.otte
Target Milestone: --- → M15
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".
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
Priority: P3 → P5
Target Milestone: M15 → M20
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.
Summary: file URLs that explicitly include "localhost" don't work → file URLs that include a hostname don't work
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.
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.
fix for the localhost part checked in.
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
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.
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
What exactly does IE5 in this case?
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.
(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.
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).
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.
=> M17
Target Milestone: M20 → M17
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.
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. 
fix checked in
Status: REOPENED → RESOLVED
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
qa to me.

I'll create a test case and then verify.
Keywords: verifyme
QA Contact: tever → benc
V
Status: RESOLVED → VERIFIED
Component: Networking → Networking: File
Keywords: verifymetestcase
You need to log in before you can comment on or make changes to this bug.