httpd-docs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: x-gzip content-encoding on downloads in /dist/
Date Thu, 20 Mar 2003 18:13:58 GMT
At 11:27 AM 3/20/2003, Henk P. Penning wrote:
>> From: Thom May <>
>> Does anyone have any objections to me removing the encoding for *.gz*
>> encoding everywhere under /dist?
>  .. and/or add
>    AddType text/plain .md5 .asc
>  in 'dist/.htaccess' ??

Thom wasn't asking about the Content-Type, but the Content-Encoding header.
I've observed Mozilla and other browser attempt to un-gzip any content if the
Content-Encoding header is set.  Instead of "Save File As" a .tar.gz, you
discover that you just have a .tar, which won't match the .md5 or .asc
signature we provided.  I believe that any .tar.gz "package" shouldn't carry
a Content-Encoding: gzip designation, but should set content-type: tar/x-gzip
so that the client doesn't try to do decompression upon receipt.

Simply removing the Content-Encoding designation will cause the browser
to respect our Content-Type for .md5 and .asc files.

Your's and Ken Coar's question highlight a common misunderstanding.
Apache's mod_mime maps extensions by content-type, charset, language,
and encoding (document metadata), as well as the handler, input and output 
filters (behavioral metadata.)  

The only override between two distinct items in that list above, is that the
content-type will replace the charset, if a content-type filename extension 
follows the charset.  E.g. .txt.en can aggregate a content-type header
of text/plain; charset=ISO8859-1 while .en.txt cannot do so since the
text/plain value overwrites the entire content-type header.  But all other
values in that list are independent of one another.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message