Closed Bug 107540 Opened 22 years ago Closed 7 years ago

file:// URL - convert 4 slash UNC's to 5 slashes (promote the servername w/ extra "/")

Categories

(Core :: Networking: File, enhancement)

Product:
Core
Component:
Networking: File
Platform:
x86
Windows 2000
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX
Milestone:
Future

People

(Reporter: edwardstanley, Unassigned)

References

(
URL
)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.5) Gecko/20011011
BuildID:    2001101117

If url format is file:////servername/dir/file.html Mozilla does not navigate to
the link. This format works in IE5.

Reproducible: Always
Steps to Reproduce:
1. Put url in page - format file:////servername/dir/file.html
2. Try to navigage to link
3.

Actual Results:  Nothing

Expected Results:  It should have opened link
dupe of bug 62851?
Whiteboard: DUPEME
Use 5 slashes and let me know if it works.
file://///server/directory/file
URL: http://file:////servername/dir/file.html → file:////servername/dir/file.html
Marking as duplicate of bug 62851

Reporter - if you feel this is incorrect, please reopen this bug with further
explanation.

Thanks for using bugzilla!

*** This bug has been marked as a duplicate of 62851 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Actually, this is not a dupe of the bug your marked...

If you paste the URL into the location bar, does it work?
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Reporter: Can you give us a feedback ?

We have many links on our internal company website using the
file:////server/a/b/c/ convention to access files on our network drives. 
mozilla seems to want file:///// (5 slashes) but IE and even the old netscape
accept 4 slashes.  

It seems that to access a local file, if you write file://D:/qtdocs/classes.html
for instance, (2 slashes) mozilla automatically changes it to 3.   so... when a
link specifies FOUR slashes for a UNC name, it would make sense if mozilla would
either expand it to FIVE slashes and check it like that, or accept the 4 slashes.

In our company's opinion, this is a bug, not a feature...  It's a bug that'll
cause us to not use mozilla and instead use IE or another browser than can do
the file:////server/a/b/c links.  it doesn't seem to be hard to fix - if there's
four slashes in the link, change it to 5 and try it.  just like you change 2
slashes into 3 for a local hard drive file. cmon!

I would really like to see this bugfix in the mozilla 1.0 release.  this is NOT
a duplicate bug (i checked the others that are claimed to be a dupe and its
not).  so would someone please fix this?????

thanks.
-> file
Assignee: neeti → dougt
Component: Networking → Networking: File
Since this bug was reported, a newer version of Mozilla (1.0 RC1) has been
released. Reporter, please can you check to see whether this bug is still 
present in a recent build (Moz1-RC1 or a new nightly build). If
this bug does not occur please can you resolve the bugreport?

Sorry, missed to notice this was confirmed no longer than yesterday.
This bug still occurs for me, using Mozilla 1.0rc1 on Windows 2000 [Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.0rc1) Gecko/20020417].

I tested the following (U being the network drive pointing to the network share):

file://u:/dir/file.pdf  -> opens the file
file://u|/dir/file.pdf  -> opens the file
file:////computer/share/dir/file.pdf   -> nothing happens
file://///computer/share/dir/file.pdf  -> opens the file

Even copying the URL w/ the four slashes in the location bar didn't help.
Mozilla does not do anything (not even giving an error).
Adapted Daniel's script to my server and used it both on IE and Mozilla, having
the same results. Moz tested: Mozilla RC1 build 2002042302 on W98.
Anders: what script?

we do what I call "drive promotion" of DOS drive letters out of the hostname
field. I don't know the history of this feature, but I know we do.

I've changed the subject to reflect your request for something like this in UNCs.
Summary: Won't pick up file from network drive → [RFE] file:// URL - convert 4 slash UNC's to 5 slashes (promote the servername w/ extra "/")
Target Milestone: --- → Future
-> NEW
As an RFE, this might be something that is done by URI fixup, and not anything
in necko...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: DUPEME
Hmmm ... I'm pretty sure we did this right at some point in time, should not be
that hard to implement this again, at least for the XP_WIN platform. 
*** Bug 152296 has been marked as a duplicate of this bug. ***
Using Build 2002061104
Changed the link in the HTML document to file://///server/etc, but mozilla did
not react in any way. Copied and pasted this line into the URL input. In this
case mozilla opened this file.
Werner Teichert: Do you load the html document also from file:// or from Http:// 
?

The document that contains the line "file:///// etc " is loaded from http:.

Werner Teichert: That can't work. See tools/Web Development/Javascript Console
YOu can't load a file:// URl from a Html:// url...

Sorry, I meant http:.
Netscape 4.7 seems to convert 5 slashes to 4 slashes.
The IE 5.5 displays it with 2 slashes.
Opera 6.0 displays it as 5 slashes but cannot open the file.

i mean Http:// :-)
You can only load file:// urls from documents that are also loaded via file://
You get a security warning if you try to load a file:// URL from a Http:// file

If this is forbidden, why do the other browser do it?
To make it clear, the "file:// etc" is a WORD document. The browser should start
WORD and load the corresponding document.
On the other hand I get no warning. So either the warning is missing (another
bug) or the browser does not do the right thing. I think it is a usual case that
a html page loaded by http: contains lines like "file://...". Otherwise it would
be a very severe restriction.
this should work : 
file:////test.html with a link to file:////
This doesn't work and you get a warning (in the JS Console): 
http://test.com/test.html with a link to file://..

The security blocking is already discussed in other bugs and we will not change
this..

We have an intranet in our company with an inhouse main page that is loaded by
http:. 
On the other hand we offer hundreds of documents for all departments to read
them over the intranet. These are all "file://" entries on dozens of html pages
also loaded by http:. 
Until now this worked fine, no restriction that a html page containing "file"
must be loaded by "file://".
If I have to load a html page containing links for "files" only by other "files"
how do I switch from the main page (http) to a "file://" loaded page?

To ask again:
The link in the following html source is not working when loaded by
"http://www.name_of_this_page" ?

<HTML>
  
  <HEAD>
    <TITLE>Blank</TITLE>
  </HEAD>
  
  <BODY>
    
    <P><A HREF="file:///E|/Documents/WORD/personal.doc">open WORD with this
document</A></P>
  </BODY>
</HTML>

No, this should not work, it violates our security manager rules. This is the
case for a very long time ... two years at least. 
As far as I remember we have this problem since Netscape 6.
It makes no sense to me, but if it so, then good bye Netscape and good bye mozilla.
Another IE user is born.

Werner Teichert:
You don't see this bug, please take the discussion in the newsgroups or on the
Mozilla.org IRC channels. (irc://irc.mozilla.org/#mozillazine)
see http://bugzilla.mozilla.org/show_bug.cgi?id=47988#c19 for more informations
change the pref in Mozilla\default\pref\all.js from
pref("security.checkloaduri", true); to false and it should work..

This security feature is controlled by a pref, so you can turn this off if you
want. If you have time, I strongly recommend you look at the reasons for this, I
think they are quite compelling.

I had created bug 122022, and left it in the file component as a mouse-trap for
these types of conversations...

Bug 84128 is the actual bug, which requests some user notification for this feature.
Thanks to all that discussed this "bug".
Turning this security feature off lets me load the "file:"´s again. 
We could have saved a lot of time when someone had told that earlier.
By the way, 5 slashes after "file:" will do it for the server name. Maybe you
should offer a switch in the preferences to turn this feature off or on.

I have submitted my comments regarding legitimate uses of file links in http
pages in bug 84128, so I won't repeat them here.

Here I did want to point out that five slashes after file: is, under some
circumstances, appropriate. According to RFC 1738, the correct syntax is:

file://server/path

or

file:///path

In the second case, the path is relative to the user's computer. If the user is
using UNC to specify the file (perhaps the file is on a server in an NT domain),
the path might be \\server\folder\file. But URLs must be specified with forward
slashes (when the browser passes the path to the local OS, it does so in an
OS-specific way, and may change the forward slashes to back slashes.)

So \\server\folder\file becomes //server/folder/file, and the whole thing
becomes file://///server/folder/file.

*** Bug 152672 has been marked as a duplicate of this bug. ***
ref comment 31.

Thanks for the explanation of file:///// 

From your comment, if <host>/<path> is UNC then it is relative to the local
machine, hence file://///

but RFC 1738 states:

   A file URL takes the form:

       file://<host>/<path>

   where <host> is the fully qualified domain name of the system on
   which the <path> is accessible, and <path> is a hierarchical
   directory path of the form <directory>/<directory>/.../<name>.

which would imply that if <host> is a FQDN then

   file://host.mydomain.com/path/to/file

should work, but it doesn't. Moz just does nothing (as it does with
file://host/path/to/file). NS4 and IE don't like it either (they both complain
that the file can't be found, even though it exists). The machine I tried this
on is in mydomain.com as well and I've set the prefs to not use the proxy for
mydomain.com. I've also edited all.js as per comment 28:

pref("security.checkloaduri", false);

This would suggest that Moz is not RFC1738 compliant.

Like Werner this is making Moz difficult to use on our Intranet where all the
links are file://host/path...., even though that is strictly incorrect.
But in file://host/path/to/file the host can only be localhost or your own
machine name, thus ignoring it should do the trick, because the file protocol is
by definition a *local* protocol. It is not possible to access files on a
different server (the protocol does not know how to access a different maschine)
unless you do a trick in the *path* and that is the UNC stuff, but it is done in
the path, not in the host part of the url. 

[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement
Summary: [RFE] file:// URL - convert 4 slash UNC's to 5 slashes (promote the servername w/ extra "/") → file:// URL - convert 4 slash UNC's to 5 slashes (promote the servername w/ extra "/")
see Bug 88293 for a WONTFIX about this issue
mass reassigning to nobody.
Assignee: dougt → nobody
Status: NEW → RESOLVED
Closed: 22 years ago → 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.