apache (mod_deflate?) weirdness

I am using apache 2.0.48, which I compiled from source with mod_deflate. I
enabled this gzip deflation in httpd.conf with
AddOutputFilterByType DEFLATE text/html text/plain

I know the deflation is working, because enabling the above directive
causes an approx. 50% reduction in the size of HTML files delivered.
Fantastic! However, what's bothering me is the way the server is treating
certain files - specifically, tar.gz.md5. A demonstration:
http://www.pc-tools.net/temp/

In my mime.types I have:
text/plain asc txt md5

Yet web browsers can not seem to display hello.tar.gz.md5 , while they
display hello.md5 and hello.txt properly. According to the mime.types,
aren't ALL of these files text/plain? And if so, how can they be
interpreted differently?

--
Jem Berkes
http://www.sysdesign.ca/

In article <Xns942ED092197C3jbuserspc9org@205.200.16.73>, Jem Berkes wrote:
> I am using apache 2.0.48, which I compiled from source with mod_deflate. I
> enabled this gzip deflation in httpd.conf with
> AddOutputFilterByType DEFLATE text/html text/plain
>
> I know the deflation is working, because enabling the above directive
> causes an approx. 50% reduction in the size of HTML files delivered.
> Fantastic! However, what's bothering me is the way the server is treating
> certain files - specifically, tar.gz.md5. A demonstration:
> http://www.pc-tools.net/temp/
>
> In my mime.types I have:
> text/plain asc txt md5
>
> Yet web browsers can not seem to display hello.tar.gz.md5 , while they
> display hello.md5 and hello.txt properly. According to the mime.types,
> aren't ALL of these files text/plain? And if so, how can they be
> interpreted differently?

Apache will look at several of the suffixes and this might be causing
you problems. The file may be being treated as already compressed.
You probably want to start capturing complete logs of the requests
so that you can see what is going on.

>> Yet web browsers can not seem to display hello.tar.gz.md5 , while
>> they display hello.md5 and hello.txt properly. According to the
>> mime.types, aren't ALL of these files text/plain? And if so, how can
>> they be interpreted differently?
>
> Apache will look at several of the suffixes and this might be causing
> you problems. The file may be being treated as already compressed.
> You probably want to start capturing complete logs of the requests
> so that you can see what is going on.

Nuts, I didn't know it looked at multiple suffixes. Maybe I'll just name
my files differently then :)

The following shows the full headers sent and received to the server,
first from lynx and then from my keyboard. Note that after getting the
file, lynx said: "Alert!: Error uncompressing temporary file!"

I just don't see why "Content-Encoding: x-gzip" should come in reply to
the second request, because the client did not indicate support for gzip.

======== Lynx request ========
GET /temp/hello.tar.gz.md5 HTTP/1.0
Host: www.pc-tools.net
Accept: text/html, text/plain, text/sgml, */*;q=0.01
Accept-Encoding: gzip, compress
Accept-Language: en
User-Agent: Lynx/2.8.4rel.1 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.7b

======== Reply to Lynx ========
HTTP/1.1 200 OK
Date: Mon, 10 Nov 2003 16:05:10 GMT
Server: Apache
Last-Modified: Mon, 10 Nov 2003 02:23:02 GMT
ETag: "1f84a-2c-79262d80"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/plain; charset=ISO-8859-1
Content-Encoding: gzip

This is hello.tar.gz.md5, a plain text file
======== end ========

Now doing a manual request

======== Simple request ========
GET /temp/hello.tar.gz.md5 HTTP/1.1
Connection: close
Host: www.pc-tools.net
======== Reply to simple request ========
HTTP/1.1 200 OK
Date: Mon, 10 Nov 2003 16:13:15 GMT
Server: Apache
Last-Modified: Mon, 10 Nov 2003 02:23:02 GMT
ETag: "1f84a-2c-79262d80"
Accept-Ranges: bytes
Content-Length: 44
Connection: close
Content-Type: text/plain; charset=ISO-8859-1
Content-Encoding: x-gzip

This is hello.tar.gz.md5, a plain text file
======== end ========

--
Jem Berkes
http://www.sysdesign.ca/

>> Yet web browsers can not seem to display hello.tar.gz.md5 , while
>> they display hello.md5 and hello.txt properly. According to the
>> mime.types, aren't ALL of these files text/plain? And if so, how can
>> they be interpreted differently?
>
> Apache will look at several of the suffixes and this might be causing
> you problems. The file may be being treated as already compressed.
> You probably want to start capturing complete logs of the requests
> so that you can see what is going on.

[I'm posting this again because my ISP has terrible USENET service; half
the posts never make it].

The problem appears to be that web browsers are mislead into believing
that 'hello.tar.gz.md5' is a gzip compressed file. It must be based on
picking out the ".gz" within the filename, though this can not be a good
practice? I don't see how it's justifiable when there are more suffixes.

For instance, I have made this manual request (obviously, the 'client'
does not support gzip deflation). Here is the query and response:

======================
GET /temp/hello.tar.gz.md5 HTTP/1.1
Host: www.pc-tools.net
======================
Content-Length: 44
Content-Type: text/plain; charset=ISO-8859-1
Content-Encoding: x-gzip
X-Pad: avoid browser bug

This is hello.tar.gz.md5, a plain text file
======================

So the server is specifying that the reply is deflated (gzip) stream,
whereas it's clearly not. And shouldn't apache NOT provide a compressed
stream anyway, since the client did not indicate this capability?

Sure enough, when I send the request through Lynx the program says:
Alert!: Error uncompressing temporary file!

--
Jem Berkes
http://www.sysdesign.ca/

In article <Xns9430599FF49ABjbuserspc9org@130.179.16.24>, Jem Berkes wrote:
>
> The problem appears to be that web browsers are mislead into believing
> that 'hello.tar.gz.md5' is a gzip compressed file. It must be based on
> picking out the ".gz" within the filename, though this can not be a good
> practice? I don't see how it's justifiable when there are more suffixes.

Using information from multiple suffixes is a feature. That way you can
use one suffix to specify content type and another to specify language.

You can probably work around this problem using an entry in your .htaccess
file to force that file to be of type text/plain.

>> The problem appears to be that web browsers are mislead into
>> believing that 'hello.tar.gz.md5' is a gzip compressed file. It must
>> be based on picking out the ".gz" within the filename, though this
>> can not be a good practice? I don't see how it's justifiable when
>> there are more suffixes.
>
> Using information from multiple suffixes is a feature. That way you
> can use one suffix to specify content type and another to specify
> language.

OK, I didn't know that was intentional. Easy enough to work around then,
this seems to work fine:
http://www.pc-tools.net/files/unix/r...rc2_tar_gz.md5

--
Jem Berkes
http://www.sysdesign.ca/

Jem Berkes <jem@users.pc9__org> writes:
> Yet web browsers can not seem to display hello.tar.gz.md5 , while they
> display hello.md5 and hello.txt properly. According to the mime.types,
> aren't ALL of these files text/plain? And if so, how can they be
> interpreted differently?

What do you mean by "web browsers"? Which specific browsers have
you noticed this behavior with? If you just mean MSIE, that's a
known MSIE "feature" where it thinks it knows better than the server
what type a file has, based on the file extension.

> Jem Berkes <jem@users.pc9__org> writes:
>> Yet web browsers can not seem to display hello.tar.gz.md5 , while they
>> display hello.md5 and hello.txt properly. According to the mime.types,
>> aren't ALL of these files text/plain? And if so, how can they be
>> interpreted differently?
>
> What do you mean by "web browsers"? Which specific browsers have
> you noticed this behavior with? If you just mean MSIE, that's a
> known MSIE "feature" where it thinks it knows better than the server
> what type a file has, based on the file extension.

Mozilla (Firebird)

No, it's an issue on the server side. The HTTP headers show what's going
on.

--
Jem Berkes
http://www.sysdesign.ca/