diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6455.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6455.txt')
| -rw-r--r-- | doc/rfc/rfc6455.txt | 3979 |
1 files changed, 3979 insertions, 0 deletions
diff --git a/doc/rfc/rfc6455.txt b/doc/rfc/rfc6455.txt new file mode 100644 index 0000000..3ee5966 --- /dev/null +++ b/doc/rfc/rfc6455.txt @@ -0,0 +1,3979 @@ + + + + + + +Internet Engineering Task Force (IETF) I. Fette +Request for Comments: 6455 Google, Inc. +Category: Standards Track A. Melnikov +ISSN: 2070-1721 Isode Ltd. + December 2011 + + + The WebSocket Protocol + +Abstract + + The WebSocket Protocol enables two-way communication between a client + running untrusted code in a controlled environment to a remote host + that has opted-in to communications from that code. The security + model used for this is the origin-based security model commonly used + by web browsers. The protocol consists of an opening handshake + followed by basic message framing, layered over TCP. The goal of + this technology is to provide a mechanism for browser-based + applications that need two-way communication with servers that does + not rely on opening multiple HTTP connections (e.g., using + XMLHttpRequest or <iframe>s and long polling). + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6455. + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + + + + +Fette & Melnikov Standards Track [Page 1] + +RFC 6455 The WebSocket Protocol December 2011 + + + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Protocol Overview . . . . . . . . . . . . . . . . . . . . 5 + 1.3. Opening Handshake . . . . . . . . . . . . . . . . . . . . 6 + 1.4. Closing Handshake . . . . . . . . . . . . . . . . . . . . 9 + 1.5. Design Philosophy . . . . . . . . . . . . . . . . . . . . 9 + 1.6. Security Model . . . . . . . . . . . . . . . . . . . . . . 10 + 1.7. Relationship to TCP and HTTP . . . . . . . . . . . . . . . 11 + 1.8. Establishing a Connection . . . . . . . . . . . . . . . . 11 + 1.9. Subprotocols Using the WebSocket Protocol . . . . . . . . 12 + 2. Conformance Requirements . . . . . . . . . . . . . . . . . . . 12 + 2.1. Terminology and Other Conventions . . . . . . . . . . . . 13 + 3. WebSocket URIs . . . . . . . . . . . . . . . . . . . . . . . . 14 + 4. Opening Handshake . . . . . . . . . . . . . . . . . . . . . . 14 + 4.1. Client Requirements . . . . . . . . . . . . . . . . . . . 14 + 4.2. Server-Side Requirements . . . . . . . . . . . . . . . . . 20 + 4.2.1. Reading the Client's Opening Handshake . . . . . . . . 21 + 4.2.2. Sending the Server's Opening Handshake . . . . . . . . 22 + 4.3. Collected ABNF for New Header Fields Used in Handshake . . 25 + 4.4. Supporting Multiple Versions of WebSocket Protocol . . . . 26 + 5. Data Framing . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 27 + 5.2. Base Framing Protocol . . . . . . . . . . . . . . . . . . 28 + 5.3. Client-to-Server Masking . . . . . . . . . . . . . . . . . 32 + 5.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 33 + 5.5. Control Frames . . . . . . . . . . . . . . . . . . . . . . 36 + 5.5.1. Close . . . . . . . . . . . . . . . . . . . . . . . . 36 + 5.5.2. Ping . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 5.5.3. Pong . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 5.6. Data Frames . . . . . . . . . . . . . . . . . . . . . . . 38 + 5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 38 + 5.8. Extensibility . . . . . . . . . . . . . . . . . . . . . . 39 + 6. Sending and Receiving Data . . . . . . . . . . . . . . . . . . 39 + 6.1. Sending Data . . . . . . . . . . . . . . . . . . . . . . . 39 + 6.2. Receiving Data . . . . . . . . . . . . . . . . . . . . . . 40 + 7. Closing the Connection . . . . . . . . . . . . . . . . . . . . 41 + 7.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 41 + 7.1.1. Close the WebSocket Connection . . . . . . . . . . . . 41 + 7.1.2. Start the WebSocket Closing Handshake . . . . . . . . 42 + 7.1.3. The WebSocket Closing Handshake is Started . . . . . . 42 + 7.1.4. The WebSocket Connection is Closed . . . . . . . . . . 42 + 7.1.5. The WebSocket Connection Close Code . . . . . . . . . 42 + + + +Fette & Melnikov Standards Track [Page 2] + +RFC 6455 The WebSocket Protocol December 2011 + + + 7.1.6. The WebSocket Connection Close Reason . . . . . . . . 43 + 7.1.7. Fail the WebSocket Connection . . . . . . . . . . . . 43 + 7.2. Abnormal Closures . . . . . . . . . . . . . . . . . . . . 44 + 7.2.1. Client-Initiated Closure . . . . . . . . . . . . . . . 44 + 7.2.2. Server-Initiated Closure . . . . . . . . . . . . . . . 44 + 7.2.3. Recovering from Abnormal Closure . . . . . . . . . . . 44 + 7.3. Normal Closure of Connections . . . . . . . . . . . . . . 45 + 7.4. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 45 + 7.4.1. Defined Status Codes . . . . . . . . . . . . . . . . . 45 + 7.4.2. Reserved Status Code Ranges . . . . . . . . . . . . . 47 + 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . . 48 + 8.1. Handling Errors in UTF-8-Encoded Data . . . . . . . . . . 48 + 9. Extensions . . . . . . . . . . . . . . . . . . . . . . . . . . 48 + 9.1. Negotiating Extensions . . . . . . . . . . . . . . . . . . 48 + 9.2. Known Extensions . . . . . . . . . . . . . . . . . . . . . 50 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 50 + 10.1. Non-Browser Clients . . . . . . . . . . . . . . . . . . . 50 + 10.2. Origin Considerations . . . . . . . . . . . . . . . . . . 50 + 10.3. Attacks On Infrastructure (Masking) . . . . . . . . . . . 51 + 10.4. Implementation-Specific Limits . . . . . . . . . . . . . . 52 + 10.5. WebSocket Client Authentication . . . . . . . . . . . . . 53 + 10.6. Connection Confidentiality and Integrity . . . . . . . . . 53 + 10.7. Handling of Invalid Data . . . . . . . . . . . . . . . . . 53 + 10.8. Use of SHA-1 by the WebSocket Handshake . . . . . . . . . 54 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 54 + 11.1. Registration of New URI Schemes . . . . . . . . . . . . . 54 + 11.1.1. Registration of "ws" Scheme . . . . . . . . . . . . . 54 + 11.1.2. Registration of "wss" Scheme . . . . . . . . . . . . . 55 + 11.2. Registration of the "WebSocket" HTTP Upgrade Keyword . . . 56 + 11.3. Registration of New HTTP Header Fields . . . . . . . . . . 57 + 11.3.1. Sec-WebSocket-Key . . . . . . . . . . . . . . . . . . 57 + 11.3.2. Sec-WebSocket-Extensions . . . . . . . . . . . . . . . 58 + 11.3.3. Sec-WebSocket-Accept . . . . . . . . . . . . . . . . . 58 + 11.3.4. Sec-WebSocket-Protocol . . . . . . . . . . . . . . . . 59 + 11.3.5. Sec-WebSocket-Version . . . . . . . . . . . . . . . . 60 + 11.4. WebSocket Extension Name Registry . . . . . . . . . . . . 61 + 11.5. WebSocket Subprotocol Name Registry . . . . . . . . . . . 61 + 11.6. WebSocket Version Number Registry . . . . . . . . . . . . 62 + 11.7. WebSocket Close Code Number Registry . . . . . . . . . . . 64 + 11.8. WebSocket Opcode Registry . . . . . . . . . . . . . . . . 65 + 11.9. WebSocket Framing Header Bits Registry . . . . . . . . . . 66 + 12. Using the WebSocket Protocol from Other Specifications . . . . 66 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 67 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 68 + 14.1. Normative References . . . . . . . . . . . . . . . . . . . 68 + 14.2. Informative References . . . . . . . . . . . . . . . . . . 69 + + + + + +Fette & Melnikov Standards Track [Page 3] + +RFC 6455 The WebSocket Protocol December 2011 + + +1. Introduction + +1.1. Background + + _This section is non-normative._ + + Historically, creating web applications that need bidirectional + communication between a client and a server (e.g., instant messaging + and gaming applications) has required an abuse of HTTP to poll the + server for updates while sending upstream notifications as distinct + HTTP calls [RFC6202]. + + This results in a variety of problems: + + o The server is forced to use a number of different underlying TCP + connections for each client: one for sending information to the + client and a new one for each incoming message. + + o The wire protocol has a high overhead, with each client-to-server + message having an HTTP header. + + o The client-side script is forced to maintain a mapping from the + outgoing connections to the incoming connection to track replies. + + A simpler solution would be to use a single TCP connection for + traffic in both directions. This is what the WebSocket Protocol + provides. Combined with the WebSocket API [WSAPI], it provides an + alternative to HTTP polling for two-way communication from a web page + to a remote server. + + The same technique can be used for a variety of web applications: + games, stock tickers, multiuser applications with simultaneous + editing, user interfaces exposing server-side services in real time, + etc. + + The WebSocket Protocol is designed to supersede existing + bidirectional communication technologies that use HTTP as a transport + layer to benefit from existing infrastructure (proxies, filtering, + authentication). Such technologies were implemented as trade-offs + between efficiency and reliability because HTTP was not initially + meant to be used for bidirectional communication (see [RFC6202] for + further discussion). The WebSocket Protocol attempts to address the + goals of existing bidirectional HTTP technologies in the context of + the existing HTTP infrastructure; as such, it is designed to work + over HTTP ports 80 and 443 as well as to support HTTP proxies and + intermediaries, even if this implies some complexity specific to the + current environment. However, the design does not limit WebSocket to + HTTP, and future implementations could use a simpler handshake over a + + + +Fette & Melnikov Standards Track [Page 4] + +RFC 6455 The WebSocket Protocol December 2011 + + + dedicated port without reinventing the entire protocol. This last + point is important because the traffic patterns of interactive + messaging do not closely match standard HTTP traffic and can induce + unusual loads on some components. + +1.2. Protocol Overview + + _This section is non-normative._ + + The protocol has two parts: a handshake and the data transfer. + + The handshake from the client looks as follows: + + GET /chat HTTP/1.1 + Host: server.example.com + Upgrade: websocket + Connection: Upgrade + Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== + Origin: http://example.com + Sec-WebSocket-Protocol: chat, superchat + Sec-WebSocket-Version: 13 + + The handshake from the server looks as follows: + + HTTP/1.1 101 Switching Protocols + Upgrade: websocket + Connection: Upgrade + Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= + Sec-WebSocket-Protocol: chat + + The leading line from the client follows the Request-Line format. + The leading line from the server follows the Status-Line format. The + Request-Line and Status-Line productions are defined in [RFC2616]. + + An unordered set of header fields comes after the leading line in + both cases. The meaning of these header fields is specified in + Section 4 of this document. Additional header fields may also be + present, such as cookies [RFC6265]. The format and parsing of + headers is as defined in [RFC2616]. + + Once the client and server have both sent their handshakes, and if + the handshake was successful, then the data transfer part starts. + This is a two-way communication channel where each side can, + independently from the other, send data at will. + + After a successful handshake, clients and servers transfer data back + and forth in conceptual units referred to in this specification as + "messages". On the wire, a message is composed of one or more + + + +Fette & Melnikov Standards Track [Page 5] + +RFC 6455 The WebSocket Protocol December 2011 + + + frames. The WebSocket message does not necessarily correspond to a + particular network layer framing, as a fragmented message may be + coalesced or split by an intermediary. + + A frame has an associated type. Each frame belonging to the same + message contains the same type of data. Broadly speaking, there are + types for textual data (which is interpreted as UTF-8 [RFC3629] + text), binary data (whose interpretation is left up to the + application), and control frames (which are not intended to carry + data for the application but instead for protocol-level signaling, + such as to signal that the connection should be closed). This + version of the protocol defines six frame types and leaves ten + reserved for future use. + +1.3. Opening Handshake + + _This section is non-normative._ + + The opening handshake is intended to be compatible with HTTP-based + server-side software and intermediaries, so that a single port can be + used by both HTTP clients talking to that server and WebSocket + clients talking to that server. To this end, the WebSocket client's + handshake is an HTTP Upgrade request: + + GET /chat HTTP/1.1 + Host: server.example.com + Upgrade: websocket + Connection: Upgrade + Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== + Origin: http://example.com + Sec-WebSocket-Protocol: chat, superchat + Sec-WebSocket-Version: 13 + + In compliance with [RFC2616], header fields in the handshake may be + sent by the client in any order, so the order in which different + header fields are received is not significant. + + The "Request-URI" of the GET method [RFC2616] is used to identify the + endpoint of the WebSocket connection, both to allow multiple domains + to be served from one IP address and to allow multiple WebSocket + endpoints to be served by a single server. + + The client includes the hostname in the |Host| header field of its + handshake as per [RFC2616], so that both the client and the server + can verify that they agree on which host is in use. + + + + + + +Fette & Melnikov Standards Track [Page 6] + +RFC 6455 The WebSocket Protocol December 2011 + + + Additional header fields are used to select options in the WebSocket + Protocol. Typical options available in this version are the + subprotocol selector (|Sec-WebSocket-Protocol|), list of extensions + support by the client (|Sec-WebSocket-Extensions|), |Origin| header + field, etc. The |Sec-WebSocket-Protocol| request-header field can be + used to indicate what subprotocols (application-level protocols + layered over the WebSocket Protocol) are acceptable to the client. + The server selects one or none of the acceptable protocols and echoes + that value in its handshake to indicate that it has selected that + protocol. + + Sec-WebSocket-Protocol: chat + + The |Origin| header field [RFC6454] is used to protect against + unauthorized cross-origin use of a WebSocket server by scripts using + the WebSocket API in a web browser. The server is informed of the + script origin generating the WebSocket connection request. If the + server does not wish to accept connections from this origin, it can + choose to reject the connection by sending an appropriate HTTP error + code. This header field is sent by browser clients; for non-browser + clients, this header field may be sent if it makes sense in the + context of those clients. + + Finally, the server has to prove to the client that it received the + client's WebSocket handshake, so that the server doesn't accept + connections that are not WebSocket connections. This prevents an + attacker from tricking a WebSocket server by sending it carefully + crafted packets using XMLHttpRequest [XMLHttpRequest] or a form + submission. + + To prove that the handshake was received, the server has to take two + pieces of information and combine them to form a response. The first + piece of information comes from the |Sec-WebSocket-Key| header field + in the client handshake: + + Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== + + For this header field, the server has to take the value (as present + in the header field, e.g., the base64-encoded [RFC4648] version minus + any leading and trailing whitespace) and concatenate this with the + Globally Unique Identifier (GUID, [RFC4122]) "258EAFA5-E914-47DA- + 95CA-C5AB0DC85B11" in string form, which is unlikely to be used by + network endpoints that do not understand the WebSocket Protocol. A + SHA-1 hash (160 bits) [FIPS.180-3], base64-encoded (see Section 4 of + [RFC4648]), of this concatenation is then returned in the server's + handshake. + + + + + +Fette & Melnikov Standards Track [Page 7] + +RFC 6455 The WebSocket Protocol December 2011 + + + Concretely, if as in the example above, the |Sec-WebSocket-Key| + header field had the value "dGhlIHNhbXBsZSBub25jZQ==", the server + would concatenate the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" + to form the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- + C5AB0DC85B11". The server would then take the SHA-1 hash of this, + giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 0xf6 + 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value is + then base64-encoded (see Section 4 of [RFC4648]), to give the value + "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=". This value would then be echoed in + the |Sec-WebSocket-Accept| header field. + + The handshake from the server is much simpler than the client + handshake. The first line is an HTTP Status-Line, with the status + code 101: + + HTTP/1.1 101 Switching Protocols + + Any status code other than 101 indicates that the WebSocket handshake + has not completed and that the semantics of HTTP still apply. The + headers follow the status code. + + 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. + + HTTP/1.1 101 Switching Protocols + Upgrade: websocket + Connection: Upgrade + Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= + + These fields are checked by the WebSocket client for scripted pages. + If the |Sec-WebSocket-Accept| value does not match the expected + value, if the header field is missing, or if the HTTP status code is + not 101, the connection will not be established, and WebSocket frames + will not be sent. + + Option fields can also be included. In this version of the protocol, + the main option field is |Sec-WebSocket-Protocol|, which indicates + the subprotocol that the server has selected. WebSocket clients + verify that the server included one of the values that was specified + in the WebSocket client's handshake. A server that speaks multiple + subprotocols has to make sure it selects one based on the client's + handshake and specifies it in its handshake. + + + + +Fette & Melnikov Standards Track [Page 8] + +RFC 6455 The WebSocket Protocol December 2011 + + + Sec-WebSocket-Protocol: chat + + The server can also set cookie-related option fields to _set_ + cookies, as described in [RFC6265]. + +1.4. Closing Handshake + + _This section is non-normative._ + + The closing handshake is far simpler than the opening handshake. + + Either peer can send a control frame with data containing a specified + control sequence to begin the closing handshake (detailed in + Section 5.5.1). Upon receiving such a frame, the other peer sends a + Close frame in response, if it hasn't already sent one. Upon + receiving _that_ control frame, the first peer then closes the + connection, safe in the knowledge that no further data is + forthcoming. + + After sending a control frame indicating the connection should be + closed, a peer does not send any further data; after receiving a + control frame indicating the connection should be closed, a peer + discards any further data received. + + It is safe for both peers to initiate this handshake simultaneously. + + The closing handshake is intended to complement the TCP closing + handshake (FIN/ACK), on the basis that the TCP closing handshake is + not always reliable end-to-end, especially in the presence of + intercepting proxies and other intermediaries. + + By sending a Close frame and waiting for a Close frame in response, + certain cases are avoided where data may be unnecessarily lost. For + instance, on some platforms, if a socket is closed with data in the + receive queue, a RST packet is sent, which will then cause recv() to + fail for the party that received the RST, even if there was data + waiting to be read. + +1.5. Design Philosophy + + _This section is non-normative._ + + The WebSocket Protocol is designed on the principle that there should + be minimal framing (the only framing that exists is to make the + protocol frame-based instead of stream-based and to support a + distinction between Unicode text and binary frames). It is expected + that metadata would be layered on top of WebSocket by the application + + + + +Fette & Melnikov Standards Track [Page 9] + +RFC 6455 The WebSocket Protocol December 2011 + + + layer, in the same way that metadata is layered on top of TCP by the + application layer (e.g., HTTP). + + Conceptually, WebSocket is really just a layer on top of TCP that + does the following: + + o adds a web origin-based security model for browsers + + o adds an addressing and protocol naming mechanism to support + multiple services on one port and multiple host names on one IP + address + + o layers a framing mechanism on top of TCP to get back to the IP + packet mechanism that TCP is built on, but without length limits + + o includes an additional closing handshake in-band that is designed + to work in the presence of proxies and other intermediaries + + Other than that, WebSocket adds nothing. Basically it is intended to + be as close to just exposing raw TCP to script as possible given the + constraints of the Web. It's also designed in such a way that its + servers can share a port with HTTP servers, by having its handshake + be a valid HTTP Upgrade request. One could conceptually use other + protocols to establish client-server messaging, but the intent of + WebSockets is to provide a relatively simple protocol that can + coexist with HTTP and deployed HTTP infrastructure (such as proxies) + and that is as close to TCP as is safe for use with such + infrastructure given security considerations, with targeted additions + to simplify usage and keep simple things simple (such as the addition + of message semantics). + + The protocol is intended to be extensible; future versions will + likely introduce additional concepts such as multiplexing. + +1.6. Security Model + + _This section is non-normative._ + + The WebSocket Protocol uses the origin model used by web browsers to + restrict which web pages can contact a WebSocket server when the + WebSocket Protocol is used from a web page. Naturally, when the + WebSocket Protocol is used by a dedicated client directly (i.e., not + from a web page through a web browser), the origin model is not + useful, as the client can provide any arbitrary origin string. + + This protocol is intended to fail to establish a connection with + servers of pre-existing protocols like SMTP [RFC5321] and HTTP, while + allowing HTTP servers to opt-in to supporting this protocol if + + + +Fette & Melnikov Standards Track [Page 10] + +RFC 6455 The WebSocket Protocol December 2011 + + + desired. This is achieved by having a strict and elaborate handshake + and by limiting the data that can be inserted into the connection + before the handshake is finished (thus limiting how much the server + can be influenced). + + It is similarly intended to fail to establish a connection when data + from other protocols, especially HTTP, is sent to a WebSocket server, + for example, as might happen if an HTML "form" were submitted to a + WebSocket server. This is primarily achieved by requiring that the + server prove that it read the handshake, which it can only do if the + handshake contains the appropriate parts, which can only be sent by a + WebSocket client. In particular, at the time of writing of this + specification, fields starting with |Sec-| cannot be set by an + attacker from a web browser using only HTML and JavaScript APIs such + as XMLHttpRequest [XMLHttpRequest]. + +1.7. Relationship to TCP and HTTP + + _This section is non-normative._ + + The WebSocket Protocol is an independent TCP-based protocol. Its + only relationship to HTTP is that its handshake is interpreted by + HTTP servers as an Upgrade request. + + By default, the WebSocket Protocol uses port 80 for regular WebSocket + connections and port 443 for WebSocket connections tunneled over + Transport Layer Security (TLS) [RFC2818]. + +1.8. Establishing a Connection + + _This section is non-normative._ + + When a connection is to be made to a port that is shared by an HTTP + server (a situation that is quite likely to occur with traffic to + ports 80 and 443), the connection will appear to the HTTP server to + be a regular GET request with an Upgrade offer. In relatively simple + setups with just one IP address and a single server for all traffic + to a single hostname, this might allow a practical way for systems + based on the WebSocket Protocol to be deployed. In more elaborate + setups (e.g., with load balancers and multiple servers), a dedicated + set of hosts for WebSocket connections separate from the HTTP servers + is probably easier to manage. At the time of writing of this + specification, it should be noted that connections on ports 80 and + 443 have significantly different success rates, with connections on + port 443 being significantly more likely to succeed, though this may + change with time. + + + + + +Fette & Melnikov Standards Track [Page 11] + +RFC 6455 The WebSocket Protocol December 2011 + + +1.9. Subprotocols Using the WebSocket Protocol + + _This section is non-normative._ + + The client can request that the server use a specific subprotocol by + including the |Sec-WebSocket-Protocol| field in its handshake. If it + is specified, the server needs to include the same field and one of + the selected subprotocol values in its response for the connection to + be established. + + These subprotocol names should be registered as per Section 11.5. To + avoid potential collisions, it is recommended to use names that + contain the ASCII version of the domain name of the subprotocol's + originator. For example, if Example Corporation were to create a + Chat subprotocol to be implemented by many servers around the Web, + they could name it "chat.example.com". If the Example Organization + called their competing subprotocol "chat.example.org", then the two + subprotocols could be implemented by servers simultaneously, with the + server dynamically selecting which subprotocol to use based on the + value sent by the client. + + Subprotocols can be versioned in backward-incompatible ways by + changing the subprotocol name, e.g., going from + "bookings.example.net" to "v2.bookings.example.net". These + subprotocols would be considered completely separate by WebSocket + clients. Backward-compatible versioning can be implemented by + reusing the same subprotocol string but carefully designing the + actual subprotocol to support this kind of extensibility. + +2. Conformance Requirements + + All diagrams, examples, and notes in this specification are non- + normative, as are all sections explicitly marked non-normative. + Everything else in this specification is normative. + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + Requirements phrased in the imperative as part of algorithms (such as + "strip any leading space characters" or "return false and abort these + steps") are to be interpreted with the meaning of the key word + ("MUST", "SHOULD", "MAY", etc.) used in introducing the algorithm. + + + + + + + + +Fette & Melnikov Standards Track [Page 12] + +RFC 6455 The WebSocket Protocol December 2011 + + + Conformance requirements phrased as algorithms or specific steps MAY + be implemented in any manner, so long as the end result is + equivalent. (In particular, the algorithms defined in this + specification are intended to be easy to follow and not intended to + be performant.) + +2.1. Terminology and Other Conventions + + _ASCII_ shall mean the character-encoding scheme defined in + [ANSI.X3-4.1986]. + + This document makes reference to UTF-8 values and uses UTF-8 + notational formats as defined in STD 63 [RFC3629]. + + Key terms such as named algorithms or definitions are indicated like + _this_. + + Names of header fields or variables are indicated like |this|. + + Variable values are indicated like /this/. + + This document references the procedure to _Fail the WebSocket + Connection_. This procedure is defined in Section 7.1.7. + + _Converting a string to ASCII lowercase_ means replacing all + characters in the range U+0041 to U+005A (i.e., LATIN CAPITAL LETTER + A to LATIN CAPITAL LETTER Z) with the corresponding characters in the + range U+0061 to U+007A (i.e., LATIN SMALL LETTER A to LATIN SMALL + LETTER Z). + + Comparing two strings in an _ASCII case-insensitive_ manner means + comparing them exactly, code point for code point, except that the + characters in the range U+0041 to U+005A (i.e., LATIN CAPITAL LETTER + A to LATIN CAPITAL LETTER Z) and the corresponding characters in the + range U+0061 to U+007A (i.e., LATIN SMALL LETTER A to LATIN SMALL + LETTER Z) are considered to also match. + + The term "URI" is used in this document as defined in [RFC3986]. + + When an implementation is required to _send_ data as part of the + WebSocket Protocol, the implementation MAY delay the actual + transmission arbitrarily, e.g., buffering data so as to send fewer IP + packets. + + Note that this document uses both [RFC5234] and [RFC2616] variants of + ABNF in different sections. + + + + + +Fette & Melnikov Standards Track [Page 13] + +RFC 6455 The WebSocket Protocol December 2011 + + +3. WebSocket URIs + + This specification defines two URI schemes, using the ABNF syntax + defined in RFC 5234 [RFC5234], and terminology and ABNF productions + defined by the URI specification RFC 3986 [RFC3986]. + + ws-URI = "ws:" "//" host [ ":" port ] path [ "?" query ] + wss-URI = "wss:" "//" host [ ":" port ] path [ "?" query ] + + host = <host, defined in [RFC3986], Section 3.2.2> + port = <port, defined in [RFC3986], Section 3.2.3> + path = <path-abempty, defined in [RFC3986], Section 3.3> + query = <query, defined in [RFC3986], Section 3.4> + + The port component is OPTIONAL; the default for "ws" is port 80, + while the default for "wss" is port 443. + + The URI is called "secure" (and it is said that "the secure flag is + set") if the scheme component matches "wss" case-insensitively. + + The "resource-name" (also known as /resource name/ in Section 4.1) + can be constructed by concatenating the following: + + o "/" if the path component is empty + + o the path component + + o "?" if the query component is non-empty + + o the query component + + 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. + +4. Opening Handshake + +4.1. Client Requirements + + To _Establish a WebSocket Connection_, a client opens a connection + and sends a handshake as defined in this section. A connection is + defined to initially be in a CONNECTING state. A client will need to + supply a /host/, /port/, /resource name/, and a /secure/ flag, which + are the components of a WebSocket URI as discussed in Section 3, + along with a list of /protocols/ and /extensions/ to be used. + Additionally, if the client is a web browser, it supplies /origin/. + + + + +Fette & Melnikov Standards Track [Page 14] + +RFC 6455 The WebSocket Protocol December 2011 + + + Clients running in controlled environments, e.g., browsers on mobile + handsets tied to specific carriers, MAY offload the management of the + connection to another agent on the network. In such a situation, the + client for the purposes of this specification is considered to + include both the handset software and any such agents. + + When the client is to _Establish a WebSocket Connection_ given a set + of (/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. The exact + requirements of how the connection should be opened, what should be + sent in the opening handshake, and how the server's response should + be interpreted are as follows in this section. In the following + text, we will use terms from Section 3, such as "/host/" and + "/secure/ flag" as defined in that section. + + 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. + + 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. + + 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. + + + + + +Fette & Melnikov Standards Track [Page 15] + +RFC 6455 The WebSocket Protocol December 2011 + + + NOTE: This makes it harder for a script to perform a denial-of- + service attack by just opening a large number of WebSocket + connections to a remote host. A server can further reduce the + load on itself when attacked by pausing before closing the + connection, as that will reduce the rate at which the client + reconnects. + + NOTE: There is no limit to the number of established WebSocket + connections a client can have with a single remote host. Servers + can refuse to accept connections from hosts/IP addresses with an + excessive number of existing connections or disconnect resource- + hogging connections when suffering high load. + + 3. _Proxy Usage_: If the client is configured to use a proxy when + using the WebSocket Protocol to connect to host /host/ and port + /port/, then the client SHOULD connect to that proxy and ask it + to open a TCP connection to the host given by /host/ and the port + given by /port/. + + EXAMPLE: For example, if the client uses an HTTP proxy for all + traffic, then if it was to try to connect to port 80 on server + example.com, it might send the following lines to the proxy + server: + + CONNECT example.com:80 HTTP/1.1 + Host: example.com + + If there was a password, the connection might look like: + + CONNECT example.com:80 HTTP/1.1 + Host: example.com + Proxy-authorization: Basic ZWRuYW1vZGU6bm9jYXBlcyE= + + If the client is not configured to use a proxy, then a direct TCP + connection SHOULD be opened to the host given by /host/ and the + port given by /port/. + + NOTE: Implementations that do not expose explicit UI for + selecting a proxy for WebSocket connections separate from other + proxies are encouraged to use a SOCKS5 [RFC1928] proxy for + WebSocket connections, if available, or failing that, to prefer + the proxy configured for HTTPS connections over the proxy + configured for HTTP connections. + + For the purpose of proxy autoconfiguration scripts, the URI to + pass the function MUST be constructed from /host/, /port/, + /resource name/, and the /secure/ flag using the definition of a + WebSocket URI as given in Section 3. + + + +Fette & Melnikov Standards Track [Page 16] + +RFC 6455 The WebSocket Protocol December 2011 + + + NOTE: The WebSocket Protocol can be identified in proxy + autoconfiguration scripts from the scheme ("ws" for unencrypted + connections and "wss" for encrypted connections). + + 4. If the connection could not be opened, either because a direct + connection failed or because any proxy used returned an error, + then the client MUST _Fail the WebSocket Connection_ and abort + the connection attempt. + + 5. If /secure/ is true, the client MUST perform a TLS handshake over + the connection after opening the connection and before sending + the handshake data [RFC2818]. If this fails (e.g., the server's + certificate could not be verified), then the client MUST _Fail + the WebSocket Connection_ and abort the connection. Otherwise, + all further communication on this channel MUST run through the + encrypted tunnel [RFC5246]. + + Clients MUST use the Server Name Indication extension in the TLS + handshake [RFC6066]. + + Once a connection to the server has been established (including a + connection via a proxy or over a TLS-encrypted tunnel), the client + MUST send an opening handshake to the server. The handshake consists + of an HTTP Upgrade request, along with a list of required and + optional header fields. The requirements for this handshake are as + follows. + + 1. The handshake MUST be a valid HTTP request as specified by + [RFC2616]. + + 2. The method of the request MUST be GET, and the HTTP version MUST + be at least 1.1. + + For example, if the WebSocket URI is "ws://example.com/chat", + the first line sent should be "GET /chat HTTP/1.1". + + 3. The "Request-URI" part of the request MUST match the /resource + name/ defined in Section 3 (a relative URI) or be an absolute + http/https URI that, when parsed, has a /resource name/, /host/, + and /port/ that match the corresponding ws/wss URI. + + 4. The request MUST contain a |Host| header field whose value + contains /host/ plus optionally ":" followed by /port/ (when not + using the default port). + + 5. The request MUST contain an |Upgrade| header field whose value + MUST include the "websocket" keyword. + + + + +Fette & Melnikov Standards Track [Page 17] + +RFC 6455 The WebSocket Protocol December 2011 + + + 6. The request MUST contain a |Connection| header field whose value + MUST include the "Upgrade" token. + + 7. The request MUST include a header field with the name + |Sec-WebSocket-Key|. The value of this header field MUST be a + nonce consisting of a randomly selected 16-byte value that has + been base64-encoded (see Section 4 of [RFC4648]). The nonce + MUST be selected randomly for each connection. + + NOTE: As an example, if the randomly selected value was the + sequence of bytes 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 + 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10, the value of the header + field would be "AQIDBAUGBwgJCgsMDQ4PEC==" + + 8. The request MUST include a header field with the name |Origin| + [RFC6454] if the request is coming from a browser client. If + the connection is from a non-browser client, the request MAY + include this header field if the semantics of that client match + the use-case described here for browser clients. The value of + this header field is the ASCII serialization of origin of the + context in which the code establishing the connection is + running. See [RFC6454] for the details of how this header field + value is constructed. + + As an example, if code downloaded from www.example.com attempts + to establish a connection to ww2.example.com, the value of the + header field would be "http://www.example.com". + + 9. The request MUST include a header field with the name + |Sec-WebSocket-Version|. The value of this header field MUST be + 13. + + NOTE: Although draft versions of this document (-09, -10, -11, + and -12) were posted (they were mostly comprised of editorial + changes and clarifications and not changes to the wire + protocol), values 9, 10, 11, and 12 were not used as valid + values for Sec-WebSocket-Version. These values were reserved in + the IANA registry but were not and will not be used. + + 10. The request MAY include a header field with the name + |Sec-WebSocket-Protocol|. If present, this value indicates one + or more comma-separated subprotocol the client wishes to speak, + ordered by preference. The elements that comprise this value + MUST be non-empty strings with characters in the range U+0021 to + U+007E not including separator characters as defined in + [RFC2616] and MUST all be unique strings. The ABNF for the + value of this header field is 1#token, where the definitions of + constructs and rules are as given in [RFC2616]. + + + +Fette & Melnikov Standards Track [Page 18] + +RFC 6455 The WebSocket Protocol December 2011 + + + 11. The request MAY include a header field with the name + |Sec-WebSocket-Extensions|. If present, this value indicates + the protocol-level extension(s) the client wishes to speak. The + interpretation and format of this header field is described in + Section 9.1. + + 12. The request MAY include any other header fields, for example, + cookies [RFC6265] and/or authentication-related header fields + such as the |Authorization| header field [RFC2616], which are + processed according to documents that define them. + + Once the client's opening handshake has been sent, the client MUST + wait for a response from the server before sending any further data. + The client MUST validate the server's response as follows: + + 1. If the status code received from the server is not 101, the + client handles the response per HTTP [RFC2616] procedures. In + particular, the client might perform authentication if it + receives a 401 status code; the server might redirect the client + using a 3xx status code (but clients are not required to follow + them), etc. Otherwise, proceed as follows. + + 2. If the response lacks an |Upgrade| header field or the |Upgrade| + header field contains a value that is not an ASCII case- + insensitive match for the value "websocket", the client MUST + _Fail the WebSocket Connection_. + + 3. If the response lacks a |Connection| header field or the + |Connection| header field doesn't contain a token that is an + ASCII case-insensitive match for the value "Upgrade", the client + MUST _Fail the WebSocket Connection_. + + 4. If the response lacks a |Sec-WebSocket-Accept| header field or + the |Sec-WebSocket-Accept| contains a value other than the + base64-encoded SHA-1 of the concatenation of the |Sec-WebSocket- + Key| (as a string, not base64-decoded) with the string "258EAFA5- + E914-47DA-95CA-C5AB0DC85B11" but ignoring any leading and + trailing whitespace, the client MUST _Fail the WebSocket + Connection_. + + 5. If the response includes a |Sec-WebSocket-Extensions| header + field and this header field indicates the use of an extension + that was not present in the client's handshake (the server has + indicated an extension not requested by the client), the client + MUST _Fail the WebSocket Connection_. (The parsing of this + header field to determine which extensions are requested is + discussed in Section 9.1.) + + + + +Fette & Melnikov Standards Track [Page 19] + +RFC 6455 The WebSocket Protocol December 2011 + + + 6. If the response includes a |Sec-WebSocket-Protocol| header field + and this header field indicates the use of a subprotocol that was + not present in the client's handshake (the server has indicated a + subprotocol not requested by the client), the client MUST _Fail + the WebSocket Connection_. + + If the server's response does not conform to the requirements for the + server's handshake as defined in this section and in Section 4.2.2, + the client MUST _Fail the WebSocket Connection_. + + Please note that according to [RFC2616], all header field names in + both HTTP requests and HTTP responses are case-insensitive. + + If the server's response is validated as provided for above, it is + said that _The WebSocket Connection is Established_ and that the + WebSocket Connection is in the OPEN state. The _Extensions In Use_ + is defined to be a (possibly empty) string, the value of which is + equal to the value of the |Sec-WebSocket-Extensions| header field + supplied by the server's handshake or the null value if that header + field was not present in the server's handshake. The _Subprotocol In + Use_ is defined to be the value of the |Sec-WebSocket-Protocol| + header field in the server's handshake or the null value if that + header field was not present in the server's handshake. + Additionally, if any header fields in the server's handshake indicate + that cookies should be set (as defined by [RFC6265]), these cookies + are referred to as _Cookies Set During the Server's Opening + Handshake_. + +4.2. Server-Side Requirements + + Servers MAY offload the management of the connection to other agents + on the network, for example, load balancers and reverse proxies. In + such a situation, the server for the purposes of this specification + is considered to include all parts of the server-side infrastructure + from the first device to terminate the TCP connection all the way to + the server that processes requests and sends responses. + + EXAMPLE: A data center might have a server that responds to WebSocket + requests with an appropriate handshake and then passes the connection + to another server to actually process the data frames. For the + purposes of this specification, the "server" is the combination of + both computers. + + + + + + + + + +Fette & Melnikov Standards Track [Page 20] + +RFC 6455 The WebSocket Protocol December 2011 + + +4.2.1. Reading the Client's Opening Handshake + + When a client starts a WebSocket connection, it sends its part of the + opening handshake. The server must parse at least part of this + handshake in order to obtain the necessary information to generate + the server part of the handshake. + + The client's opening handshake consists of the following parts. If + the server, while reading the handshake, finds that the client did + not send a handshake that matches the description below (note that as + per [RFC2616], the order of the header fields is not important), + including but not limited to any violations of the ABNF grammar + specified for the components of the handshake, the server MUST stop + processing the client's handshake and return an HTTP response with an + appropriate error code (such as 400 Bad Request). + + 1. An HTTP/1.1 or higher GET request, including a "Request-URI" + [RFC2616] that should be interpreted as a /resource name/ + defined in Section 3 (or an absolute HTTP/HTTPS URI containing + the /resource name/). + + 2. A |Host| header field containing the server's authority. + + 3. An |Upgrade| header field containing the value "websocket", + treated as an ASCII case-insensitive value. + + 4. A |Connection| header field that includes the token "Upgrade", + treated as an ASCII case-insensitive value. + + 5. A |Sec-WebSocket-Key| header field with a base64-encoded (see + Section 4 of [RFC4648]) value that, when decoded, is 16 bytes in + length. + + 6. A |Sec-WebSocket-Version| header field, with a value of 13. + + 7. Optionally, an |Origin| header field. This header field is sent + by all browser clients. A connection attempt lacking this + header field SHOULD NOT be interpreted as coming from a browser + client. + + 8. Optionally, a |Sec-WebSocket-Protocol| header field, with a list + of values indicating which protocols the client would like to + speak, ordered by preference. + + 9. Optionally, a |Sec-WebSocket-Extensions| header field, with a + list of values indicating which extensions the client would like + to speak. The interpretation of this header field is discussed + in Section 9.1. + + + +Fette & Melnikov Standards Track [Page 21] + +RFC 6455 The WebSocket Protocol December 2011 + + + 10. Optionally, other header fields, such as those used to send + cookies or request authentication to a server. Unknown header + fields are ignored, as per [RFC2616]. + +4.2.2. Sending the Server's Opening Handshake + + When a client establishes a WebSocket connection to a server, the + server MUST complete the following steps to accept the connection and + send the server's opening handshake. + + 1. If the connection is happening on an HTTPS (HTTP-over-TLS) port, + perform a TLS handshake over the connection. If this fails + (e.g., the client indicated a host name in the extended client + hello "server_name" extension that the server does not host), + then close the connection; otherwise, all further communication + for the connection (including the server's handshake) MUST run + through the encrypted tunnel [RFC5246]. + + 2. The server can perform additional client authentication, for + example, by returning a 401 status code with the corresponding + |WWW-Authenticate| header field as described in [RFC2616]. + + 3. The server MAY redirect the client using a 3xx status code + [RFC2616]. Note that this step can happen together with, before, + or after the optional authentication step described above. + + 4. Establish the following information: + + /origin/ + The |Origin| header field in the client's handshake indicates + the origin of the script establishing the connection. The + origin is serialized to ASCII and converted to lowercase. The + server MAY use this information as part of a determination of + whether to accept the incoming connection. If the server does + not validate the origin, it will accept connections from + anywhere. If the server does not wish to accept this + connection, it MUST return an appropriate HTTP error code + (e.g., 403 Forbidden) and abort the WebSocket handshake + described in this section. For more detail, refer to + Section 10. + + /key/ + The |Sec-WebSocket-Key| header field in the client's handshake + includes a base64-encoded value that, if decoded, is 16 bytes + in length. This (encoded) value is used in the creation of + the server's handshake to indicate an acceptance of the + connection. It is not necessary for the server to base64- + decode the |Sec-WebSocket-Key| value. + + + +Fette & Melnikov Standards Track [Page 22] + +RFC 6455 The WebSocket Protocol December 2011 + + + /version/ + The |Sec-WebSocket-Version| header field in the client's + handshake includes the version of the WebSocket Protocol with + which the client is attempting to communicate. If this + version does not match a version understood by the server, the + server MUST abort the WebSocket handshake described in this + section and instead send an appropriate HTTP error code (such + as 426 Upgrade Required) and a |Sec-WebSocket-Version| header + field indicating the version(s) the server is capable of + understanding. + + /resource name/ + An identifier for the service provided by the server. If the + server provides multiple services, then the value should be + derived from the resource name given in the client's handshake + in the "Request-URI" [RFC2616] of the GET method. If the + requested service is not available, the server MUST send an + appropriate HTTP error code (such as 404 Not Found) and abort + the WebSocket handshake. + + /subprotocol/ + Either a single value representing the subprotocol the server + is ready to use or null. The value chosen MUST be derived + from the client's handshake, specifically by selecting one of + the values from the |Sec-WebSocket-Protocol| field that the + server is willing to use for this connection (if any). If the + client's handshake did not contain such a header field or if + the server does not agree to any of the client's requested + subprotocols, the only acceptable value is null. The absence + of such a field is equivalent to the null value (meaning that + if the server does not wish to agree to one of the suggested + subprotocols, it MUST NOT send back a |Sec-WebSocket-Protocol| + header field in its response). The empty string is not the + same as the null value for these purposes and is not a legal + value for this field. The ABNF for the value of this header + field is (token), where the definitions of constructs and + rules are as given in [RFC2616]. + + /extensions/ + A (possibly empty) list representing the protocol-level + extensions the server is ready to use. If the server supports + multiple extensions, then the value MUST be derived from the + client's handshake, specifically by selecting one or more of + the values from the |Sec-WebSocket-Extensions| field. The + absence of such a field is equivalent to the null value. The + empty string is not the same as the null value for these + + + + + +Fette & Melnikov Standards Track [Page 23] + +RFC 6455 The WebSocket Protocol December 2011 + + + purposes. Extensions not listed by the client MUST NOT be + listed. The method by which these values should be selected + and interpreted is discussed in Section 9.1. + + 5. If the server chooses to accept the incoming connection, it MUST + reply with a valid HTTP response indicating the following. + + 1. A Status-Line with a 101 response code as per RFC 2616 + [RFC2616]. Such a response could look like "HTTP/1.1 101 + Switching Protocols". + + 2. An |Upgrade| header field with value "websocket" as per RFC + 2616 [RFC2616]. + + 3. A |Connection| header field with value "Upgrade". + + 4. A |Sec-WebSocket-Accept| header field. The value of this + header field is constructed by concatenating /key/, defined + above in step 4 in Section 4.2.2, with the string "258EAFA5- + E914-47DA-95CA-C5AB0DC85B11", taking the SHA-1 hash of this + concatenated value to obtain a 20-byte value and base64- + encoding (see Section 4 of [RFC4648]) this 20-byte hash. + + The ABNF [RFC2616] of this header field is defined as + follows: + + Sec-WebSocket-Accept = base64-value-non-empty + base64-value-non-empty = (1*base64-data [ base64-padding ]) | + base64-padding + base64-data = 4base64-character + base64-padding = (2base64-character "==") | + (3base64-character "=") + base64-character = ALPHA | DIGIT | "+" | "/" + + NOTE: As an example, if the value of the |Sec-WebSocket-Key| header + field in the client's handshake were "dGhlIHNhbXBsZSBub25jZQ==", the + server would append the string "258EAFA5-E914-47DA-95CA-C5AB0DC85B11" + to form the string "dGhlIHNhbXBsZSBub25jZQ==258EAFA5-E914-47DA-95CA- + C5AB0DC85B11". The server would then take the SHA-1 hash of this + string, giving the value 0xb3 0x7a 0x4f 0x2c 0xc0 0x62 0x4f 0x16 0x90 + 0xf6 0x46 0x06 0xcf 0x38 0x59 0x45 0xb2 0xbe 0xc4 0xea. This value + is then base64-encoded, to give the value + "s3pPLMBiTxaQ9kYGzzhZRbK+xOo=", which would be returned in the + |Sec-WebSocket-Accept| header field. + + 5. Optionally, a |Sec-WebSocket-Protocol| header field, with a + value /subprotocol/ as defined in step 4 in Section 4.2.2. + + + + +Fette & Melnikov Standards Track [Page 24] + +RFC 6455 The WebSocket Protocol December 2011 + + + 6. Optionally, a |Sec-WebSocket-Extensions| header field, with a + value /extensions/ as defined in step 4 in Section 4.2.2. If + multiple extensions are to be used, they can all be listed in + a single |Sec-WebSocket-Extensions| header field or split + between multiple instances of the |Sec-WebSocket-Extensions| + header field. + + This completes the server's handshake. If the server finishes these + steps without aborting the WebSocket handshake, the server considers + the WebSocket connection to be established and that the WebSocket + connection is in the OPEN state. At this point, the server may begin + sending (and receiving) data. + +4.3. Collected ABNF for New Header Fields Used in Handshake + + This section is using ABNF syntax/rules from Section 2.1 of + [RFC2616], including the "implied *LWS rule". + + Note that the following ABNF conventions are used in this section. + Some names of the rules correspond to names of the corresponding + header fields. Such rules express values of the corresponding header + fields, for example, the Sec-WebSocket-Key ABNF rule describes syntax + of the |Sec-WebSocket-Key| header field value. ABNF rules with the + "-Client" suffix in the name are only used in requests sent by the + client to the server; ABNF rules with the "-Server" suffix in the + name are only used in responses sent by the server to the client. + For example, the ABNF rule Sec-WebSocket-Protocol-Client describes + syntax of the |Sec-WebSocket-Protocol| header field value sent by the + client to the server. + + The following new header fields can be sent during the handshake from + the client to the server: + + Sec-WebSocket-Key = base64-value-non-empty + Sec-WebSocket-Extensions = extension-list + Sec-WebSocket-Protocol-Client = 1#token + Sec-WebSocket-Version-Client = version + + base64-value-non-empty = (1*base64-data [ base64-padding ]) | + base64-padding + base64-data = 4base64-character + base64-padding = (2base64-character "==") | + (3base64-character "=") + base64-character = ALPHA | DIGIT | "+" | "/" + extension-list = 1#extension + extension = extension-token *( ";" extension-param ) + extension-token = registered-token + registered-token = token + + + +Fette & Melnikov Standards Track [Page 25] + +RFC 6455 The WebSocket Protocol December 2011 + + + extension-param = token [ "=" (token | quoted-string) ] + ; When using the quoted-string syntax variant, the value + ; after quoted-string unescaping MUST conform to the + ; 'token' ABNF. + NZDIGIT = "1" | "2" | "3" | "4" | "5" | "6" | + "7" | "8" | "9" + version = DIGIT | (NZDIGIT DIGIT) | + ("1" DIGIT DIGIT) | ("2" DIGIT DIGIT) + ; Limited to 0-255 range, with no leading zeros + + The following new header fields can be sent during the handshake from + the server to the client: + + Sec-WebSocket-Extensions = extension-list + Sec-WebSocket-Accept = base64-value-non-empty + Sec-WebSocket-Protocol-Server = token + Sec-WebSocket-Version-Server = 1#version + +4.4. Supporting Multiple Versions of WebSocket Protocol + + This section provides some guidance on supporting multiple versions + of the WebSocket Protocol in clients and servers. + + Using the WebSocket version advertisement capability (the + |Sec-WebSocket-Version| header field), a client can initially request + the version of the WebSocket Protocol that it prefers (which doesn't + necessarily have to be the latest supported by the client). If the + server supports the requested version and the handshake message is + otherwise valid, the server will accept that version. If the server + doesn't support the requested version, it MUST respond with a + |Sec-WebSocket-Version| header field (or multiple + |Sec-WebSocket-Version| header fields) containing all versions it is + willing to use. At this point, if the client supports one of the + advertised versions, it can repeat the WebSocket handshake using a + new version value. + + The following example demonstrates version negotiation described + above: + + GET /chat HTTP/1.1 + Host: server.example.com + Upgrade: websocket + Connection: Upgrade + ... + Sec-WebSocket-Version: 25 + + + + + + +Fette & Melnikov Standards Track [Page 26] + +RFC 6455 The WebSocket Protocol December 2011 + + + The response from the server might look as follows: + + HTTP/1.1 400 Bad Request + ... + Sec-WebSocket-Version: 13, 8, 7 + + Note that the last response from the server might also look like: + + HTTP/1.1 400 Bad Request + ... + Sec-WebSocket-Version: 13 + Sec-WebSocket-Version: 8, 7 + + The client now repeats the handshake that conforms to version 13: + + GET /chat HTTP/1.1 + Host: server.example.com + Upgrade: websocket + Connection: Upgrade + ... + Sec-WebSocket-Version: 13 + +5. Data Framing + +5.1. Overview + + In the WebSocket Protocol, data is transmitted using a sequence of + frames. To avoid confusing network intermediaries (such as + intercepting proxies) and for security reasons that are further + discussed in Section 10.3, a client MUST mask all frames that it + sends to the server (see Section 5.3 for further details). (Note + that masking is done whether or not the WebSocket Protocol is running + over TLS.) The server MUST close the connection upon receiving a + frame that is not masked. In this case, a server MAY send a Close + frame with a status code of 1002 (protocol error) as defined in + Section 7.4.1. A server MUST NOT mask any frames that it sends to + the client. A client MUST close a connection if it detects a masked + frame. In this case, it MAY use the status code 1002 (protocol + error) as defined in Section 7.4.1. (These rules might be relaxed in + a future specification.) + + The base framing protocol defines a frame type with an opcode, a + payload length, and designated locations for "Extension data" and + "Application data", which together define the "Payload data". + Certain bits and opcodes are reserved for future expansion of the + protocol. + + + + + +Fette & Melnikov Standards Track [Page 27] + +RFC 6455 The WebSocket Protocol December 2011 + + + A data frame MAY be transmitted by either the client or the server at + any time after opening handshake completion and before that endpoint + has sent a Close frame (Section 5.5.1). + +5.2. Base Framing Protocol + + This wire format for the data transfer part is described by the ABNF + [RFC5234] given in detail in this section. (Note that, unlike in + other sections of this document, the ABNF in this section is + operating on groups of bits. The length of each group of bits is + indicated in a comment. When encoded on the wire, the most + significant bit is the leftmost in the ABNF). A high-level overview + of the framing is given in the following figure. In a case of + conflict between the figure below and the ABNF specified later in + this section, the figure is authoritative. + + 0 1 2 3 + 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 + +-+-+-+-+-------+-+-------------+-------------------------------+ + |F|R|R|R| opcode|M| Payload len | Extended payload length | + |I|S|S|S| (4) |A| (7) | (16/64) | + |N|V|V|V| |S| | (if payload len==126/127) | + | |1|2|3| |K| | | + +-+-+-+-+-------+-+-------------+ - - - - - - - - - - - - - - - + + | Extended payload length continued, if payload len == 127 | + + - - - - - - - - - - - - - - - +-------------------------------+ + | |Masking-key, if MASK set to 1 | + +-------------------------------+-------------------------------+ + | Masking-key (continued) | Payload Data | + +-------------------------------- - - - - - - - - - - - - - - - + + : Payload Data continued ... : + + - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + | Payload Data continued ... | + +---------------------------------------------------------------+ + + FIN: 1 bit + + Indicates that this is the final fragment in a message. The first + fragment MAY also be the final fragment. + + RSV1, RSV2, RSV3: 1 bit each + + MUST be 0 unless an extension is negotiated that defines meanings + for non-zero values. If a nonzero value is received and none of + the negotiated extensions defines the meaning of such a nonzero + value, the receiving endpoint MUST _Fail the WebSocket + Connection_. + + + + +Fette & Melnikov Standards Track [Page 28] + +RFC 6455 The WebSocket Protocol December 2011 + + + Opcode: 4 bits + + Defines the interpretation of the "Payload data". If an unknown + opcode is received, the receiving endpoint MUST _Fail the + WebSocket Connection_. The following values are defined. + + * %x0 denotes a continuation frame + + * %x1 denotes a text frame + + * %x2 denotes a binary frame + + * %x3-7 are reserved for further non-control frames + + * %x8 denotes a connection close + + * %x9 denotes a ping + + * %xA denotes a pong + + * %xB-F are reserved for further control frames + + Mask: 1 bit + + Defines whether the "Payload data" is masked. If set to 1, a + masking key is present in masking-key, and this is used to unmask + the "Payload data" as per Section 5.3. All frames sent from + client to server have this bit set to 1. + + Payload length: 7 bits, 7+16 bits, or 7+64 bits + + The length of the "Payload data", in bytes: if 0-125, that is the + payload length. If 126, the following 2 bytes interpreted as a + 16-bit unsigned integer are the payload length. If 127, the + following 8 bytes interpreted as a 64-bit unsigned integer (the + most significant bit MUST be 0) are the payload length. Multibyte + length quantities are expressed in network byte order. Note that + in all cases, the minimal number of bytes MUST be used to encode + the length, for example, the length of a 124-byte-long string + can't be encoded as the sequence 126, 0, 124. The payload length + is the length of the "Extension data" + the length of the + "Application data". The length of the "Extension data" may be + zero, in which case the payload length is the length of the + "Application data". + + + + + + + +Fette & Melnikov Standards Track [Page 29] + +RFC 6455 The WebSocket Protocol December 2011 + + + Masking-key: 0 or 4 bytes + + All frames sent from the client to the server are masked by a + 32-bit value that is contained within the frame. This field is + present if the mask bit is set to 1 and is absent if the mask bit + is set to 0. See Section 5.3 for further information on client- + to-server masking. + + Payload data: (x+y) bytes + + The "Payload data" is defined as "Extension data" concatenated + with "Application data". + + Extension data: x bytes + + The "Extension data" is 0 bytes unless an extension has been + negotiated. Any extension MUST specify the length of the + "Extension data", or how that length may be calculated, and how + the extension use MUST be negotiated during the opening handshake. + If present, the "Extension data" is included in the total payload + length. + + Application data: y bytes + + Arbitrary "Application data", taking up the remainder of the frame + after any "Extension data". The length of the "Application data" + is equal to the payload length minus the length of the "Extension + data". + + The base framing protocol is formally defined by the following ABNF + [RFC5234]. It is important to note that the representation of this + data is binary, not ASCII characters. As such, a field with a length + of 1 bit that takes values %x0 / %x1 is represented as a single bit + whose value is 0 or 1, not a full byte (octet) that stands for the + characters "0" or "1" in the ASCII encoding. A field with a length + of 4 bits with values between %x0-F again is represented by 4 bits, + again NOT by an ASCII character or full byte (octet) with these + values. [RFC5234] does not specify a character encoding: "Rules + resolve into a string of terminal values, sometimes called + characters. In ABNF, a character is merely a non-negative integer. + In certain contexts, a specific mapping (encoding) of values into a + character set (such as ASCII) will be specified." Here, the + specified encoding is a binary encoding where each terminal value is + encoded in the specified number of bits, which varies for each field. + + + + + + + +Fette & Melnikov Standards Track [Page 30] + +RFC 6455 The WebSocket Protocol December 2011 + + + ws-frame = frame-fin ; 1 bit in length + frame-rsv1 ; 1 bit in length + frame-rsv2 ; 1 bit in length + frame-rsv3 ; 1 bit in length + frame-opcode ; 4 bits in length + frame-masked ; 1 bit in length + frame-payload-length ; either 7, 7+16, + ; or 7+64 bits in + ; length + [ frame-masking-key ] ; 32 bits in length + frame-payload-data ; n*8 bits in + ; length, where + ; n >= 0 + + frame-fin = %x0 ; more frames of this message follow + / %x1 ; final frame of this message + ; 1 bit in length + + frame-rsv1 = %x0 / %x1 + ; 1 bit in length, MUST be 0 unless + ; negotiated otherwise + + frame-rsv2 = %x0 / %x1 + ; 1 bit in length, MUST be 0 unless + ; negotiated otherwise + + frame-rsv3 = %x0 / %x1 + ; 1 bit in length, MUST be 0 unless + ; negotiated otherwise + + frame-opcode = frame-opcode-non-control / + frame-opcode-control / + frame-opcode-cont + + frame-opcode-cont = %x0 ; frame continuation + + frame-opcode-non-control= %x1 ; text frame + / %x2 ; binary frame + / %x3-7 + ; 4 bits in length, + ; reserved for further non-control frames + + frame-opcode-control = %x8 ; connection close + / %x9 ; ping + / %xA ; pong + / %xB-F ; reserved for further control + ; frames + ; 4 bits in length + + + +Fette & Melnikov Standards Track [Page 31] + +RFC 6455 The WebSocket Protocol December 2011 + + + frame-masked = %x0 + ; frame is not masked, no frame-masking-key + / %x1 + ; frame is masked, frame-masking-key present + ; 1 bit in length + + frame-payload-length = ( %x00-7D ) + / ( %x7E frame-payload-length-16 ) + / ( %x7F frame-payload-length-63 ) + ; 7, 7+16, or 7+64 bits in length, + ; respectively + + frame-payload-length-16 = %x0000-FFFF ; 16 bits in length + + frame-payload-length-63 = %x0000000000000000-7FFFFFFFFFFFFFFF + ; 64 bits in length + + frame-masking-key = 4( %x00-FF ) + ; present only if frame-masked is 1 + ; 32 bits in length + + frame-payload-data = (frame-masked-extension-data + frame-masked-application-data) + ; when frame-masked is 1 + / (frame-unmasked-extension-data + frame-unmasked-application-data) + ; when frame-masked is 0 + + frame-masked-extension-data = *( %x00-FF ) + ; reserved for future extensibility + ; n*8 bits in length, where n >= 0 + + frame-masked-application-data = *( %x00-FF ) + ; n*8 bits in length, where n >= 0 + + frame-unmasked-extension-data = *( %x00-FF ) + ; reserved for future extensibility + ; n*8 bits in length, where n >= 0 + + frame-unmasked-application-data = *( %x00-FF ) + ; n*8 bits in length, where n >= 0 + +5.3. Client-to-Server Masking + + A masked frame MUST have the field frame-masked set to 1, as defined + in Section 5.2. + + + + + +Fette & Melnikov Standards Track [Page 32] + +RFC 6455 The WebSocket Protocol December 2011 + + + The masking key is contained completely within the frame, as defined + in Section 5.2 as frame-masking-key. It is used to mask the "Payload + data" defined in the same section as frame-payload-data, which + includes "Extension data" and "Application data". + + The masking key is a 32-bit value chosen at random by the client. + When preparing a masked frame, the client MUST pick a fresh masking + key from the set of allowed 32-bit values. The masking key needs to + be unpredictable; thus, the masking key MUST be derived from a strong + source of entropy, and the masking key for a given frame MUST NOT + make it simple for a server/proxy to predict the masking key for a + subsequent frame. The unpredictability of the masking key is + essential to prevent authors of malicious applications from selecting + the bytes that appear on the wire. RFC 4086 [RFC4086] discusses what + entails a suitable source of entropy for security-sensitive + applications. + + The masking does not affect the length of the "Payload data". To + convert masked data into unmasked data, or vice versa, the following + algorithm is applied. The same algorithm applies regardless of the + direction of the translation, e.g., the same steps are applied to + mask the data as to unmask the data. + + Octet i of the transformed data ("transformed-octet-i") is the XOR of + octet i of the original data ("original-octet-i") with octet at index + i modulo 4 of the masking key ("masking-key-octet-j"): + + j = i MOD 4 + transformed-octet-i = original-octet-i XOR masking-key-octet-j + + The payload length, indicated in the framing as frame-payload-length, + does NOT include the length of the masking key. It is the length of + the "Payload data", e.g., the number of bytes following the masking + key. + +5.4. Fragmentation + + The primary purpose of fragmentation is to allow sending a message + that is of unknown size when the message is started without having to + buffer that message. If messages couldn't be fragmented, then an + endpoint would have to buffer the entire message so its length could + be counted before the first byte is sent. With fragmentation, a + server or intermediary may choose a reasonable size buffer and, when + the buffer is full, write a fragment to the network. + + A secondary use-case for fragmentation is for multiplexing, where it + is not desirable for a large message on one logical channel to + monopolize the output channel, so the multiplexing needs to be free + + + +Fette & Melnikov Standards Track [Page 33] + +RFC 6455 The WebSocket Protocol December 2011 + + + to split the message into smaller fragments to better share the + output channel. (Note that the multiplexing extension is not + described in this document.) + + Unless specified otherwise by an extension, frames have no semantic + meaning. An intermediary might coalesce and/or split frames, if no + extensions were negotiated by the client and the server or if some + extensions were negotiated, but the intermediary understood all the + extensions negotiated and knows how to coalesce and/or split frames + in the presence of these extensions. One implication of this is that + in absence of extensions, senders and receivers must not depend on + the presence of specific frame boundaries. + + The following rules apply to fragmentation: + + o An unfragmented message consists of a single frame with the FIN + bit set (Section 5.2) and an opcode other than 0. + + o A fragmented message consists of a single frame with the FIN bit + clear and an opcode other than 0, followed by zero or more frames + with the FIN bit clear and the opcode set to 0, and terminated by + a single frame with the FIN bit set and an opcode of 0. A + fragmented message is conceptually equivalent to a single larger + message whose payload is equal to the concatenation of the + payloads of the fragments in order; however, in the presence of + extensions, this may not hold true as the extension defines the + interpretation of the "Extension data" present. For instance, + "Extension data" may only be present at the beginning of the first + fragment and apply to subsequent fragments, or there may be + "Extension data" present in each of the fragments that applies + only to that particular fragment. In the absence of "Extension + data", the following example demonstrates how fragmentation works. + + EXAMPLE: For a text message sent as three fragments, the first + fragment would have an opcode of 0x1 and a FIN bit clear, the + second fragment would have an opcode of 0x0 and a FIN bit clear, + and the third fragment would have an opcode of 0x0 and a FIN bit + that is set. + + o Control frames (see Section 5.5) MAY be injected in the middle of + a fragmented message. Control frames themselves MUST NOT be + fragmented. + + o Message fragments MUST be delivered to the recipient in the order + sent by the sender. + + + + + + +Fette & Melnikov Standards Track [Page 34] + +RFC 6455 The WebSocket Protocol December 2011 + + + o The fragments of one message MUST NOT be interleaved between the + fragments of another message unless an extension has been + negotiated that can interpret the interleaving. + + o An endpoint MUST be capable of handling control frames in the + middle of a fragmented message. + + o A sender MAY create fragments of any size for non-control + messages. + + o Clients and servers MUST support receiving both fragmented and + unfragmented messages. + + o As control frames cannot be fragmented, an intermediary MUST NOT + attempt to change the fragmentation of a control frame. + + o An intermediary MUST NOT change the fragmentation of a message if + any reserved bit values are used and the meaning of these values + is not known to the intermediary. + + o An intermediary MUST NOT change the fragmentation of any message + in the context of a connection where extensions have been + negotiated and the intermediary is not aware of the semantics of + the negotiated extensions. Similarly, an intermediary that didn't + see the WebSocket handshake (and wasn't notified about its + content) that resulted in a WebSocket connection MUST NOT change + the fragmentation of any message of such connection. + + o As a consequence of these rules, all fragments of a message are of + the same type, as set by the first fragment's opcode. Since + control frames cannot be fragmented, the type for all fragments in + a message MUST be either text, binary, or one of the reserved + opcodes. + + NOTE: If control frames could not be interjected, the latency of a + ping, for example, would be very long if behind a large message. + Hence, the requirement of handling control frames in the middle of a + fragmented message. + + IMPLEMENTATION NOTE: In the absence of any extension, a receiver + doesn't have to buffer the whole frame in order to process it. For + example, if a streaming API is used, a part of a frame can be + delivered to the application. However, note that this assumption + might not hold true for all future WebSocket extensions. + + + + + + + +Fette & Melnikov Standards Track [Page 35] + +RFC 6455 The WebSocket Protocol December 2011 + + +5.5. Control Frames + + Control frames are identified by opcodes where the most significant + bit of the opcode is 1. Currently defined opcodes for control frames + include 0x8 (Close), 0x9 (Ping), and 0xA (Pong). Opcodes 0xB-0xF are + reserved for further control frames yet to be defined. + + Control frames are used to communicate state about the WebSocket. + Control frames can be interjected in the middle of a fragmented + message. + + All control frames MUST have a payload length of 125 bytes or less + and MUST NOT be fragmented. + +5.5.1. Close + + The Close frame contains an opcode of 0x8. + + The Close frame MAY contain a body (the "Application data" portion of + the frame) that indicates a reason for closing, such as an endpoint + shutting down, an endpoint having received a frame too large, or an + endpoint having received a frame that does not conform to the format + expected by the endpoint. If there is a body, the first two bytes of + the body MUST be a 2-byte unsigned integer (in network byte order) + representing a status code with value /code/ defined in Section 7.4. + Following the 2-byte integer, the body MAY contain UTF-8-encoded data + with value /reason/, the interpretation of which is not defined by + this specification. This data is not necessarily human readable but + may be useful for debugging or passing information relevant to the + script that opened the connection. As the data is not guaranteed to + be human readable, clients MUST NOT show it to end users. + + Close frames sent from client to server must be masked as per + Section 5.3. + + The application MUST NOT send any more data frames after sending a + Close frame. + + If an endpoint receives a Close frame and did not previously send a + Close frame, the endpoint MUST send a Close frame in response. (When + sending a Close frame in response, the endpoint typically echos the + status code it received.) It SHOULD do so as soon as practical. An + endpoint MAY delay sending a Close frame until its current message is + sent (for instance, if the majority of a fragmented message is + already sent, an endpoint MAY send the remaining fragments before + sending a Close frame). However, there is no guarantee that the + endpoint that has already sent a Close frame will continue to process + data. + + + +Fette & Melnikov Standards Track [Page 36] + +RFC 6455 The WebSocket Protocol December 2011 + + + After both sending and receiving a Close message, an endpoint + considers the WebSocket connection closed and MUST close the + underlying TCP connection. The server MUST close the underlying TCP + connection immediately; the client SHOULD wait for the server to + close the connection but MAY close the connection at any time after + sending and receiving a Close message, e.g., if it has not received a + TCP Close from the server in a reasonable time period. + + If a client and server both send a Close message at the same time, + both endpoints will have sent and received a Close message and should + consider the WebSocket connection closed and close the underlying TCP + connection. + +5.5.2. Ping + + The Ping frame contains an opcode of 0x9. + + A Ping frame MAY include "Application data". + + Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in + response, unless it already received a Close frame. It SHOULD + respond with Pong frame as soon as is practical. Pong frames are + discussed in Section 5.5.3. + + An endpoint MAY send a Ping frame any time after the connection is + established and before the connection is closed. + + NOTE: A Ping frame may serve either as a keepalive or as a means to + verify that the remote endpoint is still responsive. + +5.5.3. Pong + + The Pong frame contains an opcode of 0xA. + + Section 5.5.2 details requirements that apply to both Ping and Pong + frames. + + A Pong frame sent in response to a Ping frame must have identical + "Application data" as found in the message body of the Ping frame + being replied to. + + If an endpoint receives a Ping frame and has not yet sent Pong + frame(s) in response to previous Ping frame(s), the endpoint MAY + elect to send a Pong frame for only the most recently processed Ping + frame. + + + + + + +Fette & Melnikov Standards Track [Page 37] + +RFC 6455 The WebSocket Protocol December 2011 + + + A Pong frame MAY be sent unsolicited. This serves as a + unidirectional heartbeat. A response to an unsolicited Pong frame is + not expected. + +5.6. Data Frames + + Data frames (e.g., non-control frames) are identified by opcodes + where the most significant bit of the opcode is 0. Currently defined + opcodes for data frames include 0x1 (Text), 0x2 (Binary). Opcodes + 0x3-0x7 are reserved for further non-control frames yet to be + defined. + + Data frames carry application-layer and/or extension-layer data. The + opcode determines the interpretation of the data: + + Text + + The "Payload data" is text data encoded as UTF-8. Note that a + particular text frame might include a partial UTF-8 sequence; + however, the whole message MUST contain valid UTF-8. Invalid + UTF-8 in reassembled messages is handled as described in + Section 8.1. + + Binary + + The "Payload data" is arbitrary binary data whose interpretation + is solely up to the application layer. + +5.7. Examples + + o A single-frame unmasked text message + + * 0x81 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains "Hello") + + o A single-frame masked text message + + * 0x81 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58 + (contains "Hello") + + o A fragmented unmasked text message + + * 0x01 0x03 0x48 0x65 0x6c (contains "Hel") + + * 0x80 0x02 0x6c 0x6f (contains "lo") + + + + + + + +Fette & Melnikov Standards Track [Page 38] + +RFC 6455 The WebSocket Protocol December 2011 + + + o Unmasked Ping request and masked Ping response + + * 0x89 0x05 0x48 0x65 0x6c 0x6c 0x6f (contains a body of "Hello", + but the contents of the body are arbitrary) + + * 0x8a 0x85 0x37 0xfa 0x21 0x3d 0x7f 0x9f 0x4d 0x51 0x58 + (contains a body of "Hello", matching the body of the ping) + + o 256 bytes binary message in a single unmasked frame + + * 0x82 0x7E 0x0100 [256 bytes of binary data] + + o 64KiB binary message in a single unmasked frame + + * 0x82 0x7F 0x0000000000010000 [65536 bytes of binary data] + +5.8. Extensibility + + The protocol is designed to allow for extensions, which will add + capabilities to the base protocol. The endpoints of a connection + MUST negotiate the use of any extensions during the opening + handshake. This specification provides opcodes 0x3 through 0x7 and + 0xB through 0xF, the "Extension data" field, and the frame-rsv1, + frame-rsv2, and frame-rsv3 bits of the frame header for use by + extensions. The negotiation of extensions is discussed in further + detail in Section 9.1. Below are some anticipated uses of + extensions. This list is neither complete nor prescriptive. + + o "Extension data" may be placed in the "Payload data" before the + "Application data". + + o Reserved bits can be allocated for per-frame needs. + + o Reserved opcode values can be defined. + + o Reserved bits can be allocated to the opcode field if more opcode + values are needed. + + o A reserved bit or an "extension" opcode can be defined that + allocates additional bits out of the "Payload data" to define + larger opcodes or more per-frame bits. + +6. Sending and Receiving Data + +6.1. Sending Data + + To _Send a WebSocket Message_ comprising of /data/ over a WebSocket + connection, an endpoint MUST perform the following steps. + + + +Fette & Melnikov Standards Track [Page 39] + +RFC 6455 The WebSocket Protocol December 2011 + + + 1. The endpoint MUST ensure the WebSocket connection is in the OPEN + state (cf. Sections 4.1 and 4.2.2.) If at any point the state of + the WebSocket connection changes, the endpoint MUST abort the + following steps. + + 2. An endpoint MUST encapsulate the /data/ in a WebSocket frame as + defined in Section 5.2. If the data to be sent is large or if + the data is not available in its entirety at the point the + endpoint wishes to begin sending the data, the endpoint MAY + alternately encapsulate the data in a series of frames as defined + in Section 5.4. + + 3. The opcode (frame-opcode) of the first frame containing the data + MUST be set to the appropriate value from Section 5.2 for data + that is to be interpreted by the recipient as text or binary + data. + + 4. The FIN bit (frame-fin) of the last frame containing the data + MUST be set to 1 as defined in Section 5.2. + + 5. If the data is being sent by the client, the frame(s) MUST be + masked as defined in Section 5.3. + + 6. If any extensions (Section 9) have been negotiated for the + WebSocket connection, additional considerations may apply as per + the definition of those extensions. + + 7. The frame(s) that have been formed MUST be transmitted over the + underlying network connection. + +6.2. Receiving Data + + To receive WebSocket data, an endpoint listens on the underlying + network connection. Incoming data MUST be parsed as WebSocket frames + as defined in Section 5.2. If a control frame (Section 5.5) is + received, the frame MUST be handled as defined by Section 5.5. Upon + receiving a data frame (Section 5.6), the endpoint MUST note the + /type/ of the data as defined by the opcode (frame-opcode) from + Section 5.2. The "Application data" from this frame is defined as + the /data/ of the message. If the frame comprises an unfragmented + message (Section 5.4), it is said that _A WebSocket Message Has Been + Received_ with type /type/ and data /data/. If the frame is part of + a fragmented message, the "Application data" of the subsequent data + frames is concatenated to form the /data/. When the last fragment is + received as indicated by the FIN bit (frame-fin), it is said that _A + WebSocket Message Has Been Received_ with data /data/ (comprised of + the concatenation of the "Application data" of the fragments) and + + + + +Fette & Melnikov Standards Track [Page 40] + +RFC 6455 The WebSocket Protocol December 2011 + + + type /type/ (noted from the first frame of the fragmented message). + Subsequent data frames MUST be interpreted as belonging to a new + WebSocket message. + + Extensions (Section 9) MAY change the semantics of how data is read, + specifically including what comprises a message boundary. + Extensions, in addition to adding "Extension data" before the + "Application data" in a payload, MAY also modify the "Application + data" (such as by compressing it). + + A server MUST remove masking for data frames received from a client + as described in Section 5.3. + +7. Closing the Connection + +7.1. Definitions + +7.1.1. Close the WebSocket Connection + + To _Close the WebSocket Connection_, an endpoint closes the + underlying TCP connection. An endpoint SHOULD use a method that + cleanly closes the TCP connection, as well as the TLS session, if + applicable, discarding any trailing bytes that may have been + received. An endpoint MAY close the connection via any means + available when necessary, such as when under attack. + + The underlying TCP connection, in most normal cases, SHOULD be closed + first by the server, so that it holds the TIME_WAIT state and not the + client (as this would prevent it from re-opening the connection for 2 + maximum segment lifetimes (2MSL), while there is no corresponding + server impact as a TIME_WAIT connection is immediately reopened upon + a new SYN with a higher seq number). In abnormal cases (such as not + having received a TCP Close from the server after a reasonable amount + of time) a client MAY initiate the TCP Close. As such, when a server + is instructed to _Close the WebSocket Connection_ it SHOULD initiate + a TCP Close immediately, and when a client is instructed to do the + same, it SHOULD wait for a TCP Close from the server. + + As an example of how to obtain a clean closure in C using Berkeley + sockets, one would call shutdown() with SHUT_WR on the socket, call + recv() until obtaining a return value of 0 indicating that the peer + has also performed an orderly shutdown, and finally call close() on + the socket. + + + + + + + + +Fette & Melnikov Standards Track [Page 41] + +RFC 6455 The WebSocket Protocol December 2011 + + +7.1.2. Start the WebSocket Closing Handshake + + To _Start the WebSocket Closing Handshake_ with a status code + (Section 7.4) /code/ and an optional close reason (Section 7.1.6) + /reason/, an endpoint MUST send a Close control frame, as described + in Section 5.5.1, whose status code is set to /code/ and whose close + reason is set to /reason/. Once an endpoint has both sent and + received a Close control frame, that endpoint SHOULD _Close the + WebSocket Connection_ as defined in Section 7.1.1. + +7.1.3. The WebSocket Closing Handshake is Started + + Upon either sending or receiving a Close control frame, it is said + that _The WebSocket Closing Handshake is Started_ and that the + WebSocket connection is in the CLOSING state. + +7.1.4. The WebSocket Connection is Closed + + When the underlying TCP connection is closed, it is said that _The + WebSocket Connection is Closed_ and that the WebSocket connection is + in the CLOSED state. If the TCP connection was closed after the + WebSocket closing handshake was completed, the WebSocket connection + is said to have been closed _cleanly_. + + If the WebSocket connection could not be established, it is also said + that _The WebSocket Connection is Closed_, but not _cleanly_. + +7.1.5. The WebSocket Connection Close Code + + As defined in Sections 5.5.1 and 7.4, a Close control frame may + contain a status code indicating a reason for closure. A closing of + the WebSocket connection may be initiated by either endpoint, + potentially simultaneously. _The WebSocket Connection Close Code_ is + defined as the status code (Section 7.4) contained in the first Close + control frame received by the application implementing this protocol. + If this Close control frame contains no status code, _The WebSocket + Connection Close Code_ is considered to be 1005. If _The WebSocket + Connection is Closed_ and no Close control frame was received by the + endpoint (such as could occur if the underlying transport connection + is lost), _The WebSocket Connection Close Code_ is considered to be + 1006. + + NOTE: Two endpoints may not agree on the value of _The WebSocket + Connection Close Code_. As an example, if the remote endpoint sent a + Close frame but the local application has not yet read the data + containing the Close frame from its socket's receive buffer, and the + local application independently decided to close the connection and + send a Close frame, both endpoints will have sent and received a + + + +Fette & Melnikov Standards Track [Page 42] + +RFC 6455 The WebSocket Protocol December 2011 + + + Close frame and will not send further Close frames. Each endpoint + will see the status code sent by the other end as _The WebSocket + Connection Close Code_. As such, it is possible that the two + endpoints may not agree on the value of _The WebSocket Connection + Close Code_ in the case that both endpoints _Start the WebSocket + Closing Handshake_ independently and at roughly the same time. + +7.1.6. The WebSocket Connection Close Reason + + As defined in Sections 5.5.1 and 7.4, a Close control frame may + contain a status code indicating a reason for closure, followed by + UTF-8-encoded data, the interpretation of said data being left to the + endpoints and not defined by this protocol. A closing of the + WebSocket connection may be initiated by either endpoint, potentially + simultaneously. _The WebSocket Connection Close Reason_ is defined as + the UTF-8-encoded data following the status code (Section 7.4) + contained in the first Close control frame received by the + application implementing this protocol. If there is no such data in + the Close control frame, _The WebSocket Connection Close Reason_ is + the empty string. + + NOTE: Following the same logic as noted in Section 7.1.5, two + endpoints may not agree on _The WebSocket Connection Close Reason_. + +7.1.7. Fail the WebSocket Connection + + Certain algorithms and specifications require an endpoint to _Fail + the WebSocket Connection_. To do so, the client MUST _Close the + WebSocket Connection_, and MAY report the problem to the user (which + would be especially useful for developers) in an appropriate manner. + Similarly, to do so, the server MUST _Close the WebSocket + Connection_, and SHOULD log the problem. + + If _The WebSocket Connection is Established_ prior to the point where + the endpoint is required to _Fail the WebSocket Connection_, the + endpoint SHOULD send a Close frame with an appropriate status code + (Section 7.4) before proceeding to _Close the WebSocket Connection_. + An endpoint MAY omit sending a Close frame if it believes the other + side is unlikely to be able to receive and process the Close frame, + due to the nature of the error that led the WebSocket connection to + fail in the first place. An endpoint MUST NOT continue to attempt to + process data (including a responding Close frame) from the remote + endpoint after being instructed to _Fail the WebSocket Connection_. + + Except as indicated above or as specified by the application layer + (e.g., a script using the WebSocket API), clients SHOULD NOT close + the connection. + + + + +Fette & Melnikov Standards Track [Page 43] + +RFC 6455 The WebSocket Protocol December 2011 + + +7.2. Abnormal Closures + +7.2.1. Client-Initiated Closure + + Certain algorithms, in particular during the opening handshake, + require the client to _Fail the WebSocket Connection_. To do so, the + client MUST _Fail the WebSocket Connection_ as defined in + Section 7.1.7. + + If at any point the underlying transport layer connection is + unexpectedly lost, the client MUST _Fail the WebSocket Connection_. + + Except as indicated above or as specified by the application layer + (e.g., a script using the WebSocket API), clients SHOULD NOT close + the connection. + +7.2.2. Server-Initiated Closure + + Certain algorithms require or recommend that the server _Abort the + WebSocket Connection_ during the opening handshake. To do so, the + server MUST simply _Close the WebSocket Connection_ (Section 7.1.1). + +7.2.3. Recovering from Abnormal Closure + + Abnormal closures may be caused by any number of reasons. Such + closures could be the result of a transient error, in which case + reconnecting may lead to a good connection and a resumption of normal + operations. Such closures may also be the result of a nontransient + problem, in which case if each deployed client experiences an + abnormal closure and immediately and persistently tries to reconnect, + the server may experience what amounts to a denial-of-service attack + by a large number of clients trying to reconnect. The end result of + such a scenario could be that the service is unable to recover in a + timely manner or recovery is made much more difficult. + + To prevent this, clients SHOULD use some form of backoff when trying + to reconnect after abnormal closures as described in this section. + + The first reconnect attempt SHOULD be delayed by a random amount of + time. The parameters by which this random delay is chosen are left + to the client to decide; a value chosen randomly between 0 and 5 + seconds is a reasonable initial delay though clients MAY choose a + different interval from which to select a delay length based on + implementation experience and particular application. + + Should the first reconnect attempt fail, subsequent reconnect + attempts SHOULD be delayed by increasingly longer amounts of time, + using a method such as truncated binary exponential backoff. + + + +Fette & Melnikov Standards Track [Page 44] + +RFC 6455 The WebSocket Protocol December 2011 + + +7.3. Normal Closure of Connections + + Servers MAY close the WebSocket connection whenever desired. Clients + SHOULD NOT close the WebSocket connection arbitrarily. In either + case, an endpoint initiates a closure by following the procedures to + _Start the WebSocket Closing Handshake_ (Section 7.1.2). + +7.4. Status Codes + + When closing an established connection (e.g., when sending a Close + frame, after the opening handshake has completed), an endpoint MAY + indicate a reason for closure. The interpretation of this reason by + an endpoint, and the action an endpoint should take given this + reason, are left undefined by this specification. This specification + defines a set of pre-defined status codes and specifies which ranges + may be used by extensions, frameworks, and end applications. The + status code and any associated textual message are optional + components of a Close frame. + +7.4.1. Defined Status Codes + + Endpoints MAY use the following pre-defined status codes when sending + a Close frame. + + 1000 + + 1000 indicates a normal closure, meaning that the purpose for + which the connection was established has been fulfilled. + + 1001 + + 1001 indicates that an endpoint is "going away", such as a server + going down or a browser having navigated away from a page. + + 1002 + + 1002 indicates that an endpoint is terminating the connection due + to a protocol error. + + 1003 + + 1003 indicates that an endpoint is terminating the connection + because it has received a type of data it cannot accept (e.g., an + endpoint that understands only text data MAY send this if it + receives a binary message). + + + + + + +Fette & Melnikov Standards Track [Page 45] + +RFC 6455 The WebSocket Protocol December 2011 + + + 1004 + + Reserved. The specific meaning might be defined in the future. + + 1005 + + 1005 is a reserved value and MUST NOT be set as a status code in a + Close control frame by an endpoint. It is designated for use in + applications expecting a status code to indicate that no status + code was actually present. + + 1006 + + 1006 is a reserved value and MUST NOT be set as a status code in a + Close control frame by an endpoint. It is designated for use in + applications expecting a status code to indicate that the + connection was closed abnormally, e.g., without sending or + receiving a Close control frame. + + 1007 + + 1007 indicates that an endpoint is terminating the connection + because it has received data within a message that was not + consistent with the type of the message (e.g., non-UTF-8 [RFC3629] + data within a text message). + + 1008 + + 1008 indicates that an endpoint is terminating the connection + because it has received a message that violates its policy. This + is a generic status code that can be returned when there is no + other more suitable status code (e.g., 1003 or 1009) or if there + is a need to hide specific details about the policy. + + 1009 + + 1009 indicates that an endpoint is terminating the connection + because it has received a message that is too big for it to + process. + + 1010 + + 1010 indicates that an endpoint (client) is terminating the + connection because it has expected the server to negotiate one or + more extension, but the server didn't return them in the response + message of the WebSocket handshake. The list of extensions that + + + + + +Fette & Melnikov Standards Track [Page 46] + +RFC 6455 The WebSocket Protocol December 2011 + + + are needed SHOULD appear in the /reason/ part of the Close frame. + Note that this status code is not used by the server, because it + can fail the WebSocket handshake instead. + + 1011 + + 1011 indicates that a server is terminating the connection because + it encountered an unexpected condition that prevented it from + fulfilling the request. + + 1015 + + 1015 is a reserved value and MUST NOT be set as a status code in a + Close control frame by an endpoint. It is designated for use in + applications expecting a status code to indicate that the + connection was closed due to a failure to perform a TLS handshake + (e.g., the server certificate can't be verified). + +7.4.2. Reserved Status Code Ranges + + 0-999 + + Status codes in the range 0-999 are not used. + + 1000-2999 + + Status codes in the range 1000-2999 are reserved for definition by + this protocol, its future revisions, and extensions specified in a + permanent and readily available public specification. + + 3000-3999 + + Status codes in the range 3000-3999 are reserved for use by + libraries, frameworks, and applications. These status codes are + registered directly with IANA. The interpretation of these codes + is undefined by this protocol. + + 4000-4999 + + Status codes in the range 4000-4999 are reserved for private use + and thus can't be registered. Such codes can be used by prior + agreements between WebSocket applications. The interpretation of + these codes is undefined by this protocol. + + + + + + + + +Fette & Melnikov Standards Track [Page 47] + +RFC 6455 The WebSocket Protocol December 2011 + + +8. Error Handling + +8.1. Handling Errors in UTF-8-Encoded Data + + When an endpoint is to interpret a byte stream as UTF-8 but finds + that the byte stream is not, in fact, a valid UTF-8 stream, that + endpoint MUST _Fail the WebSocket Connection_. This rule applies + both during the opening handshake and during subsequent data + exchange. + +9. Extensions + + WebSocket clients MAY request extensions to this specification, and + WebSocket servers MAY accept some or all extensions requested by the + client. A server MUST NOT respond with any extension not requested + by the client. If extension parameters are included in negotiations + between the client and the server, those parameters MUST be chosen in + accordance with the specification of the extension to which the + parameters apply. + +9.1. Negotiating Extensions + + A client requests extensions by including a |Sec-WebSocket- + Extensions| header field, which follows the normal rules for HTTP + header fields (see [RFC2616], Section 4.2) and the value of the + header field is defined by the following ABNF [RFC2616]. Note that + this section is using ABNF syntax/rules from [RFC2616], including the + "implied *LWS rule". If a value is received by either the client or + the server during negotiation that does not conform to the ABNF + below, the recipient of such malformed data MUST immediately _Fail + the WebSocket Connection_. + + Sec-WebSocket-Extensions = extension-list + extension-list = 1#extension + extension = extension-token *( ";" extension-param ) + extension-token = registered-token + registered-token = token + extension-param = token [ "=" (token | quoted-string) ] + ;When using the quoted-string syntax variant, the value + ;after quoted-string unescaping MUST conform to the + ;'token' ABNF. + + + + + + + + + + +Fette & Melnikov Standards Track [Page 48] + +RFC 6455 The WebSocket Protocol December 2011 + + + Note that like other HTTP header fields, this header field MAY be + split or combined across multiple lines. Ergo, the following are + equivalent: + + Sec-WebSocket-Extensions: foo + Sec-WebSocket-Extensions: bar; baz=2 + + is exactly equivalent to + + Sec-WebSocket-Extensions: foo, bar; baz=2 + + Any extension-token used MUST be a registered token (see + Section 11.4). The parameters supplied with any given extension MUST + be defined for that extension. Note that the client is only offering + to use any advertised extensions and MUST NOT use them unless the + server indicates that it wishes to use the extension. + + Note that the order of extensions is significant. Any interactions + between multiple extensions MAY be defined in the documents defining + the extensions. In the absence of such definitions, the + interpretation is that the header fields listed by the client in its + request represent a preference of the header fields it wishes to use, + with the first options listed being most preferable. The extensions + listed by the server in response represent the extensions actually in + use for the connection. Should the extensions modify the data and/or + framing, the order of operations on the data should be assumed to be + the same as the order in which the extensions are listed in the + server's response in the opening handshake. + + For example, if there are two extensions "foo" and "bar" and if the + header field |Sec-WebSocket-Extensions| sent by the server has the + value "foo, bar", then operations on the data will be made as + bar(foo(data)), be those changes to the data itself (such as + compression) or changes to the framing that may "stack". + + Non-normative examples of acceptable extension header fields (note + that long lines are folded for readability): + + Sec-WebSocket-Extensions: deflate-stream + Sec-WebSocket-Extensions: mux; max-channels=4; flow-control, + deflate-stream + Sec-WebSocket-Extensions: private-extension + + A server accepts one or more extensions by including a + |Sec-WebSocket-Extensions| header field containing one or more + extensions that were requested by the client. The interpretation of + + + + + +Fette & Melnikov Standards Track [Page 49] + +RFC 6455 The WebSocket Protocol December 2011 + + + any extension parameters, and what constitutes a valid response by a + server to a requested set of parameters by a client, will be defined + by each such extension. + +9.2. Known Extensions + + Extensions provide a mechanism for implementations to opt-in to + additional protocol features. This document doesn't define any + extension, but implementations MAY use extensions defined separately. + +10. Security Considerations + + This section describes some security considerations applicable to the + WebSocket Protocol. Specific security considerations are described + in subsections of this section. + +10.1. Non-Browser Clients + + The WebSocket Protocol protects against malicious JavaScript running + inside a trusted application such as a web browser, for example, by + checking of the |Origin| header field (see below). See Section 1.6 + for additional details. Such assumptions don't hold true in the case + of a more-capable client. + + While this protocol is intended to be used by scripts in web pages, + it can also be used directly by hosts. Such hosts are acting on + their own behalf and can therefore send fake |Origin| header fields, + misleading the server. Servers should therefore be careful about + assuming that they are talking directly to scripts from known origins + and must consider that they might be accessed in unexpected ways. In + particular, a server should not trust that any input is valid. + + EXAMPLE: If the server uses input as part of SQL queries, all input + text should be escaped before being passed to the SQL server, lest + the server be susceptible to SQL injection. + +10.2. Origin Considerations + + Servers that are not intended to process input from any web page but + only for certain sites SHOULD verify the |Origin| field is an origin + they expect. If the origin indicated is unacceptable to the server, + then it SHOULD respond to the WebSocket handshake with a reply + containing HTTP 403 Forbidden status code. + + The |Origin| header field protects from the attack cases when the + untrusted party is typically the author of a JavaScript application + that is executing in the context of the trusted client. The client + itself can contact the server and, via the mechanism of the |Origin| + + + +Fette & Melnikov Standards Track [Page 50] + +RFC 6455 The WebSocket Protocol December 2011 + + + header field, determine whether to extend those communication + privileges to the JavaScript application. The intent is not to + prevent non-browsers from establishing connections but rather to + ensure that trusted browsers under the control of potentially + malicious JavaScript cannot fake a WebSocket handshake. + +10.3. Attacks On Infrastructure (Masking) + + In addition to endpoints being the target of attacks via WebSockets, + other parts of web infrastructure, such as proxies, may be the + subject of an attack. + + As this protocol was being developed, an experiment was conducted to + demonstrate a class of attacks on proxies that led to the poisoning + of caching proxies deployed in the wild [TALKING]. The general form + of the attack was to establish a connection to a server under the + "attacker's" control, perform an UPGRADE on the HTTP connection + similar to what the WebSocket Protocol does to establish a + connection, and subsequently send data over that UPGRADEd connection + that looked like a GET request for a specific known resource (which + in an attack would likely be something like a widely deployed script + for tracking hits or a resource on an ad-serving network). The + remote server would respond with something that looked like a + response to the fake GET request, and this response would be cached + by a nonzero percentage of deployed intermediaries, thus poisoning + the cache. The net effect of this attack would be that if a user + could be convinced to visit a website the attacker controlled, the + attacker could potentially poison the cache for that user and other + users behind the same cache and run malicious script on other + origins, compromising the web security model. + + To avoid such attacks on deployed intermediaries, it is not + sufficient to prefix application-supplied data with framing that is + not compliant with HTTP, as it is not possible to exhaustively + discover and test that each nonconformant intermediary does not skip + such non-HTTP framing and act incorrectly on the frame payload. + Thus, the defense adopted is to mask all data from the client to the + server, so that the remote script (attacker) does not have control + over how the data being sent appears on the wire and thus cannot + construct a message that could be misinterpreted by an intermediary + as an HTTP request. + + Clients MUST choose a new masking key for each frame, using an + algorithm that cannot be predicted by end applications that provide + data. For example, each masking could be drawn from a + cryptographically strong random number generator. If the same key is + used or a decipherable pattern exists for how the next key is chosen, + the attacker can send a message that, when masked, could appear to be + + + +Fette & Melnikov Standards Track [Page 51] + +RFC 6455 The WebSocket Protocol December 2011 + + + an HTTP request (by taking the message the attacker wishes to see on + the wire and masking it with the next masking key to be used, the + masking key will effectively unmask the data when the client applies + it). + + It is also necessary that once the transmission of a frame from a + client has begun, the payload (application-supplied data) of that + frame must not be capable of being modified by the application. + Otherwise, an attacker could send a long frame where the initial data + was a known value (such as all zeros), compute the masking key being + used upon receipt of the first part of the data, and then modify the + data that is yet to be sent in the frame to appear as an HTTP request + when masked. (This is essentially the same problem described in the + previous paragraph with using a known or predictable masking key.) + If additional data is to be sent or data to be sent is somehow + changed, that new or changed data must be sent in a new frame and + thus with a new masking key. In short, once transmission of a frame + begins, the contents must not be modifiable by the remote script + (application). + + The threat model being protected against is one in which the client + sends data that appears to be an HTTP request. As such, the channel + that needs to be masked is the data from the client to the server. + The data from the server to the client can be made to look like a + response, but to accomplish this request, the client must also be + able to forge a request. As such, it was not deemed necessary to + mask data in both directions (the data from the server to the client + is not masked). + + Despite the protection provided by masking, non-compliant HTTP + proxies will still be vulnerable to poisoning attacks of this type by + clients and servers that do not apply masking. + +10.4. Implementation-Specific Limits + + Implementations that have implementation- and/or platform-specific + limitations regarding the frame size or total message size after + reassembly from multiple frames MUST protect themselves against + exceeding those limits. (For example, a malicious endpoint can try + to exhaust its peer's memory or mount a denial-of-service attack by + sending either a single big frame (e.g., of size 2**60) or by sending + a long stream of small frames that are a part of a fragmented + message.) Such an implementation SHOULD impose a limit on frame + sizes and the total message size after reassembly from multiple + frames. + + + + + + +Fette & Melnikov Standards Track [Page 52] + +RFC 6455 The WebSocket Protocol December 2011 + + +10.5. WebSocket Client Authentication + + This protocol doesn't prescribe any particular way that servers can + authenticate clients during the WebSocket handshake. The WebSocket + server can use any client authentication mechanism available to a + generic HTTP server, such as cookies, HTTP authentication, or TLS + authentication. + +10.6. Connection Confidentiality and Integrity + + Connection confidentiality and integrity is provided by running the + WebSocket Protocol over TLS (wss URIs). WebSocket implementations + MUST support TLS and SHOULD employ it when communicating with their + peers. + + For connections using TLS, the amount of benefit provided by TLS + depends greatly on the strength of the algorithms negotiated during + the TLS handshake. For example, some TLS cipher mechanisms don't + provide connection confidentiality. To achieve reasonable levels of + protection, clients should use only Strong TLS algorithms. "Web + Security Context: User Interface Guidelines" + [W3C.REC-wsc-ui-20100812] discusses what constitutes Strong TLS + algorithms. [RFC5246] provides additional guidance in Appendix A.5 + and Appendix D.3. + +10.7. Handling of Invalid Data + + Incoming data MUST always be validated by both clients and servers. + If, at any time, an endpoint is faced with data that it does not + understand or that violates some criteria by which the endpoint + determines safety of input, or when the endpoint sees an opening + handshake that does not correspond to the values it is expecting + (e.g., incorrect path or origin in the client request), the endpoint + MAY drop the TCP connection. If the invalid data was received after + a successful WebSocket handshake, the endpoint SHOULD send a Close + frame with an appropriate status code (Section 7.4) before proceeding + to _Close the WebSocket Connection_. Use of a Close frame with an + appropriate status code can help in diagnosing the problem. If the + invalid data is sent during the WebSocket handshake, the server + SHOULD return an appropriate HTTP [RFC2616] status code. + + A common class of security problems arises when sending text data + using the wrong encoding. This protocol specifies that messages with + a Text data type (as opposed to Binary or other types) contain UTF-8- + encoded data. Although the length is still indicated and + applications implementing this protocol should use the length to + determine where the frame actually ends, sending data in an improper + + + + +Fette & Melnikov Standards Track [Page 53] + +RFC 6455 The WebSocket Protocol December 2011 + + + encoding may still break assumptions that applications built on top + of this protocol may make, leading to anything from misinterpretation + of data to loss of data or potential security bugs. + +10.8. Use of SHA-1 by the WebSocket Handshake + + The WebSocket handshake described in this document doesn't depend on + any security properties of SHA-1, such as collision resistance or + resistance to the second pre-image attack (as described in + [RFC4270]). + +11. IANA Considerations + +11.1. Registration of New URI Schemes + +11.1.1. Registration of "ws" Scheme + + A |ws| URI identifies a WebSocket server and resource name. + + URI scheme name + ws + + Status + Permanent + + URI scheme syntax + Using the ABNF [RFC5234] syntax and ABNF terminals from the URI + specification [RFC3986]: + + "ws:" "//" authority path-abempty [ "?" query ] + + The <path-abempty> and <query> [RFC3986] components form the resource + name sent to the server to identify the kind of service desired. + Other components have the meanings described in [RFC3986]. + + URI scheme semantics + The only operation for this scheme is to open a connection using + the WebSocket Protocol. + + Encoding considerations + Characters in the host component that are excluded by the syntax + defined above MUST be converted from Unicode to ASCII as specified + in [RFC3987] or its replacement. For the purposes of scheme-based + normalization, Internationalized Domain Name (IDN) forms of the + host component and their conversions to punycode are considered + equivalent (see Section 5.3.3 of [RFC3987]). + + + + + +Fette & Melnikov Standards Track [Page 54] + +RFC 6455 The WebSocket Protocol December 2011 + + + Characters in other components that are excluded by the syntax + defined above MUST be converted from Unicode to ASCII by first + encoding the characters as UTF-8 and then replacing the + corresponding bytes using their percent-encoded form as defined in + the URI [RFC3986] and Internationalized Resource Identifier (IRI) + [RFC3987] specifications. + + Applications/protocols that use this URI scheme name + WebSocket Protocol + + Interoperability considerations + Use of WebSocket requires use of HTTP version 1.1 or higher. + + Security considerations + See "Security Considerations" section. + + Contact + HYBI WG <hybi@ietf.org> + + Author/Change controller + IETF <iesg@ietf.org> + + References + RFC 6455 + +11.1.2. Registration of "wss" Scheme + + A |wss| URI identifies a WebSocket server and resource name and + indicates that traffic over that connection is to be protected via + TLS (including standard benefits of TLS such as data confidentiality + and integrity and endpoint authentication). + + URI scheme name + wss + + Status + Permanent + + URI scheme syntax + Using the ABNF [RFC5234] syntax and ABNF terminals from the URI + specification [RFC3986]: + + "wss:" "//" authority path-abempty [ "?" query ] + + The <path-abempty> and <query> components form the resource name sent + to the server to identify the kind of service desired. Other + components have the meanings described in [RFC3986]. + + + + +Fette & Melnikov Standards Track [Page 55] + +RFC 6455 The WebSocket Protocol December 2011 + + + URI scheme semantics + The only operation for this scheme is to open a connection using + the WebSocket Protocol, encrypted using TLS. + + Encoding considerations + Characters in the host component that are excluded by the syntax + defined above MUST be converted from Unicode to ASCII as specified + in [RFC3987] or its replacement. For the purposes of scheme-based + normalization IDN forms of the host component and their + conversions to punycode are considered equivalent (see Section + 5.3.3 of [RFC3987]). + + Characters in other components that are excluded by the syntax + defined above MUST be converted from Unicode to ASCII by first + encoding the characters as UTF-8 and then replacing the + corresponding bytes using their percent-encoded form as defined in + the URI [RFC3986] and IRI [RFC3987] specifications. + + Applications/protocols that use this URI scheme name + WebSocket Protocol over TLS + + Interoperability considerations + Use of WebSocket requires use of HTTP version 1.1 or higher. + + Security considerations + See "Security Considerations" section. + + Contact + HYBI WG <hybi@ietf.org> + + Author/Change controller + IETF <iesg@ietf.org> + + References + RFC 6455 + +11.2. Registration of the "WebSocket" HTTP Upgrade Keyword + + This section defines a keyword registered in the HTTP Upgrade Tokens + Registry as per RFC 2817 [RFC2817]. + + Name of token + WebSocket + + Author/Change controller + IETF <iesg@ietf.org> + + + + + +Fette & Melnikov Standards Track [Page 56] + +RFC 6455 The WebSocket Protocol December 2011 + + + Contact + HYBI <hybi@ietf.org> + + References + RFC 6455 + +11.3. Registration of New HTTP Header Fields + +11.3.1. Sec-WebSocket-Key + + This section describes a header field registered in the Permanent + Message Header Field Names registry [RFC3864]. + + Header field name + Sec-WebSocket-Key + + Applicable protocol + http + + Status + standard + + Author/Change controller + IETF + + Specification document(s) + RFC 6455 + + Related information + This header field is only used for WebSocket opening handshake. + + The |Sec-WebSocket-Key| header field is used in the WebSocket opening + handshake. It is sent from the client to the server to provide part + of the information used by the server to prove that it received a + valid WebSocket opening handshake. This helps ensure that the server + does not accept connections from non-WebSocket clients (e.g., HTTP + clients) that are being abused to send data to unsuspecting WebSocket + servers. + + The |Sec-WebSocket-Key| header field MUST NOT appear more than once + in an HTTP request. + + + + + + + + + + +Fette & Melnikov Standards Track [Page 57] + +RFC 6455 The WebSocket Protocol December 2011 + + +11.3.2. Sec-WebSocket-Extensions + + This section describes a header field for registration in the + Permanent Message Header Field Names registry [RFC3864]. + + Header field name + Sec-WebSocket-Extensions + + Applicable protocol + http + + Status + standard + + Author/Change controller + IETF + + Specification document(s) + RFC 6455 + + Related information + This header field is only used for WebSocket opening handshake. + + The |Sec-WebSocket-Extensions| header field is used in the WebSocket + opening handshake. It is initially sent from the client to the + server, and then subsequently sent from the server to the client, to + agree on a set of protocol-level extensions to use for the duration + of the connection. + + The |Sec-WebSocket-Extensions| header field MAY appear multiple times + in an HTTP request (which is logically the same as a single + |Sec-WebSocket-Extensions| header field that contains all values. + However, the |Sec-WebSocket-Extensions| header field MUST NOT appear + more than once in an HTTP response. + +11.3.3. Sec-WebSocket-Accept + + This section describes a header field registered in the Permanent + Message Header Field Names registry [RFC3864]. + + Header field name + Sec-WebSocket-Accept + + Applicable protocol + http + + Status + standard + + + +Fette & Melnikov Standards Track [Page 58] + +RFC 6455 The WebSocket Protocol December 2011 + + + Author/Change controller + IETF + + Specification document(s) + RFC 6455 + + Related information + This header field is only used for the WebSocket opening + handshake. + + The |Sec-WebSocket-Accept| header field is used in the WebSocket + opening handshake. It is sent from the server to the client to + confirm that the server is willing to initiate the WebSocket + connection. + + The |Sec-WebSocket-Accept| header MUST NOT appear more than once in + an HTTP response. + +11.3.4. Sec-WebSocket-Protocol + + This section describes a header field registered in the Permanent + Message Header Field Names registry [RFC3864]. + + Header field name + Sec-WebSocket-Protocol + + Applicable protocol + http + + Status + standard + + Author/Change controller + IETF + + Specification document(s) + RFC 6455 + + Related information + This header field is only used for the WebSocket opening + handshake. + + The |Sec-WebSocket-Protocol| header field is used in the WebSocket + opening handshake. It is sent from the client to the server and back + from the server to the client to confirm the subprotocol of the + connection. This enables scripts to both select a subprotocol and be + sure that the server agreed to serve that subprotocol. + + + + +Fette & Melnikov Standards Track [Page 59] + +RFC 6455 The WebSocket Protocol December 2011 + + + The |Sec-WebSocket-Protocol| header field MAY appear multiple times + in an HTTP request (which is logically the same as a single + |Sec-WebSocket-Protocol| header field that contains all values). + However, the |Sec-WebSocket-Protocol| header field MUST NOT appear + more than once in an HTTP response. + +11.3.5. Sec-WebSocket-Version + + This section describes a header field registered in the Permanent + Message Header Field Names registry [RFC3864]. + + Header field name + Sec-WebSocket-Version + + Applicable protocol + http + + Status + standard + + Author/Change controller + IETF + + Specification document(s) + RFC 6455 + + Related information + This header field is only used for the WebSocket opening + handshake. + + The |Sec-WebSocket-Version| header field is used in the WebSocket + opening handshake. It is sent from the client to the server to + indicate the protocol version of the connection. This enables + servers to correctly interpret the opening handshake and subsequent + data being sent from the data, and close the connection if the server + cannot interpret that data in a safe manner. The |Sec-WebSocket- + Version| header field is also sent from the server to the client on + WebSocket handshake error, when the version received from the client + does not match a version understood by the server. In such a case, + the header field includes the protocol version(s) supported by the + server. + + Note that there is no expectation that higher version numbers are + necessarily backward compatible with lower version numbers. + + + + + + + +Fette & Melnikov Standards Track [Page 60] + +RFC 6455 The WebSocket Protocol December 2011 + + + The |Sec-WebSocket-Version| header field MAY appear multiple times in + an HTTP response (which is logically the same as a single + |Sec-WebSocket-Version| header field that contains all values). + However, the |Sec-WebSocket-Version| header field MUST NOT appear + more than once in an HTTP request. + +11.4. WebSocket Extension Name Registry + + This specification creates a new IANA registry for WebSocket + Extension names to be used with the WebSocket Protocol in accordance + with the principles set out in RFC 5226 [RFC5226]. + + As part of this registry, IANA maintains the following information: + + Extension Identifier + The identifier of the extension, as will be used in the + |Sec-WebSocket-Extensions| header field registered in + Section 11.3.2 of this specification. The value must conform to + the requirements for an extension-token as defined in Section 9.1 + of this specification. + + Extension Common Name + The name of the extension, as the extension is generally referred + to. + + Extension Definition + A reference to the document in which the extension being used with + the WebSocket Protocol is defined. + + Known Incompatible Extensions + A list of extension identifiers with which this extension is known + to be incompatible. + + WebSocket Extension names are to be subject to the "First Come First + Served" IANA registration policy [RFC5226]. + + There are no initial values in this registry. + +11.5. WebSocket Subprotocol Name Registry + + This specification creates a new IANA registry for WebSocket + Subprotocol names to be used with the WebSocket Protocol in + accordance with the principles set out in RFC 5226 [RFC5226]. + + + + + + + + +Fette & Melnikov Standards Track [Page 61] + +RFC 6455 The WebSocket Protocol December 2011 + + + As part of this registry, IANA maintains the following information: + + Subprotocol Identifier + The identifier of the subprotocol, as will be used in the + |Sec-WebSocket-Protocol| header field registered in Section 11.3.4 + of this specification. The value must conform to the requirements + given in item 10 of Section 4.1 of this specification -- namely, + the value must be a token as defined by RFC 2616 [RFC2616]. + + Subprotocol Common Name + The name of the subprotocol, as the subprotocol is generally + referred to. + + Subprotocol Definition + A reference to the document in which the subprotocol being used + with the WebSocket Protocol is defined. + + WebSocket Subprotocol names are to be subject to the "First Come + First Served" IANA registration policy [RFC5226]. + +11.6. WebSocket Version Number Registry + + This specification creates a new IANA registry for WebSocket Version + Numbers to be used with the WebSocket Protocol in accordance with the + principles set out in RFC 5226 [RFC5226]. + + As part of this registry, IANA maintains the following information: + + Version Number + The version number to be used in the |Sec-WebSocket-Version| is + specified in Section 4.1 of this specification. The value must be + a non-negative integer in the range between 0 and 255 (inclusive). + + Reference + The RFC requesting a new version number or a draft name with + version number (see below). + + Status + Either "Interim" or "Standard". See below for description. + + A version number is designated as either "Interim" or "Standard". + + A "Standard" version number is documented in an RFC and used to + identify a major, stable version of the WebSocket protocol, such as + the version defined by this RFC. "Standard" version numbers are + subject to the "IETF Review" IANA registration policy [RFC5226]. + + + + + +Fette & Melnikov Standards Track [Page 62] + +RFC 6455 The WebSocket Protocol December 2011 + + + An "Interim" version number is documented in an Internet-Draft and + used to help implementors identify and interoperate with deployed + versions of the WebSocket protocol, such as versions developed before + the publication of this RFC. "Interim" version numbers are subject + to the "Expert Review" IANA registration policy [RFC5226], with the + chairs of the HYBI Working Group (or, if the working group closes, + the Area Directors for the IETF Applications Area) being the initial + Designated Experts. + + IANA has added initial values to the registry as follows. + + +--------+-----------------------------------------+----------+ + |Version | Reference | Status | + | Number | | | + +--------+-----------------------------------------+----------+ + | 0 + draft-ietf-hybi-thewebsocketprotocol-00 | Interim | + +--------+-----------------------------------------+----------+ + | 1 + draft-ietf-hybi-thewebsocketprotocol-01 | Interim | + +--------+-----------------------------------------+----------+ + | 2 + draft-ietf-hybi-thewebsocketprotocol-02 | Interim | + +--------+-----------------------------------------+----------+ + | 3 + draft-ietf-hybi-thewebsocketprotocol-03 | Interim | + +--------+-----------------------------------------+----------+ + | 4 + draft-ietf-hybi-thewebsocketprotocol-04 | Interim | + +--------+-----------------------------------------+----------+ + | 5 + draft-ietf-hybi-thewebsocketprotocol-05 | Interim | + +--------+-----------------------------------------+----------+ + | 6 + draft-ietf-hybi-thewebsocketprotocol-06 | Interim | + +--------+-----------------------------------------+----------+ + | 7 + draft-ietf-hybi-thewebsocketprotocol-07 | Interim | + +--------+-----------------------------------------+----------+ + | 8 + draft-ietf-hybi-thewebsocketprotocol-08 | Interim | + +--------+-----------------------------------------+----------+ + | 9 + Reserved | | + +--------+-----------------------------------------+----------+ + | 10 + Reserved | | + +--------+-----------------------------------------+----------+ + | 11 + Reserved | | + +--------+-----------------------------------------+----------+ + | 12 + Reserved | | + +--------+-----------------------------------------+----------+ + | 13 + RFC 6455 | Standard | + +--------+-----------------------------------------+----------+ + + + + + + + + +Fette & Melnikov Standards Track [Page 63] + +RFC 6455 The WebSocket Protocol December 2011 + + +11.7. WebSocket Close Code Number Registry + + This specification creates a new IANA registry for WebSocket + Connection Close Code Numbers in accordance with the principles set + out in RFC 5226 [RFC5226]. + + As part of this registry, IANA maintains the following information: + + Status Code + The Status Code denotes a reason for a WebSocket connection + closure as per Section 7.4 of this document. The status code is + an integer number between 1000 and 4999 (inclusive). + + Meaning + The meaning of the status code. Each status code has to have a + unique meaning. + + Contact + A contact for the entity reserving the status code. + + Reference + The stable document requesting the status codes and defining their + meaning. This is required for status codes in the range 1000-2999 + and recommended for status codes in the range 3000-3999. + + WebSocket Close Code Numbers are subject to different registration + requirements depending on their range. Requests for status codes for + use by this protocol and its subsequent versions or extensions are + subject to any one of the "Standards Action", "Specification + Required" (which implies "Designated Expert"), or "IESG Review" IANA + registration policies and should be granted in the range 1000-2999. + Requests for status codes for use by libraries, frameworks, and + applications are subject to the "First Come First Served" IANA + registration policy and should be granted in the range 3000-3999. + The range of status codes from 4000-4999 is designated for Private + Use. Requests should indicate whether they are requesting status + codes for use by the WebSocket Protocol (or a future version of the + protocol), by extensions, or by libraries/frameworks/applications. + + + + + + + + + + + + + +Fette & Melnikov Standards Track [Page 64] + +RFC 6455 The WebSocket Protocol December 2011 + + + IANA has added initial values to the registry as follows. + + |Status Code | Meaning | Contact | Reference | + -+------------+-----------------+---------------+-----------| + | 1000 | Normal Closure | hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1001 | Going Away | hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1002 | Protocol error | hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1003 | Unsupported Data| hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1004 | ---Reserved---- | hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1005 | No Status Rcvd | hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1006 | Abnormal Closure| hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1007 | Invalid frame | hybi@ietf.org | RFC 6455 | + | | payload data | | | + -+------------+-----------------+---------------+-----------| + | 1008 | Policy Violation| hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1009 | Message Too Big | hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1010 | Mandatory Ext. | hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + | 1011 | Internal Server | hybi@ietf.org | RFC 6455 | + | | Error | | | + -+------------+-----------------+---------------+-----------| + | 1015 | TLS handshake | hybi@ietf.org | RFC 6455 | + -+------------+-----------------+---------------+-----------| + +11.8. WebSocket Opcode Registry + + This specification creates a new IANA registry for WebSocket Opcodes + in accordance with the principles set out in RFC 5226 [RFC5226]. + + As part of this registry, IANA maintains the following information: + + Opcode + The opcode denotes the frame type of the WebSocket frame, as + defined in Section 5.2. The opcode is an integer number between 0 + and 15, inclusive. + + Meaning + The meaning of the opcode value. + + + + +Fette & Melnikov Standards Track [Page 65] + +RFC 6455 The WebSocket Protocol December 2011 + + + Reference + The specification requesting the opcode. + + WebSocket Opcode numbers are subject to the "Standards Action" IANA + registration policy [RFC5226]. + + IANA has added initial values to the registry as follows. + + |Opcode | Meaning | Reference | + -+--------+-------------------------------------+-----------| + | 0 | Continuation Frame | RFC 6455 | + -+--------+-------------------------------------+-----------| + | 1 | Text Frame | RFC 6455 | + -+--------+-------------------------------------+-----------| + | 2 | Binary Frame | RFC 6455 | + -+--------+-------------------------------------+-----------| + | 8 | Connection Close Frame | RFC 6455 | + -+--------+-------------------------------------+-----------| + | 9 | Ping Frame | RFC 6455 | + -+--------+-------------------------------------+-----------| + | 10 | Pong Frame | RFC 6455 | + -+--------+-------------------------------------+-----------| + +11.9. WebSocket Framing Header Bits Registry + + This specification creates a new IANA registry for WebSocket Framing + Header Bits in accordance with the principles set out in RFC 5226 + [RFC5226]. This registry controls assignment of the bits marked + RSV1, RSV2, and RSV3 in Section 5.2. + + These bits are reserved for future versions or extensions of this + specification. + + WebSocket Framing Header Bits assignments are subject to the + "Standards Action" IANA registration policy [RFC5226]. + +12. Using the WebSocket Protocol from Other Specifications + + The WebSocket Protocol is intended to be used by another + specification to provide a generic mechanism for dynamic author- + defined content, e.g., in a specification defining a scripted API. + + Such a specification first needs to _Establish a WebSocket + Connection_, providing that algorithm with: + + o The destination, consisting of a /host/ and a /port/. + + + + + +Fette & Melnikov Standards Track [Page 66] + +RFC 6455 The WebSocket Protocol December 2011 + + + o A /resource name/, which allows for multiple services to be + identified at one host and port. + + o A /secure/ flag, which is true if the connection is to be + encrypted and false otherwise. + + o An ASCII serialization of an origin [RFC6454] that is being made + responsible for the connection. + + o Optionally, a string identifying a protocol that is to be layered + over the WebSocket connection. + + The /host/, /port/, /resource name/, and /secure/ flag are usually + obtained from a URI using the steps to parse a WebSocket URI's + components. These steps fail if the URI does not specify a + WebSocket. + + If at any time the connection is to be closed, then the specification + needs to use the _Close the WebSocket Connection_ algorithm + (Section 7.1.1). + + Section 7.1.4 defines when _The WebSocket Connection is Closed_. + + While a connection is open, the specification will need to handle the + cases when _A WebSocket Message Has Been Received_ (Section 6.2). + + To send some data /data/ to an open connection, the specification + needs to _Send a WebSocket Message_ (Section 6.1). + +13. Acknowledgements + + Special thanks are due to Ian Hickson, who was the original author + and editor of this protocol. The initial design of this + specification benefitted from the participation of many people in the + WHATWG and WHATWG mailing list. Contributions to that specification + are not tracked by section, but a list of all who contributed to that + specification is given in the WHATWG HTML specification at + http://whatwg.org/html5. + + Special thanks also to John Tamplin for providing a significant + amount of text for the "Data Framing" section of this specification. + + Special thanks also to Adam Barth for providing a significant amount + of text and background research for the "Data Masking" section of + this specification. + + + + + + +Fette & Melnikov Standards Track [Page 67] + +RFC 6455 The WebSocket Protocol December 2011 + + + Special thanks to Lisa Dusseault for the Apps Area review (and for + helping to start this work), Richard Barnes for the Gen-Art review, + and Magnus Westerlund for the Transport Area Review. Special thanks + to HYBI WG past and present WG chairs who tirelessly worked behind + the scene to move this work toward completion: Joe Hildebrand, + Salvatore Loreto, and Gabriel Montenegro. And last but not least, + special thank you to the responsible Area Director Peter Saint-Andre. + + Thank you to the following people who participated in discussions on + the HYBI WG mailing list and contributed ideas and/or provided + detailed reviews (the list is likely to be incomplete): Greg Wilkins, + John Tamplin, Willy Tarreau, Maciej Stachowiak, Jamie Lokier, Scott + Ferguson, Bjoern Hoehrmann, Julian Reschke, Dave Cridland, Andy + Green, Eric Rescorla, Inaki Baz Castillo, Martin Thomson, Roberto + Peon, Patrick McManus, Zhong Yu, Bruce Atherton, Takeshi Yoshino, + Martin J. Duerst, James Graham, Simon Pieters, Roy T. Fielding, + Mykyta Yevstifeyev, Len Holgate, Paul Colomiets, Piotr Kulaga, Brian + Raymor, Jan Koehler, Joonas Lehtolahti, Sylvain Hellegouarch, Stephen + Farrell, Sean Turner, Pete Resnick, Peter Thorson, Joe Mason, John + Fallows, and Alexander Philippou. Note that people listed above + didn't necessarily endorse the end result of this work. + +14. References + +14.1. Normative References + + [ANSI.X3-4.1986] + American National Standards Institute, "Coded Character + Set - 7-bit American Standard Code for Information + Interchange", ANSI X3.4, 1986. + + [FIPS.180-3] + National Institute of Standards and Technology, "Secure + Hash Standard", FIPS PUB 180-3, October 2008, + <http://csrc.nist.gov/publications/fips/fips180-3/ + fips180-3_final.pdf>. + + [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and + L. Jones, "SOCKS Protocol Version 5", RFC 1928, + March 1996. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., + Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext + Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. + + + + +Fette & Melnikov Standards Track [Page 68] + +RFC 6455 The WebSocket Protocol December 2011 + + + [RFC2817] Khare, R. and S. Lawrence, "Upgrading to TLS Within + HTTP/1.1", RFC 2817, May 2000. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. + + [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO + 10646", STD 63, RFC 3629, November 2003. + + [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration + Procedures for Message Header Fields", BCP 90, RFC 3864, + September 2004. + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, January 2005. + + [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource + Identifiers (IRIs)", RFC 3987, January 2005. + + [RFC4086] Eastlake, D., Schiller, J., and S. Crocker, "Randomness + Requirements for Security", BCP 106, RFC 4086, June 2005. + + [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data + Encodings", RFC 4648, October 2006. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax + Specifications: ABNF", STD 68, RFC 5234, January 2008. + + [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security + (TLS) Protocol Version 1.2", RFC 5246, August 2008. + + [RFC6066] Eastlake, D., "Transport Layer Security (TLS) Extensions: + Extension Definitions", RFC 6066, January 2011. + + [RFC6454] Barth, A., "The Web Origin Concept", RFC 6454, + December 2011. + +14.2. Informative References + + [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally + Unique IDentifier (UUID) URN Namespace", RFC 4122, + July 2005. + + + + + +Fette & Melnikov Standards Track [Page 69] + +RFC 6455 The WebSocket Protocol December 2011 + + + [RFC4270] Hoffman, P. and B. Schneier, "Attacks on Cryptographic + Hashes in Internet Protocols", RFC 4270, November 2005. + + [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, + October 2008. + + [RFC6202] Loreto, S., Saint-Andre, P., Salsano, S., and G. Wilkins, + "Known Issues and Best Practices for the Use of Long + Polling and Streaming in Bidirectional HTTP", RFC 6202, + April 2011. + + [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, + April 2011. + + [TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. + Jackson, "Talking to Yourself for Fun and Profit", 2010, + <http://w2spconf.com/2011/papers/websocket.pdf>. + + [W3C.REC-wsc-ui-20100812] + Roessler, T. and A. Saldhana, "Web Security Context: User + Interface Guidelines", World Wide Web Consortium + Recommendation REC-wsc-ui-20100812, August 2010, + <http://www.w3.org/TR/2010/REC-wsc-ui-20100812/>. + + Latest version available at + <http://www.w3.org/TR/wsc-ui/>. + + [WSAPI] Hickson, I., "The WebSocket API", W3C Working Draft WD- + websockets-20110929, September 2011, + <http://www.w3.org/TR/2011/WD-websockets-20110929/>. + + Latest version available at + <http://www.w3.org/TR/websockets/>. + + [XMLHttpRequest] + van Kesteren, A., Ed., "XMLHttpRequest", W3C Candidate + Recommendation CR-XMLHttpRequest-20100803, August 2010, + <http://www.w3.org/TR/2010/CR-XMLHttpRequest-20100803/>. + + Latest version available at + <http://www.w3.org/TR/XMLHttpRequest/>. + + + + + + + + + + +Fette & Melnikov Standards Track [Page 70] + +RFC 6455 The WebSocket Protocol December 2011 + + +Authors' Addresses + + Ian Fette + Google, Inc. + + EMail: ifette+ietf@google.com + URI: http://www.ianfette.com/ + + + Alexey Melnikov + Isode Ltd. + 5 Castle Business Village + 36 Station Road + Hampton, Middlesex TW12 2BX + UK + + EMail: Alexey.Melnikov@isode.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Fette & Melnikov Standards Track [Page 71] + |