1.1.Prior Versions of HTTP

HTTP/1.1 ([HTTP/1.1]) uses whitespace-delimited text fields to convey HTTPmessages. While these exchanges are human readable, using whitespace formessage formatting leads to parsing complexity and excessive tolerance ofvariant behavior.¶

Because HTTP/1.1 does not include a multiplexing layer, multiple TCP connectionsare often used to service requests in parallel. However, that has a negativeimpact on congestion control and network efficiency, since TCP does not sharecongestion control across multiple connections.¶

HTTP/2 ([HTTP/2]) introduced a binary framing and multiplexing layerto improve latency without modifying the transport layer. However, because theparallel nature of HTTP/2's multiplexing is not visible to TCP's loss recoverymechanisms, a lost or reordered packet causes all active transactions toexperience a stall regardless of whether that transaction was directly impactedby the lost packet.¶

1.2.Delegation to QUIC

The QUIC transport protocol incorporates stream multiplexing and per-stream flowcontrol, similar to that provided by the HTTP/2 framing layer. By providingreliability at the stream level and congestion control across the entireconnection, QUIC has the capability to improve the performance of HTTP comparedto a TCP mapping. QUIC also incorporates TLS 1.3 ([TLS]) at thetransport layer, offering comparable confidentiality and integrity to runningTLS over TCP, with the improved connection setup latency of TCP Fast Open([TFO]).¶

This document defines HTTP/3: a mapping of HTTP semantics over the QUICtransport protocol, drawing heavily on the design of HTTP/2. HTTP/3 relies onQUIC to provide confidentiality and integrity protection of data; peerauthentication; and reliable, in-order, per-stream delivery. While delegatingstream lifetime and flow-control issues to QUIC, a binary framing similar to theHTTP/2 framing is used on each stream. Some HTTP/2 features are subsumed byQUIC, while other features are implemented atop QUIC.¶

QUIC is described in[QUIC-TRANSPORT]. For a full description ofHTTP/2, see[HTTP/2].¶

2.1.Document Organization

The following sections provide a detailed overview of the lifecycle of an HTTP/3connection:¶

• "Connection Setup and Management" (Section 3) covers how an HTTP/3endpoint is discovered and an HTTP/3 connection is established.¶
• "Expressing HTTP Semantics in HTTP/3" (Section 4) describes how HTTPsemantics are expressed using frames.¶
• "Connection Closure" (Section 5) describes how HTTP/3connections are terminated, either gracefully or abruptly.¶

The details of the wire protocol and interactions with the transport aredescribed in subsequent sections:¶

• "Stream Mapping and Usage" (Section 6) describes the way QUIC streamsare used.¶
• "HTTP Framing Layer" (Section 7) describes the frames usedon most streams.¶
• "Error Handling" (Section 8) describes how error conditions are handled andexpressed, either on a particular stream or for the connection as a whole.¶

Additional resources are provided in the final sections:¶

• "Extensions to HTTP/3" (Section 9) describes how new capabilities can beadded in future documents.¶
• A more detailed comparison between HTTP/2 and HTTP/3 can be found inAppendix A.¶

2.2.Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED","MAY", and "OPTIONAL" in this document are to be interpreted asdescribed in BCP 14[RFC2119][RFC8174] when, and only when, theyappear in all capitals, as shown here.¶

This document uses the variable-length integer encoding from[QUIC-TRANSPORT].¶

The following terms are used:¶

abort:

An abrupt termination of a connection or stream, possibly due to an errorcondition.¶

client:

The endpoint that initiates an HTTP/3 connection. Clients send HTTP requestsand receive HTTP responses.¶

connection:

A transport-layer connection between two endpoints using QUIC as thetransport protocol.¶

connection error:

An error that affects the entire HTTP/3 connection.¶

endpoint:

Either the client or server of the connection.¶

frame:

The smallest unit of communication on a stream in HTTP/3, consisting of aheader and a variable-length sequence of bytes structured according to theframe type.¶

Protocol elements called "frames" exist in both this document and[QUIC-TRANSPORT]. Where frames from[QUIC-TRANSPORT] are referenced, theframe name will be prefaced with "QUIC". For example, "QUIC CONNECTION_CLOSEframes". References without this preface refer to frames defined inSection 7.2.¶

HTTP/3 connection:

A QUIC connection where the negotiated application protocol is HTTP/3.¶

peer:

An endpoint. When discussing a particular endpoint, "peer" refers to theendpoint that is remote to the primary subject of discussion.¶

receiver:

An endpoint that is receiving frames.¶

sender:

An endpoint that is transmitting frames.¶

server:

The endpoint that accepts an HTTP/3 connection. Servers receive HTTP requestsand send HTTP responses.¶

stream:

A bidirectional or unidirectional bytestream provided by the QUIC transport.All streams within an HTTP/3 connection can be considered "HTTP/3 streams",but multiple stream types are defined within HTTP/3.¶

stream error:

An application-level error on the individual stream.¶

The term "content" is defined inSection 6.4 of [HTTP].¶

Finally, the terms "resource", "message", "user agent", "origin server","gateway", "intermediary", "proxy", and "tunnel" are defined inSection 3 of [HTTP].¶

Packet diagrams in this document use the format defined inSection 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of fields.¶

3.1.Discovering an HTTP/3 Endpoint

HTTP relies on the notion of an authoritative response: a response that has beendetermined to be the most appropriate response for that request given the stateof the target resource at the time of response message origination by (or at thedirection of) the origin server identified within the target URI. Locating anauthoritative server for an HTTP URI is discussed inSection 4.3 of [HTTP].¶

The "https" scheme associates authority with possession of a certificate thatthe client considers to be trustworthy for the host identified by the authoritycomponent of the URI. Upon receiving a server certificate in the TLS handshake,the clientMUST verify that the certificate is an acceptable match for the URI'sorigin server using the process described inSection 4.3.4 of [HTTP]. Ifthe certificate cannot be verified with respect to the URI's origin server, theclientMUST NOT consider the server authoritative for that origin.¶

A clientMAY attempt access to a resource with an "https" URI by resolving thehost identifier to an IP address, establishing a QUIC connection to that addresson the indicated port (including validation of the server certificate asdescribed above), and sending an HTTP/3 request message targeting the URIto the server over that secured connection. Unless some other mechanism is usedto select HTTP/3, the token "h3" is used in the Application-Layer ProtocolNegotiation (ALPN; see[RFC7301]) extension during the TLS handshake.¶

Connectivity problems (e.g., blocking UDP) can result in a failure to establisha QUIC connection; clientsSHOULD attempt to use TCP-based versions of HTTPin this case.¶

ServersMAY serve HTTP/3 on any UDP port; an alternative service advertisementalways includes an explicit port, and URIs contain either an explicit port or adefault port associated with the scheme.¶

Alt-Svc: h3=":50781"

3.2.Connection Establishment

HTTP/3 relies on QUIC version 1 as the underlying transport. The use of otherQUIC transport versions with HTTP/3MAY be defined by future specifications.¶

QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol.HTTP/3 clientsMUST support a mechanism to indicate the target host to theserver during the TLS handshake. If the server is identified by a domain name([DNS-TERMS]), clientsMUST send the Server Name Indication (SNI;[RFC6066]) TLS extension unless an alternative mechanism to indicate thetarget host is used.¶

QUIC connections are established as described in[QUIC-TRANSPORT]. Duringconnection establishment, HTTP/3 support is indicated by selecting the ALPNtoken "h3" in the TLS handshake. Support for other application-layer protocolsMAY be offered in the same handshake.¶

While connection-level options pertaining to the core QUIC protocol are set inthe initial crypto handshake, settings specific to HTTP/3 are conveyed in theSETTINGS frame. After the QUIC connection is established, aSETTINGS frameMUST be sent by each endpoint as the initial frame of theirrespective HTTPcontrol stream.¶

3.3.Connection Reuse

HTTP/3 connections are persistent across multiple requests. For bestperformance, it is expected that clients will not close connections until it isdetermined that no further communication with a server is necessary (forexample, when a user navigates away from a particular web page) or until theserver closes the connection.¶

Once a connection to a server endpoint exists, this connectionMAY be reused forrequests with multiple different URI authority components. To use an existingconnection for a new origin, clientsMUST validate the certificate presented bythe server for the new origin server using the process described inSection 4.3.4 of [HTTP]. This implies that clients will need to retain theserver certificate and any additional information needed to verify thatcertificate; clients that do not do so will be unable to reuse the connectionfor additional origins.¶

If the certificate is not acceptable with regard to the new origin for anyreason, the connectionMUST NOT be reused and a new connectionSHOULD beestablished for the new origin. If the reason the certificate cannot beverified might apply to other origins already associated with the connection,the clientSHOULD revalidate the server certificate for those origins. Forinstance, if validation of a certificate fails because the certificate hasexpired or been revoked, this might be used to invalidate all other origins forwhich that certificate was used to establish authority.¶

ClientsSHOULD NOT open more than one HTTP/3 connection to a given IP addressand UDP port, where the IP address and port might be derived from a URI, aselected alternative service ([ALTSVC]), a configured proxy, or nameresolution of any of these. A clientMAY open multiple HTTP/3 connections to thesame IP address and UDP port using different transport or TLS configurations butSHOULD avoid creating multiple connections with the same configuration.¶

Servers are encouraged to maintain open HTTP/3 connections for as long aspossible but are permitted to terminate idle connections if necessary. Wheneither endpoint chooses to close the HTTP/3 connection, the terminating endpointSHOULD first send aGOAWAY frame (Section 5.2) so that bothendpoints can reliably determine whether previously sent frames have beenprocessed and gracefully complete or terminate any necessary remaining tasks.¶

A server that does not wish clients to reuse HTTP/3 connections for a particularorigin can indicate that it is not authoritative for a request by sending a 421(Misdirected Request) status code in response to the request; seeSection 7.4 of [HTTP].¶

4.1.HTTP Message Framing

A client sends an HTTP request on arequest stream, which is a client-initiatedbidirectional QUIC stream; seeSection 6.1. A clientMUST send only asingle request on a given stream. A server sends zero or more interim HTTPresponses on the same stream as the request, followed by a single final HTTPresponse, as detailed below. SeeSection 15 of [HTTP] for a descriptionof interim and final HTTP responses.¶

Pushed responses are sent on a server-initiated unidirectional QUIC stream; seeSection 6.2.2. A server sends zero or more interim HTTP responses, followedby a single final HTTP response, in the same manner as a standard response.Push is described in more detail inSection 4.6.¶

On a given stream, receipt of multiple requests or receipt of an additional HTTPresponse following a final HTTP responseMUST be treated asmalformed.¶

An HTTP message (request or response) consists of:¶

1. the header section, including message control data, sent as a singleHEADERSframe,¶
2. optionally, the content, if present, sent as a series ofDATA frames, and¶
3. optionally, the trailer section, if present, sent as a singleHEADERS frame.¶

Header and trailer sections are described in Sections6.3 and6.5 of[HTTP]; the content is described inSection 6.4 of [HTTP].¶

Receipt of an invalid sequence of framesMUST be treated as aconnection errorof typeH3_FRAME_UNEXPECTED. In particular, aDATA frame beforeanyHEADERS frame, or aHEADERS orDATA frame after the trailingHEADERS frame,is considered invalid. Other frame types, especially unknown frame types,might be permitted subject to their own rules; seeSection 9.¶

A serverMAY send one or morePUSH_PROMISE framesbefore, after, or interleaved with the frames of a response message. ThesePUSH_PROMISE frames are not part of the response; seeSection 4.6 for moredetails.PUSH_PROMISE frames are not permitted onpush streams; a pushedresponse that includesPUSH_PROMISE framesMUST be treated as aconnection errorof typeH3_FRAME_UNEXPECTED.¶

Frames of unknown types (Section 9), including reserved frames(Section 7.2.8)MAY be sent on a request orpush stream before, after, orinterleaved with other frames described in this section.¶

TheHEADERS andPUSH_PROMISE frames might reference updates to the QPACK dynamictable. While these updates are not directly part of the message exchange, theymust be received and processed before the message can be consumed. SeeSection 4.2 for more details.¶

Transfer codings (seeSection 7 of [HTTP/1.1]) are not defined for HTTP/3;the Transfer-Encoding header fieldMUST NOT be used.¶

A responseMAY consist of multiple messages when and only when one or moreinterim responses (1xx; seeSection 15.2 of [HTTP]) precede a finalresponse to the same request. Interim responses do not contain contentor trailer sections.¶

An HTTP request/response exchange fully consumes a client-initiatedbidirectional QUIC stream. After sending a request, a clientMUST close thestream for sending. Unless using the CONNECT method (seeSection 4.4), clientsMUST NOT make stream closure dependent on receiving a response to their request.After sending a final response, the serverMUST close the stream for sending. Atthis point, the QUIC stream is fully closed.¶

When a stream is closed, this indicates the end of the final HTTP message.Because some messages are large or unbounded, endpointsSHOULD begin processingpartial HTTP messages once enough of the message has been received to makeprogress. If a client-initiated stream terminates without enough of the HTTPmessage to provide a complete response, the serverSHOULD abort its responsestream with the error codeH3_REQUEST_INCOMPLETE.¶

A server can send a complete response prior to the client sending an entirerequest if the response does not depend on any portion of the request that hasnot been sent and received. When the server does not need to receive theremainder of the request, itMAY abort reading therequest stream, send acomplete response, and cleanly close the sending part of the stream. The errorcodeH3_NO_ERRORSHOULD be used when requesting that the client stop sending ontherequest stream. ClientsMUST NOT discard complete responses as a result ofhaving their request terminated abruptly, though clients can always discardresponses at their discretion for other reasons. If the server sends a partialor complete response but does not abort reading the request, clientsSHOULDcontinue sending the content of the request and close the stream normally.¶

4.2.HTTP Fields

HTTP messages carry metadata as a series of key-value pairs called "HTTPfields"; see Sections6.3 and6.5 of[HTTP]. For a listing of registeredHTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry"maintained at<https://www.iana.org/assignments/http-fields/>. Like HTTP/2, HTTP/3 has additional considerations related tothe use of characters in field names, the Connection header field, andpseudo-header fields.¶

Field names are strings containing a subset of ASCII characters. Properties ofHTTP field names and values are discussed in more detail inSection 5.1 of [HTTP]. Characters in field namesMUST be converted to lowercase prior totheir encoding. A request or response containing uppercase characters in fieldnamesMUST be treated asmalformed.¶

HTTP/3 does not use the Connection header field to indicate connection-specificfields; in this protocol, connection-specific metadata is conveyed by othermeans. An endpointMUST NOT generate an HTTP/3 field section containingconnection-specific fields; any message containing connection-specific fieldsMUST be treated asmalformed.¶

The only exception to this is the TE header field, whichMAY be present in anHTTP/3 request header; when it is, itMUST NOT contain any value other than"trailers".¶

An intermediary transforming an HTTP/1.x message to HTTP/3MUST removeconnection-specific header fields as discussed inSection 7.6.1 of [HTTP], or their messages will be treated by other HTTP/3 endpoints asmalformed.¶

4.3.HTTP Control Data

Like HTTP/2, HTTP/3 employs a series of pseudo-header fields, where the fieldname begins with the: character (ASCII 0x3a). These pseudo-header fieldsconvey message control data; seeSection 6.2 of [HTTP].¶

Pseudo-header fields are not HTTP fields. EndpointsMUST NOT generatepseudo-header fields other than those defined in this document. However, anextension could negotiate a modification of this restriction; seeSection 9.¶

Pseudo-header fields are only valid in the context in which they are defined.Pseudo-header fields defined for requestsMUST NOT appear in responses;pseudo-header fields defined for responsesMUST NOT appear in requests.Pseudo-header fieldsMUST NOT appear in trailer sections. EndpointsMUST treat arequest or response that contains undefined or invalid pseudo-header fields asmalformed.¶

All pseudo-header fieldsMUST appear in the header section before regular headerfields. Any request or response that contains a pseudo-header field thatappears in a header section after a regular header fieldMUST be treated asmalformed.¶

4.4.The CONNECT Method

The CONNECT method requests that the recipient establish a tunnel to thedestination origin server identified by the request-target; seeSection 9.3.6 of [HTTP]. It is primarily used with HTTP proxies to establish a TLSsession with an origin server for the purposes of interacting with "https"resources.¶

In HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a tunnelto a remote host. In HTTP/2 and HTTP/3, the CONNECT method is used to establisha tunnel over a single stream.¶

A CONNECT requestMUST be constructed as follows:¶

• The :method pseudo-header field is set to "CONNECT"¶
• The :scheme and :path pseudo-header fields are omitted¶
• The :authority pseudo-header field contains the host and port to connect to(equivalent to the authority-form of the request-target of CONNECT requests;seeSection 7.1 of [HTTP]).¶

Therequest stream remains open at the end of the request to carry the data tobe transferred. A CONNECT request that does not conform to these restrictionsismalformed.¶

A proxy that supports CONNECT establishes a TCP connection ([RFC0793]) to theserver identified in the :authority pseudo-header field. Once this connectionis successfully established, the proxy sends aHEADERS frame containing a 2xxseries status code to the client, as defined inSection 15.3 of [HTTP].¶

AllDATA frames on the stream correspond to data sent or received on the TCPconnection. The payload of anyDATA frame sent by the client is transmitted bythe proxy to the TCP server; data received from the TCP server is packaged intoDATA frames by the proxy. Note that the size and number of TCP segments is notguaranteed to map predictably to the size and number of HTTPDATA or QUIC STREAMframes.¶

Once the CONNECT method has completed, onlyDATA frames are permitted to be senton the stream. Extension framesMAY be used if specifically permitted by thedefinition of the extension. Receipt of any other known frame typeMUST betreated as aconnection error of typeH3_FRAME_UNEXPECTED.¶

The TCP connection can be closed by either peer. When the client ends therequest stream (that is, the receive stream at the proxy enters the "Data Recvd"state), the proxy will set the FIN bit on its connection to the TCP server. Whenthe proxy receives a packet with the FIN bit set, it will close the send streamthat it sends to the client. TCP connections that remain half closed in asingle direction are not invalid, but are often handled poorly by servers, soclientsSHOULD NOT close a stream for sending while they still expect to receivedata from the target of the CONNECT.¶

A TCPconnection error is signaled by abruptly terminating the stream. A proxytreats any error in the TCP connection, which includes receiving a TCP segmentwith the RST bit set, as astream error of typeH3_CONNECT_ERROR.¶

Correspondingly, if a proxy detects an error with the stream or the QUICconnection, itMUST close the TCP connection. If the proxy detects that theclient has reset the stream or aborted reading from the stream, itMUST closethe TCP connection. If the stream is reset or reading is aborted by the client,a proxySHOULD perform the same operation on the other direction in order toensure that both directions of the stream are cancelled. In all these cases, ifthe underlying TCP implementation permits it, the proxySHOULD send a TCPsegment with the RST bit set.¶

Since CONNECT creates a tunnel to an arbitrary server, proxies that supportCONNECTSHOULD restrict its use to a set of known ports or a list of saferequest targets; seeSection 9.3.6 of [HTTP] for more details.¶

4.5.HTTP Upgrade

HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of [HTTP]) or the 101 (Switching Protocols) informational status code(Section 15.2.2 of [HTTP]).¶

4.6.Server Push

Server push is an interaction mode that permits a server to push arequest-response exchange to a client in anticipation of the client making theindicated request. This trades off network usage against a potential latencygain. HTTP/3 server push is similar to what is described inSection 8.2 of [HTTP/2], but it uses different mechanisms.¶

Each server push is assigned a unique push ID by the server. The push ID isused to refer to the push in various contexts throughout the lifetime of theHTTP/3 connection.¶

The push ID space begins at zero and ends at a maximum value set by theMAX_PUSH_ID frame. In particular, a server is notable to push until after the client sends aMAX_PUSH_ID frame. A client sendsMAX_PUSH_ID frames to control the number of pushes that a server can promise. AserverSHOULD use push IDs sequentially, beginning from zero. A clientMUSTtreat receipt of apush stream as aconnection error of typeH3_ID_ERRORwhen noMAX_PUSH_ID frame has been sent or when the streamreferences a push ID that is greater than the maximum push ID.¶

The push ID is used in one or morePUSH_PROMISE frames that carry the controldata and header fields of the request message. These frames are sent on therequest stream that generated the push. This allows the server push to beassociated with a client request. When the same push ID is promised on multiplerequest streams, the decompressed request field sectionsMUST contain the samefields in the same order, and both the name and the value in each fieldMUST beidentical.¶

The push ID is then included with thepush stream that ultimately fulfillsthose promises. Thepush stream identifies the push ID ofthe promise that it fulfills, then contains a response to the promised requestas described inSection 4.1.¶

Finally, the push ID can be used inCANCEL_PUSH frames; seeSection 7.2.3. Clients use this frame to indicate they do not wish toreceive a promised resource. Servers use this frame to indicate they will notbe fulfilling a previous promise.¶

Not all requests can be pushed. A serverMAY push requests that have thefollowing properties:¶

• cacheable; seeSection 9.2.3 of [HTTP]¶
• safe; seeSection 9.2.1 of [HTTP]¶
• does not include request content or a trailer section¶

The serverMUST include a value in the :authority pseudo-header field forwhich the server is authoritative. If the client has not yet validated theconnection for the origin indicated by the pushed request, itMUST perform thesame verification process it would do before sending a request for that originon the connection; seeSection 3.3. If this verification fails,the clientMUST NOT consider the server authoritative for that origin.¶

ClientsSHOULD send aCANCEL_PUSH frame upon receipt of aPUSH_PROMISE framecarrying a request that is not cacheable, is not known to be safe, thatindicates the presence of request content, or for which it does not consider theserver authoritative. Any corresponding responsesMUST NOT be used or cached.¶

Each pushed response is associated with one or more client requests. The pushis associated with therequest stream on which thePUSH_PROMISE frame wasreceived. The same server push can be associated with additional clientrequests using aPUSH_PROMISE frame with the same push ID on multiplerequeststreams. These associations do not affect the operation of the protocol, buttheyMAY be considered by user agents when deciding how to use pushed resources.¶

Ordering of aPUSH_PROMISE frame in relation to certain parts of the response isimportant. The serverSHOULD sendPUSH_PROMISE frames prior to sendingHEADERSorDATA frames that reference the promised responses. This reduces the chancethat a client requests a resource that will be pushed by the server.¶

Due to reordering,push stream data can arrive before the correspondingPUSH_PROMISE frame. When a client receives a newpush stream with anas-yet-unknown push ID, both the associated client request and the pushedrequest header fields are unknown. The client can buffer the stream data inexpectation of the matchingPUSH_PROMISE. The client can use stream flow control(Section 4.1 of [QUIC-TRANSPORT]) to limit the amount of data a server maycommit to the pushed stream. ClientsSHOULD abort reading and discard dataalready read frompush streams if no correspondingPUSH_PROMISE frame isprocessed in a reasonable amount of time.¶

Push stream data can also arrive after a client has cancelled a push. In thiscase, the client can abort reading the stream with an error code ofH3_REQUEST_CANCELLED. This asks the server not to transfer additional data andindicates that it will be discarded upon receipt.¶

Pushed responses that are cacheable (seeSection 3 of [HTTP-CACHING]) can bestored by the client, if it implements an HTTP cache. Pushed responses areconsidered successfully validated on the origin server (e.g., if the "no-cache"cache response directive is present; seeSection 5.2.2.4 of [HTTP-CACHING]) at thetime the pushed response is received.¶

Pushed responses that are not cacheableMUST NOT be stored by any HTTP cache.TheyMAY be made available to the application separately.¶

5.1.Idle Connections

Each QUIC endpoint declares an idle timeout during the handshake. If the QUICconnection remains idle (no packets received) for longer than this duration, thepeer will assume that the connection has been closed. HTTP/3 implementationswill need to open a new HTTP/3 connection for new requests if the existingconnection has been idle for longer than the idle timeout negotiated during theQUIC handshake, and theySHOULD do so if approaching the idle timeout; seeSection 10.1 of [QUIC-TRANSPORT].¶

HTTP clients are expected to request that the transport keep connections openwhile there are responses outstanding for requests or server pushes, asdescribed inSection 10.1.2 of [QUIC-TRANSPORT]. If the client is notexpecting a response from the server, allowing an idle connection to time out ispreferred over expending effort maintaining a connection that might not beneeded. A gatewayMAY maintain connections in anticipation of need rather thanincur the latency cost of connection establishment to servers. ServersSHOULD NOT actively keep connections open.¶

5.2.Connection Shutdown

Even when a connection is not idle, either endpoint can decide to stop using theconnection and initiate a graceful connection close. Endpoints initiate thegraceful shutdown of an HTTP/3 connection by sending aGOAWAY frame. TheGOAWAYframe contains an identifier that indicates to the receiver the range ofrequests or pushes that were or might be processed in this connection. Theserver sends a client-initiated bidirectional stream ID; the client sends apushID. Requests or pushes with the indicated identifier or greater are rejected(Section 4.1.1) by the sender of theGOAWAY. This identifierMAY bezero if no requests or pushes were processed.¶

The information in theGOAWAY frame enables a client and server to agree onwhich requests or pushes were accepted prior to the shutdown of the HTTP/3connection. Upon sending aGOAWAY frame, the endpointSHOULD explicitly cancel(see Sections4.1.1 and7.2.3) any requestsor pushes that have identifiers greater than or equal to the one indicated, inorder to clean up transport state for the affected streams. The endpointSHOULDcontinue to do so as more requests or pushes arrive.¶

EndpointsMUST NOT initiate new requests or promise new pushes on the connectionafter receipt of aGOAWAY frame from the peer. ClientsMAY establish a newconnection to send additional requests.¶

Some requests or pushes might already be in transit:¶

• Upon receipt of aGOAWAY frame, if the client has already sent requests witha stream ID greater than or equal to the identifier contained in theGOAWAYframe, those requests will not be processed. Clients can safely retryunprocessed requests on a different HTTP connection. A client that isunable to retry requests loses all requests that are in flight when theserver closes the connection.¶

  Requests on stream IDs less than the stream ID in aGOAWAY frame from theserver might have been processed; their status cannot be known until aresponse is received, the stream is reset individually, anotherGOAWAY isreceived with a lower stream ID than that of the request in question,or the connection terminates.¶

  ServersMAY reject individual requests on streams below the indicated ID ifthese requests were not processed.¶

• If a server receives aGOAWAY frame after having promised pushes with apushID greater than or equal to the identifier contained in theGOAWAY frame,those pushes will not be accepted.¶

ServersSHOULD send aGOAWAY frame when the closing of a connection is knownin advance, even if the advance notice is small, so that the remote peer canknow whether or not a request has been partially processed. For example, if anHTTP client sends a POST at the same time that a server closes a QUICconnection, the client cannot know if the server started to process that POSTrequest if the server does not send aGOAWAY frame to indicate what streams itmight have acted on.¶

An endpointMAY send multipleGOAWAY frames indicating different identifiers,but the identifier in each frameMUST NOT be greater than the identifier in anyprevious frame, since clients might already have retried unprocessed requests onanother HTTP connection. Receiving aGOAWAY containing a larger identifier thanpreviously receivedMUST be treated as aconnection error of typeH3_ID_ERROR.¶

An endpoint that is attempting to gracefully shut down a connection can send aGOAWAY frame with a value set to the maximum possible value (2⁶²-4for servers, 2⁶²-1 for clients). This ensures that the peer stopscreating new requests or pushes. After allowing time for any in-flight requestsor pushes to arrive, the endpoint can send anotherGOAWAY frame indicating whichrequests or pushes it might accept before the end of the connection. Thisensures that a connection can be cleanly shut down without losing requests.¶

A client has more flexibility in the value it chooses for the Push ID field in aGOAWAY that it sends. A value of 2⁶²-1 indicates that the server cancontinue fulfilling pushes that have already been promised. A smaller valueindicates the client will reject pushes with push IDs greater than or equal tothis value. Like the server, the clientMAY send subsequentGOAWAY frames solong as the specifiedpush ID is no greater than any previously sent value.¶

Even when aGOAWAY indicates that a given request or push will not be processedor accepted upon receipt, the underlying transport resources still exist. Theendpoint that initiated these requests can cancel them to clean up transportstate.¶

Once all accepted requests and pushes have been processed, the endpoint canpermit the connection to become idle, or itMAY initiate an immediate closure ofthe connection. An endpoint that completes a graceful shutdownSHOULD use theH3_NO_ERROR error code when closing the connection.¶

If a client has consumed all available bidirectional stream IDs with requests,the server need not send aGOAWAY frame, since the client is unable to makefurther requests.¶

5.3.Immediate Application Closure

An HTTP/3 implementation can immediately close the QUIC connection at any time.This results in sending a QUIC CONNECTION_CLOSE frame to the peer indicatingthat the application layer has terminated the connection. The application errorcode in this frame indicates to the peer why the connection is being closed.SeeSection 8 for error codes that can be used when closing a connection inHTTP/3.¶

Before closing the connection, aGOAWAY frameMAY be sent to allow the client toretry some requests. Including theGOAWAY frame in the same packet as the QUICCONNECTION_CLOSE frame improves the chances of the frame being received byclients.¶

If there are open streams that have not been explicitly closed, they areimplicitly closed when the connection is closed; seeSection 10.2 of [QUIC-TRANSPORT].¶

5.4.Transport Closure

For various reasons, the QUIC transport could indicate to the application layerthat the connection has terminated. This might be due to an explicit closureby the peer, a transport-level error, or a change in network topology thatinterrupts connectivity.¶

If a connection terminates without aGOAWAY frame, clientsMUST assume that anyrequest that was sent, whether in whole or in part, might have been processed.¶

6.1.Bidirectional Streams

All client-initiated bidirectional streams are used for HTTP requests andresponses. A bidirectional stream ensures that the response can be readilycorrelated with the request. These streams are referred to as request streams.¶

This means that the client's first request occurs on QUIC stream 0, withsubsequent requests on streams 4, 8, and so on. In order to permit these streamsto open, an HTTP/3 serverSHOULD configure non-zero minimum values for thenumber of permitted streams and the initial stream flow-control window. So asto not unnecessarily limit parallelism, at least 100 request streamsSHOULD bepermitted at a time.¶

HTTP/3 does not use server-initiated bidirectional streams, though an extensioncould define a use for these streams. ClientsMUST treat receipt of aserver-initiated bidirectional stream as aconnection error of typeH3_STREAM_CREATION_ERROR unless such an extension has beennegotiated.¶

6.2.Unidirectional Streams

Unidirectional streams, in either direction, are used for a range of purposes.The purpose is indicated by a stream type, which is sent as a variable-lengthinteger at the start of the stream. The format and structure of data thatfollows this integer is determined by the stream type.¶

Unidirectional Stream Header {  Stream Type (i),}

Two stream types are defined in this document:control streams(Section 6.2.1) andpush streams (Section 6.2.2).[QPACK] definestwo additional stream types. Other stream types can be defined by extensions toHTTP/3; seeSection 9 for more details. Some stream types are reserved(Section 6.2.3).¶

The performance of HTTP/3 connections in the early phase of their lifetime issensitive to the creation and exchange of data on unidirectional streams.Endpoints that excessively restrict the number of streams or the flow-controlwindow of these streams will increase the chance that the remote peer reachesthe limit early and becomes blocked. In particular, implementations shouldconsider that remote peers may wish to exercise reserved stream behavior(Section 6.2.3) with some of the unidirectional streams they are permittedto use.¶

Each endpoint needs to create at least one unidirectional stream for the HTTPcontrol stream. QPACK requires two additional unidirectional streams, and otherextensions might require further streams. Therefore, the transport parameterssent by both clients and serversMUST allow the peer to create at least threeunidirectional streams. These transport parametersSHOULD also provide at least1,024 bytes of flow-control credit to each unidirectional stream.¶

Note that an endpoint is not required to grant additional credits to create moreunidirectional streams if its peer consumes all the initial credits beforecreating the critical unidirectional streams. EndpointsSHOULD create the HTTPcontrol stream as well as the unidirectional streams required by mandatoryextensions (such as the QPACK encoder and decoder streams) first, and thencreate additional streams as allowed by their peer.¶

If the stream header indicates a stream type that is not supported by therecipient, the remainder of the stream cannot be consumed as the semantics areunknown. Recipients of unknown stream typesMUST either abort reading of thestream or discard incoming data without further processing. If reading isaborted, the recipientSHOULD use theH3_STREAM_CREATION_ERROR error code or areserved error code (Section 8.1). The recipientMUST NOT considerunknown stream types to be aconnection error of any kind.¶

As certain stream types can affect connection state, a recipientSHOULD NOTdiscard data from incoming unidirectional streams prior to reading the streamtype.¶

ImplementationsMAY send stream types before knowing whether the peer supportsthem. However, stream types that could modify the state or semantics ofexisting protocol components, including QPACK or other extensions,MUST NOT besent until the peer is known to support them.¶

A sender can close or reset a unidirectional stream unless otherwise specified.A receiverMUST tolerate unidirectional streams being closed or reset prior tothe reception of the unidirectional stream header.¶

Push Stream Header {  Stream Type (i) = 0x01,  Push ID (i),}

7.1.Frame Layout

All frames have the following format:¶

HTTP/3 Frame Format {  Type (i),  Length (i),  Frame Payload (..),}

A frame includes the following fields:¶

Type:

A variable-length integer that identifies the frame type.¶

Length:

A variable-length integer that describes the length in bytes ofthe Frame Payload.¶

Frame Payload:

A payload, the semantics of which are determined by the Type field.¶

Each frame's payloadMUST contain exactly the fields identified in itsdescription. A frame payload that contains additional bytes after theidentified fields or a frame payload that terminates before the end of theidentified fieldsMUST be treated as aconnection error of typeH3_FRAME_ERROR. In particular, redundant length encodingsMUSTbe verified to be self-consistent; seeSection 10.8.¶

When a stream terminates cleanly, if the last frame on the stream was truncated,thisMUST be treated as aconnection error of typeH3_FRAME_ERROR. Streams thatterminate abruptly may be reset at any point in a frame.¶

7.2.Frame Definitions

DATA Frame {  Type (i) = 0x00,  Length (i),  Data (..),}

HEADERS Frame {  Type (i) = 0x01,  Length (i),  Encoded Field Section (..),}

CANCEL_PUSH Frame {  Type (i) = 0x03,  Length (i),  Push ID (i),}

Setting {  Identifier (i),  Value (i),}SETTINGS Frame {  Type (i) = 0x04,  Length (i),  Setting (..) ...,}

PUSH_PROMISE Frame {  Type (i) = 0x05,  Length (i),  Push ID (i),  Encoded Field Section (..),}

GOAWAY Frame {  Type (i) = 0x07,  Length (i),  Stream ID/Push ID (i),}

MAX_PUSH_ID Frame {  Type (i) = 0x0d,  Length (i),  Push ID (i),}

8.1.HTTP/3 Error Codes

The following error codes are defined for use when abruptly terminating streams,aborting reading of streams, or immediately closing HTTP/3 connections.¶

H3_NO_ERROR (0x0100):

No error. This is used when the connection or stream needs to be closed, butthere is no error to signal.¶

H3_GENERAL_PROTOCOL_ERROR (0x0101):

Peer violated protocol requirements in a way that does not match a morespecific error code or endpoint declines to use the more specific error code.¶

H3_INTERNAL_ERROR (0x0102):

An internal error has occurred in the HTTP stack.¶

H3_STREAM_CREATION_ERROR (0x0103):

The endpoint detected that its peer created a stream that it will not accept.¶

H3_CLOSED_CRITICAL_STREAM (0x0104):

A stream required by the HTTP/3 connection was closed or reset.¶

H3_FRAME_UNEXPECTED (0x0105):

A frame was received that was not permitted in the current state or on thecurrent stream.¶

H3_FRAME_ERROR (0x0106):

A frame that fails to satisfy layout requirements or with an invalid sizewas received.¶

H3_EXCESSIVE_LOAD (0x0107):

The endpoint detected that its peer is exhibiting a behavior that might begenerating excessive load.¶

H3_ID_ERROR (0x0108):

A stream ID orpush ID was used incorrectly, such as exceeding a limit,reducing a limit, or being reused.¶

H3_SETTINGS_ERROR (0x0109):

An endpoint detected an error in the payload of aSETTINGS frame.¶

H3_MISSING_SETTINGS (0x010a):

NoSETTINGS frame was received at the beginning of thecontrol stream.¶

H3_REQUEST_REJECTED (0x010b):

A server rejected a request without performing any application processing.¶

H3_REQUEST_CANCELLED (0x010c):

The request or its response (including pushed response) is cancelled.¶

H3_REQUEST_INCOMPLETE (0x010d):

The client's stream terminated without containing a fully formed request.¶

H3_MESSAGE_ERROR (0x010e):

An HTTP message wasmalformed and cannot be processed.¶

H3_CONNECT_ERROR (0x010f):

The TCP connection established in response to a CONNECT request was reset orabnormally closed.¶

H3_VERSION_FALLBACK (0x0110):

The requested operation cannot be served over HTTP/3. The peer shouldretry over HTTP/1.1.¶

Error codes of the format0x1f * N + 0x21 for non-negative integer values ofN are reserved to exercise the requirement that unknown error codes be treatedas equivalent toH3_NO_ERROR (Section 9). ImplementationsSHOULD select anerror code from this space with some probability when they would have sentH3_NO_ERROR.¶

10.1.Server Authority

HTTP/3 relies on the HTTP definition of authority. The security considerationsof establishing authority are discussed inSection 17.1 of [HTTP].¶

10.2.Cross-Protocol Attacks

The use of ALPN in the TLS and QUIC handshakes establishes the targetapplication protocol before application-layer bytes are processed. This ensuresthat endpoints have strong assurances that peers are using the same protocol.¶

This does not guarantee protection from all cross-protocol attacks.Section 21.5 of [QUIC-TRANSPORT] describes some ways in which the plaintext of QUICpackets can be used to perform request forgery against endpoints that don't useauthenticated transports.¶

10.3.Intermediary-Encapsulation Attacks

The HTTP/3 field encoding allows the expression of names that are not validfield names in the syntax used by HTTP (Section 5.1 of [HTTP]). Requests orresponses containing invalid field namesMUST be treated asmalformed.Therefore, an intermediary cannot translate an HTTP/3 request or responsecontaining an invalid field name into an HTTP/1.1 message.¶

Similarly, HTTP/3 can transport field values that are not valid. While mostvalues that can be encoded will not alter field parsing, carriage return (ASCII0x0d), line feed (ASCII 0x0a), and the null character (ASCII 0x00) might beexploited by an attacker if they are translated verbatim. Any request orresponse that contains a character not permitted in a field valueMUST betreated asmalformed. Valid characters are defined by the"field-content" ABNF rule inSection 5.5 of [HTTP].¶

10.4.Cacheability of Pushed Responses

Pushed responses do not have an explicit request from the client; the request isprovided by the server in thePUSH_PROMISE frame.¶

Caching responses that are pushed is possible based on the guidance provided bythe origin server in the Cache-Control header field. However, this can causeissues if a single server hosts more than one tenant. For example, a servermight offer multiple users each a small portion of its URI space.¶

Where multiple tenants share space on the same server, that serverMUST ensurethat tenants are not able to push representations of resources that they do nothave authority over. Failure to enforce this would allow a tenant to provide arepresentation that would be served out of cache, overriding the actualrepresentation that the authoritative tenant provides.¶

Clients are required to reject pushed responses for which an origin server isnot authoritative; seeSection 4.6.¶

10.5.Denial-of-Service Considerations

An HTTP/3 connection can demand a greater commitment of resources to operatethan an HTTP/1.1 or HTTP/2 connection. The use of field compression and flowcontrol depend on a commitment of resources for storing a greater amount ofstate. Settings for these features ensure that memory commitments for thesefeatures are strictly bounded.¶

The number ofPUSH_PROMISE frames is constrained in a similar fashion. A clientthat accepts server pushSHOULD limit the number of push IDs it issues at atime.¶

Processing capacity cannot be guarded as effectively as state capacity.¶

The ability to send undefined protocol elements that the peer is required toignore can be abused to cause a peer to expend additional processing time. Thismight be done by setting multiple undefinedSETTINGS parameters, unknown frametypes, or unknown stream types. Note, however, that some uses are entirelylegitimate, such as optional-to-understand extensions and padding to increaseresistance to traffic analysis.¶

Compression of field sections also offers some opportunities to waste processingresources; seeSection 7 of [QPACK] for more details on potential abuses.¶

All these features -- i.e., server push, unknown protocol elements, fieldcompression -- have legitimate uses. These features become a burden only whenthey are used unnecessarily or to excess.¶

An endpoint that does not monitor such behavior exposes itself to a risk ofdenial-of-service attack. ImplementationsSHOULD track the use of thesefeatures and set limits on their use. An endpointMAY treat activity that issuspicious as aconnection error of typeH3_EXCESSIVE_LOAD, butfalse positives will result in disrupting valid connections and requests.¶

10.6.Use of Compression

Compression can allow an attacker to recover secret data when it is compressedin the same context as data under attacker control. HTTP/3 enables compressionof fields (Section 4.2); the following concerns also apply to the useof HTTP compressed content-codings; seeSection 8.4.1 of [HTTP].¶

There are demonstrable attacks on compression that exploit the characteristicsof the web (e.g.,[BREACH]). The attacker induces multiple requestscontaining varying plaintext, observing the length of the resulting ciphertextin each, which reveals a shorter length when a guess about the secret iscorrect.¶

Implementations communicating on a secure channelMUST NOT compress content thatincludes both confidential and attacker-controlled data unless separatecompression contexts are used for each source of data. CompressionMUST NOT beused if the source of data cannot be reliably determined.¶

Further considerations regarding the compression of field sections aredescribed in[QPACK].¶

10.7.Padding and Traffic Analysis

Padding can be used to obscure the exact size of frame content and is providedto mitigate specific attacks within HTTP, for example, attacks where compressedcontent includes both attacker-controlled plaintext and secret data (e.g.,[BREACH]).¶

Where HTTP/2 employs PADDING frames and Padding fields in other frames to make aconnection more resistant to traffic analysis, HTTP/3 can either rely ontransport-layer padding or employ the reserved frame and stream types discussedin Sections7.2.8 and6.2.3. These methods ofpadding produce different results in terms of the granularity of padding, howpadding is arranged in relation to the information that is being protected,whether padding is applied in the case of packet loss, and how an implementationmight control padding.¶

Reserved stream types can be used to give the appearance of sending traffic evenwhen the connection is idle. Because HTTP traffic often occurs in bursts,apparent traffic can be used to obscure the timing or duration of such bursts,even to the point of appearing to send a constant stream of data. However, assuch traffic is still flow controlled by the receiver, a failure to promptlydrain such streams and provide additional flow-control credit can limit thesender's ability to send real traffic.¶

To mitigate attacks that rely on compression, disabling or limiting compressionmight be preferable to padding as a countermeasure.¶

Use of padding can result in less protection than might seem immediatelyobvious. Redundant padding could even be counterproductive. At best, paddingonly makes it more difficult for an attacker to infer length information byincreasing the number of frames an attacker has to observe. Incorrectlyimplemented padding schemes can be easily defeated. In particular, randomizedpadding with a predictable distribution provides very little protection;similarly, padding payloads to a fixed size exposes information as payload sizescross the fixed-sized boundary, which could be possible if an attacker cancontrol plaintext.¶

10.8.Frame Parsing

Several protocol elements contain nested length elements, typically in the formof frames with an explicit length containing variable-length integers. Thiscould pose a security risk to an incautious implementer. An implementationMUSTensure that the length of a frame exactly matches the length of the fields itcontains.¶

10.9.Early Data

The use of 0-RTT with HTTP/3 creates an exposure to replay attack. Theanti-replay mitigations in[HTTP-REPLAY]MUST be applied when usingHTTP/3 with 0-RTT. When applying[HTTP-REPLAY] to HTTP/3, references to theTLS layer refer to the handshake performed within QUIC, while all references toapplication data refer to the contents of streams.¶

10.10.Migration

Certain HTTP implementations use the client address for logging oraccess-control purposes. Since a QUIC client's address might change during aconnection (and future versions might support simultaneous use of multipleaddresses), such implementations will need to either actively retrieve theclient's current address or addresses when they are relevant or explicitlyaccept that the original address might change.¶

10.11.Privacy Considerations

Several characteristics of HTTP/3 provide an observer an opportunity tocorrelate actions of a single client or server over time. These include thevalue of settings, the timing of reactions to stimulus, and the handling of anyfeatures that are controlled by settings.¶

As far as these create observable differences in behavior, they could be used asa basis for fingerprinting a specific client.¶

HTTP/3's preference for using a single QUIC connection allows correlation of auser's activity on a site. Reusing connections for different origins allowsfor correlation of activity across those origins.¶

Several features of QUIC solicit immediate responses and can be used by anendpoint to measure latency to their peer; this might have privacy implicationsin certain scenarios.¶

11.1.Registration of HTTP/3 Identification String

This document creates a new registration for the identification ofHTTP/3 in the "TLS Application-Layer Protocol Negotiation (ALPN)Protocol IDs" registry established in[RFC7301].¶

The "h3" string identifies HTTP/3:¶

Protocol:

HTTP/3¶

Identification Sequence:

0x68 0x33 ("h3")¶

Specification:

This document¶

11.2.New Registries

New registries created in this document operate under the QUIC registrationpolicy documented inSection 22.1 of [QUIC-TRANSPORT]. These registries allinclude the common set of fields listed inSection 22.1.1 of [QUIC-TRANSPORT].These registries are collected under the "Hypertext Transfer Protocol version 3(HTTP/3)" heading.¶

The initial allocations in these registries are all assigned permanent statusand list a change controller of the IETF and a contact of the HTTP working group(ietf-http-wg@w3.org).¶

A.1.Streams

HTTP/3 permits use of a larger number of streams (2⁶²-1) than HTTP/2.The same considerations about exhaustion of stream identifier space apply,though the space is significantly larger such that it is likely that otherlimits in QUIC are reached first, such as the limit on the connectionflow-control window.¶

In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by QUIC. QUICconsiders a stream closed when all data has been received and sent data has beenacknowledged by the peer. HTTP/2 considers a stream closed when the framecontaining the END_STREAM bit has been committed to the transport. As a result,the stream for an equivalent exchange could remain "active" for a longer periodof time. HTTP/3 servers might choose to permit a larger number of concurrentclient-initiated bidirectional streams to achieve equivalent concurrency toHTTP/2, depending on the expected usage patterns.¶

In HTTP/2, only request and response bodies (the frame payload ofDATA frames)are subject to flow control. All HTTP/3 frames are sent on QUIC streams, so allframes on all streams are flow controlled in HTTP/3.¶

Due to the presence of other unidirectional stream types, HTTP/3 does not relyexclusively on the number of concurrent unidirectional streams to control thenumber of concurrent in-flight pushes. Instead, HTTP/3 clients use theMAX_PUSH_ID frame to control the number of pushes received from an HTTP/3server.¶

A.2.HTTP Frame Types

Many framing concepts from HTTP/2 can be elided on QUIC, because the transportdeals with them. Because frames are already on a stream, they can omit thestream number. Because frames do not block multiplexing (QUIC's multiplexingoccurs below this layer), the support for variable-maximum-length packets can beremoved. Because stream termination is handled by QUIC, an END_STREAM flag isnot required. This permits the removal of the Flags field from the genericframe layout.¶

Frame payloads are largely drawn from[HTTP/2]. However, QUIC includes manyfeatures (e.g., flow control) that are also present in HTTP/2. In these cases,the HTTP mapping does not re-implement them. As a result, several HTTP/2 frametypes are not required in HTTP/3. Where an HTTP/2-defined frame is no longerused, the frame ID has been reserved in order to maximize portability betweenHTTP/2 and HTTP/3 implementations. However, even frame types that appear inboth mappings do not have identical semantics.¶

Many of the differences arise from the fact that HTTP/2 provides an absoluteordering between frames across all streams, while QUIC provides this guaranteeon each stream only. As a result, if a frame type makes assumptions that framesfrom different streams will still be received in the order sent, HTTP/3 willbreak them.¶

Some examples of feature adaptations are described below, as well as generalguidance to extension frame implementors converting an HTTP/2 extension toHTTP/3.¶

A.3.HTTP/2 SETTINGS Parameters

An important difference from HTTP/2 is that settings are sent once, as the firstframe of thecontrol stream, and thereafter cannot change. This eliminates manycorner cases around synchronization of changes.¶

Some transport-level options that HTTP/2 specifies via theSETTINGS frame aresuperseded by QUIC transport parameters in HTTP/3. The HTTP-level setting thatis retained in HTTP/3 has the same value as in HTTP/2. The supersededsettings are reserved, and their receipt is an error. SeeSection 7.2.4.1 for discussion of both the retained and reserved values.¶

Below is a listing of how each HTTP/2SETTINGS parameter is mapped:¶

SETTINGS_HEADER_TABLE_SIZE (0x01):

See[QPACK].¶

SETTINGS_ENABLE_PUSH (0x02):

This is removed in favor of theMAX_PUSH_ID frame, which provides a moregranular control over server push. Specifying a setting with the identifier0x02 (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the HTTP/3SETTINGS frame is an error.¶

SETTINGS_MAX_CONCURRENT_STREAMS (0x03):

QUIC controls the largest open stream ID as part of its flow-control logic.Specifying a setting with the identifier 0x03 (corresponding to theSETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3SETTINGS frame is anerror.¶

SETTINGS_INITIAL_WINDOW_SIZE (0x04):

QUIC requires both stream and connection flow-control window sizes to bespecified in the initial transport handshake. Specifying a setting with theidentifier 0x04 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE parameter)in the HTTP/3SETTINGS frame is an error.¶

SETTINGS_MAX_FRAME_SIZE (0x05):

This setting has no equivalent in HTTP/3. Specifying a setting with theidentifier 0x05 (corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) inthe HTTP/3SETTINGS frame is an error.¶

SETTINGS_MAX_HEADER_LIST_SIZE (0x06):

This setting identifier has been renamedSETTINGS_MAX_FIELD_SECTION_SIZE.¶

In HTTP/3, setting values are variable-length integers (6, 14, 30, or 62 bitslong) rather than fixed-length 32-bit fields as in HTTP/2. This will oftenproduce a shorter encoding, but can produce a longer encoding for settings thatuse the full 32-bit space. Settings ported from HTTP/2 might choose to redefinetheir value to limit it to 30 bits for more efficient encoding or to make useof the 62-bit space if more than 30 bits are required.¶

Settings need to be defined separately for HTTP/2 and HTTP/3. The IDs ofsettings defined in[HTTP/2] have been reserved for simplicity. Note thatthe settings identifier space in HTTP/3 is substantially larger (62 bits versus16 bits), so many HTTP/3 settings have no equivalent HTTP/2 code point. SeeSection 11.2.2.¶

As QUIC streams might arrive out of order, endpoints are advised not to wait forthe peers' settings to arrive before responding to other streams. SeeSection 7.2.4.2.¶

A.4.HTTP/2 Error Codes

QUIC has the same concepts of "stream" and "connection" errors that HTTP/2provides. However, the differences between HTTP/2 and HTTP/3 mean that errorcodes are not directly portable between versions.¶

The HTTP/2 error codes defined inSection 7 of [HTTP/2] logically map tothe HTTP/3 error codes as follows:¶

NO_ERROR (0x00):

H3_NO_ERROR inSection 8.1.¶

PROTOCOL_ERROR (0x01):

This is mapped toH3_GENERAL_PROTOCOL_ERROR except in cases where morespecific error codes have been defined. Such cases includeH3_FRAME_UNEXPECTED,H3_MESSAGE_ERROR, andH3_CLOSED_CRITICAL_STREAM definedinSection 8.1.¶

INTERNAL_ERROR (0x02):

H3_INTERNAL_ERROR inSection 8.1.¶

FLOW_CONTROL_ERROR (0x03):

Not applicable, since QUIC handles flow control.¶

SETTINGS_TIMEOUT (0x04):

Not applicable, since no acknowledgment ofSETTINGS is defined.¶

STREAM_CLOSED (0x05):

Not applicable, since QUIC handles stream management.¶

FRAME_SIZE_ERROR (0x06):

H3_FRAME_ERROR error code defined inSection 8.1.¶

REFUSED_STREAM (0x07):

H3_REQUEST_REJECTED (inSection 8.1) is used to indicate that arequest was not processed. Otherwise, not applicable because QUIC handlesstream management.¶

CANCEL (0x08):

H3_REQUEST_CANCELLED inSection 8.1.¶

COMPRESSION_ERROR (0x09):

Multiple error codes are defined in[QPACK].¶

CONNECT_ERROR (0x0a):

H3_CONNECT_ERROR inSection 8.1.¶

ENHANCE_YOUR_CALM (0x0b):

H3_EXCESSIVE_LOAD inSection 8.1.¶

INADEQUATE_SECURITY (0x0c):

Not applicable, since QUIC is assumed to provide sufficient security on allconnections.¶

HTTP_1_1_REQUIRED (0x0d):

H3_VERSION_FALLBACK inSection 8.1.¶

Error codes need to be defined for HTTP/2 and HTTP/3 separately. SeeSection 11.2.3.¶