Jon Moore created HTTPCLIENT-1223:
-------------------------------------
Summary: 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
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]
