571846 - server name stripped from "file://" URI

Status: RESOLVED DUPLICATE of bug 88293

(Firefox :: General, defect)

Description

[David]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9.2.3) Gecko/20100401 Firefox/3.6.3

Upon displaying a link to a local (LAN) resource using a "file://" URI, Firefox completely strips the server name from the URI. The resulting URI looks like a "localhost" URI. Example:
A link to "file://myserver.mydomain/test.html" is displayed and interpreted as "file:///myserver.mydomain/test.html"

This has two visible effects:
1- an incorrect link is displayed in the status bar (server name missing)
2- when using the "Copy link location" item from the contextual menu, the link is also copied to the clipboard without the server name, making it impossible to open the link e.g. in the Windows Explorer. 

This problem occurs both on Mac OS X 10.6 with FF 3.6 and Windows XP SP 2 with FF 3.6.3. It also occurs both on pages loaded over HTTP and on local files (file://...)

NB: the link is alright in the source code

Reproducible: Always

Steps to Reproduce:
1. create a page with a local link e.g. "file://myserver.mydomain/test.html/"
2. open the page in FF 3.6 (either through a webserver or simply locally)
3. copy-paste the link or hover on it using the mouse and check the status bar
Actual Results:  
The complete name of the server is missing 

Expected Results:  
The link shouldn't be modified. 

Firefox already enforces security by not opening the link upon clicking. It shouldn't modify the actual URI, thus making it much more cumbersome to actually get the full address (requires looking into the source code etc)

This is especially annoying in a corporate environment where files in the local network may be linked from e.g. a wiki system or a search engine or whatever. Not being able to open the files with one click is one thing which most users can live with, being denied any kind of access to this information is quite another thing.

Comment 1

[David]

interestingly, inserting additional slashes in front of the server name "solves" this problem, e.g. 
file:////myserver.mydomain/test.html
is displayed/interpreted as such. this may be used as a workaround for e.g. enabling copy-paste on windows. 
i'm therefore setting the severity to "normal"

Comment 2

[Radek 'sysKin' Czyz]

Those "extra" slashes are necessary because server name needs to start with two slashes. So the components of url are:
file:// <- protocol
//servername <- server
/test.html <- path on server

Comment 3

[David]

Although I'm not an expert, I beg to differ. "Extra slashes" are tolerated, but not required. Only UNC paths require two backslashes before the server name. 

AFAIK the format for a URI using the "file" protocol is exactly the same as that for e.g. one using the "http" protocol:
http:// <- protocol + separator
bugzilla.mozilla.org <- server + domain
/show_bug.cgi?id=571846 <- path on server

Even if those slashes *were* required in order to properly identify a server, that would be no reason for firefox to simply strip the name from the URI...

Comment 4

[Artyom]

I think there is a typo in the original description of this bug. At least I see the following:
When I hover the cursor over link
<a href="file://host/directory/file.txt">file.txt</a>
status bar shows
file:///directory/file.txt
"Copy link location" copies invalid link. And event "Save page as..." saves the page with corrupted link.
In my case the host is stripped for real.
Needless to say this link doesn't open.

Mozilla/5.0 (Windows; U; Windows NT 6.1; ru; rv:1.9.2.7) Gecko/20100713 Firefox/3.6.7 ( .NET CLR 3.5.30729; .NET4.0E)

Comment 5

[Konrad Grajwoda]

Problem valid for FF 3.5 as well.

Problem is within rendering engine (when you watch the page source the URL is correct.

Comment 6

[Cork]

file is meant to open local files; normally it doesn't know about "servers" at all.

the exception is when you have unc servers in windows where you specify:

file:// to access the local file system
\\servername becomes //servername
followed by the path /my/part/test.html

If you would have file://servername/my/path/test.html you would leave mac and linux out in the cold as these systems doesn't have drives and file:// would be the root of the system.

By this fact i resolve this bug as invalid; as the slashes are needed for cross platform support.

Comment 7

[Joerg S.]

I believe the standard that file:// URLs have to confirm to is RFC 1738 ^1 which rather clearly states "A file URL takes the form: file://<host>/<path>".
The missing host part is a special case. Therefore file:// is not the root of the local host's filesystem but file:/// is. (i.e. file:///etc/passwd or file:///c:/windows but file://remote.host/etc/passwd).

Adding UNC paths with double slashes for Windows is not a good idea as it clearly violates the standard.

Unless I'm wrong about RFC 1738 being the governing standard, could you please re-evaluate the issue?

(In reply to Cork from comment #6)

^1: http://tools.ietf.org/html/rfc1738#section-3.10

Comment 8

[Olaf]

(In reply to Joerg S. from comment #7)

I think you are absolutely right with your interpretation of RFC1738. In fact i actually wonder what is to misinterpret about that. 

At the moment FireFox is clearly violating that standard. Currently only hacks in HTML like "file:////server/path" can prevent Firefox from crippling file URLs (cutting out the host part)

Since additionally we're talking about the conversion of UNC path, this part is described here.
http://blogs.msdn.com/b/ie/archive/2006/12/06/file-uris-in-windows.aspx


Please reopen this issue, otherwise i'm going to create a new one.