My understanding had always been that content-encoding (when talking about compression) is in practical terms no different than transfer-encoding. LWP already handles transfer-encoding (gzip or deflate), so what's the big deal about it also handling content-encoding compression in a transparent manner? My suggestion would be to make it the default to handle it transparently, but provide an option to turn it off if someone needs access to the raw datastream. All GUI browsers "just do it" - the user doesn't have to be concerned with either content-encoding or transfer-encoding.
If you have a file in .tar.gz format, the web server should NOT return a content-encoding: gzip header. This would incur redundant processing costs on the server & the client, attempting to re-compress an already compressed file for little or no gain. Instead, the server would send an appropriate mime type indicating to the client that this is a compressed archive file (usually handled in a GUI client by presenting a file download dialog box). It may not be what the RFCs originally intended, but modern web server implementations of on-the-fly compression in my experience always use content-encoding rather than transfer-encoding. I've written a server-side plug-in to do this on the Netscape/iPlanet web server, and have done fairly extensive research on what's out there in Apache, etc. --- David Carter [EMAIL PROTECTED] > >-----Original Message----- > >From: Brian Cassidy [mailto:[EMAIL PROTECTED] > >Sent: Wednesday, December 03, 2003 7:11 AM > >To: [EMAIL PROTECTED] > >Subject: RE: RFC: WWW::Mechanize::Compress or LWP patch? > > > >Gisle, > > > >> > The more I'm thinking about it, it's not appropriate for LWP. As far > >as > >> > I can think of, this would be the first and only instance of LWP > >> > modifying content that it receives before passing it back to the > >caller. > >> > I'm not sure that's a direction we should go. > >> > >> I agree. There are lots of questions to answer about what should > >> exactly happen in this case with regard to various Content-* headers. > >> Content-Length is obvious, but there are also headers like > >> Content-MD5. How about partial content with Content-Range? > > > >Like I said in reply to David's message, I would hope that we wouldn't > >have > >to modify the original response at all. > > > >> > Also, there needs to be something selectable for the users who happen > >to > >> > have Compress::Zlib but don't want to get compressed data for > >whatever > >> > reason. > >> > >> It would certainly not happen by default. If you download a .tar.gz > >> file you don't want to end up with a .tar file just because you > >> happened to have Compress::Zlib installed. > > > >Okay, but, wouldn't the tar.gz file be a tar.gz.gz file if it were > >content-encoded (gzip)? Thus uncompressing it would give you back the > >tar.gz > >file. > > > >It was always my understanding that if "content-encoding" has a value, > >then > >doing the reverse will give you back the original file, regardless of any > >original compression. > > > >-Brian > > > >PS: (Whoops, I originally only sent this to Gisle) > > > > > >http://www.gordano.com - Messaging for educators.
