W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2009

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

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 31 Dec 2009 09:53:51 +1100
Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, Brian Smith <brian@briansmith.org>
Message-Id: <1A6D6075-B177-4D4C-B018-A4B6EC91F4A9@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
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 Wednesday, 30 December 2009 22:54:26 GMT

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