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

On 23/06/2011, at 7:02 PM, Yves Lafon wrote:

> Is the semantic of 304 with a Location: header for a POST on another effective request URI defined ?
> http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-14#section-8.3.5
> <<
> The response to the request has not been modified since the
>   conditions indicated by the client's conditional GET request, as
>   defined in Section 4.1 of [Part4].
>>> 
> However it really looks like "the result of this post is available at the Location URI, but no changes were made". New ticket?

No, Location doesn't automatically change the semantics of the message, it has to be specified by the status code definition. I.e., it doesn't mean anything on a 304. 


>>> For 307, as the redirect has to be done using the same method, only a successful response code on the new URI given in 307's Location header would indicate if the invalidation needs to be done or not.
>> 
>> To be completely faithful, yes. However, waiting for the redirect complicates things quite a bit (as the redirected request may be on another connection, or through another box), and the purpose of waiting for the response is to avoid denial of service attacks. It's true that there theoretically could be some false positives if a cache invalidates upon a 307, but that's better than false negatives, when invalidation is concerned, and the DoS is still protected against.
> 
> How about calling 301,302,303, and say that it MAY be extended to 3xx? (for the "not harming" false positives)

I'm inclined to make it more general; in practice, you won't see a Location on a 304, and if it does occur spuriously, it isn't going to cause any harm.

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

Received on Friday, 24 June 2011 01:46:25 UTC