Skip to main content

9. HTTP/2 Connections

HTTP/2 connections are application-layer protocols running on top of a reliable transport [TCP] that use Transport Layer Security (TLS) [TLS13] to protect the data exchanged over the network.

HTTP/2 uses the same "http" and "https" URI schemes as HTTP/1.1. HTTP/2 shares the same default port numbers: 80 for "http" URIs and 443 for "https" URIs. As a result, implementations need to handle requests to target resource URIs such as http://example.org/foo or https://example.com/bar by first discovering whether the upstream server (the immediate peer to which the client wishes to establish a connection) supports HTTP/2.

9.1. Connection Management​

HTTP/2 connections are persistent. For best performance, it is expected that clients will not close connections until it is determined that no further communication with a server is necessary (for example, when a user navigates away from a particular web page) or until the server closes the connection.

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.

A client can create additional connections as replacements, either to replace connections that are close to exhausting the available stream identifier space (Section 5.1.1), to refresh the keying material for a TLS connection, or to replace connections that have encountered errors (Section 5.4.1).

A client MAY open multiple connections to the same target for the purpose of: creating new connections to attempt requests that are atomic (see Section 9.1.2), or replacing any stream identifier greater than 0 that was received in a GOAWAY frame and is in the "active" or "idle" state (see Section 6.8).

Servers are encouraged to maintain open connections for as long as possible but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the transport-layer TCP connection, the terminating endpoint SHOULD first send a GOAWAY frame (Section 6.8) so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks.

9.1.1. Connection Reuse​

Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.5), MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server is authoritative (Section 10.1). For TCP connections without TLS, this depends on the host having resolved to the same IP address.

For "https" resources, connection reuse additionally depends on having a certificate that is valid for the host in the URI. The certificate presented by the server MUST satisfy any checks that the client would perform when forming a new TLS connection for the origin.

An origin server might offer a certificate with multiple origins, each of which is authoritative for using the connection. For example, a certificate might include multiple host names in the subjectAltName field. Alternatively, a host name containing a wildcard can also be applicable to other origins.

In some cases, the URI authority might differ from the set of origins identified in the certificate (for example, some deployments use URIs to carry assertions of identity established elsewhere), and other attributes of the authority do not match. A client MAY attempt to use an existing connection but MUST send the request with a URI that the client considers authoritative. If the server does not wish to accept the request, it SHOULD produce a 421 (Misdirected Request) status code, which will cause the client to retry the request.

If the client discovers that the connection it is attempting to reuse is no longer available, it MAY retry an unsafe request on a new connection.

A proxy MAY reuse connections to the same origin server.

9.1.2. The 421 (Misdirected Request) Status Code​

The 421 (Misdirected Request) status code indicates that the request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.

Clients receiving a 421 (Misdirected Request) response MAY retry the request, whether the request method is idempotent or not, over a different connection. This is possible because it is only permitted to generate a 421 response code before the server chooses not to provide an authoritative response.

This status code MUST NOT be generated by proxies. A 421 response is cacheable; it is heuristically cacheable by default unless otherwise indicated by the response (see Section 4.2.2 of [HTTP-CACHING]).

9.2. Use of TLS Features​

Implementations of HTTP/2 MUST use TLS version 1.2 [TLS12] or higher for "https" URIs. General guidance on the use of TLS implementations is given in [TLSBCP].

Implementations of TLS MUST support the Server Name Indication (SNI) [TLS-EXT] extension. HTTP/2 clients MUST indicate the target domain name during the TLS handshake unless an alternative mechanism to indicate the target host is provided.

Deployments of HTTP/2 that depend on TLS 1.3 [TLS13] or higher SHOULD support and use the TLS Application-Layer Protocol Negotiation (ALPN) extension [TLS-ALPN] for both clients and servers. Doing so identifies use of HTTP/2 during the TLS handshake without consuming a round trip.

While connection-level options are not specific to the use of HTTP, a server that uses HTTP/2 can convey its preferences for connections. TLS provides encryption, which can minimize the ability for eavesdroppers to learn about what information is exchanged between a client and server. TLS also provides integrity protection, ensuring that information is not modified in transit, whether through inadvertent network corruption or through active attackers.

The rules in Section 7.4.1.4 of [TLS12] MUST be followed after the use of HTTP/2 is negotiated. These rules use the server certificate to establish identity; client certificates cannot be used for this purpose. The checks of the certificate chain and certificate authority (CA) are also required.

If HTTP/2 is negotiated over TLS 1.2, the TLS 1.2 cipher suite black list (Section 9.2.2) MUST be offered.

Use of compressed TLS certificates is discouraged; certificates used by clients and servers in HTTP/2 SHOULD NOT be compressed unless explicitly requested by the client.

9.2.1. TLS 1.2 Features​

This section describes restrictions on the use of TLS 1.2 that are specific to HTTP/2. Because these restrictions are primarily addressed in TLS 1.3, implementations are encouraged to use TLS 1.3 or higher. Implementations that use only TLS 1.2 MUST comply with the requirements in this section.

9.2.1.1. TLS 1.2 Features for HTTP/2 Clients​

HTTP/2 client implementations MUST support sending TLS Server Name Indication (SNI) [TLS-EXT] through the extension field in the handshake.

HTTP/2 clients MUST support TLS Application-Layer Protocol Negotiation (ALPN) [TLS-ALPN].

9.2.1.2. TLS 1.2 Features for HTTP/2 Servers​

If the server negotiates HTTP/2 by some means other than ALPN or NPN, the server MUST provide the client an opportunity to indicate whether they are willing to use HTTP/2.

HTTP/2 servers SHOULD send the extended master secret extension [RFC7627]. If the client does not support this extension, the server MUST NOT resume a previously established session. If the extended master secret is negotiated, the server MAY resume a previously established session.

9.2.2. TLS 1.2 Cipher Suites​

Deployments of HTTP/2 over TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] with the secp256r1 [RFC8422] elliptic curve. Note that clients indicate their support for curves they support via the supported_groups extension [TLS13] in the TLS ClientHello message, and servers indicate support for a curve by selecting any of the listed curves that the extension offers.

Clients MAY advertise support of any cipher suite on TLS 1.2 used with HTTP/2. However, the cipher suites listed below have known qualities that are of poor quality and are therefore prohibited for use in HTTP/2 over TLS 1.2. These suites have one or more of the following properties:

  • NULL cipher suites, which provide no encryption.
  • Stream cipher-based suites, whose use in TLS is vulnerable to attacks.
  • RC4-based suites, which have serious security issues.
  • 3DES-based suites, which provide less than 112 bits of actual security.
  • CBC-mode block cipher suites, which are sensitive to attacks in TLS, particularly in TLS 1.2 and earlier.
  • RSA key exchange-based suites, which do not provide forward secrecy.
  • Suites that use Diffie-Hellman parameters that are discouraged for use with TLS.
  • Suites that use SHA-1 digests with poor support for AEAD algorithms.

A complete list of prohibited cipher suites is provided in Appendix A.

9.3. Connection Preface​

In HTTP/2, each endpoint is required to send a connection preface as a final confirmation of the protocol in use and to establish the initial settings for the HTTP/2 connection. The client and server each send a different connection preface.

The client connection preface starts with a sequence of 24 octets, which in hex notation is:

0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a

That is, the connection preface starts with the string PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n. This sequence MUST be followed by a SETTINGS frame (Section 6.5), which MAY be empty. The client sends the client connection preface immediately upon receipt of the server connection preface.

| Note: The client connection preface is selected so that the possibility of an HTTP/2 | connection being viewed as a valid HTTP/1.1 request by servers that process other HTTP | protocols is minimized. Note that no HTTP/1.1 request can reasonably include "PRI" as | a method token.

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.

A client that is upgrading having received a 101 (Switching Protocols) response that requires HTTP/1.1 (or earlier) MUST send the client connection preface immediately.

The server receives the client connection preface and the client receives the server connection preface. The SETTINGS frame in the connection preface MUST be acknowledged (see Section 6.5.3) as part of further connection establishment (see Section 3.4).

To avoid unnecessary latency, clients are permitted to send additional frames to the server immediately after sending the client connection preface, without waiting to receive the server connection preface. It is important to note, however, that the server connection preface SETTINGS frame might include parameters that are required to be honored in order to communicate with the server. Upon receiving the SETTINGS frame, the client SHOULD honor any parameters established. In some configurations, it is possible for the server to transmit SETTINGS before the client sends additional frames, providing an opportunity to avoid this issue.

Clients and servers MUST treat an invalid connection preface as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. 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.

Chapter 9 complete!

References​

  • [TCP] RFC 793
  • [TLS13] RFC 8446
  • [TLS12] RFC 5246
  • [TLS-EXT] RFC 6066
  • [TLS-ALPN] RFC 7301
  • [TLSBCP] RFC 9325
  • [TLS-ECDHE] RFC 5289
  • [RFC8422] RFC 8422
  • [RFC7627] RFC 7627
  • [ALT-SVC] RFC 7838
  • [HTTP-CACHING] RFC 9111
Last updated on