- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 6 Oct 2009 16:17:32 +1100
- To: Brian Smith <brian@briansmith.org>
- Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
On 06/10/2009, at 3:56 PM, Brian Smith wrote: > Mark Nottingham wrote: >> Sent: Monday, October 05, 2009 11:07 PM >> To: Brian Smith >> Cc: 'Julian Reschke'; 'Robert Brewer'; 'HTTP Working Group' >> Subject: Re: Clarifying Content-Location (Issue 136) >> >> When did that happen? We removed its base-setting ability, not cache >> invalidation, IIRC. > > http://trac.tools.ietf.org/wg/httpbis/trac/changeset/691 > > The above change removes cache invalidation based on Content- > Location for > GET/HEAD. The part of P6-cache that discussed cache invalidation > based on > Content-Location for PUT, POST, and DELETE was retained. That > doesn't make > sense to me; it seems like we should either always invalidation > based on > Content-Location (for the same host) or we never should. I support > "we never > should" as it makes it easier to get rid of Content-Location. Yes, but PUT/POST/DELETE have side effects, and so invalidation makes sense in this case. The text removed in changeset 691 was very specific to a situation where C-L matched the request URI and the ETag and Date said it was different; it's a very different thing than the invalidation specified for methods with side effects. -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 6 October 2009 05:18:07 UTC