Subject: Re: Proposal for i23: no-store invalidation

From: Mark Nottingham <[email-masked]>
Date: Mon, 8 Jun 2009 20:57:33 +1000

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...?

Also may be worth to look at my recent proposal which may affect this  
tangentially;
   http://www.w3.org/mid/[email-masked]

Cheers,

On 09/05/2008, at 3:54 PM, Mark Nottingham wrote:

>
> OK, I've created
>  http://www3.tools.ietf.org/wg/httpbis/trac/ticket/117
>
> Henrik, could you identify the changes that need to happen in the  
> drafts?
>
> Cheers,
>
>
> On 17/04/2008, at 6:28 PM, Henrik Nordstrom wrote:
>
>>
>> ons 2008-04-16 klockan 18:58 -0700 skrev Mark Nottingham:
>>
>>> Can you give some examples? 4xx to a GET shouldn't invalidate the
>>> cache, and a cache is allowed to return a cached response when
>>> encountering a 5xx unless must-revalidate is present.
>>
>> I am not talking about error responses. I am talking about this text
>> which currently is only specified for HEAD and not GET:
>>
>>  If the new field values
>>  indicate that the cached entity differs from the current entity (as
>>  would be indicated by a change in Content-Length, Content-MD5, ETag
>>  or Last-Modified), then the cache MUST treat the cache entry as
>>  stale.
>>
>> It's a equally good rule for GET as for HEAD, and having them aligned
>> would help getting rid of cornercases such as the i23 question.
>>
>>> In any case, I believe we can close this issue with no spec  
>>> change; we
>>> may change text regarding cache invalidation separately.
>>
>> Yes. i23 requires no change. This is a separate but quite related  
>> issue.
>>
>> Regards
>> Henrik
>>
>>
>>
>
>
> --
> Mark Nottingham     http://www.mnot.net/
>
>

--
Mark Nottingham     http://www.mnot.net/

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 08 Jun 2009 14:57:49 +0200

> Are you talking about 304 responses, 200 responses, *any* response to  

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.

Regards
Henrik

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 8 Jun 2009 15:29:34 +0200

> resource has changed on the server and no longer results in a  

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.

....Roy

---

From: Henrik Nordstrom <[email-masked]>
Date: Mon, 08 Jun 2009 17:33:46 +0200

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 9 Jun 2009 15:28:38 +1000

I'm a bit wary here. Allowing a request with very restrictive  
requirements (e.g., max-age=0) to automatically invalidate or replace  
a cached response seems like an invitation to a denial of service  
attack. While someone may want to implement it that way, I'm not sure  
that all caches will want to.

Consider: if a request comes in, goes forward to the origin (because  
of restrictive request directives) and the response is a 500, by your  
requirement that means the currently cached response is replaced with  
the 500 response (unless a special case is made, as it is on  
validation responses) -- even when the cache *would* have had a fresh  
stored response if the restrictive request hadn't been made.

---

From: "Roy T. Fielding" <[email-masked]>
Date: Tue, 9 Jun 2009 11:49:58 +0200

>   * Negotiated resources with Content-Location

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

> 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.

>  * 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.

> 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

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

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 11 Jun 2009 00:00:46 +0200

> that all caches will want to.

It's not really what I meant. I meant to say that caches should
invalidate the cached response if the cache sees a later response which
indicates the resource have changed, even if the new response itself is
not getting cached for some reason. This should be independent on which
conditions the response is being seen.

The request part is just ways to trigger the conditions where this may
be needed. The request is never what causes the invalidation, the
response to the request is, in specific conditions.

The tricky part is defining "indicates the resource have changed" I
guess, 

> stored response if the restrictive request hadn't been made.

a 5xx response DO NOT indicate that the resource have changed, and
should not update or invalidate any cached response, under any
conditions.

In fact in most cases a 5xx response should not even be cached..

Been reading the specs again, and in "RFC2616 13.1.1 Cache Correctness"
the condition of receiving a newer response where a previous response is
in the cache seems to be specified at only a MAY level, implying that
it's fine for the cache to keep the previous response as "current" for
as long as it's fresh. I could not find the corresponding section in
httpbis-p6. If it's really the intention that caches only MAY replace
the previous response with the newer response in the cache storage then
there is also no need for the invalidation requirements in the HEAD or
caching of negotiated resources sections to be any stronger than a MAY.

Regards
Henrik

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 11 Jun 2009 09:00:16 +1000

> The tricky part is defining "indicates the resource have changed" I

... I think this issue is related in no small way:
   http://trac.tools.ietf.org/wg/httpbis/trac/ticket/110

> caching of negotiated resources sections to be any stronger than a  

Yes; as mentioned before, the concept of "cache correctness" was  
dropped from p6, because it didn't add any binding requirements, and  
it was fuzzy at best anyway. If you think something was lost, please  
say so...

Which requirements are you referring to when you say "caching of  
negotiated resources sections"?

Cheers,

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 11 Jun 2009 02:51:59 +0200

>    http://trac.tools.ietf.org/wg/httpbis/trac/ticket/110

Indeed, if one want to make a general blanket rule independent of method
etc..

But not for a rule restricted to successful responses to
GET/HEAD(/POST).

> dropped from p6,

Sorry, been a little too much in the shadows lately...

> because it didn't add any binding requirements, and  

Not sure anything was lost. As you say it was very fuzzy.. better make
something that makes sense.

> negotiated resources sections"?

2.6 last paragraph, about deleting obviously old cache copies. Already
have a note to discuss if it's at all needed...

Regards
Henrik

---

From: "Roy T. Fielding" <[email-masked]>
Date: Thu, 11 Jun 2009 11:56:18 +0200

> caching of negotiated resources sections to be any stronger than a  

Keep in mind that the "cache" may be seeded with a fixed content
read-only memory or distribution device (firmware or CD-ROM)
whose purpose is to keep the system working when there is no net.

....Roy

---

From: Henrik Nordstrom <[email-masked]>
Date: Thu, 25 Jun 2009 00:56:33 +0200

> invalidates whatever is cached because it is new metadata.

Which isn't really said anywhere from what I can tell..

> That invalidates the current cached item if the cache sent

By what rule?

And it may well be the case that the cache did in fact NOT send a
validating request here. One obvious case is if the previous response do
not have any cache validator so it can't be validated.

> understood (explained by the protocol).

Not sure I follow you there. Current as in current for this request
only, or current as in current state of the server?

Regards
Henrik