W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2010

Re: #197: Effect of CC directives on history lists

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>
Message-Id: <1262444068.14309.3.camel@localhost.localdomain>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:16 GMT