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.
