- From: Roy T. Fielding <fielding@gbiv.com>
- Date: Tue, 16 Jan 2007 18:52:14 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Jan 16, 2007, at 6:09 PM, Mark Nottingham wrote: > Are you saying that a cache on such a proxy or gateway SHOULD NOT > return a fresh response from cache, but instead forward the > request, if a GET request has a message-body? No. A cache does not "return" and does not "forward". You aren't using the definitions as stated in the specification. cache A program's local store of response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server may include a cache, though a cache cannot be used by a server that is acting as a tunnel. You are assuming that a cache is a server because that is how the term is often used in our line of work. That is fairly common, and you are right that 2616 has several places where the word cache is misused. What I suggested was: When a request message contains both a message-body of non-zero length and a method that does not define any semantics for that request message-body, then an origin server SHOULD either ignore the message-body or respond with an appropriate error message (e.g., 413). A proxy or gateway, when presented the same request, SHOULD either forward the request inbound with the message-body or ignore the message-body when determining a response. Note that a proxy or gateway "SHOULD either forward ... or ignore". That entirely covers all possible combinations of server, with or without cache, and without the contradictions that were added to 2616. When a proxy or gateway uses a cache, it is "determining a response". We could add "determining a response though use of an internal cache and/or configurable error mechanism", but then we would be making a guess about the scope of ways in which a proxy or gateway might be implemented, rather than specifying an HTTP interface requirement. ....Roy
Received on Wednesday, 17 January 2007 02:52:29 UTC