W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2008

Re: NEW ISSUE: message-body in CONNECT response

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 28 Feb 2008 12:22:44 +1100
Cc: "Roy T. Fielding" <fielding@gbiv.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, ietf-http-wg@w3.org
Message-Id: <78539CC9-56CA-4E5F-8E59-60D6A5B1FD01@mnot.net>
To: Robert Siemer <Robert.Siemer-httpwg@backsla.sh>

I'll take that as a +1, then.


On 28/02/2008, at 12:21 PM, Robert Siemer wrote:

> On Thu, Feb 28, 2008 at 11:10:37AM +1100, Mark Nottingham wrote:
>
>> Is it worth strengthening this language?
>
> Strengthening? Section 4.3. says that the existence of a message  
> body is
> request method dependent. That is mathematically correct, but not
> logically: apart from the historic HEAD exception, the existens of a
> body is *not* method dependant. (Future methods can not change that.)
>
> It is generally a good idea to include "why" some things are the way
> they are. A note that HEAD is different for historic reasons makes
> pretty clear to the reader: don't draw any generic conclusions from
> HEAD.
>
>>
>>
>> On 29/11/2007, at 10:58 AM, Roy T. Fielding wrote:
>>
>>>
>>> On Nov 28, 2007, at 3:20 PM, Robert Siemer wrote:
>>>> I read the last sentence as "all other respones - defined in this
>>>> spec - do
>>>> include a message-body..."
>>>
>>> You read it wrong.  The only possible way that a proxy can forward
>>> the response to a method it does not understand is if no method
>>> other than HEAD (for legacy reasons ONLY) is allowed to change the
>>> message delimiting rules.  This applies to anything that uses or
>>> extends HTTP and will not be changed.
>>>
>>> As it happens, CONNECT can't be forwarded by proxies without having
>>> understood the method (because it uses a unique request format).
>>> That allows non-compliant behavior to be ignored, but it is still
>>> non-compliant.
>>>
>>> ....Roy
>>>
>>
>>
>> --
>> Mark Nottingham     http://www.mnot.net/
>>


--
Mark Nottingham     http://www.mnot.net/
Received on Thursday, 28 February 2008 01:23:05 GMT

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