- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Wed, 21 Feb 1996 23:16:45 -0800
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-caching@pa.dec.com
> But may not be sufficient. Consider the case of a new (future)
> method that (like MOVE) affects a resource that is not the
> Request-URI and (unlike MOVE) is also not in the URI: header.
> An HTTP/1.1 cache would not know that this other resource also
> has to be flushed from the cache.
>
> There are several ways to approach this:
>
> (1) Jeff, you ignorant fool, there is no way that this
> will ever happen.
>
> (2) Maybe someone will propose this kind of method in
> the future, but we'll have to reject that proposal
> because the HTTP/1.1 caches will not support it (as
> well as the HTTP/1.0 caches)
>
> (3) We could (in HTTP/1.1) define a Cache-control directive
> to make this work. For example,
> Cache-control: flush-URI="URI"
> or something like that.
I'll take option 4:
(4) Do nothing and let the world take care of itself.
As I said before, flushing the cache is only an optimization -- it
does nothing to ensure transparency in other caches. In practice,
it doesn't matter, since either the change is not important enough
to flush the cache or the user can flush it themself using a reload.
The best solution is to just flush the cache of any Request-URI upon
receipt of any unrecognized method for the URI. It takes care of
all the worst cases and as much of the side cases as is reasonably
possible.
...Roy T. Fielding
Department of Information & Computer Science (fielding@ics.uci.edu)
University of California, Irvine, CA 92717-3425 fax:+1(714)824-4056
http://www.ics.uci.edu/~fielding/
Received on Thursday, 22 February 1996 07:40:36 UTC