Charles François Rey wrote:
Hi,
I receive gzip-compressed content from a server, and I handle it as
suggested in the ClientGZipContentCompression.java example, i.e. via
request and response interceptors. This is all working fine.
But when using HttpEntity.writeTo(OutputStream) to do something with the
content, what I have is the *compressed content* (e.g. length of the
byte array behind my ByteArrayOutputStream: 12'753), whereas
EntityUtils.toByteArray(HttpEntity) gives me the *uncompressed content*
(length=160'991), correctly processed through the
GzipDecompressingEntity/HttpEntityWrapper (cf
ClientGZipContentCompression.java).
In both cases the HttpResponseInterceptor that wraps the entity inside
the GzipDecompressingEntity of the example obviously does its job, it
just seems that HttpEntity.writeTo doesn't use the wrapper's
getContent() but somehow EntityUtils.toByteArray does.
Is it supposed to be that way ? I was surprised, from an API point of
view, that both methods did not (indirectly) yield the same result. Am I
missing a point somewhere ?
You can test the difference by using either one of these 2 snippets of
code inside ClientGZipContentCompression.java
(http://svn.apache.org/repos/asf/httpcomponents/httpclient/trunk/httpclient/src/examples/org/apache/http/examples/client/ClientGZipContentCompression.java):
This is because the GzipDecompressingEntity class in the example does
not implement HttpEntity#writeTo() method, mainly for simplicity, and
therefore what you get is the 'raw' content of the original entity
without decompression.
What you need is make GzipDecompressingEntity#wtiteTo() decompress the
content prior to writing it out to the output stream.
Hope this helps
Oleg
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
