Re: Proposal for i23: no-store invalidation

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

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.

It somewhat ties together with the invalidating requirement on
negotiated resources when seeing two responses with same
Content-Location but different entity-tag, or the requirement on
invalidation on mismatching HEAD responses. 

Example such conditions:

 * Cache-Control: no-store

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

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

Regards
Henrik

Received on Monday, 8 June 2009 15:34:27 UTC