Closed Bug 235859 Opened 17 years ago Closed 17 years ago

.gz file silently uncompressed when right-click, save link to disk [contentAreaUtils.js]

Categories

(Toolkit :: Downloads API, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.7

People

(Reporter: mozillabug, Assigned: bugs)

References

()

Details

(Whiteboard: fixed-aviary1.0)

Attachments

(1 file)

User-Agent:       
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040207 Firefox/0.8

When trying to download gzipped files, firefox silently uncompresses them and
saves them in uncompressed form. There is no option under Tools/Options... to
turn this behaviour on or off, and no indication is given that it is going to
behave in this broken manner. Two files on which I first noticed the problem are:
http://ftp.debian.org/debian/pool/non-free/u/unrar/unrar_3.3.2-1.diff.gz
http://ftp.debian.org/debian/pool/non-free/u/unrar/unrar_3.3.2.orig.tar.gz

Reproducible: Always
Steps to Reproduce:
1. Go to http://packages.debian.org/unstable/utils/unrar
2. Right click on the link "unrar_3.3.2.orig.tar.gz" or "unrar_3.3.2-1.diff.gz"
3. Click "Save Link to Disk..."
4. Wait for the file to download
5. Inspect the downloaded file - it has been uncompressed.

Actual Results:  
The files "unrar_3.3.2.orig.tar.gz" and "unrar_3.3.2-1.diff.gz" saved to my hard
disk were found to be uncompressed. By retrieving them with wget instead of
downloading them from within firefox, I verified that the original files are
compressed.

Expected Results:  
It should have saved the files in their original compressed format, as found on
the Debian website. It should not have uncompressed them. It should have saved
them without modifying them in any way.
Did they still have the .gz extensions, even though they were uncompressed?
It should be a duplicate of bug 233047. Can you please check out that bug and
let us know if it sounds right?
(In reply to comment #1)
> Did they still have the .gz extensions, even though they were uncompressed?

Yes.
(In reply to comment #2)
> It should be a duplicate of bug 233047. Can you please check out that bug and
> let us know if it sounds right?

Have checked out 233047 - yes, it does seem to be the same; I have duplicated
the result. Does this now "confirm" that bug?
Resolving it as a dupe. Thanks :)

*** This bug has been marked as a duplicate of 233047 ***
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Resolution: --- → DUPLICATE
v
Status: RESOLVED → VERIFIED
QA Contact: aebrahim
Not at all the same bug.  Bug 233047 is about the case when the user clicks on
the link and then saves it off the helper app dialog.  If the user is saving
using right-click and this behavior is happening, you guys need to fix your
forked contentAreaUtils.js
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Confirming right-click save to disk case on Mozilla/5.0 (Windows; U; Windows NT
5.1; en-US; rv:1.7b) Gecko/20040312 Firefox/0.8.0+.

--> NEW
--> All/All
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
*** Bug 236710 has been marked as a duplicate of this bug. ***
*** Bug 236978 has been marked as a duplicate of this bug. ***
*** Bug 237430 has been marked as a duplicate of this bug. ***
Summary: .gz file silently uncompressed when downloading → .gz file silently uncompressed when right-click, save link to disk [contentAreaUtils.js]
Flags: blocking0.9?
*** Bug 241684 has been marked as a duplicate of this bug. ***
Gonna try to get to this for 0.9. If not, then soon after (hopefully).
Flags: blocking0.9? → blocking0.9+
Target Milestone: --- → Firefox0.9
You can reproduce this problem consistently with
http://www.munuc.org/mygraph.svgz which as a gzip-encoded SVG file.

The Apache server its running on has the following line set:
AddEncoding x-gzip .gz .tgz .svgz

This means it sends the HTTP header 'Content-Encoding: gzip' when it serves the
file. In this case, the file is silently un-gzipped as per the bug, but retains
its mygraph.svgz filename.

If I remove the .svgz from the AddEncoding directive, then no Content-Encoding
header is sent, and the file is downloaded correctly as a gzip-encoded SVG file
called mygraph.svgz.

In *both* cases, the Content-Type is image/svg+xml.

I think this might clear things up a bit, at least in terms of where this
happens. It appears that Mozilla is confused about what to do when the
'Content-Encoding: gzip' header is set. It should only decompress the file when
its rendered in the browser, not when its saved to disk.

This is *exactly* the same behaviour as bug 233047, and occurs whether I click
on a link to the file (from http://www.munuc.org/svg.html), or right click and
save as. Are we 100% sure that its not a dupe of bug 233047?
biesi's comment from bug 220807 is relevant here:

------- Additional Comment #24 From Christian Biesinger  2004-05-04 12:51 PDT

no, it should also uncompress when opening in a helper app, and "sometimes" when
saving to disk. for example, would you appreciate a .html file that is saved
gzipped because the server wanted to save bandwith?
(In reply to comment #15)
> biesi's comment from bug 220807 is relevant here:

That should read bug 233047. Sorry for bugspam.
It certainly sounds like this is not as much a bug in Firefox as it is a
(common) misconfiguration of Apache servers. If they're sending a gzipped file,
the content-type should be "application/octet-stream" (or the nonstandard
"application/gzip") with unindicated (i.e. identity) encoding. Any other
encoding really should mean that the recieving user agent decodes the received
content before doing anything.

That said, this is a common enough misconfiguration that perhaps there should be
some sort of dialog box when saving to disk a file that was tranferred
compressed -- something along the lines of, "this file is being sent compressed.
Do you want to uncompress it before saving it?"
Attached patch fixSplinter Review
Update contentEncodings use to use UTF8 String Enumerator instead of
nsISimpleEnumerator (bug introduced late last year)... also polish default
valule for filter field when there is no description available from the OS.
fixed. 
Status: NEW → RESOLVED
Closed: 17 years ago17 years ago
Resolution: --- → FIXED
Whiteboard: fixed-aviary1.0
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.