hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oleg Kalnichevski (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1164) Compressed entities are not being cached properly
Date Fri, 16 Mar 2012 13:41:39 GMT

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

Oleg Kalnichevski commented on HTTPCLIENT-1164:
-----------------------------------------------

@Jon:
> 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? 

Indeed, DefaultConnectionKeepAliveStrategy does not look at the Content-Length header, but
the DefaultConnectionReuseStrategy does. The strategy considers connections reusable only
if the last message length is delineated either with Content-Length or Transfer-Encoding header.

http://hc.apache.org/httpcomponents-core-ga/httpcore/xref-test/org/apache/http/impl/TestDefaultConnectionReuseStrategy.html#89


However, we are all good, since the headers are removed by the decorator, and not by the protocol
interceptor (before ConnectionReuseStrategy is called), as I initially assumed. The decorator
correctly updates the message after the backend has already completed its execution.   

Great job!

Oleg

PS: I do not think we should backport this feature. There unlikely to be any more releases
from the 4.1.x branch. The stable branch should be for critical bug fixes only.
                
> 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: HttpClient
>    Affects Versions: Snapshot
>            Reporter: Manish Tripathi
>            Assignee: Jon Moore
>             Fix For: 4.2 Beta2
>
>
> 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


Mime
View raw message