- From: Jeffrey Mogul <mogul@pa.dec.com>
- Date: Wed, 10 Apr 96 11:56:13 MDT
- To: http-caching@pa.dec.com
There has been a lot said about this issue, and not a lot of
clarity.
Let me try to isolate some of the specifics:
(1) The basic mechanism by which origin servers allow
caches to avoid revalidations is to use an expiration
time (expressed either with Expires: or with max-age).
(2) We have (for a long time) had a consensus that some
caches are going to ignore expiration times in the
service of better performance, with the understanding
that "somewhat stale" responses are usually acceptable.
Such loosening of expiration times can be done either
by end-user caches or intermediate (proxy) caches.
(3) Koen has made a convincing argument that there are
some specific cases where revalidation must be done,
or else serious semantic failures will result. However,
these cases do NOT require us to disable caching entirely,
so the use of "no-cache" responses is unnecessary and
would harm performance.
(4) The "must-revalidate" response directive solves Koen's
problem, while allowing intermediate caches to violate
a max-age=0 directive according to consensus #2 above.
(5) Must-revalidate is mandatory for proxy caches. Only
an end-user cache (i.e., in a PDA) is allowed to cheat,
and I'm agreeing to this only because some people think
that PDA implementors (and the like) will cheat anyway.
The spec will insist that in this case, the user MUST
be informed that something dangerous is being done.
(6) I originally tried to suggest that all server-specified
expiration times should be mandatory, but various of you
(including Roy, if I recall) said I couldn't do this.
If you all want to change your minds now, then we can
make max-age=0 mandatory, and remove must-revalidate.
Otherwise, these are NOT redundant directives, and must
both be in the protocol in order to satisfy all of the
requirements people have imposed.
(7) This is NOT something that can be solved by attaching
a "special warning" to max-age=0 (unless by "special warning"
Koen means making it a MUST requirement in the spec, and I
don't believe this is what Koen meant). Warnings are
advisory and are meant for display at the user agent. They
are not meant to control the actions of proxy caches.
(Yes, Roy, I think you're probably right that the Warning 98
that I proposed is inconsistent with the basic Warning design.)
(8) Roy seems to think that "must-revalidate" will generate
loud warnings frequently. This a misunderstanding. The
only rational default configuration for an end-user system
is "obey must-revalidate". However, a very small number of
end-systems may be configured otherwise (although personally
I consider this stupid), and ONLY those systems will display
the warnings.
One more thing. I've heard arguments of the form "we shouldn't
include must-revalidate because service authors who want hit-counts
will probably send it all the time." This is specious for two
separate reasons:
Reason #1: In the absence of must-revalidate or any mandatory
requirement that expiration times be observed by caches, such
service authors will simply send "no-cache" instead (which I
believe we have agreed has to be mandatory). So instead of
burdening the network with a lot of conditional GETs (the
consequence of excessive use of must-revalidate), we burden
the network with the much larger load of unconditional GETs.
This is not a win!
Reason #2: We have a choice between (A) specifying a protocol
that, if used "appropriately" (i.e., not abused by servers
looking for hit counts), solves Koen's problem, and (B) specifying
a protocol that does not solve Koen's problem.
The possibility that design A might be abused does not change
the fact that design B is not satisfactory. Put another way,
for servers that do not abuse the protocol, design A provides
advantages that design B does not.
-Jeff
Received on Wednesday, 10 April 1996 19:27:54 UTC