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

Re: #250 / #251 (connect bodies)

From: Adam Barth <w3c@adambarth.com>
Date: Wed, 27 Oct 2010 20:06:50 -0700
Message-ID: <AANLkTi=uCmeNvoe3jrCpSaTCS9paCuOnR09vFCpSurHM@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
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/
>
>
>
>
Received on Thursday, 28 October 2010 03:07:51 GMT

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