Re: [hybi] More feedback on WebSockets

Ian Hickson <ian@hixie.ch> Tue, 27 October 2009 09:37 UTC

Return-Path: <ian@hixie.ch>
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 9A5B83A659B for <hybi@core3.amsl.com>; Tue, 27 Oct 2009 02:37:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.554
X-Spam-Level:
X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, 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 mZVeMpasFybO for <hybi@core3.amsl.com>; Tue, 27 Oct 2009 02:37:36 -0700 (PDT)
Received: from looneymail-a2.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by core3.amsl.com (Postfix) with ESMTP id 82C5F3A6897 for <hybi@ietf.org>; Tue, 27 Oct 2009 02:37:36 -0700 (PDT)
Received: from hixie.dreamhostps.com (hixie.dreamhost.com [208.113.210.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by looneymail-a2.g.dreamhost.com (Postfix) with ESMTP id EF44116D3CC; Tue, 27 Oct 2009 02:37:50 -0700 (PDT)
Date: Tue, 27 Oct 2009 09:37:51 +0000 (UTC)
From: Ian Hickson <ian@hixie.ch>
To: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <FDC38D4B-AB64-4F6B-B569-81D7A56DEC8D@mnot.net>
Message-ID: <Pine.LNX.4.62.0910270912040.9145@hixie.dreamhostps.com>
References: <FDC38D4B-AB64-4F6B-B569-81D7A56DEC8D@mnot.net>
Content-Language: en-GB-hixie
Content-Style-Type: text/css
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Cc: hybi@ietf.org
Subject: Re: [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 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?

Yes.


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

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