HttpEntity.writeTo vs. EntityUtils.toByteArray

[Charles François Rey-2]

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 
):

1):
byte[] a1 = EntityUtils.toByteArray(entity);
System.out.println("a1.length=" + a1.length);

or 2):
ByteArrayOutputStream os = new ByteArrayOutputStream();
entity.writeTo(os);
byte[] a2 = os.toByteArray();
System.out.println("a2.length=" + a2.length);

Thanks in advance for your comments!

(My versions of HttpClient and HttpCore are 4.0 and 4.0.1 respectively.)

--
Charles François Rey
---------------------------------------------------------------------
To unsubscribe, e-mail: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...

[olegk]

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: httpclient-users-unsubscribe@...
For additional commands, e-mail: httpclient-users-help@...