102724 - "file://c:" problems on non-Windows systems

Status: VERIFIED WORKSFORME

(Core :: Networking: File, defect)

Description

[benc]

In Mac and Linux, Mozilla 0.9.4:

Type the first URL and observe the result:

file://c:/ -> file:///[c:]/

The "c:" examples result in a tree that shows "/", but does not draw 
directories as folders.

EXPECTED BEHAVIOR:
Should ignore the host contents and draw the same thing as "file:///".

(Note: file:/// works in Linux, but Mac is broken, hence the dependency on bug 
13607.)

The c: -> [c:] conversion is an illegal host, but that doesn't matter until bug 
70871 is fixed.
nn

Comment 1

[Doug Turner (:dougt)]

file urls are specific to the the system that they are running on.  Don't expect
them to be portable across os's.

Comment 2

[benc]

REOPEN:
I'm not saying this should work, I'm saying this shouldn't happen.

I agree. We should remove the code that does drive letter handling from
non-Windows builds.

Comment 3

[Andreas Otte]

I see

file://c:/ -> file://[c:]/

instead off

file://c:/ -> file:///[c:]/

on linux. That is okay. IPv6 code is happening there I think, not drive letter
handling. Drive letter handling is limited to WIN/OS2 builds, I'm pretty sure of
that.

Comment 4

[benc]

You are correct. More problems counting all these "/"s on my part.

I don't know much about IPv6, so if you think that is the correct conversion,
that part works for me.

However, when I look at the display of "file://[c:]/", Linux does not draw the
directories as folders (same problem as "file:///" in Windows). Mac draws the
same messed up result as "file:///" it normally does. (See bug 13607).

Comment 5

[benc]

Mac OS X, RC1: no response to "file://c:/"

Comment 6

[Peter Haight]

On my machine (FreeBSD - 1.0 branch build), typing in file://c:/ displays
exactly the same thing as file:/// which seems to be what is desired.

According to the URL RFC 1738, file://c:/ should get interpreted as the file on
the machine named 'c:'. If you want to be technical about it, Mozilla should
throw up an error if that file is requested on any machine not named 'c:'.
Assuming that it makes more sense just to ignore the host in file URLs then
Mozilla should show the path that comes after the host which in this case is '/'
and that seems to be what Mozilla does on my machine.

This has nothing to do with IPv6. The URL parsing code is correctly interpreting
file://[c:]/ as a file URL whose host name is [c:] and then the file opening
code just ignores the host name which makes sense to me.

I looked briefly at the Mac file opening code and it uses the exact same
function to parse a file URL and doesn't seem to do any wierd IPv6 stuff. 

benc: What build were you using for comment #4? file://[c:]/ and file:/// seem
to work fine for me on FreeBSD.

Comment 7

[benc]

For a while,  "c:" would be converted to "[c:]".

In retrospect, that might have been some now absent URLfixup behavior, which I
didn't realize when I filed.

I'll check Linux, and send this to URLbar, where it will probably become an
INVALID bug.

Comment 8

[benc]

RESOLVED/WFM:

Mozilla 1.1b, Linux - doesn't happen anymore.

peterh: would you like to VERIFY?

Comment 9

[Peter Haight]

VERIFIED:
Works for me on a 1.1 branch build.