hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Manish Tripathi (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1164) Compressed entities are not being cached properly
Date Sat, 03 Mar 2012 19:33:58 GMT

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

Manish Tripathi commented on HTTPCLIENT-1164:

Removing Content-Length is basically what I did as a quick hack to solve the issue on my end.
However, I believe that it is not at all a perfect solution. The reason being that without
Content-Length header it would be impossible to perform entity validity checks. For instance,
if the entity was partially downloaded and decompressor was able to decompress partial content
successfully, the cache would return partial (=invalid) content to the requesting code. Right
now this problem is mitigated by comparing Content-Length value to actual length of the entity.

I personally like the first idea much better (to make ContentEncodingHttpClient a wrapper
around HttpClient). Apart from being a solution to this issue, such approach is conceptually
more correct than extending DefaultHttpClient, in my opinion. I must say that this idea also
crossed my mind, but when I looked at the implementation of ContentEncodingHttpClient and
how deeply it integrates with implementation of various aspects of the client, I dropped the
idea. Though I still believe it is the best aproach.
> 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
> 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

View raw message