W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: Proposal: 205 Bodies [#88]

From: Adrien de Croy <adrien@qbik.com>
Date: Tue, 26 Oct 2010 10:45:05 +1300
Message-ID: <4CC5FA61.9060900@qbik.com>
To: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>


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

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.

Adrien

> > ...
>
> 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."
>
> (<http://trac.tools.ietf.org/wg/httpbis/trac/attachment/ticket/88/i88.diff>) 
>
>
> Best regards, Julian
>
Received on Monday, 25 October 2010 21:45:44 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:30 GMT