[
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: [email protected]
For additional commands, e-mail: [email protected]
