- From: Mark Nottingham <mnot@mnot.net>
- Date: 2009年12月31日 09:53:51 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Henrik Nordstrom <henrik@henriknordstrom.net>, Brian Smith <brian@briansmith.org>
- Message-Id: <1A6D6075-B177-4D4C-B018-A4B6EC91F4A9@mnot.net>
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蚣 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 UTC