[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]

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>