406948 - Content-Encoding: gzip, Content-Disposition: inline; and tar.gz archives

Status: RESOLVED INACTIVE

(Firefox :: File Handling, defect)

Description

[Matthieu MOY]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

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

Comment 1

[Kevin Brosnan]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11

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

Comment 2

[Matthieu MOY]

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.

Comment 3

[James G Sack (jim)]

I would like to confirm the problem (in 2.0.0.10 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.

Comment 4

[[:Aleksej]]

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.

Comment 5

[Shawn Wilsher :sdwilsh]

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.

Comment 6

[[:Aleksej]]

See comment #4.

The bug is still there. Some consider it useful for gzipped text files, but probably not for tar.

Comment 7

[James G Sack (jim)]

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 

Comment 8

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 9

[Jason Duell]

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.

Comment 10

[Boris Zbarsky [:bzbarsky]]

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.  ;)