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] [Resolved] (HTTPCLIENT-1223) Cache could be more aggressive on cache invalidations from Content-Location
Date Wed, 22 Aug 2012 20:16:41 GMT

     [ 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message