Re: comments on HTTP/1.1 Rev02 20Feb98 (related to caching)

Dave Kristol writes:

    3) 13, Caching in HTTP
	Last paragraph:  I think something like the following needs to be
	added at the end:
	"In such cases, the design should also provide a way to inform the
	end user of a break in transparency."
    
Are you refering to this paragraph:
   A basic principle is that it must be possible for the clients to detect
   any potential relaxation of semantic transparency.
or to the "Note" that follows it?  At any rate, just before the short
paragraph I quoted, we already have:

  3. Protocol features that allow a cache to attach warnings to
     responses that do not preserve the requested approximation of
     semantic transparency.

What exactly are we missing here?

    4) 13.11 Write-Through Mandatory
	Suppose I want to add a custom method to HTTP, one of whose
	side-effects would be to invalidate a cache entry.  (Suppose
	I were adding something comparable to DELETE, for example.)
	How would the cache know it must invalidate the associated
	resource?  I don't think any of the Cache-Control directives
	can tell the cache to discard an entry, can they?  (And if they
	could, that would be an interesting denial of service attack.)
    
Note that 13.11 per se is not about invalidation (this is discussed in
other places); it's about requiring the cache to forward "all methods
that may be expected to cause modifications" to the origin server.
Which is another way of saying "if it's not GET or HEAD, a proxy must
forward it."

One could certainly attack the intellectual basis for the
discussions (elsewhere) about invalidation.  It's basically
impossible to do anything "correct", but we've added a few
stop-gap measures so that in the places where we know what is
going on, we can avoid obvious incoherencies.  A custom method
is by definition not part of HTTP/1.1, so it's hard for us to
specify what it would do to a cache entry, but one could imagine
implementing a rule that "if you are forwarding a method that
you don't understand, you should also invalidate any cache
entries that might possibly be related to the Request-URI."

The possibility of a denial-of-service attack (really, a "denial
of cache performance" attack) is not limited to this particular
case.  My own preference is that we can't engineer the protocol
to prevent them, so the right thing to do is to detect them
(at the proxy, by log analysis) and then call in the lawyers.

Anyway, it seems unlikely that we could change the HTTP/1.1
spec, at this late date, to do anything new w.r.t. cache
invalidation.

-Jeff

Received on Tuesday, 24 February 1998 13:24:50 UTC