Closed
Bug 236440
Opened 20 years ago
Closed 20 years ago
relative file URIs containing '\' mishandled on Windows
Categories
(Core :: Networking: File, defect)
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.
Comment 1•20 years ago
|
||
> (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
Assignee | ||
Updated•20 years ago
|
Severity: normal → minor
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Assignee | ||
Comment 2•20 years ago
|
||
cc'ing andreas in case he wants to hack on this...
Keywords: helpwanted
Comment 3•20 years ago
|
||
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.
Comment 4•20 years ago
|
||
Also, what does the file:/// uri definition say about using filenames with chars that are not valid in filenames on that system?
Comment 5•20 years ago
|
||
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.
Comment 6•20 years ago
|
||
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?
Comment 7•20 years ago
|
||
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.
Assignee | ||
Comment 8•20 years ago
|
||
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.
Description
•