[hybi] Proposed way forward for WebSockets

[Ian Hickson <[e-mail]>]

On Mon, 26 Jul 2010, James Graham wrote:
> 
> I think a different goal would be a better statement of Ian's intent:
> 
> "Websockets should be the minimal layer on top of TCP needed to meet the 
> additional requirements of browsers"

Yes, I think that's an accurate description of what I mean.


There are two parts to the protocol: the handshake, and the framing.

The handshake has basically three purposes: 1: allowing the protocol to be 
served by a server that also serves HTTP on the same port; 2: protecting 
existing servers and future WebSocket servers from cross-protocol attacks; 
3: allowing servers to host multiple domains and resources on the same 
IP/port combination, while supporting the browser origin security model.

The framing has one purpose: provide JavaScript applications running in 
Web browsers with a way to send and receive text messages to and from 
WebSocket servers.


There are a number of ways that we can make the protocol also support 
other goals:

 - Compression of frame data
 - Sending and receiving binary data
 - Allowing messages to be annotated with metadata*
 - Allowing multiple JavaScript applications from the same browser to 
   share a connection to a server (multiplexing)*

All of these could be supported by future backwards-compatible changes to 
the protocol, by having the client advertise support for each feature in 
the handshake, and having the server opt-in to using that feature. None of 
these changes require fundamental changes to the handshake.

Two of these, marked with an asterisk above, can also be implemented by 
script; therefore a good way of determining if they are truly needed is to 
deploy the protocol as is, and to see if people work around the lack of 
that feature by implementing it themselves. If they do, then the feature 
is needed and we should add it.

The other two features are clearly needed regardless, and we should add 
them in the near future. (Adding features piecemeal leads to more 
compliant client-side implementations, so we should not add them now.)


Here's a proposed timeline for adding these features:

 - We fix any critical bugs (not feature additions) in the protocol as it 
   stands today (next 4 weeks).

 - We deploy the protocol in four or more major browser vendors (next 4
   months).

 - When binary support in WebGL is stable, we add binary support to XHR, 
   WebSocket, etc (a matter of months?).

 - We look at how the protocol is used (another couple of months).

 - During this time, we build client and server test suites for the 
   protocol.

 - We add built-in support for the features that are needed based on 
   implementation experience (about 6 months from now), including 
   compression, multiplexing, per-frame metadata annotation, etc, as 
   needed.

 - We update the test suites.


I think it would be a mistake to add every feature we can think of right 
away, because doing so would mean that we added features before their need 
was proven, and it would lead to much less conforming client 
implementations. This dynamic has been proven time and time again with Web 
technologies; we should not repeat that mistake.

It would also be advantageous to allow implementors to experiment with 
ideas like multiplexing before we add the feature to the protocol, since 
it would let us use their implementation experience when designing the 
extensions to the protocol. Only by first getting the basic protocol out 
there and then experimenting with it can we really find how these ideas 
work out in real deployments.


(Thanks to Ian Fette for providing a sounding board for some of this.)

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