W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: Proposal for i23: no-store invalidation

From: Henrik Nordstrom <henrik@henriknordstrom.net>
Date: Mon, 08 Jun 2009 17:33:46 +0200
To: "Roy T. Fielding" <fielding@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <1244475226.26988.209.camel@localhost.localdomain>
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

  * 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

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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:19 UTC