66194 - file:// Correct URLs w/ UNC have *5* slashes

Status: VERIFIED WORKSFORME

(Core :: Networking: File, defect)

Description

[chatterj]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20010121
BuildID:    2001012120

file:\\hostname\resource URLs do not work....no symptoms at all, nothing
happens.  If the same URL is typed in the URL field at the top of the browser,
the hourglass symbol appears, and then mozilla simply freezes (requiring killing
of the process with Task Manager).

Win-NT is 4.0 with SP5.

Examples

Reproducible: Always
Steps to Reproduce:
Have some machines in a Win-NT domain.  Share some directories on those
machines.  From one of the machines launch Mozilla and try to access files in
the shared directories.

file:\\machine1\dir1\file1
file:\\machine2\dir2\file2

Actual Results:  No response at all.  No error messages.

Expected Results:  The referenced dir or file should be displayed in the browser

Sometime URLs are also specified as file:\\\\hostname\dir\file
This doesn't work either.
Both forms work fine on Netscape-4.x and earlier as well as IE.

Comment 1

[Matthias Versen [:Matti]]

This bug is related to bug 56923.

I can confirm this bug with win2k build 2001011308.

Comment 2

[Stephan Niemz]

Maybe this is a dup of bug 19174, but then that one should be reopened.

I also have an internal web page which has a file://server/dir/file.html link.
It works in IE, but not in Mozilla.

Comment 3

[Prisacari Sergey]

Duplicate of http://bugzilla.mozilla.org/show_bug.cgi?id=62851

Comment 4

[Jesse Ruderman]

The freeze may be related to bug 38643, but I don't think this is a dup of 
38643.

Two things to try:
- use / instead of \.
- use a different number of slashes (I thought the number was 5).

Comment 5

[Asa Dotzler [:asa]]

over to Component Networking: File for triage.

Comment 6

[Kelson]

This happens on my NT system as well, with forward slashes instead of backslashes.

Oddly, it only freezes when it's a valid path.  If the server doesn't exist, it
just ignores the input.

Comment 7

[srini]

Problem also seen with 
- using / instead of \.
- using a different number of slashes (ie 5).

Tested on Mozilla/5.0 (Windows; U; WinNT4.0; en-US; 0.9) Gecko/20010305

Files can be loaded by clicking a link ex <a href="file:///C:/test.htm">file on 
the pc</a>  when the file is on local directory but this does not work when the 
file is on the web server and the anchor tag is clicked.  Nothing happens in 
the latter case.

Comment 8

[P. Damian Cugley]

I have a web page locally that has links to files available on the local 
network (via SMB, since this is a Windows netowork).  
I've tried file://HOST/share/path and file://///HOST/share/path , 
both of which work in Microsoft IE, and neither
of which work in Mozilla 0.8.  On the other hand, file:////HOST/share/path
works in Mozilla 0.8 but not MSIE.  What's more, it gets converted to
file:///// in the Location box -- a URI that will not work!

I'm pretty sure it used to work (i.e., this is a regression).


Here's my opinion, for what it's worth: this file:/// nonsense has got to stop.

According to RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax,
generic URIs fall in to two cases:

  scheme://authority/abs_path
  scheme:/abs_path

Where authority is user:passwd@host:port and abs_path is 
elements separated by slashes. 

It seems plain that the former should be mapped on to "the file abs_path
on the computer specified by authority, using the conventions of the
local operating system".  On Windows' SMB-based networks, this translates
as a file share exported by the computer specified by the authority part.  
The abs_path must have at least one element; the first element is used
as the share name, and the balance to specifiy a file within the share.
Thus file://BIGSERVER/engfiles/rfcs/rfc2396.txt

Equally plainly, the second format refers to a file on the local computer.
On systems that have more than one file-system root (e.g., Windows),
the first element in abs_path specifies the root.  On windows systems,
this will be a drive name (letter plus colon).  There is no need to
encode the colon; there are not special in URI paths.  Thus 
file:/C:/rfcs/rfc2396.txt .  

Windows also allows volume-relative file
names, like \rfcs\rfc2396.txt ; these become file:/rfcs/rfc2396.txt .
When fetching the file, a Windows program will need to examine the first
element to see if it is the name of a volume or not.

In each case the directory name of the file is formed from the path elements
except the last, jouned with the local file-name-element separator
(on Windows, \).


The form file:///foo presuambly became popular because URI parsers did not
understand the local form of file: URIs, and instead encoded local file names
as if they were network files on a host whose name was the empty string.  Why?
I guess an earlier version of the RFC required this by mistake.

The form file://///HOST/share/ is then a network file URI which is really
a local file (because the authority part is missing) which is really
a network file (because it starts with two slashes).  Isn't this peverse?

My suggestion, for what it's worth, is that, while Mozilla MUST 
allow for the multi-slashie forms of URIs for backward compatibility, 
once it has found a real file, it SHOULD canonicalize the URI so it
starts with either one or two slashes.

In file URIs only, backslashes should trigger a parser that groks Microsoft's
file name formats and generates a form using slashes.  

Comment 9

[dthiede]

I have seen the no action portion of this bug on Linux. Clicking on a link that
is in a file:// form produces no result. Using the "copy link location" on the
link popup menu, pasting it into the URL box then pressing return will load the
page. I have seen this problem with all of the mozilla versions that I have
tested including the latest 0.9 release.

Comment 10

[Doug Turner (:dougt)]

I changed it so that "file:\\hostname\resource" does not work. You must use 
something like "file:\\\\\hostname\resource"  

There is another bug about prompting when a file:// location does not exists.

Comment 11

[timeless]

*** Bug 83310 has been marked as a duplicate of this bug. ***

Comment 12

[Chris Hiner]

*** Bug 85147 has been marked as a duplicate of this bug. ***

Comment 13

[hachez]

Just a comment about this very annoying bug.

There is a big discussion about the way the location should be encoded.
Nice, interesting, intellectual, ... But people do not care about that. 

When people try to open such file, they usually do not type the location, they 
use the file open box or double click on a file or use a drag and drop. 
That is the only thing people want whatever the chosen encoding rule.

I am bit worried because this bug is marked as WONTFIX. How is it possible to
leave it unfixed as there is no way to open these files with Mozilla. 
As I need to access to such files, I must use another browser Netscape, IE,
Opera, ... that open correctly those files.

Comment 14

[Johan Walles]

I agree with hacez.  This bug makes it impossible to send e-mail with
attachments coming from a non-mounted network share.  Just like hacez described,
I was hit by this when using a file requester.  The workaround for the e-mail
attachment problem is to move the files somewhere else before attaching them,
but that is extremely non-obvious (took me a couple of days to figure out)
because of the very weird error reporting from the mail program.

Can we at least have an explanation to *why* this is marked WONTFIX?

Comment 15

[Doug Turner (:dougt)]

Maybe I mistook something.  I marked this as won't fix because I changed the
semantecs of the file scheme.  Now, like some/most browser, you have to use 5
slashes: file://///server/path.  Paths like file:///server/path will not work. 

Are you unhappy with this change?  Can you access remote servers using the a
file url that contains 5 slashes?  If so, why can't you send a url like this via
mail?

Comment 16

[chatterj]

I am reopening the bug. No, five slashes doesn't make it usable (maybe it does
for the email attachment issue, but not for the reason I opened the bug
originally). I am a Unix fan, and I try to stay away from MS-products and
MS-specific issues every chance I get. That's why I am using Mozilla! But that
personal preference and all other philosophical arguments about whether one
should use file://hostname/file URLs or not aside, the fact is there are MANY,
MANY corporate intranets which have a large number of shared-NT servers and
thousands of HTML pages that provide URLs in that form. It is a bit
presumptuous to assume that all those pages will be changed because Mozilla
won't support that form of URLs, particularly since IE obviously does it and
NS-4.x did it just fine!

Comment 17

[JD Brennan]

I agree with chatterj. I'd prefer to use Mozilla on my W2K box
at work, but if I can't browse half the web pages on our intranet,
then I won't be able to use Mozilla.

Comment 18

[Doug Turner (:dougt)]

I am having a hard time understanding what the root of the problem is:

1. mozilla is not converting the wrong kind of slashes
2. mozilla needs too many slashes
3. mozilla UNC file loading is busted.

If it is (1), too bad.  '\' as directory seperators is just wrong.  DOS bites.

If the problem is (2), I am not sure that I will be fixing it.  Here is the 
problem.  Suppose you run across a bad file:// path.  On win95/98, since there 
networking resolution is slow, you will hang for a few minutes.  This kills 
mozilla's responsiveness and most people just force exit the app.  So, local 
files are referenced by file:///C|/foo and unc paths are referenced by 
file://///server/foo.  Network resource can't be loaded via mozilla because some 
how you are getting a file url that looks like: file://server/foo?  

If the problem is (3), I will investigate.

Comment 19

[Johan Walles]

Chatterj: Thanks for re-opening.  I don't know when your file:///// patch went
in, but as of Mozilla 0.9.1 sending attachments from non-mounted network shares
is still broken, just as opening files in the browser using File/Open File. 
That may or may not be related to this bug.

Otherwise, the mail problem is covered by bug 55594 (which should possibly be
marked as being blocked by this bug).

Comment 20

[Doug Turner (:dougt)]

opening files in the browser using File/Open File shouldn't be broken.  I just 
used it... 

Comment 21

[JD Brennan]

In Response to Doug T.  The problem is 1) and 2).  If Mozilla is
mostly for UNIX, then it doesn't matter, but if Mozilla is intended
to be a viable option on Windows, than it needs to deal with 
file://host/share and file:\\host\share
The academic arguments that those are not valid URIs don't matter.
They exist in web pages and IE deals with them, so if Mozilla
doesn't deal with them, then we'll be forced to use IE - which is
would be ashame.

The argument that invalid UNC paths cause the browser to hang is
interesting.  How come IE doesn't hang on bad UNC paths?  It must
be possible to deal with them intelligently if IE does.

Comment 22

[Johan Walles]

The bug that should be blocked by this one is 55591, not the one with a similar
number that I mentioned before.  Sorry.

Also, bug 8684 should also be marked as being blocked by this one.

Comment 23

[hachez]

I disagree with Doug. The File/Open dialog box does not work on 
non-mapped network drives.
I just tried with Mozilla 0.9.1 and nothing happened. 

Comment 24

[Doug Turner (:dougt)]

I take that back. File/Open does not work if you are opening something via the 
"Network Neighborhood".  

Comment 25

[Andreas Otte]

The file protocol is by definition a "local" protocol. Although there is an
authority part in the file-url-syntax it makes not much sense and consequently
the file protocol does not define any way to access a file that is not located
on a local filesystem.

The only valid authority for a file url is localhost or the local server itself
which can be ommitted, so file:///path is absolutly fine and in no way perverse.
Currently necko simply drops an authority component inside an file url if one is
detected.

Much later appeared OSes which allowed the handling of file access over the
network without mounting the file system into the local filesystem. To access
these files UNC filepaths are used. I would like to direct the attention to the
word *path*. Whatever happens with network access inside file-urls is part of
the path-component of the url. The authority is still localhost, the local
server or missing.  

By definition the path component of file urls start with a /, so whatever UNC
filepath is used, the file-url starts with file:/// or file://localhost/ and
then comes the UNC-path, may it be written as \\server\path or //server\path or
//server/path or whatever.

After going through the urlparser, being disected and put together again this
adds up to five slashes in the url, the first three being part of the file url
syntax which leaves the last two as part of the UNC filepath.

It is up to the part of the code that handles local file access to deal with UNC
filepaths and make the right (network) connections. This is highly OS depended.
If this part is broken it should be fixed. (seems to be broken...)

Necko uses a special urlparser for non-authority urls. This parser deals better
with the common mistypings of file urls than the standard url parser. Also this
parser contains some OS dependend stuff, like (on windows) trying to figure out
if the path starts with a drive and if not assuming it to be a UNC filepath and
adding the right number of slashes. This is nearly impossible on unix because
there are no drives ...

This worked fine the last time I checked but I haven't build on windows in a
long time. 

There is however one exception: When the file url looks exactly like
file://server/path the server is taken as authority and then dropped. Some time
ago we changed the behaviour from patching up this type of urls with three
slashes to dropping the server. There are some bugs about this somewhere in
bugzilla ...

So in my opinion this issue adds up to:

1) Checking (and if necessary fixing) the handling of UNC-filepaths on the OS
depended parts

2) The File/Open-Box should give something back to the urlparser which fit the
given rules for file urls with the one exception above.

3) Thinking again about the handling of file://server/path 

Comment 26

[Doug Turner (:dougt)]

what is milestone "mozilla1.0" anyway?  Moving to future.

Comment 27

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 91327 has been marked as a duplicate of this bug. ***

Comment 28

[benc]

-qawanted - finally here, really behind on bugmail.

What is needed is a UI entrypoint that allows a user to cut and paste or type a
native path, and simply have path -> file URL conversion occur.

The alternative might be to define a new URL scheme like "local:" which is
completely transient and can be mapped and escapped to a file URL.

For those of you who are complaining about the number of slashes, there is
nothing that can be done, this is the way "file:" was spec'd, and the logical
results are ugly but consistent. 

Unless I missed some comments, what is really needed here is something for users
to tell the browser: "I want THIS path". I realistically do not think users
should be composing file URL's, it takes too long to explain how this works, and
is problematic in the sense that Mozilla is actually built on many OS's with
file naming conventions that vary, possibly greatly.

Comment 29

[JD Brennan]

Just because it was spec'd this way does not mean that Mozilla
can't also support different syntaxes.  If Mozilla wants to
compete with IE then it must support the same file: syntaxes that
IE supports.  I think it's important for the Mozilla project to
realize that if they only support the spec, then they are conceding
the Windows browser market to IE.  That seems to be the case,
but I'm not sure it was a conscious decision.

Comment 30

[Andreas Otte]

It's a little bit more complicated:

mozilla is XP and there are different filesystems and syntaxes to support. It's
certainly much easier to deal with just one platform like IE does.

One thing for sure: if such an url gets to the urlparser it will be rejected.
That is very unlikely to change. Maybe the URI-Fixup code in docshell can do
something about it and fix it before it gets there. Also there are some
conversion routines that convert from nsIFile to file url and the other way. If
this routines are called and we do there the right thing (TM) with UNC Paths
this should work. But if we just get a ready file url that is malformed in this
way it is a lost case.

Comment 31

[benc]

JD: I think the general support for UNC paths could be improved, but engineers 
have to put the code somewhere, and necko is probably not the right place for 
that. 

Also, the fact that other people use incorrect file URLs is less important than 
http: URLs, because the usage and scope of these URLs is much more limited, 
especially since we (by default) do not read file URL's from a network source 
(like http URLs). 

Comment 32

[JD Brennan]

File URLs are less prevalent than http URLs, but they happen
frequently enough on our intranet sites, that I, reluctantly,
switched from Mozilla to IE so I can use our intranet.  And
these are URLs that are in web pages, not URLs that are entered
by a browser user.  I'm not sure if inexperienced web page
authors create them, or if web authoring tools create them.
I suspect the latter.  Though, I've started using file URLs
because in IE they are opened from the UNC location, so I can
then edit and save them (if they are .DOC or .MPP or .XLS files).
Mozilla would make a copy and then if I wanted to update it, I'd
have to figure out the path and do a save as.  Unfortunately,
IE saves me time and hassle the way it handles file URLs.

Comment 33

[Andreas Otte]

In time we will hopefully have working UNC support. Could you provide a generic
testcase of these intranet web pages you use?

Comment 34

[Jeff Siegel]

I just checked the behavior of Microsoft FrontPage. It creates file: URIs using
two slashes, not five. So you are going to encounter these types of URIs on web
sites. I'd like to use Mozilla instead of IE, but our corporate intranet has
lots of links to files on the network which I won't be able to access.

Comment 35

[Andreas Otte]

Two slashes (should be no problem) or two backslashes?

Comment 36

[Andreas Otte]

From a mail sent to me by Jeff:

Two ~forward~ slashes (as in file://hostname/sharename/dirname/fname) and
Mozilla build 2001080110 hangs on it under Win NT SP5. If I do
file://///hostname/sharename/dirname/filename it is ok.

So this problem seems to be located in the conversion from file-url to a native
(UNC-)filepath. 

Comment 37

[benc]

changing summary.

At this time, I have read roughly 90% of the bugs in "Networking:File".

If you have a particular problem with file URLs & UNC, please query for ALL bugs 
in this component before commenting here or creating a new bug:

http://bugzilla.mozilla.org/buglist.cgi?component=Networking%3A+File

What I need are bugs on:

UNC access failing for a certain feature.
file URL format (legal or illegal) that is not working. 
programs that create file URL's, and documentation as to the URL format (with 
STEPS for how they were created).

If you have a file problem, look for existing bugs, rather than thoughtlessly 
filing to run up the eventual dupe count. NOBODY is going to fix bugs in this 
component based on dupe totals.

I have only read up to RFC 1738, so I will try to read the newer RFC's on URI's 
ASAP, but I doubt dougt and andreas have read this wrong.

I will be completing and running my first run of a full, standards based file: 
URL test suite soon. 

I will summarize the conclusions here, as well as write a general guide to file: 
URLs, which will go to the mozilla site.

Comment 38

[benc]

+ tescase, relnote:
My current plan is to test this as the next Netscape commercial release goes 
out. Then I'm going to release note this behavior, and mark the bug 
VERIFIED/WFM...

Comment 39

[benc]

WFM:
relnote was submitted.

Comment 40

[Christopher Aillon (sabbatical, not receiving bugmail)]

*** Bug 110950 has been marked as a duplicate of this bug. ***

Comment 41

[benc]

VERIFIED:
Clearing open dependencies, will deal with this in the UNC broken meta bug 101953.

Comment 42

[benc]

Minor correction to the relnote in RC1 (bug 133795).

Comment 43

[Cyrus Patel]

my two cents:

  IE uses DDE execute (via url.dll) for any URL's that are not immediately 
  identifiable as http[s]://

  For a file:/ that does not end with .htm[l] AND does not end with a '/' or 
  '\' OR can't be immediately found, what IE does is (in effect) exec 
  'rundll32.exe url.dll,FileProtocolHandler %l'. 

  From observation, I believe the path is handled as follows...:

    unescape and convert '/' to '\' and '|' to ':'.
    strip off the 'file:'
    if only one leading backslash follows, 
      prepend current directory.
    else
      strip off all leading backslashes.
      if the second char is not ':'
        prepend literal "\\"
      endif
    endif
    dwAttrs = GetFileAttributes(path);
    regkey = NULL
    if (dwAttrs == 0xFFFFFFFFul)
      ; /* fall through and fail */
    else if (dwAttrs & FILE_ATTRIBUTE_SYSTEM)
      ; /* fall through and fail */
    else if (dwAttrs & FILE_ATTRIBUTE_DIRECTORY)
      regkey = "Folder"
    else
      regkey = getkey( extension )
    endif
    #if defined(IE)
    if regkey == "IExplore" || regkey == "Folder" || extension == ".htm[l]"
      deal_with_it_the_IE_way()
      regkey = NULL
    endif
    #endif
    if regkey != NULL
      { application,topic,@,command } = get_regvals(regkey)
      if (!FindGlobalAtom(application) || !FindGlobalAtom(topic))
        CreateProcess(make_arg(command, path))
      else
        dde_exec( application, topic, make_arg(@, path) )
      endif
    endif  

  That IE uses url.dll is easy enough to prove. Delete url.dll and watch
  what happens. :)

  That IE/url.dll uses DDE for file:/s is easy to prove as well. 
  Associate (say) .JPG with "Imaging". Then open a local .jpg with 
  IE. Voila! "Imaging" gets launched.

  Aside: Moz doesn't register itself as a DDE server (even though it does
  deal with Application='Mozilla', Topic='WWW_OpenURL', Item='"%1",,-1,,,,,'
  just fine). *sigh*

Comment 44

[benc]

(is this the right bug?)

Comment 45

[WD]

*** Bug 151787 has been marked as a duplicate of this bug. ***

Comment 46

[Dan Tobias]

Maybe there needs to be a tech evangelism bug to try to convince intranet
developers to use properly-formed URIs for local and local network files,
instead of nonstandard Microsoftisms?

Comment 47

[Tim Morley]

Here is my twist on the issue.  I have a file that is brought up by going to an
https URL.  The html file at that URL contains a link of the
format <a href="file://///server/file.html">file</a>(I didn't design it I just
support it).  I changed the anchor to contain five slashes per previous
comments.  I click on the link and nothing happens.  I right click on the link
and select either open in new tab or open in new window and nothing happens.  I
have middle clicks enabled to open links in new tabs.  When I middle click on
the link a new tab opens and the link works.  I have Mozilla 1.0 running on
Windows XP and Windows NT.

Comment 48

[benc]

morleyt: that is bug 122022.

Comment 49

[Dan Star]

I think this link is a good example of the issues discussed for this bug ID
http://www.rustoleum.com/ibg/MSDS/default.asp.  Unforturnately, the people
putting web sites together only only test with IE.  My company needs to access
this info but Mozilla chokes and IE works fine.  MS conspiracy?  Maybe.  But we
have no choice so IE will be rolled out to all the users that need it along with
the security headache.  Corporations can not adopt Mozilla until it can handle
file references commonly found in the corporate world.

Comment 50

[Andreas Otte]

Dan: If that site is so important to you than get it fixed! If you are not the
designer then write the webmaster. Especially when your problem is the \ instead
of /. Converting \ to / is just plain wrong, breaks sites and violates a bunch
of RFCs.

Comment 51

[Dan Star]

I was just giving one example (and I don't maintain it).  These types of sites 
are very prevalent.  I suspect it is because they use Windows and a "visual" web 
editor.  No way can I get these sites to change.  I did email this site and got 
no response.  Most likely these these web designers don't even no what the issue 
is because it works fine with IE.  The standard response for problem sites is 
"use IE".  That's reality.

Comment 52

[Andreas Otte]

We will only get this fixed with a total rework of the uri fixup code which
first trys the correct way to do things and then gradually trys different fixups
in a transparent way.

Comment 53

[benc]

*** Bug 167812 has been marked as a duplicate of this bug. ***

Comment 54

[charles allen]

I use Novell Netware, am authenticated to the tree, and want to access the
following UNC path:  \\ces-nw5\share\math\

If I go to the address bar and enter:  file://///ces-nw5/share/math/ it works.
If I go to the address bar and enter: file:///\\ces-nw5\share\math\ it works
after converting each \ to %5C

If I put this same text in an anchor: href='file://///ces-nw5/share/math/
nothing happens.  Why?  If it works in the address bar shouldn't it work as an
anchor HREF?  All I want are anchor HREFs that open a folder in both IE and Mozilla.

IDEA:  since file:///// is non-standard, pass it on to URL.DLL for processing.

Comment 55

[charles allen]

nevermind.  I found the appropriate bug. sorry to bother you.

Comment 56

[Guido Zimmer]

According to the 5 slashes recommendation in the 1.3 release notes, I changed my
intranet links to file://///server/share/file1.ext, but the link is still not
working. If I enter the same syntax manual into Mozilla, it works fine. If I
store it into a bookmark, it works also. 
But as long as I can't use the file:// tag on my intranet server, I can not
offer Mozilla as a IE replacement to the clients. 

Comment 57

[benc]

Guido, lets look at that in a new bug please.

Comment 58

[heinemann]

Please correct this (UNC) bug, because i can't replace IE without this feature
in my company

Comment 59

[Dan Tobias]

By this point, with all the wide-ranging discussion, I have no idea just what
the actual bug is that the last commenter wants to be fixed... is the "bug" the
fact that Mozilla doesn't support some bogus, malformed pseudo-URLs excreted by
Microsoft products (e.g., with backslashes instead of forward slashes), or is
there an actual bug causing Mozilla to fail to access LAN resources even by
correct-syntax URLs?

Comment 60

[Dan Tobias]

...And I agree with some other writers here that the "file:" URI spec is a
horrible mess... why have an "authority" component at all if it is always empty
or "localhost"?  Why not just use the single-slash form of the URI, with no
authority, for local files, which then frees the double-slash form for networked
files, instead of winding up with three- and five-slash abominations.  But
that's the way the spec is, so I guess we have to live with it (or propose an
Internet Draft to amend it).

I think in some browsers file:// with a non-localhost hostname triggers the FTP
protocol.  At least, I seem to remember that from ancient times (1995 or so).

Comment 61

[heinemann]

The bug is like this (Comment from Guido Zimmer) - i paste it again:
---------------------------------------------------------------------------- 
Additional Comment #56 From Guido Zimmer  2003-03-19 03:03 -------
According to the 5 slashes recommendation in the 1.3 release notes, I changed my
intranet links to file://///server/share/file1.ext, but the link is still not
working. If I enter the same syntax manual into Mozilla, it works fine. If I
store it into a bookmark, it works also. 
But as long as I can't use the file:// tag on my intranet server, I can not
offer Mozilla as a IE replacement to the clients. 
----------------------------------------------------------------------------
I have a lot of HREFs to different servers (Novell, Win2k, Linux) with direct
file access using the UNC notation.

Comment 62

[Andreas Otte]

There are problems with UNC paths, but in this case I assume it is something else:

Mozilla prohibits the usage of file urls in an html page when the page is served
over http or https. That is a security feature which can be removed by setting a
pref called "security.checkloaduri" to "false" if I remember correctly.

Comment 63

[heinemann]

OK, Mozilla prohibits the usage of file urls in an html page when the page is
served over http or https. Changing "security.checkloaduri" to false solve this
problem (thanks for the tip!!). But, if i use bookmarks or directly type in the
File-URL, the security feature "security.checkloaduri" is ignored and in this
two cases, i can ALWAYS access file-URLs. I think, it would be necessary to
harmonize the 3 ways of accessing file-URLs to the same behavior.

Comment 64

[benc]

Over the last few years, each of these issues was isolated in a bug, and I did
my best to clean up the technical discussions.

This weekend, I had some dead time to kill on my day off, so I started cleaning
up backlog of remaining RESOLVED bugs that should be VERIFIED. I also decided
that we are probably at the point where we need a good, short piece of
documentation about file URLs. There is already a piece I just finished on
netprefs, which included some comments about checkloaduri.

http://www.mozilla.org/quality/networking/docs/netprefs.html#file

I've filed bug 203675 to discuss common issues that we need to document.

The last question I have is, are we seeing enough scattered comments in other
bugs about file: URLs for UNCs, where we need to reopen this bug as a
placeholder ("[ISSUE]") bug, so that people can find it in their searches of
open bugs? This has worked for bug 122022. I use this sparingly, but this might
be a good choice here.

Comment 65

[Andreas Otte]

There is some sense behind this:

If you enter the file url in the urlbar or use a bookmark you *locally* access a
*local* file. You know what you do and it is you doing it. That the file url
itself is mapped over the local network is of no consequence to mozilla in this
case.

If you have a file url embeded in a http served html page and allow the access
you allow a *remote* program (the page!) access to a *local* file. Again that
the file url itself is mapped over the local network is of no consequence to
mozilla.

By using the pref you open up your system for attacks, allow snooping around,
reading system files, etc. If possible it would be much better to mount the
drives with your files on your http server and serve the files through http too.

Comment 66

[Adam Guthrie]

*** Bug 304250 has been marked as a duplicate of this bug. ***

Comment 67

[Matthew W. Jackson]

I do not know what has been fixed/changed since this bug has been open, but I
believe that the behavior is still wrong as of Firefox 1.0.6.

This could possibly restrict the adoption of Firefox for use on corporate intranets.

I don't mind supporting the nasty "five-slash" version, as IE even supports
this, but as far as I can tell, this is wrong (unless the spec was explained to
me poorly).

The general syntax is "file://[computer]/[path]" with [computer] being optional
(for localhost).  As I reported in Bug 304250, "file://///server/projects/" is
technically shorthand for "file://localhost///server/projects/", which is
absolutely *not* what is meant by "\\server\projects\".

Firefox completely ignores the [computer] part, so "file://server/C:/" resolves
to "C:\".

Of course, Intranets *could* be changed to support Firefox and IE, but I
actually believe the spec is clear and "file://///" should only be included for
compatability with malformed URLs.

I don't know about Unix (this may not even be an issue there), but if Firefox
wants to replace IE on Windows, it should support properly formed file URLs.

I also don't know if there is some security reason why UNC paths are restricted,
but seeing as they are allowed with the five-slash method, I don't believe this
to be the case.

Is there any chance of getting this re-opened?  Like I said, it's a major
problem for many corporate Intranets.

"WORKSFORME" is definately not the status I'd assign, because the behavior seems
to be broken.

Comment 68

[Andreas Otte]

Please reread the definition of the file protocol in the RFCs. If my memory
servs correctly, the host part can either be localhost or the hostname of the
local computer. It is a *local* protocol, the hostname can be ignored. Whatever
happens in the path section of the url is of no concern to the host section. In
case of UNC-Paths the *path* triggers a network access. So in my opinion, what
firefox does is by the book.

So I think "file://localhost///server/projects/" or "file://///server/projects/"
is exactly what is meant by "\\server\projects\"

"file://server/projects" where "//server/projects" is the UNC-path is
technically a broken url which can possibly be fixed. Maybe we can do a better
job there.

Comment 69

[Matthew W. Jackson]

Well, however you choose to interpret the spec (I admit it could be clearer),
the browser should support either type of file:// URL.  Whichever version you
choose to auto-generate from a path (when you type a local UNC path into the
address bar) does not matter, but when a user navigates to
"file://server/projects/file.txt", I do not see why it should not take them to
"\\server\projects\file.txt".  If it doesn't, they are possibly going to go back
to using Internet Explorer because they can't access the files off corporate
Intranet.

Even if that form *is* wrong (and I can see both sides of the argument), that
just makes file:// URLs more stupid than they already are, since the hostname
part is worthless.  And honestly, nobody is going to remember to use five
slashes to start a URL to a network share, much less understand *why* they have
to do that.  I was always forgetting the third slash on local URLs until
somebody explained that there was an implied "localhost" there.  If localhost is
*always* implied, then the third slash shouldn't be necessary.

If this needs to be special cased on the Windows version then so be it, because
you're fighting an uphill battle with almost every existing Windows application
out there that generates file:// URLs.  Frontpage uses the host name, and I
cannot count how many intranets I've encountered (and even Internet websites)
are designed using Frontpage.

Also, anything written in .NET certainly will, since creating a new Uri instance
from a local path results in the host name being used.  I assume this includes
Mono too, as I doubt they'd break compatability with .NET over a different
interpretation of the spec.

Honestly, I had never seen the "/////" version until Firefox, so I just assumed
it was wrong.

Comment 70

[Dan Tobias]

Well, actually, if the hostname portion is going to begin to be parsed to get a
local network address, then the third slash *would* continue to be necessary for
non-network file paths, or else the first part of the file path would get parsed
as a network address.

I agree this protocol is rather silly; if the network portion is always supposed
to be ignored in "file:" URIs, then why is it even included at all, instead of
having a syntax like "file:/c:/stuff/" with only one leading slash?  This whole
thing wasn't thought out very well by whoever developed the spec, and allowing
LAN addresses in the network portion seems like a reasonable extension to the
syntax.  However, this stuff is very OS-specific, rather than platform-neutral.

Comment 71

[Adrian Aichner]

file:\\host\file\path
used to work fine upto at least Fx 1.0.7
and I have put a lot of such links into a wiki at work, since this was syntax working in IE (officially supported at my workplace) and Fx (the browser I muchly prefer over the incumbent).

Now your resolution of this defect says that converting all links to slash-fivers WORKS4U.

This is just to voice my opinion that this compatibility breech DOESNOTWORKFORME, and I would have to ditch Fx at work, short of any alternatives.

Is there a RFC supporting the file://///syntax/at/all

?

Thanks in advance!

Adrian

Comment 72

[Adrian Aichner]

(In reply to comment #71)
> file:\\host\file\path
> used to work fine upto at least Fx 1.0.7
> and I have put a lot of such links into a wiki at work, since this was syntax
> working in IE (officially supported at my workplace) and Fx (the browser I
> muchly prefer over the incumbent).
> 
> Now your resolution of this defect says that converting all links to
> slash-fivers WORKS4U.
> 
> This is just to voice my opinion that this compatibility breech
> DOESNOTWORKFORME, and I would have to ditch Fx at work, short of any
> alternatives.
> 
> Is there a RFC supporting the file://///syntax/at/all

What about
http://www.ietf.org/rfc/rfc1738.txt

Why is it not obeyed?

Adrian

Comment 73

[Andreas Otte]

(In reply to comment #72)
> (In reply to comment #71)
> > file:\\host\file\path
> > used to work fine upto at least Fx 1.0.7
> > and I have put a lot of such links into a wiki at work, since this was syntax
> > working in IE (officially supported at my workplace) and Fx (the browser I
> > muchly prefer over the incumbent).
> > 
> > Now your resolution of this defect says that converting all links to
> > slash-fivers WORKS4U.
> > 
> > This is just to voice my opinion that this compatibility breech
> > DOESNOTWORKFORME, and I would have to ditch Fx at work, short of any
> > alternatives.
> > 
> > Is there a RFC supporting the file://///syntax/at/all
> 
> What about
> http://www.ietf.org/rfc/rfc1738.txt
> 
> Why is it not obeyed?
> 
> Adrian
> 

\ is not an url-path separator at all according to any RFC about URIs including 1738, instead it is even deemed an unsafe character in URIs. It is just part of the filename '\\host\file\path' in the url which gets fixed to file:///\\host\file\path or maybe file://\\host\file\path. This then may work depending on your local machine (having a protocol in the OS that can handle UNC-filepaths) and mozilla/firefox giving it in the correct form to the OS. But that is another story.

As long as you use \ as separator in URIs instead of / don't bother quoting RFCs, nobody will hear you ;-)

Comment 74

[Adrian Aichner]

(In reply to comment #73)
> (In reply to comment #72)
> > (In reply to comment #71)
> > > file:\\host\file\path
> > > used to work fine upto at least Fx 1.0.7
> > > and I have put a lot of such links into a wiki at work, since this was syntax
> > > working in IE (officially supported at my workplace) and Fx (the browser I
> > > muchly prefer over the incumbent).
> > > 
> > > Now your resolution of this defect says that converting all links to
> > > slash-fivers WORKS4U.
> > > 
> > > This is just to voice my opinion that this compatibility breech
> > > DOESNOTWORKFORME, and I would have to ditch Fx at work, short of any
> > > alternatives.
> > > 
> > > Is there a RFC supporting the file://///syntax/at/all
> > 
> > What about
> > http://www.ietf.org/rfc/rfc1738.txt
> > 
> > Why is it not obeyed?
> > 
> > Adrian
> > 
> 
> \ is not an url-path separator at all according to any RFC about URIs including
> 1738, instead it is even deemed an unsafe character in URIs. It is just part of
> the filename '\\host\file\path' in the url which gets fixed to
> file:///\\host\file\path or maybe file://\\host\file\path. This then may work
> depending on your local machine (having a protocol in the OS that can handle
> UNC-filepaths) and mozilla/firefox giving it in the correct form to the OS. But
> that is another story.
> 
> As long as you use \ as separator in URIs instead of / don't bother quoting
> RFCs, nobody will hear you ;-)
> 

file://///syntax/does/not/work/for/me
in Firefox 1.5.0.3 on the exact same link that works in IE 6.0.

Is there another bug keeping this from working?

Adrian