IETF WebSocket Protocol

This page will try to summarize where we stand as far as compliance with the IETF WebSockets Protocol. The protocol contains the word MUST 156 times and to be compliant we should satisfy and test all of them.

Section	Quote	Server HttpServer	Server HTTP	Client websocket
1.3	The Connection and Upgrade header fields complete the HTTP Upgrade. The Sec-WebSocket-Accept header field indicates whether the server is willing to accept the connection. If present, this header field must include a hash of the client's nonce sent in Sec-WebSocket-Key along with a predefined GUID. Any other value must not be interpreted as an acceptance of the connection by the server.	✓	✓	NA
3.	Fragment identifiers are meaningless in the context of WebSocket URIs and MUST NOT be used on these URIs. As with any URI scheme, the character "#", when not indicating the start of a fragment, MUST be escaped as %23.	NA	NA	✓
4.1	When the client is to Establish a WebSocket Connection given a set (/host/, /port/, /resource name/, and /secure/ flag), along with a list of /protocols/ and /extensions/ to be used, and an /origin/ in the case of web browsers, it MUST open a connection, send an opening handshake, and read the server's handshake in response.	N/A	NA	✓
4.1.1	The components of the WebSocket URI passed into this algorithm (/host/, /port/, /resource name/, and /secure/ flag) MUST be valid according to the specification of WebSocket URIs specified in Section 3. If any of the components are invalid, the client MUST Fail the WebSocket Connection and abort these steps.	NA	NA	✓
4.1.2	If the client already has a WebSocket connection to the remote host (IP address) identified by /host/ and port /port/ pair, even if the remote host is known by another name, the client MUST wait until that connection has been established or for that connection to have failed. There MUST be no more than one connection in a CONNECTING state. If multiple connections to the same IP address are attempted simultaneously, the client MUST serialize them so that there is no more than one connection at a time running through the following steps.	NA	NA	User code
4.1.2	If the client cannot determine the IP address of the remote host (for example, because all communication is being done through a proxy server that performs DNS queries itself), then the client MUST assume for the purposes of this step that each host name refers to a distinct remote host, and instead the client SHOULD limit the total number of simultaneous pending connections to a reasonably low number (e.g., the client might allow simultaneous pending connections to a.example.com and b.example.com, but if thirty simultaneous connections to a single host are requested, that may not be allowed). For example, in a web browser context, the client needs to consider the number of tabs the user has open in setting a limit to the number of simultaneous pending connections.	NA	NA	NA

Note that both servers don't actually 'check the secure flag'. User's can check the complete URI using HttpServer and connection events. HTTP is currently adding functionality, and may already be able to connect using other TCP servers.