[hybi] More feedback on WebSockets

Mark Nottingham <mnot@mnot.net> Tue, 27 October 2009 01:55 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: hybi@core3.amsl.com
Delivered-To: hybi@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 00BAB28C135 for <hybi@core3.amsl.com>; Mon, 26 Oct 2009 18:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.305
X-Spam-Status: No, score=-5.305 tagged_above=-999 required=5 tests=[AWL=-2.706, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id riKMhkJQnDU2 for <hybi@core3.amsl.com>; Mon, 26 Oct 2009 18:55:30 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net []) by core3.amsl.com (Postfix) with ESMTP id 0A6FC3A67B8 for <hybi@ietf.org>; Mon, 26 Oct 2009 18:55:29 -0700 (PDT)
Received: from chancetrain-lm.mnot.net (unknown []) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 072A3509DA; Mon, 26 Oct 2009 21:55:41 -0400 (EDT)
From: Mark Nottingham <mnot@mnot.net>
Content-Type: text/plain; charset="us-ascii"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Date: Tue, 27 Oct 2009 12:55:38 +1100
Message-Id: <FDC38D4B-AB64-4F6B-B569-81D7A56DEC8D@mnot.net>
To: Ian Hickson <ian@hixie.ch>, hybi@ietf.org
Mime-Version: 1.0 (Apple Message framework v1076)
X-Mailer: Apple Mail (2.1076)
Subject: [hybi] More feedback on WebSockets
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, 27 Oct 2009 01:55:31 -0000

Overall, I think this draft looks very good, excepting the issues below:

1) Abstract - AIUI one of the primary motivations for WS (especially  
over just exposing a TCP API in browsers) is the use of the "Web  
security model." This should be mentioned in the Abstract (and  

2) The handshake protocol looks like HTTP, but is not (e.g., it's case- 
sensitive and whitespace-sensitive). However, you define the default  
ports for WS and WSS to be port 80 and 443, respectively.

These ports are reserved for HTTP, at least initially; while you can  
use HTTP to upgrade to a different protocol, defining a HTTP-like-but- 
not-really-HTTP handshake protocol to run over them initially  
conflicts with the designated use of the port.

Possible remedies;
   a) define the handshake in terms of HTTP, not byte sequences, or
   b) define a different (i.e., non-HTTP) protocol identifier to use  
on the handshake request and response.

3) In section 1.6 (Establishing a Connection), you say

>  On the face of it, the simplest method would seem to be to use port
>    80 to get a direct connection to a Web Socket server.  Port 80
>    traffic, however, will often be intercepted by HTTP proxies, which
>    can lead to the connection failing to be established.

Given this, is it a good idea for the default port for the WS scheme  
to be port 80? Why not use a separate port and fall back to 443 with  
null encryption, for example?

4) In section 1.2, you define the payload of the headers as ASCII, but  
then allow a wide range of Unicode characters. Which is it?

5) Are there any constraints placed upon the field-value of the  
WebSocket-Protocol header? Is there any structure?

If I want to define an intermediary function for WebSockets that  
allows multiplexing, and I wish to unambiguously identify that it's in  
use, is this an appropriate use for the WebSocket-Protocol header?

If so, how do I avoid conflicting with the names of other  
subprotocols, and how do I indicate that multiple subprotocols are in  
use on one connection?

If not, what's the appropriate mechanism?


Mark Nottingham     http://www.mnot.net/