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

["Yngve N. Pettersen (Developer Opera Software ASA)" <[e-mail]>]

On Fri, 26 Jun 2009 08:41:43 +0200, Mark Nottingham <[e-mail]> wrote:

> On 25/06/2009, at 8:06 PM, Yngve N. Pettersen (Developer Opera Software  
> ASA) wrote:
>
>>> Yngve, why does must-revalidate affect user experience so much? All  
>>> that it means is that you can't serve the response once it becomes  
>>> stale. Does Opera ignore server-provided expiry as a matter of course?
>>
>> Opera treats the directive as a no-cache for history-navigation, and  
>> that means that when you navigate back and forth in history all  
>> resources in the document with that flag will be revalidated, before  
>> they are displayed again. That causes a significant delay while  
>> navigating.
>
> RFC2616 specifically states that the cache and history are separate  
> (section 13.13).

Please tell that to everybody (particularly banks) who *requires* (and  
AFAIK even block clients that does not adhere to it) that the client  
rechecks/reloads content on history navigation. Particularly after a  
logout.

Case in point, I just noticed a bugreport from somebody saying that  
no-store should mean that content is revalidated/reloaded during history  
navigation. He wanted a login page when navigating back in history after  
logging out of a site. We have also received many reports, including from  
major customers, saying that no-cache should have the same effect.

The fundamental issue is that HTTP (as you are also touching on) does not  
specify any directives for history navigation. That leaves both web site  
developers, and browser vendors (and probably other vendors) in a lurch  
about how to facilitate things like secure logout which makes sure history  
navigation is not possible, while still ensuring good display performance,  
and the result is that we use the keywords that are available and that  
seem (or can be extended, maybe even stretched) to indicate the desired  
functionality, like we did with must-revalidate (before we used  
must-revalidate we tried to use the combination "private, no-cache" as a  
kick out of cache mechanism, but that caused too many problems).

I think it would be an idea if the new HTTP RFC give specific examples for  
how the directives should be interpreted in various situations, such as  
when going to a new page, when navigating ing history, full document  
reload, etc. Yes, that may look like something that is rather targeted at  
a specific application, but most uses of HTTP will be close to one of  
these. Such a description should have enough details that it will be  
useful to designers and implementors, even if it just says that "During  
history navigation the client MUST NOT evaluate cache directives, and MUST  
NOT attempt to reload/revalidate content from the server".

>> It *may* be that we should also check expiration first (and that is  
>> being considered, but may require significant changes), but the  
>> purposes for which we added it, online banking, requires checking on  
>> every view in any case. And as mentioned, the "primary" use of the  
>> directive in many frameworks, such as PHP, combines must-revalidate  
>> with no-cache and no-store.
>
>
> If you have users that need to restrict use of browser history (a well-

Actually, it would be more proper to say that it is web sites that our  
users visit that want those restrictions, and who sometimes use what I  
consider extreme measures to ensure that those policies are implemented.

> worn topic), please come up with extension protocol directives, rather

Please see my draft on cache-context (I am planning to refresh it soon):

    http://files.myopera.com/yngve/blog/draft-pettersen-cache-context-03.txt

Background:

   http://my.opera.com/yngve/blog/2007/02/27/introducing-cache-contexts-or-why-the


Alternatively, new headers and/or directives defining actions in history  
navigation should be defined. Any suggestions?


-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: [e-mail]
Opera Software ASA                   http://www.opera.com/
Phone:  [phone]              Fax:    [phone]
********************************************************************