- From: <jg@w3.org>
- Date: Thu, 02 May 96 13:42:44 -0400
- To: "Roy T. Fielding" <fielding@avron.ICS.UCI.EDU>
- Cc: Paul Leach <paulle@microsoft.com>, "'koen@win.tue.nl'" <koen@win.tue.nl>, "'http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, jg@w3.org
Roy says: >>>Not accurate -- the cache never needs to do any such thing in order to >>>remain conditionally compliant with HTTP (the meaning of "SHOULD"). >> >> If it doesn't cache responses as a general rule, it may be a proxy, but >> it ain't a cache. > >A cache will only cache responses for which it believes there to be >a reasonable likelihood of a later hit on that cached entry. It is >always possible for the cache to have a better idea of that likelihood >than the origin server, and thus it is always possible for the cache >to not want to cache a response, even when the response is cachable. > >The spec should never require anything that doesn't need to be required, >and there is no reason to include additional sections on caching which >describe things not determinable (nor determined by) the protocol. You are fine until the last bit of the last sentence. We do have to define, if something is cached, which cached item and under what circumstances the cached item can and should be returned to satisfy a request. It is not clear to me that a communications protocol by itself has all the information required (or if it does, that mere mortal implementers can figure out the correct entry to return for a request from the protocol description alone). - Jim
Received on Thursday, 2 May 1996 10:49:49 UTC