Re: Warning: header, need origin

> For the page showing me my shopping basket, however, the server sends
>   Vary: Cookie
>   Cache-control: max-age=0
> in order to get (conditional) GET requests _every time the page is
> accessed_.  Thus, if I visit my shopping basket page, then put more
> stuff in my shopping basket (by following links to CGI scripts in
> product pages), and then re-request to my shopping basket page, the
> server can send me the updated shopping basket.
> 
> So what we don't want is caches which are configured to give stale
> responses instead of doing a conditional GETs when the max-age is
> exceeded: this leads to the showing of the old basket, which is
> unacceptable.

In cases where the Cookie is being used as an authenticator and not
as a state identifier, the entity should always be marked as

    Cache-control: private

but that is a secondary issue.

> This is why to need to detect if you can indeed rely on caches not
> returning stale responses.

You can't detect this because even a private cache can have its behavior
altered between requests.  It isn't the protocol's job to say when a
client must make a request over the net -- in fact, it cannot do so.
The only thing the protocol can do is allow both sides to state their
desires and require that a warning be displayed if the result contradicts
those desires.

In practice, it will work just fine -- paranoia about the border cases
(where the user always wins because they are the ones making the request)
is just wasting time.  If it doesn't work, then those pages will be
marked as no-cache and the whole issue is moot.  Cache busting is NOT
a concern provided that such entities are marked as "no-cache".

Adding another cache-control header is another waste of time -- it will
be ignored for the same reason that max-age=0 was ignored.  There is
nothing anyone can do to force a user to make a network request,
because forcing them would be a security violation (it may result in a
transaction cost to the user which was not specifically requested by
that user).

Sending max-age on requests is an optimization in favor of the user
(which is why it would be sent).  However, there is no guarantee that
the origin server will see it prior to the cache behaving in a
non-transparent fashion, so you can't use it as a guarantee.
That does not reduce its usefulness as an optimization for the user.

So, what I have already said many times already is that the protocol
should be defined according to how it will be used.  In this case, we
need a warning message that must be displayed if the user is viewing
a stale document (for whatever reason) in spite of the server's
requirements for freshness.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Tuesday, 9 April 1996 02:26:43 UTC