- From: Shel Kaphan <sjk@amazon.com>
- Date: Mon, 11 Sep 1995 13:01:01 -0700
- To: Larry Masinter <masinter@parc.xerox.com>
- Cc: fielding@beach.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Larry Masinter writes: ... > > Of course, proxies have to understand the semantics of <method> and > <httpversion> in order to do CACHING. Yes, you need to know what > someone really intended before you start saving away the response and > feeding it back to clients later. > It would be nice to get this clarified. What specifically is wrong with this model: *Most* of the time the header metadata (not counting the method) will contain enough information to make caching decisions. On requests, all standard HTTP methods must be forwarded to the origin server, with the exception of GET and HEAD, which may be served from a cache (depending on other headers and the state of the cache). This special rule for GET and HEAD is, I think, the only place where proxies have to know the semantics of the methods for cache control purposes. (And generalizing this is why I thought it would be useful to have another header to cause this behavior for non-standard methods). Certainly if the proxy is acting as a protocol gateway the methods also must be understood, and can't be forwarded if there is no pre-established mapping. Whether or not to pay attention to other headers such as "Pragma: no-cache" or "Cache-control: ..." is another version-dependent decision, but is independent of the method. On responses, I believe that whether or not there is an entity suitable for caching can be completely controlled by the response header information. Whether it in fact *is* controlled this way in current practice is a different matter. In current practice, only POST is really in question. And I know for a fact that some major UAs cache results the same way whether they are results of GET or POST -- in fact the results occupy the same cache slot (which I think is good, even if only serendipitous). You agreed that proxies can forward all methods. But you said that they need to understand the method semantics to properly handle caching. I think that the safe behavior is that if proxies don't recognize the request method they must forward it toward the origin server. I am looking for reasoned arguments on why the response must not be cached when the method is unknown. This all gets back to the same old unanswered questions about the semantic requirements on the behavior of caches.
Received on Monday, 11 September 1995 13:07:09 UTC