Wrong headers sent with gzip'd

[Junyor-users]

The filename and/or headers for list archives are
incorrect. This causes some browsers to choke in
their handling of the files. The filename should have
the ".gz" extension stripped, as the files are really
just text files. Headers currently sent are as
follows:

GET /mailman/<removed>/2004-February.txt.gz
HTTP/1.1
User-Agent: Opera/7.50 (Windows NT 5.1; U) [en]
Host: <removed>
Accept: text/html, application/xml;q=0.9,
application/xhtml+xml, image/png, image/jpeg,
image/gif, image/x-xbitmap, */*;q=0.1
Accept-Language: en
Accept-Charset: windows-1252, utf-8, utf-16,
iso-8859-1;q=0.6, *;q=0.1
Accept-Encoding: deflate, gzip, x-gzip, identity, *;
q=0
Referer: <removed>
Cookie: <removed>
Cookie2: $Version=1
Connection: Keep-Alive, TE
TE: deflate, gzip, chunked, identity, trailers

HTTP/1.1 200 OK
Date: Fri, 27 Feb 2004 15:13:32 GMT
Server: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Transfer-Encoding: chunked
Content-Type: text/plain

[http://sourceforge.net/tracker/index.php?func=detail&aid=905910&group_id=103&atid=100103]

[Jcflack (jcflack)]

I agree it's a problem, I'm not sure the file extension is
the problem.

What I see happening is the http server sends back a
Content-Type: of application/x-gzip instead of text/plain.
For example, here are the headers I got back from a site
that uses Mailman and Apache:

HTTP request sent, awaiting response...
 1 HTTP/1.1 200 OK
 2 Date: Thu, 22 Jul 2004 22:41:58 GMT
 3 Server: Apache/2.0.40 (Red Hat Linux)
 4 Last-Modified: Wed, 21 Jul 2004 07:27:02 GMT
 5 ETag: "39c082-338f-5407bd80"
 6 Accept-Ranges: bytes
 7 Content-Length: 13199
 8 Connection: close
 9 Content-Type: application/x-gzip
10 Content-Encoding: x-gzip

If that were only sent back as follows:

Content-Type: text/plain
Content-Encoding: x-gzip

then the browser would know exactly what to do with it.

I think it is strange that Tim's example shows a different
problem. There the Content-Type is correct (text/plain) but
there doesn't seem to be a Content-Encoding header. That's
odd; usually what I see on Mailman sites is the Content-Type
being mislabeled application/x-gzip.

I'm not sure exactly where the problem falls between Mailman
configuration and http server configuration, but I run into
the same thing at just about every Mailman site I ever
visit, so it needs some attention on the Mailman end even if
it's only documentation on how to configure the server to
send the right headers.