- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 28 Oct 2010 08:05:15 +0200
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Adam Barth <w3c@adambarth.com>, Julian Reschke <julian.reschke@gmx.de>, Adrien de Croy <adrien@qbik.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Thu, Oct 28, 2010 at 04:53:47PM +1100, Mark Nottingham 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. Not exactly in fact. Components that support being placed in front of proxies (load balancers, IPS, ...) will automatically support it provided we respect the way it's used with proxies, while they will not all necessarily support the Upgrade. Those who wont support CONNECT are likely the sames which won't support Upgrade. > You'd be better off using Upgrade, which is very much designed for this use case. I agree with the design part. But Adam found one situation where he thinks that Upgrade through a non-compatible infrastructure could be used by an attacker's site to make a browser inject requests to another site, if my memory serves me right. While I still think this is marginal, I'd rather use the safest approach that is fully compatible with HTTP and with the needs of WS. (Which also means that if we can't get CONNECT to correctly work, then Upgrade would probably fit the purpose). Regards, Willy
Received on Thursday, 28 October 2010 06:05:56 UTC