Re: [hybi] More feedback on WebSockets

Ian Hickson <> Tue, 27 October 2009 09:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A5B83A659B for <>; Tue, 27 Oct 2009 02:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mZVeMpasFybO for <>; Tue, 27 Oct 2009 02:37:36 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 82C5F3A6897 for <>; Tue, 27 Oct 2009 02:37:36 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTP id EF44116D3CC; Tue, 27 Oct 2009 02:37:50 -0700 (PDT)
Date: Tue, 27 Oct 2009 09:37:51 +0000
From: Ian Hickson <>
To: Mark Nottingham <>
In-Reply-To: <>
Message-ID: <>
References: <>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Subject: Re: [hybi] More feedback on WebSockets
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Server-Initiated HTTP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 27 Oct 2009 09:37:37 -0000

On Tue, 27 Oct 2009, Mark Nottingham wrote:
> 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 
> background?).

Added some text to that effect.

> 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.

IANA told me to use ports 80 and 443 for WebSocket. See IANA ticket
#257455. (I had originally requested new ports, ideally 81 and 815.)

I disagree that the current handshake isn't like HTTP enough, though. The 
request is fully HTTP-compliant. What value would there be in relaxing the 
rules on what WebSocket clients should send in the request? I don't 
understand the real-world case you are concerned about.

> 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?

That's what the spec used to require, but IANA requested that I use ports 
80 and 443 directly.

> 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?

Section 1.2 doesn't say that the payload of the headers is ASCII, it just 
says that they are ASCII case-insensitive (i.e. that a-z matches A-Z, but 
that U+00C1 doesn't match U+00E1). I've tried to clarify this a bit.

(Also, section 1.2 is non-normative; it doesn't define anything.)

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

Not currently.

> 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, 

Use a unique name, e.g. by using your domain name as the protocol name, 
or googling for your protocol name and seeing if anyone else has used it.

> and how do I indicate that multiple subprotocols are in use on one 
> connection?

Only one protocol can be in use per connection. If your protocol is just 
another layer below the final application-level protocol, then your 
protocol would have its own equivalent mechanism.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'