- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 8 Oct 2009 11:37:44 +1100
- To: Henrik Nordstrom <henrik@henriknordstrom.net>
- Cc: Brian Smith <brian@briansmith.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Existing text: > By default, an expiration time does not apply to history > mechanisms. If the entity is still > in storage, a history mechanism SHOULD display it even if the > entity has expired, > unless the user has specifically configured the agent to refresh > expired history documents. > > This is not to be construed to prohibit the history mechanism from > telling the user that a > view might be stale. Proposed text: """ By default, the freshness model [ref] does not apply to history mechanisms. If the entity is still in storage, a history mechanism SHOULD display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents. This is not to be construed to prohibit the history mechanism from telling the user that a view might be stale, or from honoring cache directives (e.g., Cache- Control: no-store). """ On 22/09/2009, at 4:49 AM, Henrik Nordstrom wrote: > mån 2009-09-21 klockan 10:05 -0500 skrev Brian Smith: >> 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.) > > It's an explicit freedom to disregard HTTP freshness controls in > history > buffers and the like. > > But yes, the fine details there belongs more in a browser profile > specification than the HTTP specifications as such. > > Regards > Henrik > -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 8 October 2009 00:38:17 UTC