[
https://issues.apache.org/jira/browse/HTTPCLIENT-1223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jon Moore resolved HTTPCLIENT-1223.
-----------------------------------
Resolution: Fixed
Assignee: Jon Moore
> 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: [email protected]
For additional commands, e-mail: [email protected]
