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

Jeffrey Mogul writes:

 > Here is the language that I have now:
 > 
	...
 >    Because a cache may be configured to ignore a server's specified
 >    expiration time, and because a client request may include a max-stale
 >    directive, which has a similar effect, the protocol also includes a
 >    mechanism for the origin server to require revalidation of a cache
 >    entry on any subsequent use.  When the ``must-revalidate'' directive
 >    is present in a response received by a cache, that cache MUST NOT use
 >    the value to respond to a subsequent request without first
 >    revalidating it with the origin server.  (I.e., the cache must do an
 >    end-to-end revalidation every time.)
 > 

The thing that seems wrong to me about this is that it is not
orthogonal to the other parts of the protocol.

The way you have stated it, if "must-revalidate" is present, that
effectively nullifies other cache controls like expires or max-age.

Why can't we have an orthogonal control on this that specifies what is
to happen when the existing protocol (using expires and max-age) is
not obeyed?  This way we have the flexibility of allowing things
to be served from a cache in a fully general way, with the exception
behavior also fully general.  Why put in non-orthogonal elements?
The fact is we *don't* know all applications of the protocol now.
Putting in non-orthogonal elements restricts what you can do using the
protocol unnecessarily.

A slight improvement on what you have would be that
"must-revalidate" *doesn't* override the existing protocol -- it just
specifies what *MUST* happen when a cached object is stale, relegating
the default case (i.e. without "must-revalidate") to be about what
*SHOULD* happen when a cached object is stale.  But I'd still prefer
if the behavior on violation of the nominal "freshness/staleness"
rules were fully controllable separately from those rules themselves.

If I'm missing something about what you meant, what do you suppose it is?

--Shel

Received on Sunday, 14 April 1996 01:29:57 UTC