
Hi Folks! I've been bit by a bug in mailman 2.0.1 where mailman assumes that there will always be an uncompressed version of a monthly private archive file hanging around, which for my setup isn't the case. Path truncation in the content_type routine wrongly chomps off .gz extension. Here is how I fixed the bug: --- mailman/Mailman/Cgi/private.py.orig Tue Aug 26 15:24:04 2003 +++ mailman/Mailman/Cgi/private.py Tue Aug 26 16:06:04 2003 @@ -84,7 +84,8 @@ def content_type(path): if path[-3:] == '.gz': - path = path[:-3] + # path = path[:-3] + return 'application/x-gzip' if path[-4:] == '.txt': return 'text/plain' return 'text/html' @@ -186,9 +187,9 @@ f = open(os.path.join(mlist.archive_directory + '.mbox', mlist.internal_name() + '.mbox')) ctype = 'text/plain' - elif true_filename[-3:] == '.gz': - import gzip - f = gzip.open(true_filename, 'r') + #elif true_filename[-3:] == '.gz': + # import gzip + # f = gzip.open(true_filename, 'r') else: f = open(true_filename, 'r') except IOError: It also occured to me that mailman is bothering to decompress compressed archive files before sending them back to the web client. This is wrong in many ways: 1) extra load decompressing the file 2) clients getting a file back with a .gz extention that is really a text file 3) extra bandwidth consumed while sending the uncompressed file back to the client 4) many web browsers will silently decompress application/x-gzip mime data automatically I checked Mailman 2.1.2 to see if any of this is still done, and apparently the decompression issue still is, at least in the copy I have here. (haven't checked cvs head). Here's my version of a fix for this: --- mailman-2.1.2/Mailman/Cgi/private.py.orig 2003-08-26 16:46:16.000000000 -0400 +++ mailman-2.1.2/Mailman/Cgi/private.py 2003-08-26 16:47:21.000000000 -0400 @@ -148,8 +148,8 @@ mlist.internal_name() + '.mbox')) ctype = 'text/plain' elif true_filename.endswith('.gz'): - import gzip - f = gzip.open(true_filename, 'r') + ctype = 'application/x-gzip' + f = open(true_filename, 'r') else: f = open(true_filename, 'r') except IOError: Most folks on non-Linux-like operating systems have some kind of decompression software available that can handle gz format even if their browser does not. Kind Regards, Matthew Galgoci -- Matthew Galgoci "Dirty deeds, done dirt cheap" System Administrator Red Hat, Inc 919.754.3700 x44155

On Tue, 2003-08-26 at 17:06, Matthew Galgoci wrote:
Hi Folks!
Hi Matthew!
I checked Mailman 2.1.2 to see if any of this is still done, and apparently the decompression issue still is, at least in the copy I have here. (haven't checked cvs head). Here's my version of a fix for this:
--- mailman-2.1.2/Mailman/Cgi/private.py.orig 2003-08-26 16:46:16.000000000 -0400 +++ mailman-2.1.2/Mailman/Cgi/private.py 2003-08-26 16:47:21.000000000 -0400 @@ -148,8 +148,8 @@ mlist.internal_name() + '.mbox')) ctype = 'text/plain' elif true_filename.endswith('.gz'): - import gzip - f = gzip.open(true_filename, 'r') + ctype = 'application/x-gzip' + f = open(true_filename, 'r') else: f = open(true_filename, 'r') except IOError:
Could you please submit a SF patch on this? Less of a chance of getting lost in my inbox. ;) -Barry
participants (2)
-
Barry Warsaw
-
Matthew Galgoci