Hypertext Transfer Protocol Version 2 (HTTP/2)
Extracted elements (31)
HTTP/2 uses binary framing rather than the text-based framing of HTTP/1.1 to enable efficient parsing, reduced error rates from whitespace ambiguity, and natural support for multiplexing without head-of-line blocking. The frame and stream layers are intentionally tailored to HTTP semantics and server push rather than defined as a general-purpose binary protocol.
The client connection preface magic 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 reject the connection immediately rather than attempting to parse subsequent binary HTTP/2 frames as HTTP/1.x text, reducing interoperability hazards during accidental cleartext HTTP/2 connections.
HTTP/2 uses 'h2' as the ALPN identifier for TLS-based HTTP/2 and 'h2c' for cleartext TCP. Negotiating either token commits both endpoints to all transport, framing, and message semantics of this specification. The 'h2c' token is reserved in the ALPN space but describes a non-TLS protocol and MUST NOT be selected in TLS negotiation.
All implementations MUST be capable of receiving and minimally processing frames up to 2^14 (16,384) octets in length plus the 9-octet header. SETTINGS_MAX_FRAME_SIZE may be set to any value between 2^14 and 2^24-1 (16,777,215) octets. Exceeding the negotiated maximum MUST be treated as a FRAME_SIZE_ERROR, which is a connection error for frames that carry header blocks or SETTINGS.
An endpoint that encounters a connection error SHOULD send a GOAWAY frame with the Last-Stream-ID set to the highest-numbered stream it has processed, along with an error code, and MUST then close the TCP connection. GOAWAY provides a best-effort signal; reliable delivery is not guaranteed.
Client-initiated streams MUST use odd-numbered stream identifiers; server-initiated streams MUST use even-numbered stream identifiers. New stream identifiers MUST be numerically greater than all streams previously opened or reserved by the initiating endpoint. Stream identifiers cannot be reused; identifier exhaustion requires opening a new connection.
Header blocks MUST be transmitted as a contiguous sequence of frames with no intervening frames of any other type or from any other stream. Extension frames appearing inside a header block MUST be treated as a connection error of type PROTOCOL_ERROR. A HEADERS frame without END_HEADERS MUST be immediately followed by a CONTINUATION frame on the same stream.
HTTP/1.1 connection-specific header fields (Connection, Keep-Alive, Proxy-Connection, Transfer-Encoding, Upgrade) MUST NOT be used in HTTP/2. An endpoint that receives such a field MUST treat the associated request or response as malformed. The TE header is an exception: it MAY be included if its value is exactly 'trailers'.
HTTP/2 over TLS (h2) MUST use TLS 1.2 or higher, MUST NOT negotiate compression, and MUST use SNI. Implementations MUST NOT negotiate cipher suites listed in the Appendix A blacklist (export ciphers, NULL, anonymous, RC4, many CBC-mode suites). An endpoint that cannot negotiate an acceptable cipher suite SHOULD use the INADEQUATE_SECURITY error code.
HTTP/2 over TLS MUST use the 'h2' ALPN protocol identifier; 'h2c' MUST NOT be sent over TLS. For cleartext TCP, a client with prior knowledge MUST send the connection preface but MAY skip the HTTP/1.1 Upgrade mechanism. Implementations supporting HTTP/2 over TLS MUST use ALPN negotiation rather than cleartext prior-knowledge procedures.
HTTP/2 request pseudo-header fields (:method, :scheme, :path, :authority) and the response pseudo-header :status MUST appear before any regular header fields. Pseudo-headers MUST NOT appear in trailers. All pseudo-headers defined for a request MUST be present (with :method and :path required; :scheme required except for CONNECT). An endpoint MUST treat a violation as a malformed request.
Upon receiving a SETTINGS frame, the recipient MUST apply all parameters and acknowledge with a SETTINGS frame bearing the ACK flag (0x1) and an empty payload. A SETTINGS ACK with a non-empty payload MUST be treated as a FRAME_SIZE_ERROR. An endpoint that does not receive timely acknowledgement SHOULD treat this as a connection error of type SETTINGS_TIMEOUT.
HTTP/2 header compression maintains state across requests, and the association of multiple requests over a single TCP connection can reveal browsing patterns more readily than separate connections. Traffic analysis of compressed header sizes may leak information about request content. The use of padding in DATA and HEADERS frames provides limited mitigation against size-based traffic analysis.
Flow control in HTTP/2 is credit-based, using WINDOW_UPDATE frames, and applies only to DATA frames. The initial flow-control window is 65,535 octets for both new streams and the connection as a whole. Flow control cannot be disabled, is hop-by-hop, and is directional (controlled by the receiver).
HTTP/2 header compression uses HPACK (RFC 7541) with a single stateful compression context and a single decompression context shared across the entire connection. Header block fragments are transmitted inside HEADERS, PUSH_PROMISE, and CONTINUATION frames. A decoding error in any header block MUST be treated as a connection error of type COMPRESSION_ERROR.
Server push allows a server to send a PUSH_PROMISE frame on an open or half-closed (remote) stream to reserve an even-numbered server-initiated stream, then send a pushed response on that stream. A client may disable server push by setting SETTINGS_ENABLE_PUSH to 0; a server MUST NOT send PUSH_PROMISE frames after this setting is acknowledged.
Stream prioritization uses a weighted dependency tree. Each stream can declare an exclusive or non-exclusive dependency on another stream and a weight from 1 to 256. Priority information is advisory and does not guarantee transmission order. All streams initially have a non-exclusive dependency on stream 0x0 with a default weight of 16.
The client connection preface is the 24-octet magic string 'PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n' (hex: 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a) followed immediately by a SETTINGS frame. The server connection preface is a (potentially empty) SETTINGS frame that MUST be the first frame the server sends. Both endpoints MUST send their preface upon connection establishment.
IANA created the HTTP/2 Error Code Registry with 'Expert Review' policy. Initial entries: NO_ERROR (0x0), PROTOCOL_ERROR (0x1), INTERNAL_ERROR (0x2), FLOW_CONTROL_ERROR (0x3), SETTINGS_TIMEOUT (0x4), STREAM_CLOSED (0x5), FRAME_SIZE_ERROR (0x6), REFUSED_STREAM (0x7), CANCEL (0x8), COMPRESSION_ERROR (0x9), CONNECT_ERROR (0xa), ENHANCE_YOUR_CALM (0xb), INADEQUATE_SECURITY (0xc), HTTP_1_1_REQUIRED (0xd).
IANA created the HTTP/2 Frame Type Registry with 'Specification Required' policy for values 0x00-0xef and 'IETF Review' for 0xf0-0xff. Initial entries: DATA (0x0), HEADERS (0x1), PRIORITY (0x2), RST_STREAM (0x3), SETTINGS (0x4), PUSH_PROMISE (0x5), PING (0x6), GOAWAY (0x7), WINDOW_UPDATE (0x8), CONTINUATION (0x9).
IANA created the HTTP/2 Settings Registry with 'Expert Review' policy. Initial entries: SETTINGS_HEADER_TABLE_SIZE (0x1, default 4096), SETTINGS_ENABLE_PUSH (0x2, default 1), SETTINGS_MAX_CONCURRENT_STREAMS (0x3, no default), SETTINGS_INITIAL_WINDOW_SIZE (0x4, default 65535), SETTINGS_MAX_FRAME_SIZE (0x5, default 16384), SETTINGS_MAX_HEADER_LIST_SIZE (0x6, advisory).
Cross-protocol attacks can occur if cleartext HTTP/2 traffic is misinterpreted by HTTP/1.x servers or intermediaries. The client connection preface ('PRI * HTTP/2.0...') was chosen to be an invalid HTTP/1.x method line, mitigating unintentional processing. Implementations MUST still validate the protocol identifier before processing frames.
HTTP/2 header compression creates CRIME-like attack vectors: compressing sensitive header fields (e.g., cookies, Authorization) alongside attacker-controlled data on the same connection can allow a compression-ratio side-channel to leak secrets. HTTP/2 does not mandate any mitigations but notes that disabling compression or limiting cross-origin header sharing reduces exposure.
HTTP/2 multiplexing creates denial-of-service vectors: an adversary can send many small or rapid RST_STREAM frames (causing server state churn), large header blocks exceeding available memory, or large numbers of SETTINGS frames requiring processing. Servers MUST impose limits on header block size and SHOULD rate-limit control frame processing.
HTTP/2 streams transition through seven states: idle, reserved (local), reserved (remote), open, half-closed (local), half-closed (remote), and closed. Transitions are triggered by sending or receiving HEADERS frames (opening), PUSH_PROMISE frames (reserving), the END_STREAM flag (half-closing), and RST_STREAM frames (immediate close). Frames received in an unexpected state MUST be treated as a PROTOCOL_ERROR.
Each SETTINGS parameter is encoded as an unsigned 16-bit identifier followed by an unsigned 32-bit value (6 octets total). A SETTINGS frame payload MUST be a multiple of 6 octets; otherwise it MUST be treated as a connection error of type FRAME_SIZE_ERROR.
Every HTTP/2 frame begins with a fixed 9-octet header: a 24-bit unsigned Length (payload size, excluding the header), an 8-bit Type, an 8-bit Flags field, a reserved 1-bit R field that MUST remain unset, and a 31-bit unsigned Stream Identifier. Stream identifier 0x0 is reserved for connection-level frames.
The GOAWAY frame contains a reserved 1-bit field, a 31-bit Last-Stream-ID (highest stream identifier processed by the sender), a 32-bit Error Code, and optional opaque Additional Debug Data. It signals intent to close the connection and the boundary of reliably processed streams.
The PING frame (type=0x6) carries exactly 8 octets of opaque data; a sender echoes this data in a PING with the ACK flag set. A PING frame with a length other than 8 octets MUST be treated as a connection error of type FRAME_SIZE_ERROR.
The RST_STREAM frame (type=0x3) carries a single unsigned 32-bit Error Code and has a fixed payload length of exactly 4 octets. Any other length MUST be treated as a connection error of type FRAME_SIZE_ERROR.
The WINDOW_UPDATE frame (type=0x8) payload is a reserved 1-bit field plus an unsigned 31-bit Window Size Increment (valid range: 1 to 2^31-1 octets). A value of 0 MUST be treated as a stream error (stream-level) or connection error (connection-level) of type PROTOCOL_ERROR.