- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 29 Oct 2010 10:09:44 +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>
It (i.e., not using port 80) has already been raised many times, doubtless it'll be raised again. Regards, On 29/10/2010, at 4:36 AM, Adam Barth wrote: > This sounds like a valuable discussion to have in the HyBi working > group. I'm not sure we've got all the right folks on this mailing > list to respond to your feedback. > > Adam > > > On Thu, Oct 28, 2010 at 2:00 AM, Mark Nottingham <mnot@mnot.net> wrote: >> >> On 28/10/2010, at 6:23 PM, Willy Tarreau wrote: >>> >>> I'd pose the question the other way around : how could we replace existing >>> long-polling mechanisms that already work over HTTP and benefit from all >>> features that have been built around HTTP, on a different port. Right now, >>> virtual hosting >> >> WebSockets on a separate port can easily identify the intended host, just as HTTP does... >> >>> , ability to be proxied any number of times >> >> ... but as proposed, it's not, because it's so extremely brittle... >> >>> , including through URL filters (think about schools) >> >> ... which will either block WS as a policy decision, or just block by host/port combination anyway... >> >>> , session state management >> >> ... which can already span multiple hosts and ports... >> >>> and server stickiness >> >> ... which would also be available on a separate port... >> >>> are essential to web applications nowadays. If we're going to >>> use a distinct port, we're losing most of these existing features, which >>> will considerably lower adoption. >> >> As you can probably tell, I don't buy it. >> >>>>> From CONNECT, specifically, we'd like to get WebSocket-oblivious >>>>> intermediaries to ignore the rest of the bytes on the socket. CONNECT >>>>> lets them know that the rest of the bytes coming from the client >>>>> aren't going to be HTTP, so they shouldn't try to understand the >>>>> semantics of those bytes. >>>> >>>> Explicitly configured forward proxies -- as opposed to "reverse" proxies, interception (a.k.a. "transparent") proxies, L7 load balancers, firewalls and the like -- will indeed do this. Whether any of the rest will is anyone's guess, and depends upon how they're coded, whether they're ever used as a forward proxy, and how generous / clued-up the administrator is. >>> >>> Pure reverse proxies will probably not work, just as they currently don't >>> work with 101 either. Firewalls and load balancers do support explicit >>> proxies (those were the first users of load balancers) >> >> They support *being* a proxy, or being a proxy behind a firewall. The question here is whether they support connections *through* them using CONNECT to another proxy. E.g., Checkpoint's URL filtering and web protection stuff, and lots of other products besides. >> >>> and as such are >>> well aware of the methods used in such environments. There's still the >>> common issue of proxy-connection vs connection but there's already a bug >>> open on the subject. >> >> [...] >> >>>> You're missing the point here -- a box that isn't expecting and explicitly handling CONNECT will also think that HTTP semantics apply beyond the end of the message. >>> >>> But do we have any chance to spot any such implementation ? That was one of >>> my concern in the early days when I too proposed CONNECT, but if the >>> implementation is server-side only, it generally does not support CONNECT, >>> which is fine. And if it supports relaying to proxies it will support it >>> with correct semantics. >> >> >> No. Nothing requires an intermediary to support CONNECT, and if they don't, nothing prevents them from treating it like any other HTTP message; i.e., delimited according to HTTP, and followed by more HTTP messages. >> >> Cheers, >> >> -- >> Mark Nottingham http://www.mnot.net/ >> >> >> >> -- Mark Nottingham http://www.mnot.net/
Received on Thursday, 28 October 2010 23:10:19 UTC