no-cache no longer means don't reply from cache at all.  It only means don't return a stored representation without revalidating it first.  The stored representation can still be served if you get a 304 from the server, so you can still save the bulk transfer.  So this is a client or server override on freshness processing.  You get the same result from a conformant cache by using max-age=0, which by the way is what Chrome sends when you Ctrl-F5.  IE and FF send no-cache.

Actually this highlights some problems in the structure of 13.1.1 Cache Correctness.  The no-store directive shouldn't be only part of option 2.  It's global.  As it's currently written, 13.1.1 allows serving a stored response that had no-store if it's revalidated.

"... which meets one of the following conditions"

Back when everyone used Pragma: no-cache, no-cache meant don't cache it.  Now that there is a more explicit distinction in RFC 2616 between

a) retrieving something from a store
b) putting something into a store
c) revalidating something stored

the words "cache" (verb), and "cachable" are no longer clear and unambiguous.  I'd be keen for some better (more strict) nomenclature for these cases.


Jamie Lokier wrote:
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  

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

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


Adrien de Croy - WinGate Proxy Server -