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

On Wed, 24 Jun 2009 23:03:48 +0200, Jamie Lokier <jamie@shareable.org>  
wrote:

> Yngve N. Pettersen (Developer Opera Software ASA) wrote:
>> Additionally, the default in PHP (at least my copy of v5.0.4) seems to  
>> be
>> "Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
>> pre-check=0", and I seem to recall that the MoinMoin wiki had that, too,
>> at least last year (but in that case I may be misremembering).
>>
>> Given the extensive use of no-store in situations where it does not seem
>> necessary, I have started wondering if Opera need to start ignoring the
>> no-store header in non-HTTPS responses, just like we currently only  
>> accept
>> must-revalidate (interpreted as re-validate on history navigation) only
>> for HTTPS responses. No decision has been reached yet.
>
> Oh.  My.  Goodness.
>
> You ignore must-revalidate?

For HTTP-URLs, yes we do ignore it, but not HTTP*S*. When heeded, history  
navigation, as well as normal load, will trigger a if-modified since load.

And the reason we had to do that was that there was a significant uproar  
among our users when we first added support for the directive, as it  
caused a significant slow down when browsing, even on static wikis. The  
average user won't blame the *site* when their experience is bad, they  
will blame the browser, even when it is the site causing the bad  
experience.


> Thanks for letting me know that Opera is broken.
>
>       "Recipients MUST NOT take any automated action that
>       violates this directive, and MUST NOT automatically provide an
>       unvalidated copy of the entity if revalidation fails."
>
> Do you have a suggested workaround for this client bug?  The only one
> which comes to mind is redirecting to an HTTPS-equivalent page when
> the User-Agent indicates Opera.  Something cheaper would be nice.

A no-cache will work fine for load events, must-revalidate on HTTPS does  
cause that to be set, but otherwise only affects history navigation.

> If I've set must-revalidate, it's because I want my Etags revalidated,
> thank you.  As in, when the user visits the page, they must not see an
> out of date page.  It causes confusion if they do.  Web applications,
> you know the sort of thing.

As long as you send a no-cache directive we will send an if-modified since  
for when the resource is used in a *loading* page

> Your interpretation that the directive wasn't really intended is just
> another step in a silly arms-race, where we have to add yet more
> workaround on the server side to compensate for clients who don't
> follow simple specifications.

The interpretation (history navigation revalidation + no-cache) was one  
that made sense to us, based on the phrasing in the specification, since  
if it did not imply revalidation during history navigation, then it was  
just an alias for no-cache, which is apparently what a significant number  
of framework developers think it is.

As stated above, the backlash was significant enough when we released it,  
that we had to disable it for HTTP-only sites.

We implemented the history navigation revalidation because a number of  
online banks indicated that they required revalidation when navigating  
history, something which seems to work implicitly in certain other  
browsers, AFAICT because they "always" reload top documents even during  
history navigation, something which Opera does not do since our default is  
history navigation shows the state when we loaded the document, not the  
current state (see also RFC 2616 sec 13.13), and if the server does not  
specifiy policy we use local preferences to determine revalidation (which  
have had to be cut to the bone for documents, again due to the browser  
being blamed when the expirence is "bad" when the cache copy was used on  
going to a page that "should" have been updated, but did not specify any  
expiration policy).

-- 
Sincerely,
Yngve N. Pettersen
 
********************************************************************
Senior Developer                     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

Received on Wednesday, 24 June 2009 22:55:24 UTC