Closed Bug 107540 Opened 24 years ago Closed 9 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: 24 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: 24 years ago → 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.