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