[
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 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]
