gzip encoding in the default configuration

["Jeffrey W. Baker" <jw...@acm.org>]

i am interested in the history behind these two lines in httpd.conf.dist
in the 1.3.x version of apache:

    AddEncoding x-compress Z
    AddEncoding x-gzip gz tgz

these two line cuase a browser to decompress gz files automatically.  
according to the comments in httpd.conf.dist, this was done on purpose.  
the problem this is causing for me is that files like, for example,
linux-2.4.0-test9.tar.gz, are decompressed during download at a rather
extraordinary 6-to-1 ratio.  when i download these files, i expect them to
land on my disk in compressed format, just as if i had downloaded them
using ftp.  when i download them from an apache server, they are
decompressed by my browser.

why were these encodings added?  it seems more appropriate to use a mime
type application/x-gzip with the identity encoding, than to use the tar
mime type with an x-gzip encoding.

fyi see this mozilla bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=35956

-jwb

Re: gzip encoding in the default configuration

[Martin Kraemer <Ma...@Mch.sni.de>]

On Tue, Oct 24, 2000 at 08:16:39AM -0700, Jeffrey W. Baker wrote:
> i am interested in the history behind these two lines in httpd.conf.dist
> in the 1.3.x version of apache:
> 
>     AddEncoding x-compress Z
>     AddEncoding x-gzip gz tgz
> 
> these two line cuase a browser to decompress gz files automatically.  
> according to the comments in httpd.conf.dist, this was done on purpose.  
> the problem this is causing for me is that files like, for example,
> linux-2.4.0-test9.tar.gz, are decompressed during download at a rather
> extraordinary 6-to-1 ratio.  when i download these files, i expect them to
> land on my disk in compressed format, just as if i had downloaded them
> using ftp.  when i download them from an apache server, they are
> decompressed by my browser.
> 
> why were these encodings added?  it seems more appropriate to use a mime
> type application/x-gzip with the identity encoding, than to use the tar
> mime type with an x-gzip encoding.
> 
> fyi see this mozilla bug:
> http://bugzilla.mozilla.org/show_bug.cgi?id=35956
> 
> -jwb

See what headers are really returned when you access, e.g., linux-2.4.0-test9.tar.gz:
% HEAD http://www.kernel.org/pub/linux/kernel/v2.4/linux-2.4.0-test9.tar.gz
HTTP/1.0 200 OK
Date: Fri, 27 Oct 2000 07:24:02 GMT
Server: Apache/1.3.14 (Unix)  (Red-Hat/Linux)
Last-Modified: Tue, 03 Oct 2000 16:36:40 GMT
ETag: "8a404b-15d4086-39da0b18"
Accept-Ranges: bytes
Content-Length: 22888582
Content-Type: application/x-tar         <----------------------
Content-Encoding: x-gzip                <----------------------
Via: 0.9 NetHawk
X-Cache: MISS from deejai2.mch.fsc.net
Proxy-Connection: close

With these two lines, a client is expected to know that the MIME type is
a tar file, and it is gzip-encoded. That is *MUCH* more useful than
return the MIME type application/x-gzip, because the client would not
know what the result of the decompression was. In the case above it knows
that after decompression, it's a tar file.

Now if one of these lines is missing, as may happen if you pull the
file via FTP, then your browser will default to text/plain
(just like in the case when you pull a README.gz file). That is in most
cases a configuration error on the server side.

Many server admins forget to add a line
  AddType application/x-tar .tgz
to their configuration, which causes the same problems.

Hope this helps,

   Martin
-- 
  <Ma...@MchP.Siemens.De>      |       Fujitsu Siemens
       <ma...@apache.org>              |   81730  Munich,  Germany