You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Jon Moore (JIRA)" <ji...@apache.org> on 2012/08/22 22:16:42 UTC
[jira] [Closed] (HTTPCLIENT-1223) Cache could be more aggressive on
cache invalidations from Content-Location
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jon Moore closed HTTPCLIENT-1223.
---------------------------------
> Cache could be more aggressive on cache invalidations from Content-Location
> ---------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1223
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1223
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: Cache
> Affects Versions: 4.2.1
> Reporter: Jon Moore
> Assignee: Jon Moore
> Priority: Minor
> Fix For: 4.2.2, 4.3 Final
>
>
> When a response to a PUT, POST, or DELETE carries a Content-Location header, there are certain cases where the cache MUST invalidate its entry for the URI in the Content-Location header, namely:
> 1. If the Date on the response is later than the Date on the entry; OR
> 2. If the Etag on the response is different than the one on the entry.
> The tricky bit is when the Dates match, as it isn't a priori clear which is more up-to-date, as responses can be received out-of-order. Right now the caching client errs on the side of caching things and relying on the Cache-Control semantics of the existing entry to specify freshness. I'm wondering if this isn't the wrong tradeoff, as the cache is receiving the response after the entry already exists, so there is a strong likelihood that the response is actually fresher (even though we can't tell due to the 1-second granularity of the Date headers) and we probably ought to invalidate in this case.
> The HTTP/1.1 spec does not require one behavior or the other (both are compliant -- I have a patch with this behavior that passes all the ProtocolRequirements/Recommendations unit tests), so this is listed as an improvement. I'll upload a patch shortly.
--
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