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

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?



On 25/06/2009, at 8:54 AM, Yngve N. Pettersen (Developer Opera  
Software ASA) wrote:

> 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
> ********************************************************************
>


--
Mark Nottingham     http://www.mnot.net/

Received on Thursday, 25 June 2009 05:51:23 UTC