Re: Warning: header, need origin

Thanks for explaining that with an example.  I think I finally understand
what you need, now.

However, I think there is a much simpler and more robust way of
providing it.

The basic problem is that we have already come to a consensus that
caches may be configured to ignore max-age (on responses) if that
is deemed necessary for performance.  Not recommended, but allowed.

The protocol also already allows an origin server to say "don't
cache this response," but we all agree that this is too restrictive
to use in all cases.

You write:
    So what we don't want is caches which are configured to give stale
    responses instead of doing a conditional GETs when the max-age is
    exceeded: this leads to the showing of the old basket, which is
    unacceptable.

I.e., you need an unavoidable mechanism to require at least conditional
validations on every access.

There are two ways to accomplish this:

	(1) somehow the origin server detects when a client cache
	is not observing max-age, and in such cases, the origin
	server forces non-caching of responses to such requests.

	(2) We provide a mandatory mechanism in the protocol that
	allows the origin server to mark a response as "cachable
	but you must always revalidate, no exceptions allowed".

I've tried to argue that using method (1) is complex, may hurt
performance in unrelated contexts (violating the rule that Roy
proposed "place the burdens where the benefits lie"), and may not
be robust.  We could argue more about that, but time is short.

But method #2 seems to be quite simple and foolproof: We add a
new
	Cache-control: must-revalidate
for responses.  The origin server sets this on any response that
it requires revalidations (e.g., conditional GETs).  No HTTP/1.1
cache is allowed to ignore it.  It has the same meaning as
	Cache-control: max-age=0
on responses, but MUST be obeyed.

Any problems with that?

-Jeff

Received on Monday, 8 April 1996 19:40:41 UTC