- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 27 Oct 2010 20:06:50 -0700
- 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 UTC