Librarian shouldn't claim "Content-Encoding: gzip" for already-gzipped files

[rasz]

http://librarian.launchpad.net/6877553/wine_0.9.33.orig.tar.gz

GET /6877553/wine_0.9.33.orig.tar.gz HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; X11; Linux i686; en) Opera 9.20
Host: librarian.launchpad.net
Accept: text/html, application/xml;q=0.9, application/xhtml+xml, image/png, image/jpeg, image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en-US,en;q=0.9
Accept-Charset: iso-8859-1, utf-8, utf-16, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;q=0
Referer: http://my.opera.com/community/forums/topic.dml?id=183622
Connection: Keep-Alive

HTTP/1.0 200 OK
Date: Tue, 03 Apr 2007 03:55:01 GMT
Server: TwistedWeb/2.4.0
Last-modified: Tue, 20 Mar 2007 21:25:14 GMT
Content-length: 15322503
Content-type: application/gzipped-tar
Via: 1.1 librarian.launchpad.net
Connection: close
Content-Encoding: gzip

server is telling my browser that Content-Encoding: gzip = my browser tries to decompress the file on the fly, but the file is allready "application/gzipped-tar" so server should not send "Content-Encoding: gzip" because it is NOT encoding it, it is just serving it.

[rasz (citizenr)]

this is not a dupe :(

this link
http://librarian.launchpad.net/6877553/wine_0.9.33.orig.tar.gz

will give you EVERY TIME this header :
Content-type: application/gzipped-tar
Content-Encoding: gzip

= misconfigured server, its not random, server sends correct data, the only bug is the "Content-Encoding: gzip" when serving allready zipped file, server is sending this header, but not gzipping anything(just passing bits).

[Ian Jackson (ijackson)]

The submitter is correct and this is not a duplicate of 89194.

[Diogo Matsubara (matsubara)]

Note that librarian re-encoding a gzipped file doesn't really hurt. I tested on Opera 9.10 and FF 2.0.0.2, on both I got the file download dialog when I clicked the link and successfully donwloaded the file.

Am I missing something?

[Ian Jackson (ijackson)]

Diogo Matsubara writes ("[Bug 102652] Re: Librarian should not re-encode gzipped files"):
> - Content-Encoding: gzip and Content-type: application/gzipped-tar
> + Librarian should not re-encode gzipped files

I think this is an erroneous description. The file is _not_ being
_reencoded_. The file is being served up as-is (gzipped tarfile), but
the Content-Type and Content-Encoding headers together wrongly suggest
that it was wrongly reencoded (ie, these headers are those which would
correspond to a gzipped gzipped tarfile).

Ian.

[rasz (citizenr)]

yes, Diogo Matsubara added
"+ Librarian should not re-encode gzipped files"
but its not true

librarian is NOT re-encoding, its adding "Content-Encoding: gzip"
Content-Encoding: gzip should be added only when server is encoding something, it should not be added when the server is serving allready encoded file.

>Note that librarian re-encoding a gzipped file doesn't really hurt. I tested on Opera 9.10 and FF 2.0.0.2, on both I got the file
>download dialog when I clicked the link

yes, you got the file download dialog, now in Opera click CANCEL on this download dialog - Opera will think it is a webpage gzipped by the server, will try to unzip it on the fly and display it like html = BAD thing.

> and successfully donwloaded the file.

no you didnt, browser decompressed it on the fly because server told it to do it by "Content-Encoding: gzip", look at the file on the disk, it has a name wine_0.9.33.orig.tar.gz, but is a text file not a tar.gzip

[Gustavo Niemeyer (niemeyer)]

As reported by Floris Bruynooghe at

    http://bruynooghe.blogspot.com/2007/09/theres-first-time-for-everying.html

the headers provided by Launchpad on file releases such as

    https://edge.launchpad.net/storm/trunk/0.10/+download/storm-0.10.tar.gz

will trick Firefox into decompressing the file before saving.

Considering that kind of comment, it'd be good to consider a fix for this.

[Sidnei da Silva (sidnei)]

I would like to request this bug priority to be raised since it really affects all Firefox users.