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

Dave Kristol (dmk@bell-labs.com)
Tue, 24 Feb 1998 16:39:59 -0500 

Jeffrey Mogul wrote:
> 
> 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:

That latter.

> 
>   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?

My marbles. :-)  The warnings should suffice.

> 
>     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."

Would it make sense to add words to that effect to the spec.?  Or at
least advice to implementers?

> [...]

Dave Kristol