[ mailman-Bugs-905910 ] Wrong headers sent with gzip'd

SourceForge.net noreply at sourceforge.net
Fri Jul 23 01:03:15 CEST 2004

Bugs item #905910, was opened at 2004-02-27 10:20
Message generated for change (Comment added) made by jcflack
You can respond by visiting: 

Category: Web/CGI
Group: 2.1 (stable)
Status: Open
Resolution: None
Priority: 5
Submitted By: Tim Altman (junyor)
Assigned to: Nobody/Anonymous (nobody)
Summary: Wrong headers sent with gzip'd 

Initial Comment:
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 

GET /mailman/<removed>/2004-February.txt.gz 
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, *;
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


Comment By: Chapman Flack (jcflack)
Date: 2004-07-22 18:03

Logged In: YES 

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.


You can respond by visiting: 

More information about the Mailman-coders mailing list