# checklist-6455-4.1

tool: generate_checklist
args: {"rfc":6455,"sections":["4.1"],"role":"client"}

--- markdown ---
# RFC 6455 Implementation Checklist

**The WebSocket Protocol**

Role: client

Generated: <generatedAt>

## Mandatory Requirements (MUST / REQUIRED / SHALL)

- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** If any of the components are invalid, the client MUST _Fail the WebSocket Connection_ and abort these steps. (§4.1)
- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** There MUST be no more than one connection in a CONNECTING state. (§4.1)
- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** 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). (§4.1)
- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** 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]. (§4.1)
- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** 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]. (§4.1)
- [ ] **MUST** Clients MUST use the Server Name Indication extension in the TLS handshake [RFC6066]. (§4.1)
- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** The handshake MUST be a valid HTTP request as specified by [RFC2616]. (§4.1)
- [ ] **MUST** The method of the request MUST be GET, and the HTTP version MUST be at least 1.1. (§4.1)
- [ ] **MUST** 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.1)
- [ ] **MUST** The request MUST contain a |Host| header field whose value contains /host/ plus optionally ":" followed by /port/ (when not using the default port). (§4.1)
- [ ] **MUST** The request MUST contain an |Upgrade| header field whose value MUST include the "websocket" keyword. (§4.1)
- [ ] **MUST** The request MUST contain a |Connection| header field whose value MUST include the "Upgrade" token. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Sec-WebSocket-Key|. (§4.1)
- [ ] **MUST** 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]). (§4.1)
- [ ] **MUST** The nonce MUST be selected randomly for each connection. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Origin| [RFC6454] if the request is coming from a browser client. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Sec-WebSocket-Version|. (§4.1)
- [ ] **MUST** The request MUST include a header field with the name |Sec-WebSocket-Version|. The value of this header field MUST be 13. (§4.1)
- [ ] **MUST** 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. (§4.1)
- [ ] **MUST** Once the client's opening handshake has been sent, the client MUST wait for a response from the server before sending any further data. (§4.1)
- [ ] **MUST** The client MUST validate the server's response as follows: (§4.1)
- [ ] **MUST** 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_. (§4.1)
- [ ] **MUST** 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.1)
- [ ] **MUST** 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_. (§4.1)
- [ ] **MUST** 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_. (§4.1)
- [ ] **MUST** 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_. (§4.1)
- [ ] **MUST** 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_. (§4.1)

## Recommended Requirements (SHOULD / RECOMMENDED)

- [ ] **SHOULD** 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). (§4.1)
- [ ] **SHOULD** _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/. (§4.1)
- [ ] **SHOULD** 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/. (§4.1)

## Optional Requirements (MAY / OPTIONAL)

- [ ] **MAY** 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. (§4.1)
- [ ] **MAY** 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. (§4.1)
- [ ] **MAY** The request MAY include a header field with the name |Sec-WebSocket-Protocol|. (§4.1)
- [ ] **MAY** The request MAY include a header field with the name |Sec-WebSocket-Extensions|. (§4.1)
- [ ] **MAY** 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. (§4.1)

--- json ---
{
  "rfc": 6455,
  "role": "client",
  "stats": {
    "must": 35,
    "should": 3,
    "may": 5,
    "total": 43
  },
  "_source": "text",
  "_sourceNote": "Warning: Parsed from text format. Checklist accuracy may be limited."
}