hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Moore (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HTTPCLIENT-1223) Cache could be more aggressive on cache invalidations from Content-Location
Date Fri, 17 Aug 2012 17:04:38 GMT
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,
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

View raw message