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

Re: #250 / #251 (connect bodies)

From: Mark Nottingham <mnot@mnot.net>
Date: Thu, 28 Oct 2010 14:14:53 +1100
Cc: Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Message-Id: <0158DEB3-5137-4DCE-9072-7C1D716F0A55@mnot.net>
To: Adam Barth <w3c@adambarth.com>
Because CONNECT is for establishing a connection to a proxy, not a gateway (which is what you're doing).

Also, I suspect putting a body on a CONNECT request is going to lead to interop problems (which is what led to #251).

Cheers,


On 28/10/2010, at 2:06 PM, Adam Barth wrote:

> Why isn't CONNECT appropriate?  We're trying to negotiate a
> bidirectional channel after receiving the server's response.  Seems a
> lot like CONNECT + Proxy-Authentication giving you a bidirectional
> channel for TLS.
> 
> Adam
> 
> 
> On Wed, Oct 27, 2010 at 5:52 PM, Mark Nottingham <mnot@mnot.net> wrote:
>> If you're referring to section 1.1 step 7 -- that's not really an appropriate use of CONNECT, according to its definition. POST would be more so (although the criticism that it's not really HTTP that's being spoken still holds).
>> 
>> Cheers,
>> 
>> 
>> On 27/10/2010, at 6:31 PM, Adam Barth wrote:
>> 
>>> There are use cases for including a non-zero length body in an CONNECT
>>> request.  For example, draft-abarth-websocket-handshake includes some
>>> additional data with the CONNECT request.  Of course, we could put
>>> that data in a header, but it seems to make sense as an entity-body.
>>> 
>>> Adam
>>> 
>>> 
>>> On Tue, Oct 26, 2010 at 6:58 PM, Mark Nottingham <mnot@mnot.net> wrote:
>>>> I think we can specify:
>>>> 
>>>> 1) CONNECT requests MUST have a zero-length body (same language referring to p1 as we used for 205)
>>>> 2) CONNECT responses that are successful (2xx) MUST have a zero-length body, because the tunnel begins after the header block.
>>>> 
>>>> Thoughts?
>>>> 
>>>> 
>>>> On 26/10/2010, at 7:33 PM, Julian Reschke wrote:
>>>> 
>>>>> On 25.10.2010 23:45, Adrien de Croy wrote:
>>>>>> ...
>>>>>> 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
>>>>> 
>>>>> I think we are in agreement that CONNECT, once we add it to the spec, needs more work (see issues 250 and 251).
>>>>> 
>>>>> Best regards, Julian
>>>>> 
>>>> 
>>>> --
>>>> Mark Nottingham   http://www.mnot.net/
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>> 
>> --
>> Mark Nottingham   http://www.mnot.net/
>> 
>> 
>> 
>> 

--
Mark Nottingham   http://www.mnot.net/
Received on Thursday, 28 October 2010 03:15:29 GMT

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