289851 - jar: protocol does not handle file names with embedded spaces

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Peter Wilson]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050405 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050405 Firefox/1.0.3

I created a jar file (call it MyJar.jar) with 2 files in it:
File1.js
 and File 1.js (note embedded space - but possibly other special characters aer
not handled).
The url
jar://c|/MyDir/MyJar.jar!/File1.js Displays the file content correctly.
jar://c|/MyDir/MyJar.jar!/File%201.js Finds nothing.
Perhaps this is a known feature of jar files as I can find no Mozilla jar file
entry with a space in the name. Zip files permit this feature and Windows XP
compressed folder has no problems displaying the content of "File 1.js"
I susppect that this is just lack of handling for URL encoding.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 2

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.

Comment 3

[Simo Melenius]

I can verify this here. The nsJARURI internally uses nsStandardURL which URL-escapes certain characters by default. Reading the ``JAREntry'' attribute of the nsIJARURI later will return an escaped string, for which there's naturally no entry in the zip file.

I wrote a small patch against the head version of nsJARChannel.cpp that unescapes the name of the JAR entry when it is read from the nsIJARURI. Maybe that nsIJARURI::GetJAREntry() could be patched instead, but the effect would propagate everywhere.

This patch is exemplary only for now: I haven't considered security implications yet (as unescaping into potentially malicious bytes). I'll revisit those issues if anyone wakes up this time :-)

Comment 4

[Simo Melenius]

Attachment: Unescapes URI escapes in JAR entry names when read from nsIJARURI

Comment 5

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 204047 [details] [diff] [review]
Unescapes URI escapes in JAR entry names when read from nsIJARURI

you don't need the AlwaysCopy, do you? Couldn't you do:

+    nsCAutoString escaped;
+    if (NS_UnescapeURL(mJarEntry.get(),
+                    mJarEntry.Length(),
+                    0,
+                    escaped)
+        mJarEntry.Assign (escaped);

Also, spaces before parentheses is not the style of this file...

Comment 6

[Simo Melenius]

(In reply to comment #5)
> you don't need the AlwaysCopy, do you? Couldn't you do:

Yes, esc_AlwaysCopy was unnecessary. Removed and conditionalized.

> Also, spaces before parentheses is not the style of this file...

Suggested by my Emacs configuration; didn't pay attention to the formatting, sorry about that. Creating a better patch.

Comment 7

[Simo Melenius]

Attachment: Slight changes: conditional updating of mJarEntry; conforms to the style of the existing C++ source

Comment 8

[Darin Fisher]

Attachment: v1.1 patch

revised patch

Comment 9

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 204053 [details] [diff] [review]
v1.1 patch

thinking about this again, maybe JAREntry should not return an escaped string? hm... the one caller outside of libjar would probably slightly prefer an escaped string. r=biesi

Comment 10

[Darin Fisher]

I decided not to unescape in nsJARURI because that could cause problems for JS consumers.  The entry has a type of AUTF8String, and the result of unescaping might not be a UTF-8 string.

Comment 11

[Darin Fisher]

fixed-on-trunk