Re: #250 / #251 (connect bodies)

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 00:53:19 UTC