W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Re: Requests that do now allow bodies (do they exist?), was: Proposal: 205 Bodies [#88]

From: Roy T. Fielding <fielding@gbiv.com>
Date: Thu, 11 Jun 2009 13:56:26 +0200
Message-Id: <BA59E414-CD8C-481B-AEC5-4E44500A5336@gbiv.com>
Cc: Mark Nottingham <mnot@mnot.net>, HTTP Working Group <ietf-http-wg@w3.org>
To: Julian Reschke <julian.reschke@gmx.de>
On Jun 11, 2009, at 1:01 PM, Julian Reschke wrote:

> 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."

I am not sure about the last sentence, but the rest is okay.  The
real interoperability requirement is that the proxy/gateway must parse
the message correctly (handling the body even if it is not expected
by the method semantics) and not treat that body as a second request.
Whether it forwards the request or responds with an error is a decision
left to the local policies, I think.

Received on Thursday, 11 June 2009 11:56:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:40 UTC