Closed Bug 406948 Opened 15 years ago Closed 4 years ago
Content-Encoding: gzip, Content-Disposition: inline; and tar
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:220.127.116.11) Gecko/20071008 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:22.214.171.124) Gecko/20071008 Firefox/126.96.36.199 Hi, Downloading a .tar.gz archive from a site which sets Content-Disposition: inline leads to Firefox uncompressing the archive on-the-fly, and still saving it as .tar.gz file. This is _very_ confusing for the user: one downloads foo.tar.gz, sees it on disk as foo.tar.gz, and "tar xzvf foo.tar.gz" doesn't work! Other browsers I've tried (links, wget, konqueror) save the file unmodified. I suppose on-the-fly decompression should be activated only when the file is to be displayed immediately, not when it's saved on disk. I can reproduce this with the following PHP code: <?php $filename="toto.tar.gz"; header("Content-Disposition: inline; filename=".basename($filename).";"); header("Content-Type: application/x-tar"); header("Content-Encoding: gzip"); readfile("$filename"); exit(); ?> Reproducible: Always Steps to Reproduce: 1. Download http://www-verimag.imag.fr/~moy/tmp/toto.php (or the above PHP code if this page isn't available) 2. tar xzvf ... 3. Actual Results: File is a tar archive Expected Results: File is a _compressed_ tar archive
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:188.8.131.52) Gecko/20071127 Firefox/184.108.40.206 I get the download dialog box, at some point the do this automatically check box was checked for your case to happen. Check the settings in edit -> preferences -> content -> file types -> advanced -> tar.gz
You missunderstood the issue. I have no problem with Firefox downloading the archive. I _do_ expect this to happen. The issue is that Firefox unzips the file on-the-fly, modifying its content. I download a TAR+gzip archive, I get a TAR archive. I can reproduce that with a plain firefox : $ mv .mozilla mozilla.bak $ firefox 'http://www-verimag.imag.fr/~moy/tmp/toto.php' [X] save to disk $ file Desktop/toto.tar.gz Desktop/toto.tar.gz: POSIX tar archive $ wget --server-response 'http://www-verimag.imag.fr/~moy/tmp/toto.php' [...] HTTP/1.1 200 OK Date: Wed, 05 Dec 2007 13:02:55 GMT Server: Apache/2.0.54 (Debian GNU/Linux) X-Powered-By: PHP/4.3.10-22 Content-Disposition: inline; filename=toto.tar.gz; Content-Encoding: gzip Content-Length: 156 Connection: close Content-Type: application/x-tar [...] `toto.php' saved [156/156] $ file toto.php toto.php: gzip compressed data, from Unix, last modified: Wed Dec 5 10:49:53 2007 See: same URL, same data sent by server, but wget and Firefox get different content.
I would like to confirm the problem (in 220.127.116.11 on Linux), and echo that it is annoying when telling an application to download a file (such as a .gz) that the application performs an unrequested and unwelcome transformation (decompression) on the downloaded file. I have searched for in vain configuration options that might apply. I ccnsider this a serious problem.
I see this with Mozilla/5.0 (X11; U; Linux i686 (x86_64); eo; rv:1.9b4pre) Gecko/2008021804 Minefield/3.0b4pre. If bug 235859 (bug 233047) has been fixed, this one should be NEW and probably in a different component.
Version: unspecified → Trunk
Resolving old UNCONFIRMED Download Manager bugs as INCOMPLETE. If you still see this issue, please reopen. To mark all these bug changes as read, filter on ONOMATOPOEIA.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → INCOMPLETE
See comment #4. The bug is still there. Some consider it useful for gzipped text files, but probably not for tar.
I wouldn't call it useful for any cases. It is an unwanted conversion. A download should deposit a file on my disk without changing it in any way! ..jim
> A download should deposit a file on my disk without changing it in any way! The problem is that a number of sites abuse Content-Encoding, using it when they mean Transfer-Encoding. So they'll send, say, a gzipped Word file with a .doc extension and expect the decompressed data to be saved. So the decision on whether to decompress is based on the filename. However, the filename that's used is the one from the URL; content-disposition is not taken into account at that point. That's definitely a bug. Jason, are you interested in taking a stab at this? The relevant code is in nsWebBrowserPersist::SetApplyConversionIfNeeded and nsExternalAppHandler::OnStartRequest.
Status: UNCONFIRMED → NEW
Component: Download Manager → File Handling
Ever confirmed: true
Product: Toolkit → Core
QA Contact: download.manager → file-handling
Sure, I can put this on my list o' bugs. So the behavior desired is to still decompress based on the filename, but to get the filename from the Content-disposition header (if present: otherwise use the URL)? (Is there any reason not to peek at the file instead of using these filename conventions?). Do we want this just for things that are inlined? I'm sympathetic to the argument that we shouldn't decompress things that we're just saving to disk.
Assignee: nobody → jduell.mcbugs
Status: NEW → ASSIGNED
As architected right now, we need to make the "do we decompress" decision before we get any of the data from the HTTP impl, since that's where the decompression happens. We could peek at the data if we moved the decompression to the exthandler, but I'm not quite sure what we'd even look for there... > Do we want this just for things that are inlined? We want to do this for things we're saving or things we're opening in helper apps. If we don't, you'll get gzipped .doc files on your disk and won't be able to open them in Word.... I can point you to the old bugs on this, or you can follow the CVS blame if you prefer. ;)
Status: ASSIGNED → RESOLVED
Closed: 15 years ago → 4 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.