Internet Engineering Task Force (IETF)
`Request for Comments: 6455
`Category: Standards Track
`ISSN: 2070-1721
`
`I. Fette
`Google, Inc.
`A. Melnikov
`Isode Ltd.
`December 2011
`
`Abstract
`
`The WebSocket Protocol
`
` 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 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]
`
`Genius Sports Ex. 1029
`p. 13
`
`

`

`RFC 6455 The WebSocket Protocol December 2011
`
`3. WebSocket UR