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

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