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

Re: httpbis-p6-cache-06 and no-store response directive

From: David Morris <dwm@xpasc.com>
Date: Mon, 29 Jun 2009 14:11:27 -0700 (PDT)
cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <Pine.LNX.4.64.0906291358050.9775@egate.xpasc.com>

On Sun, 28 Jun 2009, Henrik Nordstrom wrote:

> fre 2009-06-26 klockan 21:45 +0200 skrev Yngve N. Pettersen (Developer
> Opera Software ASA):
>> Alternatively, new headers and/or directives defining actions in history
>> navigation should be defined. Any suggestions?
> user agent history buffer behavior is slightly outside of the HTTP
> realm, but I would suggest that must-revalidate applies to history
> buffer views as well, preventing stale information from being shown
> without validation.

The issue here is user interaction model design ... I find it really 
offensive when a browser reloads a page or denys same because it is stale.
Until this is done right we'll never get folks to stop printing. As a 
user, I should be able to review and/or print what I'm looking at w/o 
requiring ANY network activity. Without ANY change from what I last read.
It should work just like a printed document, newspaper, etc. Until I 
request an update, I want to flip between pages of what I have already 

I have no problem with the browser adding a non-intrusive notification 
that the page is now stale (e.g., similar to the page secure LOCK used
now to show a page as secure). Likewise, the browser should block 
re-posting already used content or content from a stale page. It typically 
takes 10-60 seconds to revalidate/refresh a page ... flipping back in 
history should be really fast ... as a user I've already paid to see the 

Yeah we've deemed this outside of HTTP's scope and it needs to stay that 
way. History navigation does not constitute a new web request. How well 
the UIModel is implemented is an opportunity for browser differentiation.

Dave Morris
Received on Monday, 29 June 2009 21:12:10 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:49 UTC