Subject: NEW: #225: PUT and DELETE invalidation vs. staleness

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Jul 2010 17:06:42 +0200

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

p2 7.6 (PUT):

If the request passes through a cache and the Effective Request URI identifies one or more currently cached entities, those entries SHOULD be treated as stale.

p6 2.5 (Request Methods that Invalidate):

Here, "invalidate" means that the cache will either remove all stored responses related to the Effective Request URI, or will mark these as "invalid" and in need of a mandatory validation before they can be returned in response to a subsequent request.

These sections conflict regarding the side effects of PUT; p2 only wants it marked stale, whereas p6 says it cannot be served stale, but must (at least) be revalidated.

The same problem holds for DELETE.

---

One point of data: Squid invalidates (i.e., removes from cache) as a side effect of PUT/DELETE, although IIRC this is only in Squid-2.HEAD. 

Opinions?

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

---

From: Yves Lafon <[email-masked]>
Date: Thu, 29 Jul 2010 06:08:18 -0400 (EDT)

On Fri, 23 Jul 2010, Mark Nottingham wrote:

> If the request passes through a cache and the Effective Request URI 
> identifies one or more currently cached entities, those entries SHOULD 
> be treated as stale.
>
> Here, "invalidate" means that the cache will either remove all stored 
> responses related to the Effective Request URI, or will mark these as 
> "invalid" and in need of a mandatory validation before they can be 
> returned in response to a subsequent request.
>
> These sections conflict regarding the side effects of PUT; p2 only wants 
> it marked stale, whereas p6 says it cannot be served stale, but must (at 
> least) be revalidated.
>

> One point of data: Squid invalidates (i.e., removes from cache) as a 
> side effect of PUT/DELETE, although IIRC this is only in Squid-2.HEAD.
>
> Opinions?

Just checked my implementation, and it marks it as stale, mandating 
revalidation. It is really up to implementation, so p2 should defer to p6 
for the definition of what a cache should do in any case (to remove the 
current conflict), and let implementation decide.

Proposal:
p2:
> If the request passes through a cache and the Effective Request URI
> identifies one or more currently cached entities, those entries SHOULD
> be treated as stale.

=>

If the request passes through a cache and the Effective Request URI
identifies one or more currently cached entities, those entries SHOULD
be treated invalidated (See p6 2.5)

And for p6 change

> Here, "invalidate" means that the cache will either remove all stored
> responses related to the Effective Request URI, or will mark these as
> "invalid" and in need of a mandatory validation before they can be
> returned in response to a subsequent request.

=>

Here, "invalidate" means that the cache will either remove all stored 
responses related to the Effective Request URI, or will mark these as 
stale and in need of a mandatory validation before they can be returned in 
response to a subsequent request.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 29 Jul 2010 12:10:13 +0200

On 29/07/2010, at 12:08 PM, Yves Lafon wrote:
> 
> Just checked my implementation, and it marks it as stale, mandating revalidation. It is really up to implementation, so p2 should defer to p6 for the definition of what a cache should do in any case (to remove the current conflict), and let implementation decide.

If you mandate revalidation, it's not just stale; it conforms to the p6 definition of invalidation. Calling it 'stale' will confuse matters.

---

From: Yves Lafon <[email-masked]>
Date: Thu, 29 Jul 2010 06:28:49 -0400 (EDT)

On Thu, 29 Jul 2010, Mark Nottingham wrote:

>> revalidation. It is really up to implementation, so p2 should defer to 
>> p6 for the definition of what a cache should do in any case (to remove 
>> the current conflict), and let implementation decide.
>
> If you mandate revalidation, it's not just stale; it conforms to the p6 
> definition of invalidation. Calling it 'stale' will confuse matters.

My code mandates revalidation, so it conforms to p6, the modification in 
p6 from "invalid" to "stale" is just to reflect what is in p2.

In a way, marking it stale makes more sense, serving content will happen 
only if the cache can't revalidate, so if contacting the server is 
impossible, and it is not worse than asking another cache that might have 
the same outdated information.

If the server really don't want that to happen, must-revalidate is in 
order.

         ~~Yves