- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 22 Oct 2010 13:26:39 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Yves Lafon <ylafon@w3.org>
I haven't heard anything back about this from others. My inclination is to adjust p2 to reflect the text in p6, as the caching-specific text is clearly where cache implementers will have been looking, and realistically the text in p2 is likely to be a loose generalisation, whereas the text is p6 is a lot more specific. Objections? On 03/08/2010, at 4:50 PM, Mark Nottingham wrote: > 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/ > > -- Mark Nottingham http://www.mnot.net/
Received on Friday, 22 October 2010 02:27:13 UTC