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 7540 実装チェックリスト **Internet Engineering Task Force (IETF) M. Belshe** 生成日時: 2026-01-18T16:38:42.597Z ## 必須要件 (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 RFC 2119 [RFC2119]. (2.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 RFC 2119 [RFC2119]. (2.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 RFC 2119 [RFC2119]. (2.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 RFC 2119 [RFC2119]. (2.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 RFC 2119 [RFC2119]. (2.2) - [ ] Such an HTTP/1.1 request MUST include exactly one HTTP2-Settings (Section 3. (3.2) - [ ] Requests that contain a payload body MUST be sent in their entirety before the client can send HTTP/2 frames. (3.2) - [ ] A server MUST ignore an "h2" token in an Upgrade header field. (3.2) - [ ] These frames MUST include a response to the request that initiated the upgrade. (3.2) - [ ] The first HTTP/2 frame sent by the server MUST be a server connection preface (Section 3. (3.2) - [ ] Upon receiving the 101 response, the client MUST send a connection preface (Section 3. (3.2) - [ ] A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one "HTTP2-Settings" header field. (3.2.1) - [ ] A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present or if more than one is present. (3.2.1) - [ ] A server MUST NOT send this header field. (3.2.1) - [ ] Since the upgrade is only intended to apply to the immediate connection, a client sending the HTTP2-Settings header field MUST also send "HTTP2-Settings" as a connection option in the Connection header field to prevent it from being forwarded (see Section 6. (3.2.1) - [ ] The "h2c" protocol identifier MUST NOT be sent by a client or selected by a server; the "h2c" protocol identifier describes a protocol that does not use TLS. (3.3) - [ ] Once TLS negotiation is complete, both the client and the server MUST send a connection preface (Section 3. (3.3) - [ ] A client MUST send the connection preface (Section 3. (3.4) - [ ] only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use protocol negotiation in TLS [TLS-ALPN]. (3.4) - [ ] Likewise, the server MUST send a connection preface (Section 3. (3.4) - [ ] This sequence MUST be followed by a SETTINGS frame (Section 6. (3.5) - [ ] The server connection preface consists of a potentially empty SETTINGS frame (Section 6.5) that MUST be the first frame the server sends in the HTTP/2 connection. (3.5) - [ ] The SETTINGS frames received from a peer as part of the connection preface MUST be acknowledged (see Section 6. (3.5) - [ ] Clients and servers MUST treat an invalid connection preface as a connection error (Section 5. (3.5) - [ ] Values greater than 2^14 (16,384) MUST NOT be sent unless the receiver has set a larger value for SETTINGS_MAX_FRAME_SIZE. (4.1) - [ ] Implementations MUST ignore and discard any frame that has a type that is unknown. (4.1) - [ ] Flags that have no defined semantics for a particular frame type MUST be ignored and MUST be left unset (0x0) when sending. (4.1) - [ ] Flags that have no defined semantics for a particular frame type MUST be ignored and MUST be left unset (0x0) when sending. (4.1) - [ ] The semantics of this bit are undefined, and the bit MUST remain unset (0x0) when sending and MUST be ignored when receiving. (4.1) - [ ] The semantics of this bit are undefined, and the bit MUST remain unset (0x0) when sending and MUST be ignored when receiving. (4.1) - [ ] All implementations MUST be capable of receiving and minimally processing frames up to 2^14 octets in length, plus the 9-octet frame header (Section 4. (4.2) - [ ] An endpoint MUST send an error code of FRAME_SIZE_ERROR if a frame exceeds the size defined in SETTINGS_MAX_FRAME_SIZE, exceeds any limit defined for the frame type, or is too small to contain mandatory frame data. (4.2) - [ ] A frame size error in a frame that could alter the state of the entire connection MUST be treated as a connection error (Section 5. (4.2) - [ ] A decoding error in a header block MUST be treated as a connection error (Section 5. (4.3) - [ ] Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved frames of any other type or from any other stream. (4.3) - [ ] A receiver MUST terminate the connection with a connection error (Section 5. (4.3) - [ ] Receiving any frame other than HEADERS or PRIORITY on a stream in this state MUST be treated as a connection error (Section 5. (5.1) - [ ] An endpoint MUST NOT send any type of frame other than HEADERS, RST_STREAM, or PRIORITY in this state. (5.1) - [ ] Receiving any type of frame other than RST_STREAM, PRIORITY, or WINDOW_UPDATE on a stream in this state MUST be treated as a connection error (Section 5. (5.1) - [ ] An endpoint MUST NOT send any type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in this state. (5.1) - [ ] Receiving any type of frame other than HEADERS, RST_STREAM, or PRIORITY on a stream in this state MUST be treated as a connection error (Section 5. (5.1) - [ ] If an endpoint receives additional frames, other than WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in this state, it MUST respond with a stream error (Section 5. (5.1) - [ ] An endpoint MUST NOT send frames other than PRIORITY on a closed stream. (5.1) - [ ] An endpoint that receives any frame other than PRIORITY after receiving a RST_STREAM MUST treat that as a stream error (Section 5. (5.1) - [ ] Similarly, an endpoint that receives any frames after receiving a frame with the END_STREAM flag set MUST treat that as a connection error (Section 5. (5.1) - [ ] Endpoints MUST ignore WINDOW_UPDATE or RST_STREAM frames received in this state, though endpoints MAY choose to treat frames that arrive a significant time after sending END_STREAM as a connection error (Section 5. (5.1) - [ ] An endpoint MUST ignore frames that it receives on closed streams after it has sent a RST_STREAM frame. (5.1) - [ ] Streams initiated by a client MUST use odd-numbered stream identifiers; those initiated by the server MUST use even-numbered stream identifiers. (5.1.1) - [ ] Streams initiated by a client MUST use odd-numbered stream identifiers; those initiated by the server MUST use even-numbered stream identifiers. (5.1.1) - [ ] The identifier of a newly established stream MUST be numerically greater than all streams that the initiating endpoint has opened or reserved. (5.1.1) - [ ] An endpoint that receives an unexpected stream identifier MUST respond with a connection error (Section 5. (5.1.1) - [ ] Endpoints MUST NOT exceed the limit set by their peer. (5.1.2) - [ ] An endpoint that receives a HEADERS frame that causes its advertised concurrent stream limit to be exceeded MUST treat this as a stream error (Section 5. (5.1.2) - [ ] A sender MUST respect flow-control limits imposed by a receiver. (3) - [ ] When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. (5.2.2) - [ ] An endpoint MUST treat this as a stream error (Section 5. (5.3.1) - [ ] After sending the GOAWAY frame for an error condition, the endpoint MUST close the TCP connection. (5.4.1) - [ ] The peer that sends the RST_STREAM frame MUST be prepared to receive any frames that were sent or enqueued for sending by the remote peer. (5.4.2) - [ ] To avoid looping, an endpoint MUST NOT send a RST_STREAM in response to a RST_STREAM frame. (5.4.2) - [ ] Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. (5.5) - [ ] Implementations MUST discard frames that have unknown or unsupported types. (5.5) - [ ] However, extension frames that appear in the middle of a header block (Section 4.3) are not permitted; these MUST be treated as a connection error (Section 5. (5.5) - [ ] Extensions that could change the semantics of existing protocol components MUST be negotiated before being used. (5.5) - [ ] a setting is used for extension negotiation, the initial value MUST be defined in such a fashion that the extension is initially disabled. (5.5) - [ ] Padding octets MUST be set to zero when sending. (6.1) - [ ] DATA frames MUST be associated with a stream. (6.1) - [ ] If a DATA frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5. (6.1) - [ ] If a DATA frame is received whose stream is not in "open" or "half-closed (local)" state, the recipient MUST respond with a stream error (Section 5. (6.1) - [ ] If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a connection error (Section 5. (6.1) - [ ] A HEADERS frame without the END_HEADERS flag set MUST be followed by a CONTINUATION frame for the same stream. (6.2) - [ ] A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5. (6.2) - [ ] HEADERS frames MUST be associated with a stream. (6.2) - [ ] If a HEADERS frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5. (6.2) - [ ] Padding that exceeds the size remaining for the header block fragment MUST be treated as a PROTOCOL_ERROR. (6.2) - [ ] If a PRIORITY frame is received with a stream identifier of 0x0, the recipient MUST respond with a connection error (Section 5. (6.3) - [ ] A PRIORITY frame with a length other than 5 octets MUST be treated as a stream error (Section 5. (6.3) - [ ] After receiving a RST_STREAM on a stream, the receiver MUST NOT send additional frames for that stream, with the exception of PRIORITY. (6.4) - [ ] However, after sending the RST_STREAM, the sending endpoint MUST be prepared to receive and process additional frames sent on the stream that might have been sent by the peer prior to the arrival of the RST_STREAM. (6.4) - [ ] RST_STREAM frames MUST be associated with a stream. (6.4) - [ ] If a RST_STREAM frame is received with a stream identifier of 0x0, the recipient MUST treat this as a connection error (Section 5. (6.4) - [ ] RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. (6.4) - [ ] If a RST_STREAM frame identifying an idle stream is received, the recipient MUST treat this as a connection error (Section 5. (6.4) - [ ] A RST_STREAM frame with a length other than 4 octets MUST be treated as a connection error (Section 5. (6.4) - [ ] A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection. (6.5) - [ ] Implementations MUST support all of the parameters defined by this specification. (6.5) - [ ] When this bit is set, the payload of the SETTINGS frame MUST be empty. (6.5) - [ ] Receipt of a SETTINGS frame with the ACK flag set and a length field value other than 0 MUST be treated as a connection error (Section 5. (6.5) - [ ] The stream identifier for a SETTINGS frame MUST be zero (0x0). (6.5) - [ ] If an endpoint receives a SETTINGS frame whose stream identifier field is anything other than 0x0, the endpoint MUST respond with a connection error (Section 5. (6.5) - [ ] A badly formed or incomplete SETTINGS frame MUST be treated as a connection error (Section 5. (6.5) - [ ] A SETTINGS frame with a length other than a multiple of 6 octets MUST be treated as a connection error (Section 5. (6.5) - [ ] An endpoint MUST NOT send a PUSH_PROMISE frame if it receives this parameter set to a value of (6.5.2) - [ ] acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5. (0) - [ ] Any value other than 0 or 1 MUST be treated as a connection error (Section 5. (0) - [ ] Values above the maximum flow-control window size of 2^31-1 MUST be treated as a connection error (Section 5. (0) - [ ] The value advertised by an endpoint MUST be between this initial value and the maximum allowed frame size (2^24-1 or 16,777,215 octets), inclusive. (0) - [ ] Values outside this range MUST be treated as a connection error (Section 5. (0) - [ ] An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier MUST ignore that setting. (0) - [ ] In order to provide such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag is not set MUST apply the updated parameters as soon as possible upon receipt. (6.5.3) - [ ] The values in the SETTINGS frame MUST be processed in the order they appear, with no other frame processing between values. (6.5.3) - [ ] Unsupported parameters MUST be ignored. (6.5.3) - [ ] recipient MUST immediately emit a SETTINGS frame with the ACK flag set. (6.5.3) - [ ] The promised stream identifier MUST be a valid choice for the next stream sent by the sender (see "new stream identifier" in Section 5. (6.6) - [ ] A PUSH_PROMISE frame without the END_HEADERS flag set MUST be followed by a CONTINUATION frame for the same stream. (6.6) - [ ] A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5. (6.6) - [ ] PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that is in either the "open" or "half-closed (remote)" state. (6.6) - [ ] If the stream identifier field specifies the value 0x0, a recipient MUST respond with a connection error (Section 5. (6.6) - [ ] PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of the peer endpoint is set to 0. (6.6) - [ ] An endpoint that has set this setting and has received acknowledgement MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5. (6.6) - [ ] A sender MUST NOT send a PUSH_PROMISE on a stream unless that stream is either "open" or "half-closed (remote)"; the sender MUST ensure that the promised stream is a valid choice for a new stream identifier (Section 5. (6.6) - [ ] A sender MUST NOT send a PUSH_PROMISE on a stream unless that stream is either "open" or "half-closed (remote)"; the sender MUST ensure that the promised stream is a valid choice for a new stream identifier (Section 5. (6.6) - [ ] A sender MUST NOT send a PUSH_PROMISE on a stream unless that stream is either "open" or "half-closed (remote)"; the sender MUST ensure that the promised stream is a valid choice for a new stream identifier (Section 5.1.1) (that is, the promised stream MUST be in the "idle" state). (6.6) - [ ] A receiver MUST treat the receipt of a PUSH_PROMISE on a stream that is neither "open" nor "half-closed (local)" as a connection error (Section 5. (6.6) - [ ] However, an endpoint that has sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE frames that might have been created before the RST_STREAM frame is received and processed. (6.6) - [ ] A receiver MUST treat the receipt of a PUSH_PROMISE that promises an illegal stream identifier (Section 5. (6.6) - [ ] In addition to the frame header, PING frames MUST contain 8 octets of opaque data in the payload. (6.7) - [ ] Receivers of a PING frame that does not include an ACK flag MUST send a PING frame with the ACK flag set in response, with an identical payload. (6.7) - [ ] An endpoint MUST set this flag in PING responses. (6.7) - [ ] An endpoint MUST NOT respond to PING frames containing this flag. (6.7) - [ ] If a PING frame is received with a stream identifier field value other than 0x0, the recipient MUST respond with a connection error (Section 5. (6.7) - [ ] Receipt of a PING frame with a length field value other than 8 MUST be treated as a connection error (Section 5. (6.7) - [ ] Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. (6.8) - [ ] An endpoint MUST treat a GOAWAY frame with a stream identifier other than 0x0 as a connection error (Section 5. (6.8) - [ ] Endpoints MUST NOT increase the value they send in the last stream identifier, since the peers might already have retried unprocessed requests on another connection. (6.8) - [ ] For instance, HEADERS, PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to ensure the state maintained for header compression is consistent (see Section 4. (6.8) - [ ] For instance, HEADERS, PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to ensure the state maintained for header compression is consistent (see Section 4.3); similarly, DATA frames MUST be counted toward the connection flow-control window. (6.8) - [ ] Logged or otherwise persistently stored debug data MUST have adequate safeguards to prevent unauthorized access. (6.8) - [ ] Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to handling the frame. (6.9) - [ ] A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an flow-control window increment of 0 as a stream error (Section 5. (6.9) - [ ] A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an flow-control window increment of 0 as a stream error (Section 5.4.2) of type PROTOCOL_ERROR; errors on the connection flow-control window MUST be treated as a connection error (Section 5. (6.9) - [ ] A receiver MUST NOT treat this as an error (see Section 5. (6.9) - [ ] A receiver that receives a flow-controlled frame MUST always account for its contribution against the connection flow-control window, unless the receiver treats this as a connection error (Section 5. (6.9) - [ ] A WINDOW_UPDATE frame with a length other than 4 octets MUST be treated as a connection error (Section 5. (6.9) - [ ] The sender MUST NOT send a flow-controlled frame with a length that exceeds the space available in either of the flow-control windows advertised by the receiver. (6.9.1) - [ ] A sender MUST NOT allow a flow-control window to exceed 2^31-1 octets. (6.9.1) - [ ] If a sender receives a WINDOW_UPDATE that causes a flow- control window to exceed this maximum, it MUST terminate either the stream or the connection, as appropriate. (6.9.1) - [ ] When the value of SETTINGS_INITIAL_WINDOW_SIZE changes, a receiver MUST adjust the size of all stream flow-control windows that it maintains by the difference between the new value and the old value. (6.9.2) - [ ] A sender MUST track the negative flow-control window and MUST NOT send new flow- controlled frames until it receives WINDOW_UPDATE frames that cause the flow-control window to become positive. (6.9.2) - [ ] A sender MUST track the negative flow-control window and MUST NOT send new flow- controlled frames until it receives WINDOW_UPDATE frames that cause the flow-control window to become positive. (6.9.2) - [ ] An endpoint MUST treat a change to SETTINGS_INITIAL_WINDOW_SIZE that causes any flow-control window to exceed the maximum size as a connection error (Section 5. (6.9.2) - [ ] However, the receiver MUST be prepared to receive data that exceeds this window size, since the sender might send data that exceeds the lower limit prior to processing the SETTINGS frame. (6.9.3) - [ ] If the END_HEADERS bit is not set, this frame MUST be followed by another CONTINUATION frame. (6.10) - [ ] A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5. (6.10) - [ ] CONTINUATION frames MUST be associated with a stream. (6.10) - [ ] If a CONTINUATION frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5. (6.10) - [ ] A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or CONTINUATION frame without the END_HEADERS flag set. (6.10) - [ ] A recipient that observes violation of this rule MUST respond with a connection error (Section 5. (6.10) - [ ] Unknown or unsupported error codes MUST NOT trigger any special behavior. (7) - [ ] Other frames (from any stream) MUST NOT occur between the HEADERS frame and any CONTINUATION frames that might follow. (4) - [ ] The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be used in HTTP/2. (4) - [ ] An endpoint that receives a HEADERS frame without the END_STREAM flag set after receiving a final (non- informational) status code MUST treat the corresponding request or response as malformed (Section 8. (4) - [ ] Clients MUST NOT discard responses as a result of receiving such a RST_STREAM, though clients can always discard responses at their discretion for other reasons. (4) - [ ] However, header field names MUST be converted to lowercase prior to their encoding in HTTP/2. (8.1.2) - [ ] A request or response containing uppercase header field names MUST be treated as malformed (Section 8. (8.1.2) - [ ] Endpoints MUST NOT generate pseudo-header fields other than those defined in this document. (8.1.2.1) - [ ] Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests. (8.1.2.1) - [ ] Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header fields defined for responses MUST NOT appear in requests. (8.1.2.1) - [ ] Pseudo-header fields MUST NOT appear in trailers. (8.1.2.1) - [ ] Endpoints MUST treat a request or response that contains undefined or invalid pseudo-header fields as malformed (Section 8. (8.1.2.1) - [ ] All pseudo-header fields MUST appear in the header block before regular header fields. (8.1.2.1) - [ ] Any request or response that contains a pseudo-header field that appears in a header block after a regular header field MUST be treated as malformed (Section 8. (8.1.2.1) - [ ] An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed (Section 8. (8.1.2.2) - [ ] An endpoint MUST NOT generate an HTTP/2 message containing connection-specific header fields; any message containing connection-specific header fields MUST be treated as malformed (Section 8. (8.1.2.2) - [ ] The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any value other than "trailers". (8.1.2.2) - [ ] The authority MUST NOT include the deprecated "userinfo" subcomponent for "http" or "https" schemed URIs. (8.1.2.3) - [ ] To ensure that the HTTP/1.1 request line can be reproduced accurately, this pseudo-header field MUST be omitted when translating from an HTTP/1. (8.1.2.3) - [ ] An intermediary that converts an HTTP/2 request to HTTP/1.1 MUST create a Host header field if one is not present in a request by copying the value of the ":authority" pseudo-header field. (8.1.2.3) - [ ] This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of '/'. (8.1.2.3) - [ ] This pseudo-header field MUST NOT be empty for "http" or "https" URIs; "http" or "https" URIs that do not contain a path component MUST include a value of '/'. (8.1.2.3) - [ ] The exception to this rule is an OPTIONS request for an "http" or "https" URI that does not include a path component; these MUST include a ":path" pseudo-header field with a value of '*' (see [RFC7230], Section 5. (8.1.2.3) - [ ] All HTTP/2 requests MUST include exactly one valid value for the ":method", ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT request (Section 8. (8.1.2.3) - [ ] This pseudo-header field MUST be included in all responses; otherwise, the response is malformed (Section 8. (8.1.2.4) - [ ] If there are multiple Cookie header fields after decompression, these MUST be concatenated into a single octet string using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ") before being passed into a non-HTTP/2 context, such as an HTTP/1. (8.1.2.5) - [ ] Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response. (8.1.2.6) - [ ] Malformed requests or responses that are detected MUST be treated as a stream error (Section 5. (8.1.2.6) - [ ] Clients MUST NOT accept a malformed response. (8.1.2.6) - [ ] A server MUST NOT indicate that a stream has not been processed unless it can guarantee that fact. (8.1.4) - [ ] If frames that are on a stream are passed to the application layer for any stream, then REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame MUST include a stream identifier that is greater than or equal to the given stream identifier. (8.1.4) - [ ] If frames that are on a stream are passed to the application layer for any stream, then REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame MUST include a stream identifier that is greater than or equal to the given stream identifier. (8.1.4) - [ ] Promised requests MUST be cacheable (see [RFC7231], Section 4. (8.2) - [ ] Promised requests MUST be cacheable (see [RFC7231], Section 4.2.3), MUST be safe (see [RFC7231], Section 4. (8.2) - [ ] Promised requests MUST be cacheable (see [RFC7231], Section 4.2.3), MUST be safe (see [RFC7231], Section 4.2.1), and MUST NOT include a request body. (8.2) - [ ] Clients that receive a promised request that is not cacheable, that is not known to be safe, or that indicates the presence of a request body MUST reset the promised stream with a stream error (Section 5. (8.2) - [ ] Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache. (8.2) - [ ] The server MUST include a value in the ":authority" pseudo-header field for which the server is authoritative (see Section 10. (8.2) - [ ] A client MUST treat a PUSH_PROMISE for which the server is not authoritative as a stream error (Section 5. (8.2) - [ ] Thus, servers MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5. (8.2) - [ ] Clients MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the message as a connection error (Section 5. (8.2) - [ ] The header fields in PUSH_PROMISE and any subsequent CONTINUATION frames MUST be a valid and complete set of request header fields (Section 8. (8.2.1) - [ ] The server MUST include a method in the ":method" pseudo-header field that is safe and cacheable. (8.2.1) - [ ] If a client receives a PUSH_PROMISE that does not include a complete and valid set of header fields or the ":method" pseudo-header field identifies a method that is not safe, it MUST respond with a stream error (Section 5. (8.2.1) - [ ] PUSH_PROMISE frames MUST NOT be sent by the client. (8.2.1) - [ ] PUSH_PROMISE frames can be sent by the server in response to any client-initiated stream, but the stream MUST be in either the "open" or "half-closed (remote)" state with respect to the server. (8.2.1) - [ ] Clients receiving a pushed response MUST validate that either the server is authoritative (see Section 10. (8.2.2) - [ ] o The ":scheme" and ":path" pseudo-header fields MUST be omitted. (8.3) - [ ] Frame types other than DATA or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY) MUST NOT be sent on a connected stream and MUST be treated as a stream error (Section 5. (8.3) - [ ] Frame types other than DATA or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY) MUST NOT be sent on a connected stream and MUST be treated as a stream error (Section 5. (8.3) - [ ] Correspondingly, a proxy MUST send a TCP segment with the RST bit set if it detects an error with the stream or the HTTP/2 connection. (8.3) - [ ] The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the host in the URI. (9.1.1) - [ ] This status code MUST NOT be generated by proxies. (9.1.2) - [ ] Implementations of HTTP/2 MUST use TLS version 1. (9.2) - [ ] The TLS implementation MUST support the Server Name Indication (SNI) [TLS-EXT] extension to TLS. (9.2) - [ ] HTTP/2 clients MUST indicate the target domain name when negotiating TLS. (9.2) - [ ] A deployment of HTTP/2 over TLS 1.2 MUST disable compression. (9.2.1) - [ ] A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation. (9.2.1) - [ ] An endpoint MUST treat a TLS renegotiation as a connection error (Section 5. (9.2.1) - [ ] An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any renegotiation MUST occur prior to sending the connection preface. (9.2.1) - [ ] Implementations MUST support ephemeral key exchange sizes of at least (9.2.1) - [ ] Clients MUST accept DHE sizes of up to 4096 bits. (2048) - [ ] Implementations MUST NOT generate this error in reaction to the negotiation of a cipher suite that is not on the black list. (9.2.2) - [ ] Requests or responses containing invalid header field names MUST be treated as malformed (Section 8. (10.3) - [ ] Any request or response that contains a character not permitted in a header field value MUST be treated as malformed (Section 8. (10.3) - [ ] Where multiple tenants share space on the same server, that server MUST ensure that tenants are not able to push representations of resources that they do not have authority over. (10.4) - [ ] Pushed responses for which an origin server is not authoritative (see Section 10.1) MUST NOT be used or cached. (10.4) - [ ] The header block MUST be processed to ensure a consistent connection state, unless the connection is closed. (10.5.1) - [ ] Implementations communicating on a secure channel MUST NOT compress content that includes both confidential and attacker-controlled data unless separate compression dictionaries are used for each source of data. (10.6) - [ ] Compression MUST NOT be used if the source of data cannot be reliably determined. (10.6) - [ ] Generic stream compression, such as that provided by TLS, MUST NOT be used with HTTP/2 (see Section 9. (10.6) ## 推奨要件 (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 RFC 2119 [RFC2119]. (2.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 RFC 2119 [RFC2119]. (2.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 RFC 2119 [RFC2119]. (2.2) - [ ] Endpoints SHOULD process PRIORITY frames, though they can be ignored if the stream has been removed from the dependency tree (see Section 5. (5.1) - [ ] In the absence of more specific guidance elsewhere in this document, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a connection error (Section 5. (5.1) - [ ] Inside the dependency tree, a dependent stream SHOULD only be allocated resources if either all of the streams that it depends on (the chain of parent streams up to 0x0) are closed or it is not possible to make progress on them. (5.3.1) - [ ] Streams with the same parent SHOULD be allocated resources proportionally based on their weight. (256) - [ ] To avoid these problems, an endpoint SHOULD retain stream prioritization state for a period after streams become closed. (5.3.4) - [ ] If a limit is applied, endpoints SHOULD maintain state for at least as many streams as allowed by their setting for SETTINGS_MAX_CONCURRENT_STREAMS. (5.3.4) - [ ] Implementations SHOULD also attempt to retain state for streams that are in active use in the priority tree. (5.3.4) - [ ] If it has retained enough state to do so, an endpoint receiving a PRIORITY frame that changes the priority of a closed stream SHOULD alter the dependencies of the streams that depend on it. (5.3.4) - [ ] An endpoint that encounters a connection error SHOULD first send a GOAWAY frame (Section 6. (5.4.1) - [ ] Endpoints SHOULD send a GOAWAY frame when ending a connection, providing that circumstances permit it. (5.4.1) - [ ] Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame for any stream. (5.4.2) - [ ] A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be treated as special by endpoints. (0) - [ ] Servers SHOULD only set a zero value for short durations; if a server does not wish to accept requests, closing the connection is more appropriate. (0) - [ ] PING responses SHOULD be given higher priority than any other frame. (6.7) - [ ] Endpoints SHOULD always send a GOAWAY frame before closing a connection so that the remote peer can know whether a stream has been partially processed or not. (6.8) - [ ] A GOAWAY frame might not immediately precede closing of the connection; a receiver of a GOAWAY that has no more use for the connection SHOULD still send a GOAWAY frame before terminating the connection. (6.8) - [ ] A server that is attempting to gracefully shut down a connection SHOULD send an initial GOAWAY frame with the last stream identifier set to 2^31-1 and a NO_ERROR code. (6.8) - [ ] Such intermediaries SHOULD also remove other connection- specific header fields, such as Keep-Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they are not nominated by the Connection header field. (8.1.2.2) - [ ] Clients that generate HTTP/2 requests directly SHOULD use the ":authority" pseudo-header field instead of the Host header field. (8.1.2.3) - [ ] The server SHOULD send PUSH_PROMISE (Section 6. (8.2.1) - [ ] Once a client receives a PUSH_PROMISE frame and chooses to accept the pushed response, the client SHOULD NOT issue any requests for the promised response until after the promised stream has closed. (8.2.2) - [ ] Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair, where the host is derived from a URI, a selected alternative service [ALT-SVC], or a configured proxy. (9.1) - [ ] A client MAY open multiple connections to the same IP address and TCP port using different Server Name Indication [TLS-EXT] values or to provide different TLS client certificates but SHOULD avoid creating multiple connections with the same configuration. (9.1) - [ ] When either endpoint chooses to close the transport-layer TCP connection, the terminating endpoint SHOULD first send a GOAWAY (Section 6. (9.1) - [ ] The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. (9.2) - [ ] A server SHOULD request a client certificate if it sees a renegotiation request immediately after establishing a connection. (9.2.1) - [ ] A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher suites that are listed in the cipher suite black list (Appendix A). (9.2.2) - [ ] A client that accepts server push SHOULD limit the number of streams it allows to be in the "reserved (remote)" state. (10.5) - [ ] Implementations SHOULD track the use of these features and set limits on their use. (10.5) - [ ] Intermediaries SHOULD retain padding for DATA frames but MAY drop padding for HEADERS and PUSH_PROMISE frames. (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 RFC 2119 [RFC2119]. (2.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 RFC 2119 [RFC2119]. (2.2) - [ ] A client MUST send the connection preface (Section 3.5) and then MAY immediately send HTTP/2 frames to such a server; servers can identify these connections by the presence of the connection preface. (3.4) - [ ] This sequence MUST be followed by a SETTINGS frame (Section 6.5), which MAY be empty. (3.5) - [ ] A GOAWAY frame (Section 6.8) MAY be omitted in this case, since an invalid preface indicates that the peer is not using HTTP/2. (3.5) - [ ] A PRIORITY or WINDOW_UPDATE frame MAY be received in this state. (5.1) - [ ] An endpoint MAY send a PRIORITY frame in this state to reprioritize the reserved stream. (5.1) - [ ] Endpoints MUST ignore WINDOW_UPDATE or RST_STREAM frames received in this state, though endpoints MAY choose to treat frames that arrive a significant time after sending END_STREAM as a connection error (Section 5. (5.1) - [ ] An endpoint MAY choose to limit the period over which it ignores frames and treat frames that arrive after this time as being in error. (5.1) - [ ] A receiver MAY choose to set any window size that it desires for each stream and for the entire connection. (3) - [ ] Therefore, the amount of prioritization state that is retained MAY be limited. (5.3.4) - [ ] In particular, an endpoint MAY choose to treat a stream error as a connection error. (5.4.1) - [ ] However, an endpoint MAY send additional RST_STREAM frames if it receives frames on a closed stream after more than a round-trip time. (5.4.2) - [ ] DATA frames MAY also contain padding. (6.1) - [ ] A receiver is not obligated to verify padding but MAY treat non-zero padding as a connection error (Section 5. (6.1) - [ ] A SETTINGS frame MUST be sent by both endpoints at the start of a connection and MAY be sent at any other time by either endpoint over the lifetime of the connection. (6.5) - [ ] For any given request, a lower limit than what is advertised MAY be enforced. (0) - [ ] If the sender of a SETTINGS frame does not receive an acknowledgement within a reasonable amount of time, it MAY issue a connection error (Section 5. (6.5.3) - [ ] An endpoint MAY send multiple GOAWAY frames if circumstances change. (6.8) - [ ] Endpoints MAY append opaque data to the payload of any GOAWAY frame. (6.8) - [ ] A receiver MAY respond with a stream error (Section 5. (6.9) - [ ] Frames with zero length with the END_STREAM flag set (that is, an empty DATA frame) MAY be sent if there is no available space in either flow-control window. (6.9.1) - [ ] After sending a SETTINGS frame that reduces the initial flow-control window size, a receiver MAY continue to process streams that exceed flow-control limits. (6.9.3) - [ ] The receiver MAY instead send a RST_STREAM with an error code of FLOW_CONTROL_ERROR for the affected streams. (6.9.3) - [ ] These MAY be treated by an implementation as being equivalent to INTERNAL_ERROR. (7) - [ ] When this is true, a server MAY request that the client abort transmission of a request without error by sending a RST_STREAM with an error code of NO_ERROR after sending a complete response (i. (4) - [ ] The only exception to this is the TE header field, which MAY be present in an HTTP/2 request; when it is, it MUST NOT contain any value other than "trailers". (8.1.2.2) - [ ] To allow for better compression efficiency, the Cookie header field MAY be split into separate header fields, each with one or more cookie-pairs. (8.1.2.5) - [ ] For malformed requests, a server MAY send an HTTP response prior to closing or resetting the stream. (8.1.2.6) - [ ] Requests that have not been processed have not failed; clients MAY automatically retry them, even those with non-idempotent methods. (8.1.4) - [ ] They MAY be made available to the application separately. (8.2) - [ ] A client MAY open multiple connections to the same IP address and TCP port using different Server Name Indication [TLS-EXT] values or to provide different TLS client certificates but SHOULD avoid creating multiple connections with the same configuration. (9.1) - [ ] Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3), MAY be reused for requests with multiple different URI authority components. (9.1.1) - [ ] Clients receiving a 421 (Misdirected Request) response from a server MAY retry the request -- whether the request method is idempotent or not -- over a different connection. (9.1.2) - [ ] An endpoint MAY immediately terminate an HTTP/2 connection that does not meet these TLS requirements with a connection error (Section 5. (9.2.1) - [ ] An endpoint MAY use renegotiation to provide confidentiality protection for client credentials offered in the handshake, but any renegotiation MUST occur prior to sending the connection preface. (9.2.1) - [ ] Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error (Section 5. (2048) - [ ] Endpoints MAY choose to generate a connection error (Section 5. (9.2.2) - [ ] An endpoint MAY treat activity that is suspicious as a connection error (Section 5. (10.5) - [ ] This setting is only advisory, so endpoints MAY choose to send header blocks that exceed this limit and risk having the request or response being treated as malformed. (10.5.1) - [ ] Intermediaries SHOULD retain padding for DATA frames but MAY drop padding for HEADERS and PUSH_PROMISE frames. (10.7) - [ ] An HTTP/2 implementation MAY treat the negotiation of any of the following cipher suites with TLS 1. (12.2) --- > ⚠️ ⚠️ テキストからの解析結果です。チェックリストの精度が低い可能性があります。