RFC 2616 distinguishes between content codings (section 3.5) and transport codings (section 3.6). Content coding is out of scope, as Oleg mentioned. HttpClient will not automatically decompress for example a gzipped tar into a plain tar archive.
Transport coding is in scope for HttpClient/HttpComponents, as we already support "chunked". We can consider adding support for other transport codings, such as "gzip". The pluggable filter architecture of HttpComponents will at least allow you to add your own support for transport codings. I guess that seamless interoperability of the HttpComponents "chunked" implementation with additional custom transport encodings will be made possible on request. I don't think we'll find time to add new transport codings out of the box in HttpClient nor HttpComponents. Which implies that the interaction of chunked with other transport codings will not be tested until somebody tries to do it. It is a tricky thing, since the response filter chain will have to depend on the value of the Transfer-Encoding response header. Given the complexity of the task, I see this item dangling near the end of the to-do list forever. As always, contributions will be welcome. If somebody should contribute code that performs decompression for transport codings, we sure won't stop you from re-using that code for decompression of content codings. But that will remain the responsibility of the application using HttpComponents. cheers, Roland --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
