- From: Yves Lafon <ylafon@w3.org>
- Date: Wed, 22 Jun 2011 08:55:03 -0400 (EDT)
- To: Mark Nottingham <mnot@mnot.net>
- cc: HTTP Working Group <ietf-http-wg@w3.org>
On Wed, 22 Jun 2011, Mark Nottingham wrote: > <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/235> > > On 02/05/2011, at 11:44 AM, Mark Nottingham wrote: > >> The editors talked about this in Prague, and we came to a place where we agreed specifying it for 2xx would be fine. >> >> I changed my mind because my case below isn't the common case; that's a POST followed by a 201 with a Location. >> >> Any objections to / thoughts about that? > > > ... and then I realised that a 302 after a POST is a *very* common use case, e.g., when editing a blog entry. > > So, I think we need to include 3xx redirects. Sorry for the confusion; count it up to jetlag. > > Current text: > > """ > A cache MUST invalidate the effective Request URI (Section 4.3 of > [Part1]) as well as the URI(s) in the Location and Content-Location > header fields (if present) when requests with unsafe methods are > received. > > However, a cache MUST NOT invalidate a URI from a Location or > Content-Location header field if the host part of that URI differs > from the host part in the effective request URI (Section 4.3 of > [Part1]). This helps prevent denial of service attacks. > > A cache SHOULD invalidate the effective request URI (Section 4.3 of > [Part1]) when passing through requests with methods whose safety is > unknown. > """ > > Proposal: > > """ > A cache MUST invalidate the effective Request URI (Section 4.3 of [Part1]) as well as the URI(s) in the Location and Content-Location header fields (if present) when a successful response to a request with an unsafe method is received. > > However, a cache MUST NOT invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part in the effective request URI (Section 4.3 of [Part1]). This helps prevent denial of service attacks. > > A cache SHOULD invalidate the effective request URI (Section 4.3 of [Part1]) when it receives a successful response to a request with a method whose safety is unknown. > > Here, a successful response is one with a 2xx or 3xx status code. > """ For 301/302/303 that's fine. For 305, invalidating the URI of the proxy given in Location is a bit far from what 305 says, but won't harm. 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. -- Baroula que barouleras, au tiéu toujou t'entourneras. ~~Yves
Received on Wednesday, 22 June 2011 12:55:06 UTC