Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Thu, 12 May 2011 17:17:47 +0000 (UTC)
From: "Daniel Rabe (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: 
 <1599745155.7335.1305220667312.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Created] (HTTPCLIENT-1085) Connection is never reused if
 response is gzip with non-negative Content-Length
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org