- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Thu, 11 Jun 2009 13:01:05 +0200
- To: "Roy T. Fielding" <fielding@gbiv.com>
- CC: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
Roy T. Fielding wrote: > ... >> From RFC2616 I see two potential candidates: (1) TRACE (which uses the >> same terminology as the 205 status that started this thread: "MUST NOT >> include an entity"), and (2) CONNECT (?). > > There are no candidates. Any change to the message parsing algorithm > would require a major bump in HTTP version. > ... I should have phrased that differently. Right now there's a unfortunate combination of Part 1 saying: "...A message-body MUST NOT be included in a request if the specification of the request method (Section 2 of [Part2]) explicitly disallows an entity-body in requests..." -- <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-06.html#rfc.section.4.3.p.5> and non-optimal text in Part 2. So to reduce confusion, it would be good to drop the sentence above, and make that paragraph just say: "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. 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." BR, Julian
Received on Thursday, 11 June 2009 11:01:47 UTC