httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Ausbeck <>
Subject Re: Compression via content negotiation
Date Wed, 02 Dec 1998 21:03:49 GMT
Rodent of Unusual Size wrote:

> Is this actually true?  ISTR lots of problems with IE downloading
> gzipped files and stripping the .gz extension -- but not actually
> gunzipping them.  I don't think I'd call that doing the right
> thing..  Maybe it works properly if the uncompressed document
> is a displayable content-type, but not for others?

Yes this only works correctly for displayable content. For example, if a
request is made for NPpwc32.dll.gz, and apache is configured as follows:
AddEncoding gzip gz, things don't work but not because decompression is
not done. IE decompresses the file but messes up on the filename that it
suggests for saving to disk (nppwc32_dll(1).gz). This is because its url
to suggested filename code is broken not because compression is broken. 

Navigator 4.5 also does not work for non-displayable content (at least
on Windows 95). In the preceding test case, it comes up with the
suggested filename of NPpwc32_dll.gz AND doesn't decompress to boot.
This is probably better behavior that IE in that since it kept the .gz
extension it shouldn't decompress. Note the (1) on the IE suggested
filename. This is IE's way of indicating that the file has been altered
(copied) during transmission.

The problem here is that on the PC platform, multiple . extensions are
not normally used. Probably because of the rarity of this sort of thing
occuring in practice, the browser folks don't seem to have put much
effort into handling this. 

In order to avoid problems, the gz extension should be reserved for
"content-encoding" compression. Publically advertised or href url's that
are compressed typically should only be deflated (.zip). On the Windows
platform, zip is far more common than gzip. Under UNIX both are
typically available. 

The default apache distribution seems to do the best thing possible. In
the default mime.types, only application/zip is defined. Example
AddEncodings are in in the default srm.conf only for the suffix coders
gzip (.gz) and compress (.Z). This seems like a good compromise in that
zip does have a default suffix addition behavior.

View raw message