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/