- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 28 Oct 2010 14:14:53 +1100
- To: Adam Barth <w3c@adambarth.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
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 UTC