- From: Mark Nottingham <mnot@mnot.net>
- Date: Mon, 8 Jun 2009 20:57:33 +1000
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
Ping? I'm still struggling to understand what you want here; see also Roy's comment on the issue in the tracker. Are you talking about 304 responses, 200 responses, *any* response to a GET...? Also may be worth to look at my recent proposal which may affect this tangentially; http://www.w3.org/mid/19AC8559-09F9-44AE-90C5-5BA95ECCC3AA@mnot.net Cheers, On 09/05/2008, at 3:54 PM, Mark Nottingham wrote: > > OK, I've created > http://www3.tools.ietf.org/wg/httpbis/trac/ticket/117 > > Henrik, could you identify the changes that need to happen in the > drafts? > > Cheers, > > > On 17/04/2008, at 6:28 PM, Henrik Nordstrom wrote: > >> >> ons 2008-04-16 klockan 18:58 -0700 skrev Mark Nottingham: >> >>> Can you give some examples? 4xx to a GET shouldn't invalidate the >>> cache, and a cache is allowed to return a cached response when >>> encountering a 5xx unless must-revalidate is present. >> >> I am not talking about error responses. I am talking about this text >> which currently is only specified for HEAD and not GET: >> >> If the new field values >> indicate that the cached entity differs from the current entity (as >> would be indicated by a change in Content-Length, Content-MD5, ETag >> or Last-Modified), then the cache MUST treat the cache entry as >> stale. >> >> It's a equally good rule for GET as for HEAD, and having them aligned >> would help getting rid of cornercases such as the i23 question. >> >>> In any case, I believe we can close this issue with no spec >>> change; we >>> may change text regarding cache invalidation separately. >> >> Yes. i23 requires no change. This is a separate but quite related >> issue. >> >> Regards >> Henrik >> >> >> > > > -- > Mark Nottingham http://www.mnot.net/ > > -- Mark Nottingham http://www.mnot.net/
Received on Monday, 8 June 2009 10:58:09 UTC