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, 8 Oct 2009 11:37:44 +1100
Cc: Brian Smith <brian@briansmith.org>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-Id: <FB161A79-328D-475E-9E53-1E08E042A532@mnot.net>
To: Henrik Nordstrom <henrik@henriknordstrom.net>
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 GMT

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