Re: [hybi] More feedback on WebSockets

[Ian Hickson <[e-mail]>]

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.   `._.-(,_..'--(,_..'`-.;.'