- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 19 Oct 2010 11:28:34 +1100
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: "Moore, Jonathan" <jonathan_moore@comcast.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 18/10/2010, at 4:31 PM, Roy T. Fielding wrote: > On Oct 17, 2010, at 9:28 PM, Mark Nottingham wrote: > >> Roy, what's your precise definition of successful? 2xx, or 2xx + 3xx? >> >> E.g., 303 See Other seems like it's squarely within the intent of cache invalidation, since Location is included. > > Note that this is just for invalidation of an existing cached > response to a prior GET upon receiving a state-changing request > for the same URI. For example, in the case > > GET /x --> 200 with form to fill out > POST /x --> 303 to /y > > I would not expect the first GET to be invalidated by the 303 > even if the 303 is marked cacheable. Ah. That's an interesting point. The question here, though, is whether /y should also be invalidated; since 2616 goes to pretty extensive lengths to say that the URL indicated by Location is to be invalidated, I don't see why it shouldn't be... -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 19 October 2010 00:29:13 UTC