W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1996

Re: The problem with proxy-revalidate, and a proposed solution

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Fri, 20 Dec 96 11:13:07 PST
Message-Id: <9612201913.AA20214@acetes.pa.dec.com>
To: Anselm Baird-Smith <abaird@w3.org>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
    Jeffrey Mogul writes:
     > After thinking about it for a while, and making up a table of all
     > the possible combinations....
    
    Anselm Baird-Smith writes:
    I think it would help a lot to have this table, before actually going
    into deeper discussions.
    
Actually, I did create the table before sending that message, but I
thought the message was already pretty long without it.  Also, the
table needs some explanatory notes, which I have now added.  See
below.

    BTW it would be nice if this table also contained the warnings to be
    emitted for each cases along with the conditions under which these
    warnings should be emitted.

I'll take you up on your offer to help ... if you can figure out
how to add these to the table, please do so.  It would be nice if
it still fits in a 72-column fixed-width format, because then I
can stick it into an Internet-Draft without any glitches.

-Jeff

Explanatory notes:

The leftmost column shows the Cache-control headers emitted by the
origin server.  In all cases, I assume that the response is marked
as "revalidatable" in some way, such as the presence of an entity-tag
or last-modified date.

The rest of the table is divided into two major columns, depending
on whether the cache involved is at an end-client system, or a
shared proxy cache.  (We can probably treat a non-shared proxy
cache as being a sort of "distributed" implementation of an end-client
cache.)

Each of the major columns is divided into three minor columns, showing
the action to take
	(1) if the response is fresh
	(2) if the response is stale, and the cache is being strict
	about revalidating stale responses
	(3) if the response is stale, and the cache is not being strict
	about revalidating stale responses

The table assumes that there is only one kind of "max age" for a response,
set by a max-age directive (or, equivalently, by an Expires header).
If we were to introduce a proxy-maxage directive, the table would
need some more rows, and in the Proxy Cache columns, the test for
"freshness" would have to account for this new kind of "max age".

In the table entries,
	NA	   means "not applicable" (i.e., can't happen)
	use	   means "use entry without revalidating"
	check	   means "use entry after revalidating"
	ignore	   means "use entry without revalidating, even if stale"


Site:		    Client cache		    Proxy Cache
entry state:	fresh	stale	stale		fresh	stale	stale
policy:			strict	loose			strict	loose
-----------------------------------------------------------------------
In current HTTP/1.1 spec:
-----------------------------------------------------------------------
Age limit
from server
===========
No max-age	use	NA	NA		use	NA	NA

max-age > 0	use	check	ignore		use	check	ignore

max-age = 0	NA	check	ignore		NA	check	ignore

must-reval	use	check	check		use	check	check
+max-age > 0

must-reval	NA	check	check		NA	check	check
+max-age = 0

proxy-reval	use	check	ignore		use	check	check
+max-age > 0

proxy-reval	NA	check	ignore		NA	check	check
+max-age = 0

-----------------------------------------------------------------------
Missing from HTTP/1.1 spec:
-----------------------------------------------------------------------
Age limit
from server
===========
No max-age	use	NA	NA		check	NA	NA

max-age > 0	use	check	ignore		check	check	check

max-age = 0	NA	check	ignore		NA	check	check

-----------------------------------------------------------------------
If we added a proxy-mustcheck directive, those three rows would become:
-----------------------------------------------------------------------
Age limit
from server
===========
No max-age	use	NA	NA		check	NA	NA
+proxy-
mustcheck

max-age > 0	use	check	ignore		check	check	check
+proxy-
mustcheck

max-age = 0	NA	check	ignore		NA	check	check
+proxy-
mustcheck

-----------------------------------------------------------------------
Missing from HTTP/1.1 spec, but probably not useful:
-----------------------------------------------------------------------
Age limit
from server
===========
No max-age	check	NA	NA		use	NA	NA

max-age > 0	check	check	check		use	check	ignore

max-age = 0	NA	check	check		NA	check	ignore
Received on Friday, 20 December 1996 11:21:54 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:19 EDT