Re: [hybi] Redesigning the Web Socket handshake

Jamie Lokier <jamie@shareable.org> Wed, 03 February 2010 16:33 UTC

Return-Path: <jamie@shareable.org>
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 C720E28C123 for <hybi@core3.amsl.com>; Wed, 3 Feb 2010 08:33:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.614
X-Spam-Level:
X-Spam-Status: No, score=-2.614 tagged_above=-999 required=5 tests=[AWL=-0.015, BAYES_00=-2.599]
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 43q1KwJP56J3 for <hybi@core3.amsl.com>; Wed, 3 Feb 2010 08:33:20 -0800 (PST)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id E10533A6946 for <hybi@ietf.org>; Wed, 3 Feb 2010 08:33:19 -0800 (PST)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1NciAx-00056T-DZ; Wed, 03 Feb 2010 16:33:59 +0000
Date: Wed, 03 Feb 2010 16:33:59 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Greg Wilkins <gregw@webtide.com>
Message-ID: <20100203163359.GA19037@shareable.org>
References: <Pine.LNX.4.64.1002012305000.21600@ps20323.dreamhostps.com> <20100203025736.GS32743@shareable.org> <4B68FD77.7020107@webtide.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <4B68FD77.7020107@webtide.com>
User-Agent: Mutt/1.5.13 (2006-08-11)
Cc: hybi@ietf.org
Subject: Re: [hybi] Redesigning the Web Socket handshake
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: Wed, 03 Feb 2010 16:33:20 -0000

Greg Wilkins wrote:
> Jamie Lokier wrote:
> 
> > An interesting idea I've looked at, which would be tricky but _really_
> > improve widespread support (and compatibility), would be to send
> > something which looks like a valid HTTP long-polling request, and
> > allow the server and any proxies to proactively signal that they'll
> > convert it to the more efficient WebSocket - when they will.  When
> > they won't, communication continues over HTTP long-polling, carrying
> > the same messages and subprotocols over that.  I guarantee if that
> > could be pulled off, everyone would start using WebSocket asap ;-)
> 
> Cometd-2 (in alpha state) is more or less doing this already.
> 
> It should be in beta release shortly and then any cometd client
> will be able to use websockets if the browser has it and the
> server handshake says that the server supports it.  Otherwise
> it is long polling business as usual.

Nice!  But that's not really what I meant.

What I meant is two things, I suppose.  One protocol, one client API:

Protocol: Establishing a connection, and then each proxy in the chain
either opts in to making it a WebSocket (or similar in style)
resulting in single connection with bidirectional messaging, or if
there are any proxies detected which won't participate, there will be
HTTP long-polling - at least for the hops on either side of that proxy
(perhaps not the other hops).

I *think* what you described is: Use WebSocket if the whole path
supports it, otherwise long-polling for the whole path.

The difference from what that is the intentional proxy-friendliness
and friendliness to all other deployed HTTP infrastructure.  It'll
pass through everything, including the internals of xrandomhttpd <->
CGI, etc. and upgrade to WebSocket opportunistically on those hops
where it can, while working transparently to the user where it can't.

For the API, you've probably understood that it'd be nice if the
WebSocket API had a fallback to HTTP long-polling implementation,
Of course that can be written in Javascript today.

-- Jamie