Re: #250 / #251 (connect bodies)

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/
>
>
>
>
>

Received on Wednesday, 27 October 2010 07:32:34 UTC