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: Fri, 29 Oct 2010 07:40:14 +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: <20101029054014.GB28406@1wt.eu>
On Fri, Oct 29, 2010 at 10:13:06AM +1100, Mark Nottingham wrote:
> On 29/10/2010, at 7:23 AM, Willy Tarreau wrote:
> > 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 !
> If the request-line doesn't have HTTP/ in it, I don't care what it does on another port... however, if I were actually designing WebSockets to be a successful protocol, I don't know that I'd want to be constrained to HTTP syntax, given that it's not getting much benefit from doing so. The concepts that you're interested in can be reused without dragging along all of the baggage.

But still they need to be reinvented for the new protocol, and components to
be redevelopped. Right now, HTTP-compatible infrastructure offers all of that
for free. Host, URI and cookies are used a lot along the chain to direct the
client's connection to the proper component of the proper server of the proper
farm, and all of that already exists.

Infrastructure components are sensible and rarely upgraded. Doing so requires
a very long qualification process, and if this is needed to offer compatibility
with WebSocket, many developers will have no choice but stay with Comet and the
like for their new devs.

However, saying that they work the same as before on another port indeed makes
a lot of sense. Nothing would even prevent them from sharing the same port if
they want and they know their infrastructure is compatible.

> > BTW, I'm suspecting we're getting off-topic for this WG and that this discussion
> > should move to hybi.
> Hey, that's my job :)

Sorry :-)

Received on Friday, 29 October 2010 05:40:56 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:55 UTC