HTML and CSS Reference
Table 3-5. WebSocket Close Code Ranges
When to Use this Code
Codes below 1000 are invalid and can
never be used for any purpose.
These codes are reserved for use in
extensions and revised versions of the
WebSocket protocol itself. Use these codes
as the standard prescribes. See Table 3-4.
These codes are intended for use
by “libraries, frameworks, and
applications.” These codes should be
publicly registered with IANA (Internet
Assigned Numbers Authority).
Use these codes for custom purposes
in your applications. Because they are
not registered, do not expect them to be
widely understood by other WebSocket
Support for Other Protocols
The WebSocket Protocol supports higher-level protocols and protocol negotiation.
Paradoxically, RFC 6455 refers to protocols you can use with WebSocket as “subprotocols,”
even though they are higher-level, fully formed protocols. As we mentioned in Chapter 2,
throughout this topic, we'll generally refer to protocols that you can use with WebSocket
simply as “protocols” to avoid confusion.
In Chapter 2, we explained how to negotiate higher-layer protocols with the
WebSocket API. At the network level, these protocols are negotiated using the
Sec-WebSocket-Protocol header. Protocol names are header values sent from the client
in the initial upgrade request:
Sec-WebSocket-Protocol: com.kaazing.echo, example.protocol.name
This header indicates that the client can use either protocol ( com.kaazing.echo or
example.protocol.name ) and the server can choose which protocol to use. If you send
include the following header:
This response indicates that the server has elected to speak the com.kaazing.echo
protocol. Selecting a protocol does not change the syntax of the WebSocket Protocol
itself. Instead, these protocols are layered on top of the WebSocket Protocol to provide
higher-level semantics for frameworks and applications. We will examine three different
use cases of layering widely used, standards-based protocols on top of WebSocket in the