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

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

From: Mark Nottingham <mnot@mnot.net>
Date: Fri, 24 Jun 2011 11:45:47 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <998519F2-D30E-4C1F-8EF9-1EBFAECDC624@mnot.net>
To: Yves Lafon <ylafon@w3.org>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:52 UTC