From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20020111 BuildID: 2002011108 Mozilla saves file as gzipped file when transfer encoding is gzip. Reproducible: Always Steps to Reproduce: 1. Open the URL and locate some patch/file to download 2. Download file 3. execute "file <downloaded-file>" Actual Results: File is gzipped. Expected Results: Decoded text should be saved just like IE does. I'm not saying decode gzipped file, but decode gzip transfer encoding :)
Yasuo, how are you downloading the file/patch?
If you see this page, you'll see "Download" links at right hand side. http://cvs.php.net/cvs.php/php4/ext/pgsql/pgsql.c
Confirming. Clicking on the link and then selecting "save" from the resulting dialog does not decode based on the content-encoding. This is distinct from doing right click and then save as, which uses the persistance object....
Note that the gzip is a _content_ encoding, not a _transfer_ encoding. So arguably we should _not_ be unzipping....
Boris, Are you saying the file(content) is actually gzipped? If so, I have to complain about it to horde guys :) They said files are not gzipped. IEs decodes files from cvs.php.net, while gzipped files remain gzipped, though...
> Are you saying the file(content) is actually gzipped? I'm saying that servers send the _same_ headers in both cases, unfortunately... so we have to try to guess whether it's "actually gzipped" or "just content-encoded"
Then I'll take a look at server settings, actual headers and code when I have time.
*** Bug 123192 has been marked as a duplicate of this bug. ***
I haven't spent time to take a look at actual packets, yet. I noticed Mozilla decodes zgip/bz2 files in some cases. Try http://snaps.php.net/
This makes life difficult for me. http://hosted.barrysworld.net/basiliskii/rail/photos.html is where I am usually bitten by it...
From comments in this bug, it sounds like it's a problem with content-encoding rather than transfer-encoding. Update summary?
When saving a file Mozilla obviously forgets to parse the received HTTP header for the presence of the "Content-Encoding:" header (and to decode it before saving if necessary) as specified in RFC 2616 section 14.11 (HTTP 1.1) and RFC 1945 section 10.3 (HTTP 1.0). This is also necessary if the file is in the cache and Mozilla is offline! Here are some wget logfiles for http://hosted.barrysworld.net/basiliskii/rail/photos.html: without the accept-content header: ---request begin--- GET /basiliskii/rail/photos.html HTTP/1.0 User-Agent: Wget/1.7 Host: hosted.barrysworld.net Accept: */* Connection: Keep-Alive ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Sun, 17 Feb 2002 08:26:56 GMT Server: Apache Last-Modified: Thu, 07 Feb 2002 19:43:16 GMT ETag: "3c199-1805-3c62d8d4" Accept-Ranges: bytes Content-Length: 6149 Connection: close Content-Type: text/html Length: 6,149 [text/html] and now with the header: ---request begin--- GET /basiliskii/rail/photos.html HTTP/1.0 User-Agent: Wget/1.7 Host: hosted.barrysworld.net Accept: */* Connection: Keep-Alive Accept-Encoding: gzip, deflate, compress;q=0.9 ---request end--- HTTP request sent, awaiting response... HTTP/1.1 200 OK Date: Sun, 17 Feb 2002 08:27:26 GMT Server: Apache Last-Modified: Thu, 07 Feb 2002 19:43:16 GMT ETag: "3c199-1805-3c62d8d4" Accept-Ranges: bytes Connection: close Content-Type: text/html Content-Encoding: gzip Content-Length: 2057 Length: 2,057 [text/html]
*** Bug 126007 has been marked as a duplicate of this bug. ***
> and is only decoded before rendering or analogous usage. It's not clear that saving is analogous usage. The problem with content encoding is that the encoding is an integral part of the data, unlike with transfer encoding. So we _should_ save with the content encoding. Servers often use content encoding when they mean transfer encoding, however. Please see my comments in bug 121001 For example, type application/tar content-encoding gzip should not be decompressed before saving. IE gets this wrong because it always decodes. All that said, I am working on a possible fix.
16 years ago
fixed by checkin for bug 69306
*** Bug 127954 has been marked as a duplicate of this bug. ***