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

Re: Proposal for i23: no-store invalidation

From: Roy T. Fielding <fielding@gbiv.com>
Date: Mon, 8 Jun 2009 15:29:34 +0200
Message-Id: <89B6434F-2355-4367-8D1D-D0D7D25BE583@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
On Jun 8, 2009, at 2:57 PM, Henrik Nordstrom wrote:

> mån 2009-06-08 klockan 20:57 +1000 skrev Mark Nottingham:
>> Ping?
>> I'm still struggling to understand what you want here; see also Roy's
>> comment on the issue in the tracker.
>> Are you talking about 304 responses, 200 responses, *any* response to
>> a GET...?
> It's about generalizing the rule to get a consistent cache behavior
> independent of if the request was a GET or HEAD.
> To answer the comment from Roy there is other conditions as well where
> the request may need to be forwarded even if the cached entry still
> looks valid as such. For example if the request contained Cache- 
> Control:
> max-age=N, Cache-Control: no-cache or at the extreme Cache-Control:
> no-store (note: in all these cases as request headers, not response
> headers). Without having the statement generalized there is corner  
> cases
> where a GET could still leave old entries in the cache but a HEAD with
> the exact same conditions would force them to be invalidated. Mainly
> when the cache contains a still seemingly valid response but the
> resource has changed on the server and no longer results in a  
> cacheable
> response.

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.

Received on Monday, 8 June 2009 13:30:04 UTC

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