Connection is never reused if response is gzip with non-negative Content-Length
-------------------------------------------------------------------------------
Key: HTTPCLIENT-1085
URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1085
Project: HttpComponents HttpClient
Issue Type: Improvement
Components: HttpClient
Affects Versions: 4.1.1
Reporter: Daniel Rabe
Priority: Minor
While debugging a separate issue, I noticed that DefaultConnectionReuseStrategy
is very sensitive to whether the server returns a positive content-length or
content-length=-1 with chunked encoding. In particular, I saw two cases:
(1) Server returns gzip response with Content-Length=-1, chunked encoding. The
connection is reused.
(2) Server returns gzip response with
Content-Length=<actual-number-of-bytes-in-response> The connection is NOT
reused.
This is because of the following code in DefaultConnectionReuseStrategy:
if (entity.getContentLength() < 0) {
if (!entity.isChunked() ||
ver.lessEquals(HttpVersion.HTTP_1_0)) {
// if the content length is not known and is not chunk
// encoded, the connection cannot be reused
return false;
}
}
GzipDecompressingEntity implements its getContentLength as always returning -1.
However, it is not chunked. Therefore, the connection is not reused.
I'm not sure if you would consider this a bug or a request for enhancement, but
it seems to me that if the server is returning an accurate content-length, the
client should be able to consume that number of bytes, then reuse the
connection.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
