java.util.zip.GZipInputStream
which happens to work just like the fictional GZipInputStream in my code example. So effectively, you have to manually add the Accept-Encoding header and then wrap the resulting stream when appropriate.
Any thoughts on a good way to implement this given the current API? I agree that filters would be ideal in 3.0 but it would be nice to have a drop in solution in the contrib directory for 2.0 if possible (and not to hackish). If a clean API isn't possible or is too much work for 2.0 I might just write an article on how to achieve this and add it to the website. We can then implement support in 3.0.
Regards,
Adrian Sutton.
On Wednesday, July 2, 2003, at 02:13 PM, Laura Werner wrote:
Adrian wrote:
The input stream retrieved from the method would return the gzip encoded data and the GZipInputStream would read that, decompress it and return the actual data. A similar process would be applied to the output stream.
We're interested in this too, because the http client in our VoiceXML interpreter often has to download huge, multi-megabyte grammar files that are very compressible. I'd be willing to collaborate with anyone who wants to work on creating an HttpClient add-in to make this work.
For HttpClient 3.0, this is one place where the "Filter" concept that Christian mentioned last week would work well. On the request side, the filter would add the Accept-Encoding header, and on the response side it would look for the Content-Encoding header and if it's present then wrap the input stream in an appropriate decoding stream.
-- Laura
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
