- From: Henrik Nordstrom <henrik@henriknordstrom.net>
- Date: Sat, 02 Jan 2010 15:54:28 +0100
- To: Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>, Brian Smith <brian@briansmith.org>
Looks fine to me. Regards Henrik tor 2009-12-31 klockan 09:53 +1100 skrev Mark Nottingham: > Revised proposal: > > """ > The freshness model [ref] does not necessarily apply to history mechanisms. I.e., > a history mechanism can display a previous representation even if it has expired. > > This does not 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 08/10/2009, at 11:37 AM, Mark Nottingham wrote: > > > 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/ > > > > > > > -- > Mark Nottingham http://www.mnot.net/ >
Received on Saturday, 2 January 2010 14:55:05 UTC