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

Bug #102652 reported by rasz on 2007-04-03
Affects Status Importance Assigned to Milestone
Launchpad itself

Bug Description

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
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
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
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) wrote :

this is not a dupe :(

this link

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) wrote :

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

Changed in launchpad:
status: Unconfirmed → Confirmed

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

Am I missing something?

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


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

description: updated
Changed in launchpad:
importance: Undecided → Low
Gustavo Niemeyer (niemeyer) wrote :

As reported by Floris Bruynooghe at

the headers provided by Launchpad on file releases such as

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) wrote :

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

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers