Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Thu, 15 Mar 2012 17:39:37 +0000 (UTC)
From: "Jon Moore (Commented) (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: 
 <250268585.19827.1331833177747.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1426001806.35840.1329211199437.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (HTTPCLIENT-1164) Compressed entities are not
 being cached properly
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13230348#comment-13230348 ] 

Jon Moore commented on HTTPCLIENT-1164:
---------------------------------------

@Oleg: I just wired up the CompressionDecorator around a DefaultHttpClient and the connections seem to be reused just fine, per wire logging + context logging. The DefaultConnectionKeepAliveStrategy doesn't seem to look at the Content-Length header. Am I missing something?

                
> Compressed entities are not being cached properly
> -------------------------------------------------
>
>                 Key: HTTPCLIENT-1164
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1164
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: Cache
>    Affects Versions: Snapshot
>            Reporter: Manish Tripathi
>            Assignee: Jon Moore
>
> org.apache.http.impl.client.cache.CacheValidityPolicy.contentLengthHeaderMatchesActualLength() returns false for entities decompressed by ContentEncodingHttpClient, because the length of decompressed entity stored in cache will be different from the length specified in the response header.
> Consequently, gzipped/deflated entities will never be satisfied from the cache.
> Proposed fix: introduce new field in HttpCacheEntry() - actualContentLength, and populate it with the actual content length rigth before the cache entry is stored in the cache. Change the org.apache.http.impl.client.cache.CacheValidityPolicy.contentLengthHeaderMatchesActualLength() method to compare
> entry.getResource().length() with entry.getActualContentLength()

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
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