ietf-corpus

rfc-9113

HTTP/2

M. Thomson (Editor), C. Benfield (Editor)
date2022-06 streamIETF areawit wghttpbis statusPROPOSED STANDARD pages78 canonicalhttps://www.rfc-editor.org/rfc/rfc9113 doi10.17487/RFC9113 errataview
This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more efficient use of network resources and a reduced latency by introducing field compression and allowing multiple concurrent exchanges on the same connection. This document obsoletes RFCs 7540 and 8740.

obsoletes

Extracted elements (30)

design-rationale §3.4

The client connection preface string ("PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n") was chosen so that a large proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries would not attempt to process further frames, providing a degree of cross-protocol safety for cleartext connections.

http

design-rationale §5.3

The priority signaling scheme defined in RFC 7540 is deprecated in this document. The RFC 7540 scheme was complex, not uniformly implemented, and server deployments often ignored client signals. Implementations are encouraged to use the scheme described in [HTTP-PRIORITY] instead.

http

interoperability-note §4.3.1

Reducing SETTINGS_HEADER_TABLE_SIZE is not widely interoperable. Use of the connection preface to reduce the value below the initial value of 4,096 is somewhat better supported but may fail with some implementations.

http

normative-requirement §4.3 MUST

A HEADERS frame without the END_HEADERS flag set MUST be followed by CONTINUATION frames for the same stream with no interleaved frames of any other type or from any other stream. The last CONTINUATION frame has the END_HEADERS flag set.

http

normative-requirement §4.3 MUST

A receiver MUST terminate the connection with a connection error of type COMPRESSION_ERROR if it does not decompress a field block, even if the frames are to be discarded. HPACK compression state is connection-wide and stateful; all field blocks on a connection share the same encoder/decoder context.

http

normative-requirement §3.4 MUST

Clients and servers MUST treat an invalid connection preface as a connection error of type PROTOCOL_ERROR. The client MUST send the 24-octet magic followed by a SETTINGS frame as the first application data on the connection.

http

normative-requirement §5.1.2 MUST NOT

Endpoints MUST NOT exceed the SETTINGS_MAX_CONCURRENT_STREAMS limit set by their peer. Receiving a HEADERS frame that causes the advertised concurrent stream limit to be exceeded MUST be treated as a stream error of type PROTOCOL_ERROR or REFUSED_STREAM. Streams in 'open' or either 'half-closed' state count toward the limit.

http

normative-requirement §5.2.2 MUST

Endpoints MUST read and process HTTP/2 frames from the TCP receive buffer as soon as data is available. Failure to read promptly could cause a deadlock when critical frames such as WINDOW_UPDATE are not processed.

http, tcp

normative-requirement §3.1 MUST

For 'https' URIs, HTTP/2 MUST use TLS with the ALPN extension and the 'h2' protocol identifier (0x68, 0x32). The 'h2c' protocol identifier MUST NOT be sent by a client or selected by a server. The h2c upgrade token and HTTP2-Settings header field are deprecated.

http, tls

normative-requirement §8.2.2 MUST

HTTP/2 prohibits connection-specific header fields such as Connection, Keep-Alive, Proxy-Connection, Transfer-Encoding, and Upgrade. An endpoint MUST treat a message containing these fields as malformed. The TE header field is permitted only if its value is 'trailers'.

http

normative-requirement §8.4 MUST NOT

Server push MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting from the client is 0. A pushed response MUST be cacheable, MUST be safe (in the HTTP sense), and MUST NOT include a request body. Clients may reject pushed streams by sending RST_STREAM with REFUSED_STREAM.

http

normative-requirement §5.1.1 MUST

Streams initiated by a client MUST use odd-numbered stream identifiers; those initiated by the server MUST use even-numbered stream identifiers. Stream identifier 0x00 is reserved for connection-level control messages. Stream identifiers cannot be reused.

http

normative-requirement §6.5.3 MUST

Upon receiving a SETTINGS frame without the ACK flag, the recipient MUST apply settings as soon as possible and MUST immediately emit a SETTINGS frame with the ACK flag set. SETTINGS frames are acknowledged in the order they are received.

http

privacy-consideration §10.7

HTTP/2 field compression makes it possible for an eavesdropper to observe patterns in traffic even when TLS is used. Padding (in DATA, HEADERS, and PUSH_PROMISE frames) can be used to obscure message sizes but does not eliminate traffic analysis. The amount of padding SHOULD be chosen to make traffic analysis difficult.

http, privacy

protocol-element §5.2.1

HTTP/2 flow control is credit-based using WINDOW_UPDATE frames. The initial flow-control window is 65,535 octets for both new streams and the overall connection. Only DATA frames consume flow-control window space; control frames are not subject to flow control.

http, congestion

protocol-element §8.3

HTTP/2 uses pseudo-header fields prefixed with ':' to carry HTTP control data. Request pseudo-headers are :method, :scheme, :path, and :authority. The response pseudo-header is :status. Pseudo-header fields MUST appear before regular header fields and MUST NOT appear in trailers.

http

protocol-element §6.5.2

Six SETTINGS parameters are defined: SETTINGS_HEADER_TABLE_SIZE (0x01, initial 4096), SETTINGS_ENABLE_PUSH (0x02, initial 1), SETTINGS_MAX_CONCURRENT_STREAMS (0x03, initially unlimited), SETTINGS_INITIAL_WINDOW_SIZE (0x04, initial 65535), SETTINGS_MAX_FRAME_SIZE (0x05, initial 16384), SETTINGS_MAX_HEADER_LIST_SIZE (0x06, initial unlimited).

http

protocol-element §3.4

The client connection preface is 24 octets (the ASCII string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n") followed immediately by a SETTINGS frame (which MAY be empty). The server connection preface is a potentially empty SETTINGS frame that MUST be the first frame sent by the server.

http

security-consideration §10.6

Combining compression with encryption (as HTTP/2 does via HPACK) can expose plaintext to CRIME-like attacks if an attacker controls part of the compressed payload. HTTP/2 limits this risk by using HPACK rather than general-purpose compression, which is designed to mitigate such attacks.

http, security, crypto

security-consideration §10.5

HTTP/2 implementations are vulnerable to denial-of-service via resource exhaustion. Endpoints should limit field block sizes (SETTINGS_MAX_HEADER_LIST_SIZE), the number of concurrent streams (SETTINGS_MAX_CONCURRENT_STREAMS), and monitor for excessive CONTINUATION frames, which can be used to exhaust memory.

http, security

security-consideration §9.2

HTTP/2 requires use of TLS to mitigate cross-protocol attacks. TLS 1.2 implementations MUST NOT negotiate cipher suites from the prohibited list in Appendix A, which includes all cipher suites with NULL, export-grade, or RC4 encryption. TLS 1.2 MUST support SNI.

http, tls, security

state-machine §5.1

HTTP/2 streams progress through states: idle → open (on HEADERS), idle → reserved (local/remote) (on PUSH_PROMISE), open → half-closed (local) or half-closed (remote) (on END_STREAM flag), any non-closed → closed (on RST_STREAM or both sides sending END_STREAM). The terminal state is 'closed'.

http

wire-format §4.1

Every HTTP/2 frame begins with a fixed 9-octet header: Length (24-bit unsigned, payload size in octets), Type (8-bit), Flags (8-bit), a Reserved 1-bit field, and a 31-bit Stream Identifier. The 9-octet header is not counted in the Length field value.

http

wire-format §6.1

The DATA frame (type=0x00) carries variable-length application data on a stream. Fields beyond the 9-octet header: optional Pad Length (8-bit, present if PADDED flag set), Data (variable), and optional Padding (up to 2040 octets). DATA frames are subject to flow control.

http

wire-format §6.8

The GOAWAY frame (type=0x07) contains a Reserved (1-bit), Last-Stream-ID (31-bit unsigned), Error Code (32-bit), and optional Additional Debug Data. It MUST use stream identifier 0x00. The Last-Stream-ID indicates the highest stream that may have been processed by the sender.

http

wire-format §6.2

The HEADERS frame (type=0x01) opens a stream and carries a field block fragment. Optional fields: Pad Length (8-bit), Exclusive (1-bit, deprecated priority), Stream Dependency (31-bit, deprecated), Weight (8-bit, deprecated), Field Block Fragment (variable), Padding. Flags: END_STREAM (0x01), END_HEADERS (0x04), PADDED (0x08), PRIORITY (0x20).

http

wire-format §6.7

The PING frame (type=0x06) has a fixed 8-octet payload of opaque data and MUST be associated with stream 0x00. Receivers of a PING without the ACK flag MUST respond with a PING with the ACK flag set and identical payload. A PING with length other than 8 MUST be treated as a connection error of type FRAME_SIZE_ERROR.

http

wire-format §6.6

The PUSH_PROMISE frame (type=0x05) carries a Reserved (1-bit) field, a 31-bit Promised Stream ID, and a Field Block Fragment. It MUST only be sent on a peer-initiated stream in 'open' or 'half-closed (remote)' state. The promised stream identifier MUST be in the 'idle' state.

http

wire-format §6.4

The RST_STREAM frame (type=0x03) has a fixed 4-octet payload containing a single unsigned 32-bit Error Code. It immediately terminates the referenced stream, causing it to enter 'closed' state. RST_STREAM MUST NOT be sent on a stream in the 'idle' state.

http

wire-format §6.5

The SETTINGS frame (type=0x04) carries zero or more Setting fields, each consisting of a 16-bit Identifier and a 32-bit Value. The stream identifier MUST be 0x00. A SETTINGS frame with ACK flag set MUST have an empty payload. Each parameter in SETTINGS replaces any existing value for that parameter.

http