At 11:27 AM 3/20/2003, Henk P. Penning wrote:
>> From: Thom May <[EMAIL PROTECTED]>
>> 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.

Bill 

Reply via email to