The default bug view has changed. See this FAQ.

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

RESOLVED WONTFIX

Status

()

Core
Networking: File
--
enhancement
RESOLVED WONTFIX
16 years ago
a year ago

People

(Reporter: Mr. Stan, Unassigned)

Tracking

Trunk
Future
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
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

Comment 1

16 years ago
dupe of bug 62851?
Whiteboard: DUPEME

Comment 2

16 years ago
Use 5 slashes and let me know if it works.
file://///server/directory/file

Comment 3

16 years ago
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
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Comment 4

15 years ago
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 ?

Comment 6

15 years ago
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.

Comment 7

15 years ago
-> file
Assignee: neeti → dougt
Component: Networking → Networking: File

Comment 8

15 years ago
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?

Comment 9

15 years ago
Sorry, missed to notice this was confirmed no longer than yesterday.

Comment 10

15 years ago
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).

Comment 11

15 years ago
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.

Comment 12

15 years ago
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

Comment 13

15 years ago
-> 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

Comment 14

15 years ago
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. 

Comment 15

15 years ago
*** Bug 152296 has been marked as a duplicate of this bug. ***

Comment 16

15 years ago
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:// 
?

Comment 18

15 years ago
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...

Comment 20

15 years ago
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

Comment 22

15 years ago
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..

Comment 24

15 years ago
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?

Comment 25

15 years ago
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>

Comment 26

15 years ago
No, this should not work, it violates our security manager rules. This is the
case for a very long time ... two years at least. 

Comment 27

15 years ago
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..

Comment 29

15 years ago
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.

Comment 30

15 years ago
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.

Comment 31

15 years ago
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.

Comment 32

15 years ago
*** Bug 152672 has been marked as a duplicate of this bug. ***

Comment 33

15 years ago
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.

Comment 34

15 years ago
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. 

Comment 35

15 years ago
[RFE] is deprecated in favor of severity: enhancement.  They have the same meaning.
Severity: normal → enhancement

Updated

15 years ago
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 "/")

Comment 36

13 years ago
see Bug 88293 for a WONTFIX about this issue

Comment 37

10 years ago
mass reassigning to nobody.
Assignee: dougt → nobody
Status: NEW → RESOLVED
Last Resolved: 16 years agoa year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.