- From: Scott Lawrence <scott@skrb.org>
- Date: Tue, 16 Jan 2007 10:56:49 -0500
- To: Mark Nottingham <mnot@mnot.net>
- Cc: "Roy T.Fielding" <fielding@gbiv.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Tue, 2007-01-16 at 10:16 +1100, Mark Nottingham wrote: > This is fairly clear upon a careful reading of 4.3; > > > The presence of a message-body in a request is signaled by the > > inclusion of a Content-Length or Transfer-Encoding header field in > > the request's message-headers. A message-body MUST NOT be included > > in a request if the specification of the request method (section > > 5.1.1) does not allow sending an entity-body in requests. 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. > However, I think casual readers -- and some implementers -- have been > tripped up because many method definitions are silent on the matter, > and don't *explicitly* allow sending an entity-body. It might be > clarified by changing "does not allow" to "explicitly disallows". This is a general problem: some people want everything spelled out in every possible place where it might be relevant, others would prefer that each statement be made only once so that the spec is as short as possible but you must read all of it to understand it. I'm strongly in the latter camp. From my point of view, the current spec is too long by at least half, and the repetition of some rules in some places leads the unwise to assume that if that rule was repeated here and wasn't repeated there, then it must not apply there... > Also, devil's advocate; > 1) What are the implications of an entity-body on GET for the caching > model? The spec is silent on this AFAICT. Again - the spec has clear mechanisms for providing explicit cache controls - they should be used, and nothing should be inferred that they do not make explicit. IMHO, any cache should assume that any response is not cachable unless told that it is. > 2) Ditto for content negotiation. > 3) Are there any existent origin server or intermediary > implementations that are fully conformant with this requirement? Which requirement? -- Scott Lawrence http://skrb.org/scott/
Received on Tuesday, 16 January 2007 15:57:02 UTC