W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2010

Re: NEW: #225: PUT and DELETE invalidation vs. staleness

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 3 Aug 2010 16:50:27 +1000
Cc: HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <3502C33E-F4BC-493E-8BC9-626F11C6815F@mnot.net>
To: Yves Lafon <ylafon@w3.org>
Right, but by changing 'invalidate' to 'stale', we're loosening a requirement -- one that's specified in some detail.

How do others feel about this?


On 29/07/2010, at 8:28 PM, Yves Lafon wrote:

> On Thu, 29 Jul 2010, Mark Nottingham wrote:
> 
>> 
>> On 29/07/2010, at 12:08 PM, Yves Lafon wrote:
>>> 
>>> Just checked my implementation, and it marks it as stale, mandating revalidation. It is really up to implementation, so p2 should defer to p6 for the definition of what a cache should do in any case (to remove the current conflict), and let implementation decide.
>> 
>> If you mandate revalidation, it's not just stale; it conforms to the p6 definition of invalidation. Calling it 'stale' will confuse matters.
> 
> My code mandates revalidation, so it conforms to p6, the modification in p6 from "invalid" to "stale" is just to reflect what is in p2.
> 
> In a way, marking it stale makes more sense, serving content will happen only if the cache can't revalidate, so if contacting the server is impossible, and it is not worse than asking another cache that might have the same outdated information.
> 
> If the server really don't want that to happen, must-revalidate is in order.
> 
> -- 
> Baroula que barouleras, au tiéu toujou t'entourneras.
> 
>        ~~Yves
> 


--
Mark Nottingham     http://www.mnot.net/
Received on Tuesday, 3 August 2010 06:50:52 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:24 GMT