rfcxml-mcp

> 🤖 This file was auto-generated by rfcxml-mcp's `generate_checklist` tool. > > Generated: 2026-01-18 > Tool: @shuji-bonji/rfcxml-mcp > Source: Text fallback (medium accuracy) --- # RFC 6455 実装チェックリスト **Internet Engineering Task Force (IETF) I. Fette** 生成日時: 2026-01-18T16:38:42.445Z ## 必須要件 (MUST / REQUIRED / SHALL) - [ ] 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]. (2) - [ ] 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]. (2) - [ ] 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]. (2) - [ ] 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]. (2) - [ ] 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]. (2) - [ ] 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. (2) - [ ] Fragment identifiers are meaningless in the context of WebSocket URIs and MUST NOT be used on these URIs. (3) - [ ] As with any URI scheme, the character "#", when not indicating the start of a fragment, MUST be escaped as %23. (3) - [ ] 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) - [ ] (/host/, /port/, /resource name/, and /secure/ flag) MUST be valid according to the specification of WebSocket URIs specified in Section 3. (1) - [ ] If any of the components are invalid, the client MUST _Fail the WebSocket Connection_ and abort these steps. (1) - [ ] 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. (2) - [ ] There MUST be no more than one connection in a CONNECTING state. (2) - [ ] 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. (2) - [ ] 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. (2) - [ ] 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. (3) - [ ] connection failed or because any proxy used returned an error, then the client MUST _Fail the WebSocket Connection_ and abort the connection attempt. (4) - [ ] 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. (5) - [ ] Otherwise, all further communication on this channel MUST run through the encrypted tunnel [RFC5246]. (5) - [ ] Clients MUST use the Server Name Indication extension in the TLS handshake [RFC6066]. (5) - [ ] 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. (5) - [ ] MUST include the "websocket" keyword. (5) - [ ] MUST include the "Upgrade" token. (6) - [ ] 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]). (7) - [ ] The nonce MUST be selected randomly for each connection. (7) - [ ] The value of this header field MUST be 13. (9) - [ ] 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. (10) - [ ] 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. (10) - [ ] Once the client's opening handshake has been sent, the client MUST wait for a response from the server before sending any further data. (12) - [ ] The client MUST validate the server's response as follows: (12) - [ ] header field contains a value that is not an ASCII case- insensitive match for the value "websocket", the client MUST _Fail the WebSocket Connection_. (2) - [ ] |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_. (3) - [ ] 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) - [ ] 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_. (5) - [ ] 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_. (6) - [ ] 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_. (6) - [ ] 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). (4.2.1) - [ ] 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. (4.2.2) - [ ] 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]. (1) - [ ] If the server does not wish to accept this connection, it MUST return an appropriate HTTP error code (e. (4) - [ ] 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. (4) - [ ] 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. (4) - [ ] 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). (4) - [ ] 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). (4) - [ ] 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. (4) - [ ] Extensions not listed by the client MUST NOT be listed. (4) - [ ] 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. (4.3) - [ ] 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. (4.4) - [ ] 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. (5.1) - [ ] (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. (5.1) - [ ] A server MUST NOT mask any frames that it sends to the client. (5.1) - [ ] A client MUST close a connection if it detects a masked frame. (5.1) - [ ] MUST be 0 unless an extension is negotiated that defines meanings for non-zero values. (0) - [ ] 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_. (0) - [ ] If an unknown opcode is received, the receiving endpoint MUST _Fail the WebSocket Connection_. (0) - [ ] If 127, the following 8 bytes interpreted as a 64-bit unsigned integer (the most significant bit MUST be 0) are the payload length. (0) - [ ] 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. (0) - [ ] 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. (0) - [ ] 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. (0) - [ ] frame-rsv1 = %x0 / %x1 ; 1 bit in length, MUST be 0 unless ; negotiated otherwise (0) - [ ] frame-rsv2 = %x0 / %x1 ; 1 bit in length, MUST be 0 unless ; negotiated otherwise (0) - [ ] frame-rsv3 = %x0 / %x1 ; 1 bit in length, MUST be 0 unless ; negotiated otherwise (0) - [ ] A masked frame MUST have the field frame-masked set to 1, as defined in Section 5. (5.3) - [ ] When preparing a masked frame, the client MUST pick a fresh masking key from the set of allowed 32-bit values. (5.3) - [ ] 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. (5.3) - [ ] 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. (5.3) - [ ] Control frames themselves MUST NOT be fragmented. (5.4) - [ ] o Message fragments MUST be delivered to the recipient in the order sent by the sender. (5.4) - [ ] 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. (5.4) - [ ] o An endpoint MUST be capable of handling control frames in the middle of a fragmented message. (5.4) - [ ] o Clients and servers MUST support receiving both fragmented and unfragmented messages. (5.4) - [ ] o As control frames cannot be fragmented, an intermediary MUST NOT attempt to change the fragmentation of a control frame. (5.4) - [ ] 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. (5.4) - [ ] 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. (5.4) - [ ] 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. (5.4) - [ ] 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. (5.4) - [ ] All control frames MUST have a payload length of 125 bytes or less and MUST NOT be fragmented. (5.5) - [ ] All control frames MUST have a payload length of 125 bytes or less and MUST NOT be fragmented. (5.5) - [ ] 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. (5.5.1) - [ ] As the data is not guaranteed to be human readable, clients MUST NOT show it to end users. (5.5.1) - [ ] The application MUST NOT send any more data frames after sending a Close frame. (5.5.1) - [ ] If an endpoint receives a Close frame and did not previously send a Close frame, the endpoint MUST send a Close frame in response. (5.5.1) - [ ] After both sending and receiving a Close message, an endpoint considers the WebSocket connection closed and MUST close the underlying TCP connection. (5.5.1) - [ ] 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. (5.5.1) - [ ] Upon receipt of a Ping frame, an endpoint MUST send a Pong frame in response, unless it already received a Close frame. (5.5.2) - [ ] Note that a particular text frame might include a partial UTF-8 sequence; however, the whole message MUST contain valid UTF-8. (5.6) - [ ] The endpoints of a connection MUST negotiate the use of any extensions during the opening handshake. (5.8) - [ ] To _Send a WebSocket Message_ comprising of /data/ over a WebSocket connection, an endpoint MUST perform the following steps. (6.1) - [ ] 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. (1) - [ ] MUST be set to the appropriate value from Section 5. (3) - [ ] MUST be set to 1 as defined in Section 5. (4) - [ ] Incoming data MUST be parsed as WebSocket frames as defined in Section 5. (6.2) - [ ] If a control frame (Section 5.5) is received, the frame MUST be handled as defined by Section 5. (6.2) - [ ] 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. (6.2) - [ ] Subsequent data frames MUST be interpreted as belonging to a new WebSocket message. (6.2) - [ ] A server MUST remove masking for data frames received from a client as described in Section 5. (6.2) - [ ] 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. (7.1.2) - [ ] 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. (7.1.7) - [ ] Similarly, to do so, the server MUST _Close the WebSocket Connection_, and SHOULD log the problem. (7.1.7) - [ ] 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_. (7.1.7) - [ ] To do so, the client MUST _Fail the WebSocket Connection_ as defined in Section 7. (7.2.1) - [ ] If at any point the underlying transport layer connection is unexpectedly lost, the client MUST _Fail the WebSocket Connection_. (7.2.1) - [ ] To do so, the server MUST simply _Close the WebSocket Connection_ (Section 7. (7.2.2) - [ ] 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_. (8.1) - [ ] A server MUST NOT respond with any extension not requested by the client. (9) - [ ] 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) - [ ] 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_. (9.1) - [ ] 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. (9.1) - [ ] Any extension-token used MUST be a registered token (see Section 11. (9.1) - [ ] The parameters supplied with any given extension MUST be defined for that extension. (9.1) - [ ] 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. (9.1) - [ ] Clients MUST choose a new masking key for each frame, using an algorithm that cannot be predicted by end applications that provide data. (10.3) - [ ] 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. (10.4) - [ ] WebSocket implementations MUST support TLS and SHOULD employ it when communicating with their peers. (10.6) - [ ] Incoming data MUST always be validated by both clients and servers. (10.7) - [ ] 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. (11.1.1) - [ ] 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. (11.1.1) - [ ] 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. (11.1.2) - [ ] 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. (5.3.3) - [ ] The |Sec-WebSocket-Key| header field MUST NOT appear more than once in an HTTP request. (11.3.1) - [ ] However, the |Sec-WebSocket-Extensions| header field MUST NOT appear more than once in an HTTP response. (11.3.2) - [ ] The |Sec-WebSocket-Accept| header MUST NOT appear more than once in an HTTP response. (11.3.3) - [ ] However, the |Sec-WebSocket-Protocol| header field MUST NOT appear more than once in an HTTP response. (11.3.4) - [ ] However, the |Sec-WebSocket-Version| header field MUST NOT appear more than once in an HTTP request. (11.3.5) ## 推奨要件 (SHOULD / RECOMMENDED) - [ ] 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]. (2) - [ ] 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]. (2) - [ ] 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]. (2) - [ ] 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. (2) - [ ] 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. (2) - [ ] 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/. (3) - [ ] 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/. (3) - [ ] A connection attempt lacking this header field SHOULD NOT be interpreted as coming from a browser client. (7) - [ ] (When sending a Close frame in response, the endpoint typically echos the status code it received.) It SHOULD do so as soon as practical. (5.5.1) - [ ] 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. (5.5.1) - [ ] It SHOULD respond with Pong frame as soon as is practical. (5.5.2) - [ ] 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. (7.1.1) - [ ] 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). (7.1.1) - [ ] 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. (7.1.1) - [ ] 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. (7.1.1) - [ ] Once an endpoint has both sent and received a Close control frame, that endpoint SHOULD _Close the WebSocket Connection_ as defined in Section 7. (7.1.2) - [ ] Similarly, to do so, the server MUST _Close the WebSocket Connection_, and SHOULD log the problem. (7.1.7) - [ ] 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. (7.1.7) - [ ] 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.1.7) - [ ] 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.1) - [ ] To prevent this, clients SHOULD use some form of backoff when trying to reconnect after abnormal closures as described in this section. (7.2.3) - [ ] The first reconnect attempt SHOULD be delayed by a random amount of time. (7.2.3) - [ ] 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. (7.2.3) - [ ] Clients SHOULD NOT close the WebSocket connection arbitrarily. (7.3) - [ ] are needed SHOULD appear in the /reason/ part of the Close frame. (1010) - [ ] 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. (10.2) - [ ] 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. (10.2) - [ ] (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. (10.4) - [ ] WebSocket implementations MUST support TLS and SHOULD employ it when communicating with their peers. (10.6) - [ ] 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. (10.7) - [ ] If the invalid data is sent during the WebSocket handshake, the server SHOULD return an appropriate HTTP [RFC2616] status code. (10.7) ## 任意要件 (MAY / OPTIONAL) - [ ] 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]. (2) - [ ] 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]. (2) - [ ] 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. (2) - [ ] Conformance requirements phrased as algorithms or specific steps MAY be implemented in any manner, so long as the end result is equivalent. (2) - [ ] When an implementation is required to _send_ data as part of the WebSocket Protocol, the implementation MAY delay the actual transmission arbitrarily, e. (2.1) - [ ] The port component is OPTIONAL; the default for "ws" is port 80, while the default for "wss" is port 443. (3) - [ ] 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) - [ ] 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. (8) - [ ] Servers MAY offload the management of the connection to other agents on the network, for example, load balancers and reverse proxies. (4.2) - [ ] The server MAY use this information as part of a determination of whether to accept the incoming connection. (4) - [ ] In this case, a server MAY send a Close frame with a status code of 1002 (protocol error) as defined in Section 7. (5.1) - [ ] In this case, it MAY use the status code 1002 (protocol error) as defined in Section 7. (5.1) - [ ] 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) - [ ] The first fragment MAY also be the final fragment. (0) - [ ] o Control frames (see Section 5.5) MAY be injected in the middle of a fragmented message. (5.4) - [ ] o A sender MAY create fragments of any size for non-control messages. (5.4) - [ ] 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. (5.5.1) - [ ] 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. (5.5.1) - [ ] 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). (5.5.1) - [ ] 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). (5.5.1) - [ ] 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. (5.5.1) - [ ] A Ping frame MAY include "Application data". (5.5.2) - [ ] An endpoint MAY send a Ping frame any time after the connection is established and before the connection is closed. (5.5.2) - [ ] 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. (5.5.3) - [ ] A Pong frame MAY be sent unsolicited. (5.5.3) - [ ] 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. (2) - [ ] Extensions (Section 9) MAY change the semantics of how data is read, specifically including what comprises a message boundary. (6.2) - [ ] 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). (6.2) - [ ] An endpoint MAY close the connection via any means available when necessary, such as when under attack. (7.1.1) - [ ] 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. (7.1.1) - [ ] 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. (7.1.7) - [ ] 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. (7.1.7) - [ ] 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. (7.2.3) - [ ] Servers MAY close the WebSocket connection whenever desired. (7.3) - [ ] 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. (7.4) - [ ] Endpoints MAY use the following pre-defined status codes when sending a Close frame. (7.4.1) - [ ] 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). (1003) - [ ] WebSocket clients MAY request extensions to this specification, and WebSocket servers MAY accept some or all extensions requested by the client. (9) - [ ] WebSocket clients MAY request extensions to this specification, and WebSocket servers MAY accept some or all extensions requested by the client. (9) - [ ] Note that like other HTTP header fields, this header field MAY be split or combined across multiple lines. (9.1) - [ ] Any interactions between multiple extensions MAY be defined in the documents defining the extensions. (9.1) - [ ] This document doesn't define any extension, but implementations MAY use extensions defined separately. (9.2) - [ ] 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. (10.7) - [ ] 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. (11.3.2) - [ ] 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). (11.3.4) - [ ] 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). (11.3.5) --- > ⚠️ ⚠️ テキストからの解析結果です。チェックリストの精度が低い可能性があります。