Closed Bug 235859 Opened 17 years ago Closed 17 years ago
.gz file silently uncompressed when right-click, save link to disk [content
Area Utils .js]
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
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]
*** 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?"
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.
Status: NEW → RESOLVED
Closed: 17 years ago → 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.