must-revalidate

There's something bothering me about this stuff.

We've got this nice  (well, it's kind of nice, anyway) protocol that
tells caches when they can and can't deliver objects out of the cache.

But we know some people are going to ignore the rules, so here we are
making a rule that says, essentially, we made these rules, but we know
you're going to break them, so when you do, then here are the other
rules you must follow.

This seems a bit defeatist.

I think the direction we're going with "must-revalidate", or
"must-verify"  or "user-must-see-a-warning-dammit" is good, but
there's still something not quite right.

There is a range of behavior that is acceptable under different
circumstances, and what we need to figure out is what the right
default is and how to encode deviations from the default.

The existing spec-in-progress without must-revalidate gives a nominal
behavior that allows certain kinds of services to work if it is followed.

There seems to me to be an orthogonal parameter to this, which is
what should happen if these rules are not adhered to.

I think the right *default* behavior is for the user to be warned.
I also think it is reasonable for the server to be able to specify
at least two other positions:   (1) it's ok to violate the rules
without impairing the semantics of the service, and (2) you'd better
not even *think* of violating the rules, because if you do, something
really bad will happen.

So, what about, instead of cache-control: must-revalidate, we had some
parameterized option such as:

	cache-control: exception=fatal	 (means you can't "legally" violate
					  the other rules, period)

	cache-control: exception=warning (this is the default.  A user
					  warning is *required* to be legal)

	cache-control: exception=ok	(means the other rules are advisory
					and you can ignore them safely)

--Shel

Received on Thursday, 11 April 1996 04:11:11 UTC