Re: [hybi] workability (or otherwise) of HTTP upgrade

Willy Tarreau <w@1wt.eu> Tue, 07 December 2010 06:09 UTC

Return-Path: <w@1wt.eu>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4438C3A6915 for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 22:09:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.046
X-Spam-Level:
X-Spam-Status: No, score=-2.046 tagged_above=-999 required=5 tests=[AWL=-0.003, BAYES_00=-2.599, HELO_IS_SMALL6=0.556]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsJoabw-GsVx for <hybi@core3.amsl.com>; Mon, 6 Dec 2010 22:09:10 -0800 (PST)
Received: from 1wt.eu (1wt.eu [62.212.114.60]) by core3.amsl.com (Postfix) with ESMTP id DD0573A6911 for <hybi@ietf.org>; Mon, 6 Dec 2010 22:09:09 -0800 (PST)
Received: (from willy@localhost) by mail.home.local (8.14.4/8.14.4/Submit) id oB76ASsc022017; Tue, 7 Dec 2010 07:10:28 +0100
Date: Tue, 07 Dec 2010 07:10:28 +0100
From: Willy Tarreau <w@1wt.eu>
To: Mark Nottingham <mnot@mnot.net>
Message-ID: <20101207061028.GM19364@1wt.eu>
References: <AANLkTin6=8_Bhn2YseoSHGh1OSkQzsYrTW=fMiPvYps1@mail.gmail.com> <20101126000352.ad396b9a.eric@bisonsystems.net> <AANLkTimzQyG4hugOvHqoNrBrZFA4fGbGXQ7MZ2i+68dO@mail.gmail.com> <BB947F6D-15AA-455D-B830-5E12C80C1ACD@mnot.net> <81870DB1-B177-4253-8233-52C4168BE99D@apple.com> <F4D1B715-3606-4E9A-BFB2-8B7BC11BE331@mnot.net>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <F4D1B715-3606-4E9A-BFB2-8B7BC11BE331@mnot.net>
User-Agent: Mutt/1.4.2.3i
Cc: hybi HTTP <hybi@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
Subject: Re: [hybi] workability (or otherwise) of HTTP upgrade
X-BeenThere: hybi@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <hybi.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hybi>
List-Post: <mailto:hybi@ietf.org>
List-Help: <mailto:hybi-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hybi>, <mailto:hybi-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 07 Dec 2010 06:09:11 -0000

On Tue, Dec 07, 2010 at 01:13:28PM +1100, Mark Nottingham wrote:
> 
> On 07/12/2010, at 12:30 PM, Maciej Stachowiak wrote:
> 
> > On Dec 6, 2010, at 4:53 PM, Mark Nottingham wrote:
> > 
> >> I don't think that's the relevant aspect here. "Another port" could be port 80 or port 443 (nasty, and you wouldn't make it the default, but I think you see where I'm going). 
> >> 
> >> The question is why it's necessary to run both HTTP and WebSockets traffic over the *same* port simultaneously -- something that AFAICT is taken as axiomatic, and I'm really wondering why.
> > 
> > Web developers will likely want to operate both a WebSocket service and an HTTP service on the same server, since WebSocket services are likely to be most useful in combination with a Web application that makes use of them. At the same time, they will want their WebSocket traffic to go through firewalls properly. It would be a significant burden if a WebSocket service required a separate domain name, physical or virtual server, and possibly SSL cert.
> > 
> > Thus desire to have a single piece of server software that can dispatch connects to HTTP applications or Web applications as appropriate.
> 
> You don't need a different domain name, hardware, OS instance or certificate to listen to a different port, and if you have a wildcard SSL cert, you can use the same cert for the same port number on two different hosts. 

In my opinion the problem is not here, but the adoption rate depending
on the port. Many organisations implement URL filtering on port 80,
white-list based filtering on 443 and nothing else around. If you want
to deploy a site which quickly gets a lot of traffic, port 80 clearly
is the most suited, which is even more true considering that long polling
mechanisms already work over that port.

Also, being able to switch from HTTP to WS over a same socket for some
services can save one round trip, but that's marginal in most situations,
except from mobile phones.

Regards,
Willy