- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 11 Jun 2009 09:00:16 +1000
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
On 11/06/2009, at 8:00 AM, Henrik Nordstrom wrote: > > The tricky part is defining "indicates the resource have changed" I > guess, ... I think this issue is related in no small way: http://trac.tools.ietf.org/wg/httpbis/trac/ticket/110 > Been reading the specs again, and in "RFC2616 13.1.1 Cache > Correctness" > the condition of receiving a newer response where a previous > response is > in the cache seems to be specified at only a MAY level, implying that > it's fine for the cache to keep the previous response as "current" for > as long as it's fresh. I could not find the corresponding section in > httpbis-p6. If it's really the intention that caches only MAY replace > the previous response with the newer response in the cache storage > then > there is also no need for the invalidation requirements in the HEAD or > caching of negotiated resources sections to be any stronger than a > MAY. Yes; as mentioned before, the concept of "cache correctness" was dropped from p6, because it didn't add any binding requirements, and it was fuzzy at best anyway. If you think something was lost, please say so... Which requirements are you referring to when you say "caching of negotiated resources sections"? Cheers, -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 10 June 2009 23:00:53 UTC