Re: Proposal for i23: no-store invalidation

On Jun 8, 2009, at 5:33 PM, Henrik Nordstrom wrote:

> mån 2009-06-08 klockan 15:29 +0200 skrev Roy T. Fielding:
>
>> I don't follow.  If the cache is involved in the request, then it  
>> will
>> invalidate the cached response when it receives a 200.  If the cache
>> is not involved in the request (no-cache or no-store) then it has
>> no part in the communication and cannot be required to do anything.
>
> The thing is that there is nothing that says the cache should  
> invalidate
> the previous response except implicit where the new response replaces
> the previous response in the cache. The exception is a couple special
> cases
>
>   * HEAD responses
>
>   * Negotiated resources with Content-Location

Shouldn't that be in the definition of refreshing a cache?  Perhaps we
need more introductory material.

> There is several conditions where the new response won't get stored in
> the cache. Under those conditions there is no rule which tells caches
> how to deal with the older cached entry unless the request was a HEAD
> request or a negotiated resource... or at least that's my reading.
> Common sense says to apply the same rule as for HEAD responses,
> invalidating the prior response if the new response indicates
> significant change of the resource.

I would go with the common sense, except keep in mind that the
request fields for no-cache and no-store are for bypassing any
cache entirely -- it is okay to ignore the response because the
expectation is that the "cache" component is separate from the
agent/proxy/gateway/origin component handling that request.

> Example such conditions:
>
>  * Cache-Control: no-store

On a request, this is an instruction to the proxy/gateway to bypass
the cache (if any).  On a response to a validating request, it
invalidates whatever is cached because it is new metadata.

>  * Cached response considered fresh by cache but not meeting request
> requirements, and the new response is not cacheable.

That invalidates the current cached item if the cache sent
a validating request.

>  * As above, but cache for other reasons selects not to store the new
> response.

That is outside the protocol, I think.  What matters is that the
server's current instructions regarding the representation be
understood (explained by the protocol).

....Roy

Received on Tuesday, 9 June 2009 09:50:35 UTC