You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Svilena Momova (JIRA)" <ji...@apache.org> on 2015/11/25 15:46:11 UTC
[jira] [Comment Edited] (HTTPCLIENT-1699) Content of response with
content-encoding: deflate cannot be read
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1699?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15026850#comment-15026850 ]
Svilena Momova edited comment on HTTPCLIENT-1699 at 11/25/15 2:45 PM:
----------------------------------------------------------------------
Hello Oleg,
The response of the server is complete. Sent content is not in zlib format, but it is a deflate stream (pure deflate, without 0x78... header bytes).
According to hc documentation, DeflateInputStream must be capable of working with both: zlib and pure deflate.
I dumped the http response from the server and I did some simple tests with the content.
If I load the compressed content within org.apache.http.client.entity.DeflateInputStream, it gets recognized as non-zlib and the sourceStream member variable gets initialized on line 122 with new DeflateStream(pushback, new Inflater(true)); which seems to be correct. But at the end the mentioned exception happens, because the EOF is processed somehow incorrectly.
If I load the same compressed content in a simple test program using only an Inflater with nowrap = true, and calling Inflator's methods setInput, needsInput and inflate, the content is decompressed correctly without any errors.
Additionally with Firefox and Chrome I am able to fetch the content again without any problems.
Could you please double-check how is DeflateInputStream acting when it has to deal with pure deflate content?
Regards,
Svilena
was (Author: svilena):
Hello Oleg,
The response of the server is complete. Sent content is not in zlib format, but it is a deflate stream (pure deflate, without 0x78... header bytes).
According to hc documentation, DeflateInputStream must be capable of working with both: zlib and pure deflate.
I dumped the http response from the server and I did some simple tests with the content.
If I loaded the compressed content within org.apache.http.client.entity.DeflateInputStream, it got recognized as non-zlib and the sourceStream member variable was initialized on line 122 with new DeflateStream(pushback, new Inflater(true)); which seems to be correct. But at the end the mentioned exception happens, because the EOF is processed somehow incorrectly.
If I load the same compressed content in a simple test program using only an Inflater with nowrap = true, and calling Inflator's methods setInput, needsInput and inflate, the content is decompressed correctly without any errors.
Additionally with Firefox and Chrome I am able to fetch the content again without any problems.
Could you please double-check how is DeflateInputStream acting when it has to deal with pure deflate content?
Regards,
Svilena
> Content of response with content-encoding: deflate cannot be read
> -----------------------------------------------------------------
>
> Key: HTTPCLIENT-1699
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1699
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.5.1
> Environment: Windows7,
> java version "1.8.0_66"
> Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
> Reporter: Svilena Momova
>
> Hello,
> I'm using httpclient-4.5.1. Yesterday I received http chunked response with content-encoding header with value "deflate".
> Trying to read the compressed content from the response I get an exception with the following stack trace:
> {noformat}
> java.io.EOFException: Unexpected end of ZLIB input stream
> at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:240)
> at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:158)
> at org.apache.http.client.entity.DeflateInputStream.read(DeflateInputStream.java:153)
> at org.apache.http.client.entity.LazyDecompressingInputStream.read(LazyDecompressingInputStream.java:73)
> {noformat}
> It seems that when the end of the content is reached, instead of correct closing of the stream, this exception happens.
> Can you please confirm the issue and when it could be fixed?
> Thank you!
> Best Regards,
> Svilena Momova
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org