- From: Mark Nottingham <mnot@mnot.net>
- Date: Wed, 17 Jan 2007 13:09:56 +1100
- To: Roy T. Fielding <fielding@gbiv.com>
- Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 2007/01/17, at 10:20 AM, Roy T. Fielding wrote: > > On Jan 16, 2007, at 2:49 PM, Mark Nottingham wrote: >> My reading is that this would be cacheable, and that the cache key >> would be just the URI. In particular, the last sentence of the >> quoted spec text above helps clarify this, although it's talking >> about servers, not necessarily caches. > > Don't get the terminology messed up. Caches are storage things that > could be on either clients or servers. Servers are components that > happen to be playing the role of sending a response at this moment. > As such, the only thing it should talk about is servers -- whether > or not a cache exists in the server is irrelevant. That's what I meant by "it's talking about servers, not necessarily caches." >> Does that make sense? I'd feel a bit better if the language were >> massaged to include not just servers, but caches as well. E.g., >> >> "A server SHOULD read and forward a message-body on any request. >> If the request method does not include defined semantics for an >> entity-body, or if the request method is unrecognised, then the >> message-body SHOULD be ignored by servers and caches when handling >> the request." > > I disagree with both sentences. The first one is just wrong -- it > contradicts both the rules for message parsing (fails to account for > HEAD requests) and lumps all servers into the category of proxies > and gateways. 2616 already says "A server SHOULD read and forward a message-body on any request; if the request method does not include defined semantics for an entity-body, then the message-body SHOULD be ignored when handling the request." so it seems that this problem already exists. > In the second sentence, caches do not "handle the request", > ever. The cache is part of the server and subject to its > requirements. > > 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. 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? -- Mark Nottingham http://www.mnot.net/
Received on Wednesday, 17 January 2007 02:09:48 UTC