Andy Lester <[EMAIL PROTECTED]> writes: > > Brian - Had I read your code more closely, I would have > > seen this! I agree with you that handling this at the > > LWP layer makes more sense than handling it in > > Mechanize. > > 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? But, it does make sense to have something in LWP that makes decompression of content easy. It could for instance just a library of LWP compatible content callback functions that do decoding on the fly. Also note that LWP already do transparent decompression at the Content-Transfer-Encoding level, so if you have a server that can compress on-the-fly it should just work. This is different in that it does not modifiy the actual payload of the message. > 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. --Gisle
