Re: [hybi] Redesigning the Web Socket handshake

Jamie Lokier <jamie@shareable.org> Wed, 03 February 2010 03:12 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 AE0FA28C128 for <hybi@core3.amsl.com>; Tue, 2 Feb 2010 19:12:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.615
X-Spam-Level:
X-Spam-Status: No, score=-2.615 tagged_above=-999 required=5 tests=[AWL=-0.016, 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 OEHYcRfCS5fZ for <hybi@core3.amsl.com>; Tue, 2 Feb 2010 19:12:09 -0800 (PST)
Received: from mail2.shareable.org (mail2.shareable.org [80.68.89.115]) by core3.amsl.com (Postfix) with ESMTP id 092A628C117 for <hybi@ietf.org>; Tue, 2 Feb 2010 19:12:09 -0800 (PST)
Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from <jamie@shareable.org>) id 1NcVfb-00062Z-BO; Wed, 03 Feb 2010 03:12:47 +0000
Date: Wed, 03 Feb 2010 03:12:47 +0000
From: Jamie Lokier <jamie@shareable.org>
To: Ian Hickson <ian@hixie.ch>
Message-ID: <20100203031247.GT32743@shareable.org>
References: <Pine.LNX.4.64.1002012305000.21600@ps20323.dreamhostps.com> <4B676E8C.70804@webtide.com> <Pine.LNX.4.64.1002020311030.3846@ps20323.dreamhostps.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.64.1002020311030.3846@ps20323.dreamhostps.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 03:12:12 -0000

Ian Hickson wrote:
> On Tue, 2 Feb 2010, Greg Wilkins wrote:
> > 
> > I think you've left out the main suggestion that's been made on this 
> > list.
> > 
> > Leave the handshake more or less as it is, but specify it as a real HTTP 
> > request and real HTTP response, rather than a binary almost-equivalent.  
> 
> That's basically a non-starter, IMHO. The HTTP rules are orders of 
> magnitude more complicated than necessary here. Given the goal of making 
> this trivially implementable, we can't require that servers implement 
> every last detail of the HTTP rules.

That's understandable.  As a wannabee non-HTTP WebSocket server writer,
I sympathise.

The header syntax rules for HTTP aren't all that complicated.  Heck,
I've seen it done in one or two lines of Perl (wrongly of course! ;-)

Maybe it's worth extracting out the essential header syntax into
straightforward form.

HTTPbis is a bit more precise on the subject, and might be simpler than RFC2616
which meanders rather.

   - Request line / Status line syntax is quite simple, one regexp.
   - Header: value (no space before the colon, no space before Header)
   - Header names must only use characters in "token" list.
   - Discard whitespace before and after value (it defines what whitespace)
   - Line beginning with whitespace just appends to previous line, (possibly
     after trimming whitespace before and after, and joining with a space)
   - Duplicate header may be merged with previous by joining with a comma
   - Lines ends with CRLF, suggests accepting just LF too.
   - Empty line finishes the lot.

On top of that, a server should:

   - Reject Expect values that it doesn't recognise
   - Reject methods it doesn't recognise
     (Sending a rejection message is easy, no need to follow many rules)
   - Reject HTTP/a.b versions it can't handle

And both sides should:

   - Include a Date header with the current time

Because WebSocket clients and servers are not proxies, many of the
rules in RFC2616 don't apply.

It's not much really, when you condense it down, is it?

(I probably missed a few things.  Finding them might involve a tedious
read of RFC2616 or HTTPbis.  But once found, I doubt if they demand
much from a WebSocket implementor, nor take much space in the spec.)

-- Jamie