- From: Yngve N. Pettersen (Developer Opera Software ASA) <yngve@opera.com>
- Date: Thu, 25 Jun 2009 12:06:35 +0200
- To: "Mark Nottingham" <mnot@mnot.net>
- Cc: "Jamie Lokier" <jamie@shareable.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Thu, 25 Jun 2009 07:50:43 +0200, Mark Nottingham <mnot@mnot.net> 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. 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. > 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/ > -- 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 Thursday, 25 June 2009 10:07:37 UTC