WebSockets ( PR #67 )

1. Introduction

2. WebSocket protocol alterations

2.1. Connections

2.2. Opening handshake

Fail the WebSocket connection and the WebSocket connection is established are defined by The WebSocket Protocol. [WSP]

The reason redirects are not followed and this handshake is generally restricted is because it could introduce serious security problems in a web browser context. For example, consider a host with a WebSocket server at one path and an open HTTP redirector at another. Suddenly, any script that can be given a particular WebSocket URL can be tricked into communicating to (and potentially sharing secrets with) any host on the internet, even if the script checks that the URL has the right hostname.

3. The WebSocket interface

3.1. Interface definition

The Web IDL definition for the WebSocket class is given as follows:

enum BinaryType { "blob", "arraybuffer" };
[Exposed=(Window,Worker)]
interface WebSocket : EventTarget {
  constructor(USVString url, optional (DOMString or sequence<DOMString>) protocols = []);
  readonly attribute USVString url;
  // ready state
  const unsigned short CONNECTING = 0;
  const unsigned short OPEN = 1;
  const unsigned short CLOSING = 2;
  const unsigned short CLOSED = 3;
  readonly attribute unsigned short readyState;
  readonly attribute unsigned long long bufferedAmount;
  // networking
  attribute EventHandler onopen;
  attribute EventHandler onerror;
  attribute EventHandler onclose;
  readonly attribute DOMString extensions;
  readonly attribute DOMString protocol;
  undefined close(optional [Clamp] unsigned short code, optional USVString reason);
  // messaging
  attribute EventHandler onmessage;
  attribute BinaryType binaryType;
  undefined send((BufferSource or Blob or USVString) data);
};

Each WebSocket object has an associated url , which is a URL record .

Each WebSocket object has an associated binary type , which is a BinaryType . Initially it must be " blob ".

Each WebSocket object has an associated ready state , which is a number representing the state of the connection. Initially it must be CONNECTING (0). It can have the following values:

CONNECTING (numeric value 0)

The connection has not yet been established.

OPEN (numeric value 1)

The WebSocket connection is established and communication is possible.

CLOSING (numeric value 2)

The connection is going through the closing handshake, or the close() method has been invoked.

CLOSED (numeric value 3)

The connection has been closed or could not be opened.

socket = new WebSocket ( url [, protocols ])

Creates a new WebSocket object, immediately establishing the associated WebSocket connection.

url is a string giving the URL over which the connection is established. Only " ws ", " wss ", " http ", and " https " schemes are allowed; others will cause a " SyntaxError " DOMException . URLs with fragments will always cause such an exception.

protocols is either a string or an array of strings. If it is a string, it is equivalent to an array consisting of just that string; if it is omitted, it is equivalent to the empty array. Each string in the array is a subprotocol name. The connection will only be established if the server reports that it has selected one of these subprotocols. The subprotocol names have to match the requirements for elements that comprise the value of ` Sec-WebSocket-Protocol ` fields as defined by The WebSocket protocol. [WSP]

socket . send ( data )

Transmits data using the WebSocket connection. data can be a string, a Blob , an ArrayBuffer , or an ArrayBufferView .

socket . close ([ code ] [, reason ])

Closes the WebSocket connection, optionally using code as the WebSocket connection close code and reason as the WebSocket connection close reason .

socket . url

Returns the URL that was used to establish the WebSocket connection.

socket . readyState

Returns the state of the WebSocket connection. It can have the values described above.

socket . bufferedAmount

Returns the number of bytes of application data (UTF-8 text and binary data) that have been queued using send() but not yet been transmitted to the network.

If the WebSocket connection is closed, this attribute’s value will only increase with each call to the send() method. (The number does not reset to zero once the connection closes.)

socket . extensions

Returns the extensions selected by the server, if any.

socket . protocol

Returns the subprotocol selected by the server, if any. It can be used in conjunction with the array form of the constructor’s second argument to perform subprotocol negotiation.

socket . binaryType

Returns a string that indicates how binary data from socket is exposed to scripts:

" blob "

Binary data is returned in Blob form.

" arraybuffer "

Binary data is returned in ArrayBuffer form.

The default is " blob ".

socket . binaryType = value

Changes how binary data is returned.

The url getter steps are to return this ’s url , serialized .

The readyState getter steps are to return this ’s ready state .

The extensions attribute must initially return the empty string. After the WebSocket connection is established , its value might change, as defined below.

The protocol attribute must initially return the empty string. After the WebSocket connection is established , its value might change, as defined below.

The close() method does not discard previously sent messages before starting the WebSocket closing handshake — even if, in practice, the user agent is still busy sending those messages, the handshake will only start after the messages are sent.

The bufferedAmount getter steps are to return the number of bytes of application data (UTF-8 text and binary data) that have been queued using send() but that, as of the last time the event loop reached step 1 , had not yet been transmitted to the network. (This thus includes any text sent during the execution of the current task, regardless of whether the user agent is able to transmit text in the background in parallel with script execution.) This does not include framing overhead incurred by the protocol, or buffering done by the operating system or network hardware.

var socket = new WebSocket('ws://game.example.com:12010/updates');
socket.onopen = function () {
  setInterval(function() {
    if (socket.bufferedAmount == 0)
      socket.send(getUpdateData());
  }, 50);
};

The binaryType getter steps are to return this ’s binary type .

The binaryType setter steps are to set this ’s binary type to the given value .

User agents can use the binary type as a hint for how to handle incoming binary data: if it is " blob ", it is safe to spool it to disk, and if it is " arraybuffer ", it is likely more efficient to keep the data in memory. Naturally, user agents are encouraged to use more subtle heuristics to decide whether to keep incoming data in memory or not, e.g. based on how big the data is or how common it is for a script to change the attribute at the last minute. This latter aspect is important in particular because it is quite possible for the attribute to be changed after the user agent has received the data but before the user agent has fired the event for it.

The following are the event handlers (and their corresponding event handler event types ) that must be supported, as event handler IDL attributes , by all objects implementing the WebSocket interface:

4. Feedback from the protocol

When the WebSocket connection is established , the user agent must queue a task to run these steps:

mysocket.onmessage = function (event) {
  if (event.data == 'on') {
    turnLampOn();
  } else if (event.data == 'off') {
    turnLampOff();
  }
};

When the WebSocket closing handshake is started , the user agent must queue a task to change the ready state to CLOSING (2). (If the close() method was called, the ready state will already be set to CLOSING (2) when this task runs.) [WSP]

When the WebSocket connection is closed , possibly cleanly , the user agent must queue a task to run the following substeps:

The task source for all tasks queued in this section is the WebSocket task source .

5. Ping and Pong frames

The WebSocket protocol defines Ping and Pong frames that can be used for keep-alive, heart-beats, network status probing, latency instrumentation, and so forth. These are not currently exposed in the API.

User agents may send ping and unsolicited pong frames as desired, for example in an attempt to maintain local network NAT mappings, to detect failed connections, or to display latency metrics to the user. User agents must not use pings or unsolicited pongs to aid the server; it is assumed that servers will solicit pongs whenever appropriate for the server’s needs.

6. The CloseEvent interface

WebSocket objects use the CloseEvent interface for their close events:

[Exposed=(Window,Worker)]
interface CloseEvent : Event {
  constructor(DOMString type, optional CloseEventInit eventInitDict = {});
  readonly attribute boolean wasClean;
  readonly attribute unsigned short code;
  readonly attribute USVString reason;
};
dictionary CloseEventInit : EventInit {
  boolean wasClean = false;
  unsigned short code = 0;
  USVString reason = "";
};

event . wasClean

Returns true if the connection closed cleanly; false otherwise.

event . code

Returns the WebSocket connection close code provided by the server.

event . reason

Returns the WebSocket connection close reason provided by the server.

The wasClean attribute must return the value it was initialized to. It represents whether the connection closed cleanly or not.

The code attribute must return the value it was initialized to. It represents the WebSocket connection close code provided by the server.

The reason attribute must return the value it was initialized to. It represents the WebSocket connection close reason provided by the server.

7. Garbage collection

A WebSocket object whose ready state was set to CONNECTING (0) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for open events, message events, error events, or close events.

A WebSocket object whose ready state was set to OPEN (1) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for message events, error , or close events.

A WebSocket object whose ready state was set to CLOSING (2) as of the last time the event loop reached step 1 must not be garbage collected if there are any event listeners registered for error or close events.

A WebSocket object with an established connection that has data queued to be transmitted to the network must not be garbage collected. [WSP]

If a WebSocket object is garbage collected while its connection is still open, the user agent must start the WebSocket closing handshake , with no status code for the Close message. [WSP]

If a user agent is to make disappear a WebSocket object (this happens when a Document object goes away), the user agent must follow the first appropriate set of steps from the following list:

Acknowledgments

Until the creation of this standard in 2021, the text here was maintained in the HTML Standard and Fetch Standard . Thanks to all of the contributors to those repositories who helped develop the specification, especially Ian Hickson and Anne van Kesteren as the respective original authors.

Thanks to devsnek and 平野裕 (Yutaka Hirano) for their contributions after the creation of the WebSockets Standard.

This standard is written by Adam Rice ( Google , ricea@chromium.org ).

Intellectual property rights

Copyright © WHATWG (Apple, Google, Mozilla, Microsoft). This work is licensed under a Creative Commons Attribution 4.0 International License . To the extent portions of it are incorporated into source code, such portions in the source code are licensed under the BSD 3-Clause License instead.

This is the Living Standard. Those interested in the patent-review version should view the Living Standard Review Draft .