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

Status: RESOLVED FIXED

(Toolkit :: Downloads API, defect)

Description

[Pigeon]

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.

Comment 1

[Wayne Woods]

Did they still have the .gz extensions, even though they were uncompressed?

Comment 2

[Wayne Woods]

It should be a duplicate of bug 233047. Can you please check out that bug and
let us know if it sounds right?

Comment 3

[Pigeon]

(In reply to comment #1)
> Did they still have the .gz extensions, even though they were uncompressed?

Yes.

Comment 4

[Pigeon]

(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?

Comment 5

[Wayne Woods]

Resolving it as a dupe. Thanks :)

*** This bug has been marked as a duplicate of 233047 ***

Comment 6

[Ali Ebrahim]

v

Comment 7

[Boris Zbarsky [:bzbarsky]]

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

Comment 8

[Ali Ebrahim]

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

Comment 9

[Ali Ebrahim]

*** Bug 236710 has been marked as a duplicate of this bug. ***

Comment 10

[Ali Ebrahim]

*** Bug 236978 has been marked as a duplicate of this bug. ***

Comment 11

[Tuukka Tolvanen (sp3000)]

*** Bug 237430 has been marked as a duplicate of this bug. ***

Comment 12

[Ali Ebrahim]

*** Bug 241684 has been marked as a duplicate of this bug. ***

Comment 13

[Asa Dotzler [:asa]]

Gonna try to get to this for 0.9. If not, then soon after (hopefully).

Comment 14

[Ali Ebrahim]

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?

Comment 15

[Ali Ebrahim]

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?

Comment 16

[Ali Ebrahim]

(In reply to comment #15)
> biesi's comment from bug 220807 is relevant here:

That should read bug 233047. Sorry for bugspam.

Comment 17

[Adam Roach]

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?"

Comment 18

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: fix

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.

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

fixed.