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

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.

....Roy

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