W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1998

Re: ISSUE: revalidation

From: Richard Gray <rlgray@us.ibm.com>
Date: Wed, 15 Jul 1998 13:58:56 -0400
To: mogul@pa.dec.com
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <5040300018231286000002L062*@MHS>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/229
If the spec is so murky as to need a tutorial, perhaps it is not good enough to
produce interoperable implementations?

We intend to implment "must-revalidate", "proxy-revalidate", "max-age", and
"s-maxage" the same if credentials are present; that is, _always_ revalidate,
using the current credentials.

And I just noticed that 14.8 Authorization, special case (1) mentions
I assume that is intended to be "proxy-revalidate"?

Richard L. Gray
will code for chocolate

mogul@pa.dec.com on 07-14-98 01:57:23 PM
Please respond to mogul@pa.dec.com
To: Richard Gray/Raleigh/IBM@ibmus
cc: http-wg@cuckoo.hpl.hp.com
Subject: Re: ISSUE: revalidation

Richard Gray <rlgray@us.ibm.com> writes:
    Having read both
    and the diff version of rev-03, I am now confused about the
    Cache-control revalidation directives, and their intended
    interaction with the Authorization mechanism.

I have no opinions about Authorization, so you'll have to wait
for someone else to discuss the "intended interaction".  But
regarding the basic revalidation mechanism:

    14.9.4 seems to say that must-revalidate is not unconditional, but
    rather that it only requires revalidation if the object is stale.
    It further seems to say that proxy-revalidate can be used to
    require shared proxies to authenticate each user.

The difference between must-revalidate and proxy-revalidate is
that the former applies to all caches, but the latter does not
apply to non-shared caches (e.g., browser caches).  If you are
willing to assume that a given browser cache is uniquely associated
with a specific user, then you could use proxy-revalidate instead
of must-revalidate (if your goal is to force re-authentication.)

    So, an origin server should send both "proxy-revalidate" and
    "public" to force revalidation?  If so, I think at the very least
    this should be added to the list in 14.8, and that proxies ought to
    be required to revalidate in this case.  If not, I need educating.

The intended way to force revalidation (by shared caches) is to use

 Cache-control: s-maxage=0, proxy-revalidate

I.e., tell the shared caches that the response is immediately
stale, and that shared caches are not allowed to ignore this.
*HOWEVER*, since this is rather verbose, and since the "s-maxage"
directive was added specifically to support this case, the
spec says "s-maxage directive also implies ... proxy-revalidate",
so you really only need to send

 Cache-control: s-maxage=0

to force a shared cache to revalidate on every access.  It's
a no-op for private caches.

Bottom line: I don't think this is an issue, except perhaps
for "the specification is complicated and someone should
write a tutorial".

Received on Wednesday, 15 July 1998 11:07:01 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:22 UTC