- From: Mark Nottingham <mnot@mnot.net>
- Date: Tue, 22 Sep 2009 11:55:36 +1000
- To: Brian Smith <brian@briansmith.org>
- Cc: "'Henrik Nordstrom'" <henrik@henriknordstrom.net>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
As the spec mentioned, it's relevant to HTTP because people often misinterpret the relationship between a cache and a history list, and mis-implementation of a history list can incent people to avoid caching. At this point it sounds like we want to refine the language to more explicitly point out that expiration mechanisms don't apply to history lists, but other cache-control directives may (e.g., no-store). I also hear some reluctance to go further than this, because if we did we'd need to more fully specify history lists. On 22/09/2009, at 1:05 AM, Brian Smith wrote: > Henrik Nordstrom wrote: >> But this part of the specifications should only be advisory and best >> practice recommendation, giving browsers permission to bypass >> freshness >> controls on accesses due to history navigation, not a strict >> requirement on implementaitons to do exactly this. > > Why does the HTTP specification even need to mention history lists. > The vast majority of HTTP caches do not even maintain history lists. > The ones that do (built into browsers) will design their history > list mechanism according to their own security & performance goals. > Plus, as Henrik noted previously, there's a lot more to a browser > history list than caching the HTTP request/response (ActiveX/plugin > state, Javascript state, SVG animation state, Javascript APIs for > controlling history, etc.) > > Regards, > Brian > > -- Mark Nottingham http://www.mnot.net/
Received on Tuesday, 22 September 2009 01:56:21 UTC