W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 1998

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

From: Dave Kristol <dmk@bell-labs.com>
Date: Tue, 24 Feb 1998 16:39:59 -0500
Message-Id: <34F33E2F.237C228A@bell-labs.com>
To: Jeffrey Mogul <mogul@pa.dec.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/5392
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
Received on Tuesday, 24 February 1998 13:47:06 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:04 UTC