Closed Bug 38643 Opened 20 years ago Closed 19 years ago

file:///UNC and file:////UNC should not -> file://///UNC


(Core :: Networking: File, defect, P3, critical)

Windows 98





(Reporter: jruderman, Assigned: dougt)




(Keywords: hang, testcase)


(4 files)

Steps to reproduce:  (about 60% reproducability)
1. Save your work so you don't panic if your OS freezes
2. Save URL or attachment to your hard drive
3. Load local copy of attachment file in mozilla
4. Leave the page (click home icon, close mozilla, etc.)


- other apps become unresponsive as well, and ctrl-alt-del takes more than a
  second to show up

- adding more bogus drive names increases crash length, but adding more
  filenames with the same drive name image files doesn't (not sure about this)

- /foo/bar.gif works as well as file:///foo/bar.gif
  (this is why it showed up on local copies of legit pages)

- freeze is most reproducable while leaving page, but can happen if page is
  open and you're working in another application
Attached file test case
Marking as a crasher and raising severity because with many different bogus 
drive names, this freezes the OS for quite a while.
Severity: major → critical
Keywords: crash, testcase
Assignee: gagan → warren
I just use nsIFile.  => dougt
Assignee: warren → dougt
This is a known windows 98 system problem.  I belive that Microsoft has patches 
via WindowsUpdate for this. 

Closed: 20 years ago
Resolution: --- → WONTFIX
This may be known, and it is probably a bug, but I don't see any patches for 
it.  This bug is not bug 29079, which involved device driver names, whereas 
this one involves bogus drive names.
Resolution: WONTFIX → ---
pam, do you know of any problems loading images from a bad file url on windows 

nope. Imglib doesn't care about files. It cares about data streams.
We use file specs for id'ing images, but we deal with data streams.
something must have changed.  works for me.
Closed: 20 years ago20 years ago
Resolution: --- → WORKSFORME
Win98 2000070508
now freezes mozilla but not windows 98.  reopening.
Resolution: WORKSFORME → ---
Summary: Bogus drive name in file:/// url freezes Windows 98 → Bogus drive name in file:/// url freezes mozilla (no longer freezes Windows 98)
oh, it does sometimes still freeze windows 98.
Summary: Bogus drive name in file:/// url freezes mozilla (no longer freezes Windows 98) → Bogus drive name in file:/// url freezes mozilla and sometimes freezes Windows 98
Still can't reproduce.  QA, can you try/verify this again on a couple different
Closed: 20 years ago19 years ago
Resolution: --- → WORKSFORME
jesse, I'm not seeing any attachment in your 05-08 23:41 comment.  Was this 
basically the URL you saved locally as an html file?
My comment really wasn't clear; thanks for pointing that out.  I was referring 
to what happens when I load a file that looks like

<img SRC="/foo1/bar" alt="1">
<img SRC="/foo2/bar" alt="2">
<img SRC="/foo3/bar" alt="3">
<img SRC="/foo4/bar" alt="4">
<img SRC="/foo5/bar" alt="5">
<img SRC="/foo6/bar" alt="6">
<img SRC="/foo7/bar" alt="7">

and load it in the browser.  (Hint: try it with fewer than 7 first.)

Note that

<img SRC="/foo1/bar1" alt="1">
<img SRC="/foo1/bar2" alt="2">
<img SRC="/foo1/bar3" alt="3">
<img SRC="/foo1/bar4" alt="4">
<img SRC="/foo1/bar5" alt="5">
<img SRC="/foo1/bar6%22 alt="6">
<img SRC="/foo1/bar7" alt="7">

is much less problematic.
ok, the way I understand this is that you are giving two examples of a lockup 
problem.  The first example uses a copy of the zdnet page stored locally, and 
the second example uses an html test file with the code listed in your last 
comment (with 7 img tags and the alt attribute).  

If that is correct I am still not reproducing this.  Could you possibly 
re-attach your test case?  thx
I typed that last comment to quickly.  What I can see is a lockup (on win 98) 
when I load a copy of the page from a local drive.  It is ok on win NT.  But I 
cannot narrow it down to the bogus directory using the html you provided.
Doug, copies of the files I am using are at 
but you need to copy them locally.
Added 40 bogus directories to test case per Jesse's recomendation.  Still 
works on win98 for me.  

I do however see a slight pause when the page is loading.  Is it possible you 
are seeing this?   What is the speed / memory of the system you are you using?   
reopening based on comments..
Resolution: WORKSFORME → ---
Attached file test case
I think I figured it out: Mozilla is interpreting file:///foo1/bar/ as 
\\foo1\bar\, meaning "ask computer foo1 on your local network for a directory 
called bar".  Windows 98 is very slow about network things (try start-r, 
\\foo115\bar) but apparently only freezes if asked to try to access several 
computers on the local network at once.

IE and Mozilla will both accept file://///watership/mp3/ typed into the 
location bar.  Mozilla will also accept file:///watership/mp3/ as an equivalent 
url for the url above, and will replace it with the 5-slash version if the 3-
slash version is typed into the url bar.  This should only happen when the url 
is typed by the user (see bug 34943 for a similar problem).

So we actually have two problems here:
- url error-corrrection happening when it shouldn't
- a bad crash, that afaict can't be exploited remotely

Netscape 4.75 doesn't accept file:///// urls.
Summary: Bogus drive name in file:/// url freezes mozilla and sometimes freezes Windows 98 → page with multiple file:///// images freezes Win98
This file url correction only happens on XP_PC if the stuff after file:/// can
not be identified as a syntactically valid drivename. It is a best guess on what
the user want's and sometimes that's false. This conversion is currently deeply
burried into the urlparser, no way of getting it out there without changing the
whole process of creating fixup URIs, as suggested many times before.
Oops, this crash is remotely exploitable.

<a href="data:text/html,<script>for (i = 0; i < 4; ++i) document.write('<img 
src=file://///bogusdrive' + i + '/foo.jpg alt=' + i + '>');</script>" 
target="_blank">click here to freeze moz for a while</a>
any opinion on this, mstoltz?  Thanks.
over to you mitch per our conversation.
Assignee: dougt → mstoltz
Keywords: crashfreeze
Keywords: freezehang
Blocks: 63736
All of these testcase now work for me can anyone else verify that its now ok?

Platform: PC
OS: Windows 98
Mozilla Build: 2001022620
Setting milestone to Moz0.9.
Target Milestone: --- → mozilla0.9
Using 2001041104 on Win98, all of the test cases seem to work.

When loading a local file that contains:

<img SRC="/foo1/bar" alt="1">
<img SRC="/foo2/bar" alt="2">
<!-- ... -->
<img SRC="/foo9/bar" alt="9">

mozilla "thinks" for several seconds (5-10) but does not freeze.

Adding CheckLoadURI to IMG tags will keep this from being remotely exploitable,
which IMHO is acceptable. This is supposed to happen by 0.9. After that, if
anyone wants to address this crash/slowdown, that's cool, if not, that aspect of
the bug is a WONTFIX.
OK, my part is done. It should be generally impossible to reference a file: URL
of any kind from Web content, at least it will be win Pavlov gets his fix in.
Meantime, I'm moving this over to Necko and pushing out the milestone to see if
anyone over there thinks the slowdown caused by asking Windows to search for a
network drive is worth treating as a denial-of-service issue.
Assignee: mstoltz → neeti
Target Milestone: mozilla0.9 → mozilla0.9.1
this is an annoying problem and should get fixed for the beta. giving to doug 
since he has been working on file transport related issues. 
Assignee: neeti → dougt
Keywords: nsbeta1+
Keywords: nsenterprise
RFC 1738 states that the syntax of file:// URL is:


so, if there is a computer that is accessible via UNC named foo, the URL to that
computer is file://foo/.  Is the suggestion that the host name of a UNC mount in
a URL is always prepended by "//" or "///"?  

The host in the file-url has nothing to do the host in an UNC filepath. As the
name suggests, all of UNC is happening inside the path component of the URL. All
the urlparser can do is guess and add the appropiate number of slashes as
necessary. So to really be an UNC filepath it has to be file://///foo to work on
every OS. Two slashes for the protocol, one to delimit the non existing host and
then two to start the UNC filepath.

The file protocol is by definition a local protocol, even if the syntax might
suggest otherwise. The only possible host can be localhost, nothing else makes
really sense because there is no generic way to access a file a on remote

The problem during parsing is to distinguish a hostname from a directory. This
is easy on XP_PC where drives can be easily detected at the beginning of a path
and eyerything else *could* be a network name. Currently the urlparser doeas
just that. On unix/linux there is no way to syntactically distinguish a hostname
from a directory, so there is much less fixup possible.
As near as I can tell, the bug is that we assue that if a file url does not have 
a drive specifier, it is a UNC path.  This, however, is incorrect.  We should be 
defaulting to the drive where the application is running from.

The code that check for UNC paths is here:

So, I think one way of handling this is for the check in nsNoAuthURLParser.cpp 
to go away.  Then in nsStdUrl::GetFile(), where we convert the url path to 
native path, we have some logic to determine if it is a UNC path or if it is a 
path missing a drive spec.

I will attach a patch which addresses this.  I tested the path against 
the testcases and it performs well.  I also loaded file files and such, but I am 
not sure I am covering all bases.  

Andreas, could you tell me what I am missing?  
Keywords: patch
As far as I know there is no defaulting to the current drive with file urls. A
file url is either absolute and contains a full path (which includes a drive on
some OS) or is relative and maybe contains no drive but the base url has to (on
some OS).

But if this url guessing is to agressive, we should try and switch it off/apply
the patch. I currently have no working win32 build (totally rotten away), so I
can't check against my modified urltest-version. tever has the diffs. Maybe
someone else has time to test the patch.
gagan, darin, please review.  
sr=darin (but make sure you get enough testing before landing this)
Fix checked in.

Checking in nsNoAuthURLParser.cpp;
/cvsroot/mozilla/netwerk/base/src/nsNoAuthURLParser.cpp,v  <--  
new revision: 1.13; previous revision: 1.12
Checking in nsStdURL.cpp;
/cvsroot/mozilla/netwerk/base/src/nsStdURL.cpp,v  <--  nsStdURL.cpp
new revision: 1.72; previous revision: 1.71
Closed: 19 years ago19 years ago
Resolution: --- → FIXED
-> file

So, is the fix that we do not take file:///<path> as UNC, and require file:///// 
paths now?
Component: Networking → Networking: File
Yes, we no longer stuff the url with / when we can't detect a drivename in file
urls and it is not a UNC-PATH. Instead we let it default to the current(?)
drive. This may be wrong as it is to always assume UNC-Paths if no drive is
present. But I think this may be the best compromise. Time will tell ....
Thanks for the clairification.

File URL's will be getting more attention in the next milestone release notes.

We'll find out one way or the other...
Keywords: relnote
Win98, Mozilla 0.9.4.

1- access file:///UNC
Viewed file.
2- attempted to access shorter file URLs by progressively removing slashes

file:///UNC and file:///UNC are non-existent files and treated as such. 
file://UNC -> file://servername/path (correct)
file:/UNC -> file:///UNC, which is non-existent. (correct)
Summary: page with multiple file:///// images freezes Win98 → file:///UNC should not -> file://///UNC
I can't count...
file://///UNC (5) works.

"file:///UNC and file:///UNC" should have been:
file:///UNC (3) and file:////UNC (4)"

Fixed summary too.
Summary: file:///UNC should not -> file://///UNC → file:///UNC and file:////UNC should not -> file://///UNC
Keywords: relnote
You need to log in before you can comment on or make changes to this bug.