Python list archives double-gzipped?

[Tim Chase]

On 08/27/12 08:52, Andreas Perstinger wrote:
> On 27.08.2012 03:40, Tim Chase wrote:
>> So it looks like some python-list@ archiving process is double
>> gzip'ing the archives.  Can anybody else confirm this and get the
>> info the right people?
> 
> If you send the "Accept-Encoding: gzip, deflate"-header, the server will 
> gzip the file a second time (which is arguably unnecessary) and responds 
> with "Content-Encoding: gzip" and "Content-Type: application/x-gzip" 
> (which is IMHO correct according to RFC2616/14.11 and 14.17[3]).
> But because many servers apparently don't set correct headers, the 
> default behaviour of most browsers nowadays is to ignore the 
> content-encoding for gzip files (application/x-gzip - see bug report for 
> firefox[4] and chromium[5]) and don't uncompress the outer layer, 
> leading to a double gzipped file in this case.

That corresponds with what I see in various testing.  To whomever
controls the python.org web-server, is it possible to tweak Apache
so that it doesn't try to gzip *.gz files?  It may ameliorate the
problem, as well as reduce server load (since it's actually taking
the time to make the file larger)

-tkc