- From: Mark Nottingham <mnot@mnot.net>
- Date: Thu, 28 Oct 2010 17:04:16 +1100
- To: Adam Barth <w3c@adambarth.com>
- Cc: Willy Tarreau <w@1wt.eu>, Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
Intermediaries that aren't expecting CONNECT are just as likely to ignore it (i.e., many, but not all, will error out, whereas the rest will pass it through). E.g., try CONNECTing to Squid running as a transparent proxy, or against a L7 load balancer, or... Cheers, On 28/10/2010, at 4:59 PM, Adam Barth wrote: > On Wed, Oct 27, 2010 at 10:53 PM, Mark Nottingham <mnot@mnot.net> wrote: >> On 28/10/2010, at 4:48 PM, Willy Tarreau wrote: >>> On Thu, Oct 28, 2010 at 02:14:53PM +1100, Mark Nottingham wrote: >>>> Because CONNECT is for establishing a connection to a proxy, not a gateway (which is what you're doing). >>> >>> That's true but the semantics of the CONNECT method is the closest to what we >>> need in WebSocket. After all, we're negociating a bidirectionnal tunnel between >>> the browser and the application through the HTTP infrastructure. >> >> This is neither horseshoes nor hand grenades. CONNECT is unique (and badly designed, as a method) because it doesn't go through, it terminates at the proxy. Sending a CONNECT to an origin server makes no sense, and is likely to be blocked by all sorts of infrastructure. >> >> You'd be better off using Upgrade, which is very much designed for this use case. > > Unfortunately using Upgrade for WebSockets causes security > vulnerabilities because many intermediaries don't understand its > semantics and ignore it. On the other hand, CONNECT is widely used > and has the behavior we want. > > Adam -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 28 October 2010 06:05:02 UTC