[Pkg-chromium-maint] Bug#677948: [chromium] When saving a file served with gzip Content-Encoding and application/x-gzip Content-Type, the file is saved (double-)compressed
Filipus Klutiero
chealer at gmail.com
Mon Jun 18 01:59:23 UTC 2012
Package: chromium
Version: 18.0.1025.151~r130497-1
Severity: normal
Tags: upstream
When saving a file served with gzip Content-Encoding and
application/x-gzip Content-Type, the file is saved compressed (Chromium
does not decompress the content). Amazingly, all major browsers have the
same problem. Firefox has it (see
https://bugzilla.mozilla.org/show_bug.cgi?id=610679 ), Konqueror 4.7.4,
Opera 11.62, Safari 5.1.4 and Internet Explorer 8. Even wget has the
problem, in a sense (see
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=150766 ). The only
browser which doesn't have this problem that I found is NetSurf (tested
on version 2.8). Otherwise, curl doesn't have the problem.
I discovered this bug on http://release.debian.org/britney/ with
update_output.txt.gz. The same problem also affects
update_excuses.html.gz. The server is Apache. I was able to reproduce
this using my system as the server and a random .txt.gz found locally (a
README). The file I use to test is /usr/share/doc/xz-utils/faq.txt.gz
from xz-utils and has MD5 sum 3d9b4fbacb5c1c4b6fc6930ad02abd28. When I
download it and hit this bug, the double-gzipped version I get has MD5
sum 4b978d76df448f894fcf427f86d74674. I hit this bug when downloading
from my local httpd, Apache 2.2.22 on testing, with a highly stock
configuration.
In practice, this only happens when a gzipped file is gzipped during
transfer, and this is understandably rare. It's a performance bug that
Apache gzips a gzipped file, but it happens in a few situations, as in
the case of a gzipped text file. Apache's content coding is managed by
mod_deflate. mod_deflate is enabled by default, but only for some MIME
types for which compression is known to be efficient, for example text
files. The AddOutputFilterByType directive is used to tell mod_deflate
to compress some MIME types. The default configuration (deflate.conf)
contains:
> AddOutputFilterByType DEFLATE text/html text/plain text/xml
It is arguably an Apache bug that problematic files (.txt.gz) are
considered as text/plain, since they're compressed, but this is what
happens, and explains the server's behavior.
The problem does not only happen with Apache, it also happened when I
tried with lighttpd, but not by default. By default, lighttpd would send
Content-Type application/octet-stream IIRC. After some hacking in
lighttpd.conf (compress.filetype = ( "application/javascript",
"text/css", "text/html", "text/plain", "application/x-gzip" )) and
/usr/share/lighttpd/create-mime.assign.pl, I obtained the same problem.
I added the following just before the last line of
/usr/share/lighttpd/create-mime.assign.pl:
> print ' ".tar.gz" => "application/x-tgz",';
> print "\n";
> print ' ".gz" => "application/x-gzip",';
> print "\n";
This was reported upstream in
http://code.google.com/p/chromium/issues/detail?id=47951 but this will
not be fixed upstream.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: faq.txt.gz
Type: application/gzip
Size: 3835 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/pkg-chromium-maint/attachments/20120617/ee75f008/attachment-0001.bin>
More information about the Pkg-chromium-maint
mailing list