Re: Proposal: 205 Bodies [#88]

On 26/10/2010 4:23 a.m., Julian Reschke wrote:
> On 11.06.2009 11:58, Roy T. Fielding wrote:
>> On Jun 11, 2009, at 11:39 AM, Julian Reschke wrote:
>>> Mark Nottingham wrote:
>>>> We have a similar situation around request bodies --
>>>>> 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.
>>>> What I'd like to do in both cases is make it more apparent that the
>>>> list of exceptions is closed, by not predicating it on an external
>>>> MUST NOT.
>>> That's a good point.
>>>> In the case for requests, I think the entire sentence disappears,
>>>> because we have not specified any method that disallow request bodies
>>>> (unless one of the many WebDAV methods places this requirement on
>>>> requests, and even then...).
>>> Nope, WebDAV doesn't do that.
>>> 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.

in relation to CONNECT, I think we can justify giving it special 
treatment for several reasons:

1. It's not part of the original spec, but an extension designed to 
enable arbitrary connectivity through a compliant proxy
2. It already has very specific requirements which make it very 
un-HTTP-like (e.g. the proxy connects and gets out of the way), no HTTP 
is (necessarily) used upstream.

In fact in our code-base the special handling for CONNECT is much more 
involved than for say HEAD.  I find it hard to conceive of a proxy that 
wouldn't treat CONNECT as a very special case already.

In the one case where I've seen a body on a CONNECT method (blu-ray 
player), if that body were passed through to the end server, it broke 

If you allow bodies on a method, then Content-Length is required.  I 
don't see any Content-Length headers on CONNECT messages, so current 
browsers would become incompatible.

Can we allow Transfer-Encoding: chunked on CONNECT?  IMO we can't.


> > ...
> In the meantime, the parsing section in Part 1 has been revised.
> I believe we still need to rephrase the description of 205, currently 
> saying:
> "The response MUST NOT include a message-body."
> Proposal:
> "The message-body included with the response MUST be empty."
> (<>) 
> Best regards, Julian

Received on Monday, 25 October 2010 21:45:44 UTC