Closed Bug 236440 Opened 20 years ago Closed 20 years ago

relative file URIs containing '\' mishandled on Windows

Categories

(Core :: Networking: File, defect)

x86
Windows XP
defect
Not set
minor

Tracking

()

RESOLVED WONTFIX
Future

People

(Reporter: bugzilla.mozilla.org, Assigned: darin.moz)

Details

(Keywords: helpwanted)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219

Interpretation of local URL's in stylesheets seems to be influenced by using
either 'folder/file.css' or 'folder\file.css' from HTML

Reproducible: Always
Steps to Reproduce:
Situation 1:
1. Connect a stylesheet to an HTML document using <link rel='stylesheet'
href='style/default.css'>
2. Reference an image from the stylesheet, like BODY {background-image:
url('image.gif');}

Situation 2:
3. Change the slash into a backslash for calling the stylesheet: <link
rel='stylesheet' href='style\default.css'>
4. Do not change the stylesheet
Actual Results:  
Situation 1: the image is loaded from the style folder (./style/image.gif).
Situation 2: the image is loaded from the base folder (./image.gif).
(Note that in both situations, the stylesheet file IS found.)

Expected Results:  
It seems most logical to me that the relative URLs are always resolved from the
style folder.
> (Note that in both situations, the stylesheet file IS found.)

That sounds like a bug to me.  The relative URI resolution from a URI containing
'\' is correct in this case, but the URI with a '\' in it should link to the
file called "style\default.css" (and if the OS does not allow such a character
in filenames, as Windows does not, we should report an error instead of just
passing it off to the OS and having it mess up the file we want).
Assignee: dbaron → darin
Status: UNCONFIRMED → NEW
Component: Style System (CSS) → Networking: File
Ever confirmed: true
QA Contact: ian → benc
Summary: relative url interpretation depends on stylesheet calling → relative file URIs containing '\' mishandled on Windows
Severity: normal → minor
Status: NEW → ASSIGNED
Target Milestone: --- → Future
cc'ing andreas in case he wants to hack on this...
Keywords: helpwanted
The problem probably comes up on Mac too if a ':' is used in the URI, depending
on how the nsLocalFileMac::Init methods work, of course.
Also, what does the file:/// uri definition say about using filenames with chars
that are not valid in filenames on that system?
file urls have a very well defined set of allowed characters, as defined by
RFC2396. The conversion functions from local filepath to file url and the other
around have to do the heavy lifting of replacing not allowed characters,
escaping, etc.
So the code at
http://lxr.mozilla.org/seamonkey/source/netwerk/base/src/nsURLHelperWin.cpp#99
should handle removing (or replacing? by what?  %-escapes?) illegal chars from
the filebasename and extension?  I assume the other nsURLHelper* impls need
similar changes?
Usually special chars for urls that are part of a filename get escaped when
moving from local filepath to fileurl. The path separator gets translated to /
from whatever it is locally (for example \ or :). Also unusual characters get
escaped.

In the other direction in the path-component of the file-url the path separator
gets retranslated and the path then gets unescaped. Nothing more is done AFAIK.

In this case with the usage of \ instead of / mozilla sets the right base
directory, just not the directory the page author wanted. His fault. But mozilla
is able to read the stylesheet because windows does the right thing with the
file "style\default.css" which is a valid filename in a file url but is a
directory and a file in a windows local path.

In my opinion it is not really a bug, the page author did something wrong and
unexpected things happened after that. But if we want to do something about it,
I guess we could remove \ or %5C from the filename-component while translating
(and before unescaping) to local path in nsURLHelperWin.cpp to trash the
filename deliberatly and prevent any loading. But that may break some usages of
\ instead of / that work now by accident and will give Tech Evangelism plenty of
work.
andreas has a good point: WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.