Subject: NEW: #235: Cache Invalidation only happens upon successful responses

From: Mark Nottingham <[email-masked]>
Date: Sat, 24 Jul 2010 17:21:46 +0200

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

Any objection to specifying that invalidation only happens upon a successful response (as opposed to any POST/PUT/DELETE/etc. response)?

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

---

From: "Moore, Jonathan" <[email-masked]>
Date: Sun, 25 Jul 2010 11:19:56 -0400

By successful response, do you mean "received a response successfully"  
or "received a response with a 2xx response code"? If the former, I  
think I'd agree, but if the latter, there are definitely non-2xx  
response codes that would still give an indication that a cached entry  
wasn't valid anymore (for example, a 404).

Jon
........
Jon Moore

On Jul 24, 2010, at 11:22 AM, "Mark Nottingham" <[email-masked]> wrote:

> Any objection to specifying that invalidation only happens upon a  
> successful response (as opposed to any POST/PUT/DELETE/etc. response)?
>
> --

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 26 Jul 2010 10:53:14 +0200

Good point. 

How about non-5xx status code?

On 25/07/2010, at 5:19 PM, Moore, Jonathan wrote:

> By successful response, do you mean "received a response successfully" or "received a response with a 2xx response code"? If the former, I think I'd agree, but if the latter, there are definitely non-2xx response codes that would still give an indication that a cached entry wasn't valid anymore (for example, a 404).
> 
> Jon
> ........
> Jon Moore
> 
>

---

From: Yves Lafon <[email-masked]>
Date: Mon, 26 Jul 2010 05:19:12 -0400 (EDT)

> How about non-5xx status code?

Well, 405 or 413 should not trigger invalidation. We need 2xx plus status 
code that are making an assertion about the state of the 
possibly updated representation.

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

         ~~Yves

---

From: "Moore, Jonathan" <[email-masked]>
Date: Mon, 26 Jul 2010 07:51:30 -0400

I think this is right that we might need to look at different status  
codes here. What about a 500 (internal server error)? It seems like  
the resource may have been put into a different state due to a  
partially-completed operation, and the cache, being aware of a  
potential change, ought to invalidate and re-establish the current  
state.

Let me ask the intent behind invalidation, though: is this to be done  
when the cache *knows* the state of the resource has changed, or just  
when it *might* have changed?

Jon
........
Jon Moore

On Jul 26, 2010, at 5:19 AM, "Yves Lafon" <[email-masked]> wrote:

> Well, 405 or 413 should not trigger invalidation. We need 2xx plus  
> status code that are making an assertion about the state of the  
>>> By successful response, do you mean "received a response  
>>> successfully" or "received a response with a 2xx response code"?  
>>> If the former, I think I'd agree, but if the latter, there are  
>>> definitely non-2xx response codes that would still give an  
>>> indication that a cached entry wasn't valid anymore (for example,  
>>> a 404).
>>>
>>> Jon
>>> ........
>>> Jon Moore
>>>
>>>

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Jul 2010 14:09:51 +0200

> potential change, ought to invalidate and re-establish the current  

Please avoid abusing the 500 internal server error. It's monitored at a
lot of places to explicitly indicate a server failure that, if repeated,
requires human intervention. Probably that other more specific codes are
appropriate.

Regards,
Willy

---

From: Yves Lafon <[email-masked]>
Date: Mon, 26 Jul 2010 08:11:40 -0400 (EDT)

On Mon, 26 Jul 2010, Moore, Jonathan wrote:

> I think this is right that we might need to look at different status codes 
> here. What about a 500 (internal server error)? It seems like the resource 
> may have been put into a different state due to a partially-completed 
> operation, and the cache, being aware of a potential change, ought to 
> invalidate and re-establish the current state.
>
> Let me ask the intent behind invalidation, though: is this to be done when 
> the cache *knows* the state of the resource has changed, or just when it 
> *might* have changed?

If it is a *might*, there is no need to ways for the response, any unknown 
method or unsafe method is enough to trigger invalidation, but it leads to 
denial of service attacks.

If is it a *knows*, then we have two cases:
1/ successful response (in the sense of 2xx) => invalidate
All the other cases (404, 410) are indeed giving information about the 
state of the resource, but that is no different from an unsuccesful 
revalidation.

So for #235, we should say that a cache MUST invalidate when there is a 
successful response and not more, as reasons to do so are covered 
elsewhere already.

>> code that are making an assertion about the state of the possibly updated 
>> representation.
>> 
>>>> By successful response, do you mean "received a response successfully" or 
>>>> "received a response with a 2xx response code"? If the former, I think 
>>>> I'd agree, but if the latter, there are definitely non-2xx response codes 
>>>> that would still give an indication that a cached entry wasn't valid 
>>>> anymore (for example, a 404).
>>>> 
>>>> Jon
>>>> ........
>>>> Jon Moore
>>>> 
>>>> 

         ~~Yves

---

From: Yves Lafon <[email-masked]>
Date: Mon, 26 Jul 2010 09:10:56 -0400 (EDT)

> If it is a *might*, there is no need to ways for the response, any unknown
                                          *wait*

         ~~Yves

---

From: "Roy T. Fielding" <[email-masked]>
Date: Mon, 26 Jul 2010 06:33:51 -0700

> By successful response, do you mean "received a response successfully" or "received a response with a 2xx response code"? If the former, I think I'd agree, but if the latter, there are definitely n…

No, it must be a success response from the origin server.  No other response
indicates that the cached GET is invalid because the origin server may use
various error responses to deal with authenticatiin problems on the
part of an attacker.

....Roy