- From: Jamie Lokier <jamie@shareable.org>
- Date: Sun, 28 Jun 2009 23:45:22 +0100
- To: "Yngve N. Pettersen (Developer Opera Software ASA)" <yngve@opera.com>
- Cc: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Yngve N. Pettersen (Developer Opera Software ASA) wrote: > >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. Sigh. So we have to add a server-side rule "if user-agent == Oper cache behaviour depends on HTTP vs. HTTPs". > 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. I remember a similar thing with Mozilla/Firefox. They originally revalidated on history browsing, but added and advertised a new feature - showing pages from history without revalidating them :-) > >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. I don't see how that's a workaround. no-cache means don't cache at all. I *do* want pages cached - but I want them validated on display too. > >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 If it has no-cache directive, isn't sending if-modified a browser bug too? That's why all those sites you mentioned send must-revalidate etc. etc. Because browsers don't obey no-cache by itself. > 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. More likely, framework developers found browsers who don't obey no-cache (like Opera, sending if-modified?), so they add every directive they can think of, hoping at least one of them causes a browser to not cache. > As stated above, the backlash was significant enough when we released it, > that we had to disable it for HTTP-only sites. An arms race. The next step is pages having Javascript to revalidate themselves, with the whole page inside "<div class=hide-while-validating>". I already have the code in mind. If that becomes a standard part of common frameworks, it'll be interesting to see your response when users complain about history speed :-) > 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, I agree with the banks. It's reasonable to want to hide user's personal data after a secure logout or session expiry. It's just ugly to do it so differently for HTTP and nHTTPS. > 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), It's in interesting problem, as fast history is a good feature, but non-validating history is wrong for some applications, after a session has finished. > 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). Ok. As a server author, how do I specify a "please revalidate" policy? You said no-cache, but that means don't cache at all, not cache but please always revalidate. So it won't work with conforming browsers, and it'll break caching at proxies. Perhaps a Cache-Control: history-revalidate(=yes/no) is needed, with the defaults being HTTPS-dependent as you implemented. -- Jamie
Received on Sunday, 28 June 2009 22:45:58 UTC