W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2010

Re: #250 / #251 (connect bodies)

From: Willy Tarreau <w@1wt.eu>
Date: Thu, 28 Oct 2010 22:23:37 +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>
Message-ID: <20101028202337.GD25911@1wt.eu>
On Thu, Oct 28, 2010 at 08:00:10PM +1100, Mark Nottingham 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 you suggesting to be HTTP compliant but to just use a different port ?
If so, then I agree that we can easily reuse existing infrastructure without
implying risks on existing shared hosting environments. But it's not clear
to me that it is what you're talking about. My understanding is that you
want to get rid of the HTTP compatibility which at the same time would
require to reinvent all the components to offer the features above.

I think that it is a solution which has never been suggested on the hybi WG
to use HTTP over a different port. Either it was HTTP on same port with
horrible tricks, or something very different and incompatible on a dedicated
port. The more I think about it, the more I like the principle of HTTP over
another 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.

I've noticed, but your wording does not make it clear to me what you're
proposing.

> > 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.

I was not talking about them being a proxy but clearly being installed in front
of a proxy. I know for sure that haproxy works. Alteon used to work last time I
tested (years ago). I'm pretty sure that Cisco ACE works. I don't know for them
all, but what I mean is that it's common to install a load balancer before a
proxy, which is transparent to both sides.

BTW, I'm suspecting we're getting off-topic for this WG and that this discussion
should move to hybi.

Regards,
Willy
Received on Thursday, 28 October 2010 20:24:15 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:32 GMT