W3C home > Mailing lists > Public > http-caching-historical@w3.org > February 1996

extensibility

From: Jeffrey Mogul <mogul@pa.dec.com>
Date: Tue, 20 Feb 96 15:17:36 PST
Message-Id: <9602202317.AA09920@acetes.pa.dec.com>
To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
Cc: http-caching@pa.dec.com
    Why don't you just define the default on other methods to be a 
    cache flush, and then allow
    
	Cache-control: idempotent
    
    on the request to identify a method that doesn't need a flush.
    Note, however, that you'll still need to tell the cache what it
    should use as the cache key, and that is not a trivial problem.

This might be a useful thing to include (leaving aside the question
of whether "idempotent" has the right meaning).

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.

-Jeff
Received on Tuesday, 20 February 1996 23:31:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 28 November 2008 20:51:42 GMT