RE: Must-revalidate [was Re: Warning: header, need origin]

Henry Sanders made an interesting suggestion to me -- what if we made
max-age=0 always mandatory (same as proposed "must-validate", but told
people to use max-age=1 when it was (barely) acceptable for end-user
caches to violate it.

Not revalidating when max-age is 0 would require a dialog box each time
for the user to approve; not validating for max-age > 0 could be done
with a preference setting.

This way, a user-agent that just wanted to strictly obey the
origin-server's max-age request could just ignore this whole issue.

Paul

>----------
>From: 	Jeffrey Mogul[SMTP:mogul@pa.dec.com]
>Sent: 	Wednesday, April 10, 1996 10:56 AM
>To: 	http-caching@pa.dec.com
>Subject: 	Must-revalidate [was Re: Warning: header, need origin]
>
>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 23:37:16 UTC