Movatterモバイル変換

<?xml<!DOCTYPE rfc<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-quic-http-34" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true"sortRefs="true" symRefs="true" version="3">  <front>    <seriesInfo    <author      <organization>Akamai</organization>      <address>        <email>mbishop@evequefou.be</email>      </address>    </author>    <date    <area>Transport</area>    <workgroup>QUIC</workgroup>    <abstract>      <t>The QUIC transport protocol has several features that are desirable in atransport for HTTP, such as stream multiplexing, per-stream flow control, andlow-latency connection establishment.  This document describes a mapping of HTTPsemantics over QUIC.  This document also identifies HTTP/2 features that aresubsumed by and describes how HTTP/2 extensions can be ported to HTTP/3.</t>    </abstract>  </front>  <middle>    <section      <name>Introduction</name>      <t>HTTP semantics (<xref are used for a broad range of services on theInternet. These semantics have most commonly been used with HTTP/1.1 and HTTP/2.HTTP/1.1 has been used over a variety of transport and session layers, whileHTTP/2 has been used primarily with TLS over TCP. HTTP/3 supports the samesemantics over a new transport QUIC.</t>      <section        <name>Prior of HTTP</name>        <t>HTTP/1.1 (<xref uses whitespace-delimited text fields to convey HTTPmessages.  While these exchanges are using whitespace formessage formatting leads to parsing complexity and excessive tolerance ofvariant behavior.</t>        <t>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.</t>        <t>HTTP/2 (<xref 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.</t>      </section>      <section        <name>Delegation to QUIC</name>        <t>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 (<xref at thetransport layer, offering comparable confidentiality and integrity to runningTLS over TCP, with the improved connection setup latency of TCP Fast Open(<xref        <t>This document defines 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 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.</t>        <t>QUIC is described in <xref  For a full description ofHTTP/2, see <xref      </section>    </section>    <section      <name>HTTP/3 Protocol Overview</name>      <t>HTTP/3 provides a transport for HTTP semantics using the QUIC transport protocoland an internal framing layer similar to HTTP/2.</t>      <t>Once a client knows that an HTTP/3 server exists at a certain endpoint, it opensa QUIC connection. QUIC provides protocol negotiation, stream-basedmultiplexing, and flow control.  Discovery of an HTTP/3 endpoint is described in<xref      <t>Within each stream, the basic unit of HTTP/3 communication is a frame(<xref  Each frame type serves a different purpose.  For example,and frames form the basis of HTTP requests and responses(<xref  Frames that apply to the entire connection areconveyed on a dedicated      <t>Multiplexing of requests is performed using the QUIC stream abstraction, described in <xref  Each request-response pairconsumes a single QUIC stream.  Streams are independent of each other, so onestream that is blocked or suffers packet loss does not prevent progress on otherstreams.</t>      <t>Server push is an interaction mode introduced in HTTP/2 (<xref thatpermits a server to push a request-response exchange to a client in anticipationof the client making the indicated request.  This trades off network usageagainst a potential latency gain.  Several HTTP/3 frames are used to manageserver push, such as and      <t>As in HTTP/2, request and response fields are compressed for transmission.Because HPACK (<xref relies on in-order transmission ofcompressed field sections (a guarantee not provided by QUIC), HTTP/3 replacesHPACK with QPACK (<xref QPACK uses separate unidirectional streams tomodify and track field table state, while encoded field sections refer to thestate of the table without modifying it.</t>      <section        <name>Document Organization</name>        <t>The following sections provide a detailed overview of the lifecycle of an HTTP/3connection:</t>        <ul (<xref covers how an HTTP/3endpoint is discovered and an HTTP/3 connection is established.</li> (<xref describes how HTTPsemantics are expressed using frames.</li> (<xref describes how HTTP/3connections are terminated, either gracefully or abruptly.</li>        </ul>        <t>The details of the wire protocol and interactions with the transport aredescribed in subsequent sections:</t>        <ul (<xref describes the way QUIC streamsare used.</li> (<xref describes the frames usedon most streams.</li> (<xref describes how error conditions are handled andexpressed, either on a particular stream or for the connection as a whole.</li>        </ul>        <t>Additional resources are provided in the final sections:</t>        <ul (<xref describes how new capabilities can beadded in future documents.</li>          <li>A more detailed comparison between HTTP/2 and HTTP/3 can be found in<xref        </ul>      </section>      <section        <name>Conventions and Terminology</name>        <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALLNOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>","<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted asdescribed in BCP&nbsp;14 <xref format="default"/> <xref format="default"/> when, and only when, theyappear in all capitals, as shown here.</t>        <t>This document uses the variable-length integer encoding from<xref        <t>The following terms are used:</t>        <dl>          <dd>            <t>An abrupt termination of a connection or stream, possibly due to an errorcondition.</t>          </dd>          <dd>            <t>The endpoint that initiates an HTTP/3 connection.  Clients send HTTP requestsand receive HTTP responses.</t>          </dd>          <dd>            <t>A transport-layer connection between two using QUIC as thetransport protocol.</t>          </dd>          <dd>            <t>An error that affects the entire HTTP/3 connection.</t>          </dd>          <dd>            <t>Either the client or server of the connection.</t>          </dd>          <dd>            <t>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            <t>Protocol elements called "frames" exist in both this document and<xref Where frames from <xref are referenced, theframe name will be prefaced with  For example, "QUIC CONNECTION_CLOSE  References without this preface refer to frames defined in<xref          </dd>          <dd>            <t>A QUIC connection where the negotiated application protocol is HTTP/3.</t>          </dd>          <dd>            <t>An endpoint.  When discussing a particular endpoint, "peer" refers to theendpoint that is remote to the primary subject of discussion.</t>          </dd>          <dd>            <t>An endpoint that is receiving frames.</t>          </dd>          <dd>            <t>An endpoint that is transmitting frames.</t>          </dd>          <dd>            <t>The endpoint that accepts an HTTP/3 connection.  Servers receive HTTP requestsand send HTTP responses.</t>          </dd>          <dd>            <t>A bidirectional or unidirectional bytestream provided by the QUIC transport.All streams within an HTTP/3 connection can be considered "HTTP/3but multiple stream types are defined within HTTP/3.</t>          </dd>          <dd>            <t>An application-level error on the individual stream.</t>          </dd>        </dl>        <t>The term "content" is defined in <xref        <t>Finally, the terms "resource", "message", "user agent", "origin server","gateway", "intermediary", "proxy", and "tunnel" are defined in <xref        <t>Packet diagrams in this document use the format defined in<xref to illustrate the order and size of fields.</t>      </section>    </section>    <section      <name>Connection Setup and Management</name>      <section        <name>Discovering an HTTP/3 Endpoint</name>        <t>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 in <xref        <t>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 client          <bcp14>MUST</bcp14> verify that the certificate is an acceptable match for the URI'sorigin server using the process described in <xref Ifthe certificate cannot be verified with respect to the URI's origin server, theclient          <bcp14>MUST NOT</bcp14> consider the server authoritative for that origin.</t>        <t>A client          <bcp14>MAY</bcp14> 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 ProtocolNegotiation (ALPN; see <xref extension during the TLS handshake.</t>        <t>Connectivity problems (e.g., blocking UDP) can result in QUIC clients          <bcp14>SHOULD</bcp14> attempt to use TCP-based versions of HTTPin this case.</t>        <t>Servers          <bcp14>MAY</bcp14> 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.</t>        <section          <name>HTTP Alternative Services</name>          <t>An HTTP origin can advertise the availability of an equivalent HTTP/3 endpointvia the Alt-Svc HTTP response header field or the HTTP/2 ALTSVC frame(<xref using the "h3" ALPN token.</t>          <t>For example, an origin could indicate in an HTTP response that HTTP/3 wasavailable on UDP port 50781 at the same hostname by including the followingheader field:</t>Alt-Svc: h3=":50781"          <t>On receipt of an Alt-Svc record indicating HTTP/3 support, a client            <bcp14>MAY</bcp14> attemptto establish a QUIC connection to the indicated host and port; if thisconnection is successful, the client can send HTTP requests using the mappingdescribed in this document.</t>        </section>        <section          <name>Other Schemes</name>          <t>Although HTTP is independent of the transport protocol, the "http" schemeassociates authority with the ability to receive TCP connections on theindicated port of whatever host is identified within the authority component.Because HTTP/3 does not use TCP, HTTP/3 cannot be used for direct access to theauthoritative server for a resource identified by an "http" URI.  However,protocol extensions such as <xref permit the authoritative serverto identify other services that are also authoritative and that might bereachable over HTTP/3.</t>          <t>Prior to making requests for an origin whose scheme is not "https", the client            <bcp14>MUST</bcp14> ensure the server is willing to serve that scheme. For origins whose schemeis "http", an experimental method to accomplish this is described in<xref Other mechanisms might be defined for various schemes in thefuture.</t>        </section>      </section>      <section        <name>Connection Establishment</name>        <t>HTTP/3 relies on QUIC version 1 as the underlying transport.  The use of otherQUIC transport versions with HTTP/3          <bcp14>MAY</bcp14> be defined by future specifications.</t>        <t>QUIC version 1 uses TLS version 1.3 or greater as its handshake protocol.HTTP/3 clients          <bcp14>MUST</bcp14> support a mechanism to indicate the target host to theserver during the TLS handshake.  If the server is identified by a domain name(<xref clients          <bcp14>MUST</bcp14> send the Server Name Indication (SNI;<xref TLS extension unless an alternative mechanism to indicate thetarget host is used.</t>        <t>QUIC connections are established as described in <xref Duringconnection establishment, HTTP/3 support is indicated by selecting the ALPNtoken "h3" in the TLS handshake.  Support for other application-layer protocols          <bcp14>MAY</bcp14> be offered in the same handshake.</t>        <t>While connection-level options pertaining to the core QUIC protocol are set inthe initial crypto handshake, settings are conveyed in the frame. After the QUIC connection is established, a frame          <bcp14>MUST</bcp14> be sent by each endpoint as the initial frame of theirrespective HTTP <xref      </section>      <section        <name>Connection Reuse</name>        <t>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.</t>        <t>Once a connection to a server this connection          <bcp14>MAY</bcp14> be reused forrequests with multiple different URI authority components.  To use an existingconnection for a new origin, clients          <bcp14>MUST</bcp14> validate the certificate presented bythe server for the new origin server using the process described in <xref  This implies that clients will need to retain theserver certificate and any additional information needed to verify thatcertificate; clients do not do so will be unable to reuse the connectionfor additional origins.</t>        <t>If the certificate is not acceptable with regard to the new origin for anyreason, the connection          <bcp14>MUST NOT</bcp14> be reused and a new connection          <bcp14>SHOULD</bcp14> beestablished for the new origin.  If the reason the certificate cannot beverified might apply to other origins already associated with the connection,the client          <bcp14>SHOULD</bcp14> 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.</t>        <t>Clients          <bcp14>SHOULD NOT</bcp14> 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 (<xref a configured proxy, or nameresolution of any of these. A client          <bcp14>MAY</bcp14> open multiple HTTP/3 connections to thesame IP address and UDP port using different transport or TLS configurations but          <bcp14>SHOULD</bcp14> avoid creating multiple connections with the same configuration.</t>        <t>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 endpoint          <bcp14>SHOULD</bcp14> first send a frame (<xref so that bothendpoints can reliably determine whether previously sent frames have beenprocessed and gracefully complete or terminate any necessary remaining tasks.</t>        <t>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; see <xref      </section>    </section>    <section      <section        <name>HTTP Message        <t>A client sends an HTTP request on a which is a client-initiatedbidirectional QUIC stream; see <xref  A client          <bcp14>MUST</bcp14> 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. See <xref for a descriptionof interim and final HTTP responses.</t>        <t>Pushed responses are sent on a server-initiated unidirectional QUIC stream; see<xref  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 in <xref        <t>On a given stream, receipt of multiple requests or receipt of an additional HTTPresponse following a final HTTP response          <bcp14>MUST</bcp14> be treated as        <t>An HTTP message (request or response) consists of:</t>        <ol header section, sent as a single <xref          <li>optionally, the content, if present, sent as a series of <xref and</li>          <li>optionally, the trailer section, if present, sent as a single frame.</li>        </ol>        <t>Header and trailer sections are described in Sections <xref and <xref of <xref the content is described in <xref        <t>Receipt of an invalid sequence of frames          <bcp14>MUST</bcp14> be treated as aof type <xref  In particular, a frame beforeany frame, or a or frame after the trailing frame,is considered invalid.  Other frame types, especially unknown frame types,might be permitted subject to their own rules; see <xref        <t>A server          <bcp14>MAY</bcp14> send one or more framesbefore, after, or interleaved with the frames of a response message. These frames are not part of the response; see <xref for moredetails. frames are not permitted on a pushedresponse that includes frames          <bcp14>MUST</bcp14> be treated as aof type <xref        <t>Frames of unknown types (<xref including reserved frames(<xref          <bcp14>MAY</bcp14> be sent on a request or before, after, orinterleaved with other frames described in this section.</t>        <t>The and 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.  See<xref for more details.</t>        <t>Transfer codings (see <xref are not defined for HTTP/3;the Transfer-Encoding header field          <bcp14>MUST NOT</bcp14> be used.</t>        <t>A response          <bcp14>MAY</bcp14> consist of multiple messages when and only when one or moreinterim responses (1xx; see <xref precede a finalresponse to the same request.  Interim responses do not contain contentor trailer sections.</t>        <t>An HTTP request/response exchange fully consumes a client-initiatedbidirectional QUIC stream. After sending a request, a client          <bcp14>MUST</bcp14> close thestream for sending.  Unless using the CONNECT method (see <xref clients          <bcp14>MUST NOT</bcp14> make stream closure dependent on receiving a response to their request.After sending a final response, the server          <bcp14>MUST</bcp14> close the stream for sending. Atthis point, the QUIC stream is fully closed.</t>        <t>When a stream is closed, this indicates the end of the final HTTP message.Because some messages are large or unbounded, endpoints          <bcp14>SHOULD</bcp14> 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 server          <bcp14>SHOULD</bcp14> abort its responsestream with the error code <xref        <t>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, it          <bcp14>MAY</bcp14> abort reading the send acomplete response, and cleanly close the sending part of the stream.  The errorcode          <bcp14>SHOULD</bcp14> be used when requesting that the client stop sending onthe  Clients          <bcp14>MUST NOT</bcp14> 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, clients          <bcp14>SHOULD</bcp14>continue sending the of the request and close the stream normally.</t>        <section and        <t>HTTP messages carry metadata as a series of key-value pairs called see Sections <xref and <xref of <xref For a listing of registeredHTTP fields, see the "Hypertext Transfer Protocol (HTTP) Field Name Registry"maintained at <eref to        <t>Field names are strings containing a subset of ASCII characters. Properties ofHTTP field names and values are discussed in more detail in <xref in field names          <bcp14>MUST</bcp14> be converted to lowercase prior totheir encoding. A request or response containing uppercase characters in fieldnames          <bcp14>MUST</bcp14> be treated as does not use the Connection header field to indicate connection-specificfields; in this protocol, connection-specific metadata is conveyed by othermeans.  An endpoint          <bcp14>MUST NOT</bcp14> generate an HTTP/3 field section containingconnection-specific fields; any message containing connection-specific fields          <bcp14>MUST</bcp14> be treated as        <t>The only exception to this is the TE header field, which          <bcp14>MAY</bcp14> be present in anHTTP/3 request header; when it is, it          <bcp14>MUST NOT</bcp14> contain any value other than"trailers".</t>        <t>An intermediary transforming an HTTP/1.x message to HTTP/3          <bcp14>MUST</bcp14> removeconnection-specific header fields as discussed in <xref or their messages will be treated by other HTTP/3 endpoints as(<xref        <section        <t>Like HTTP/2, HTTP/3 employs a series of pseudo-header where the fieldname begins with the character (ASCII 0x3a).  These pseudo-header fieldsconvey        <t>Pseudo-header fields are not HTTP fields.  Endpoints          <bcp14>MUST NOT</bcp14> generatepseudo-header fields other than those defined in this anextension could negotiate a modification of this restriction; see<xref        <t>Pseudo-header fields are only valid in the context in which they are defined.Pseudo-header fields defined for requests          <bcp14>MUST NOT</bcp14> appear in responses;pseudo-header fields defined for responses          <bcp14>MUST NOT</bcp14> appear in requests.Pseudo-header fields          <bcp14>MUST NOT</bcp14> appear in trailer sections. Endpoints          <bcp14>MUST</bcp14> treat arequest or response that contains undefined or invalid pseudo-header fields as        <t>All pseudo-header fields          <bcp14>MUST</bcp14> 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 field          <bcp14>MUST</bcp14> be treated as          <t>The following pseudo-header fields are defined for requests:</t>          <dl>            <dd>              <t>Contains the HTTP method (<xref            <dd>              <t>Contains the scheme portion of the target URI (<xref            </dd>            <dt/>            <dd> is not restricted to URIs with scheme "http" and"https". A proxy or gateway can translate requests for non-HTTP schemes,enabling the use of HTTP to interact with non-HTTP services.</t>            </dd>            <dt/>            <dd>              <t>See <xref for guidance on using a scheme other than "https".</t>            </dd>            <dd>              <t>Contains the authority portion of the target URI (<xrefThe authority                <bcp14>MUST NOT</bcp14> include the deprecatedsubcomponent for URIs of scheme "http" or "https".</t>            </dd>            <dt/>            <dd>              <t>To ensure that the HTTP/1.1 request line can be reproduced accurately, thispseudo-header field                <bcp14>MUST</bcp14> be omitted when translating from an HTTP/1.1request that has a request target in form; see <xref  Clients that generate HTTP/3 requests directly                <bcp14>SHOULD</bcp14> usethe pseudo-header field instead of the Host field. Anintermediary that converts an HTTP/3 request to HTTP/1.1                <bcp14>MUST</bcp14> create a Hostfield if one is not present in a request by copying the value of the pseudo-header field.</t>            </dd>            <dd>              <t>Contains the path and query parts of the target URI (the "path-absolute"production and optionally a character followed by the"query" production; see Sections <xref and <xref of <xref            </dd>            <dt/>            <dd>              <t>This pseudo-header field                <bcp14>MUST NOT</bcp14> be empty for "http" or "https" URIs;"http" or "https" URIs that do not contain a path component                <bcp14>MUST</bcp14> include avalue of OPTIONS request that does not include a path value see <xref            </dd>          </dl>          <t>All HTTP/3 requests            <bcp14>MUST</bcp14> include exactly one value for theand pseudo-header fields, unless is a CONNECT request; see<xref          <t>If the pseudo-header field identifies a scheme that has a mandatoryauthority component (including "http" and "https"), the request            <bcp14>MUST</bcp14> containeither an pseudo-header field or a header field.  If thesefields are present, they            <bcp14>MUST NOT</bcp14> be empty.  If both fields are present, they            <bcp14>MUST</bcp14> contain the same value.  If the scheme does not have a mandatory authoritycomponent and none is provided in the request target, the request            <bcp14>MUST NOT</bcp14>contain the pseudo-header or header fields.</t>          <t>An HTTP request that omits mandatory pseudo-header fields or contains invalidvalues for those pseudo-header fields is          <t>HTTP/3 does not define a way to carry the version identifier that is included inthe HTTP/1.1 request          <t>For responses, a single ":status" pseudo-header field is defined that carriesthe HTTP status code; see <xref  This pseudo-headerfield            <bcp14>MUST</bcp14> be included in all responses; otherwise, the response is          <t>HTTP/3 does not define a way to carry the version or reason phrase that isincluded in an HTTP/1.1 status HTTP/3 responses have a of        </section>      </section>      <section        <name>The CONNECT Method</name>        <t>The CONNECT method requests that the recipient establish a tunnel to thedestination origin server identified by the request-target; see <xref It is primarily used with HTTP proxies to establish a TLSsession with an origin server for the purposes of interacting with "https"resources.</t>        <t>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.</t>        <t>A CONNECT request          <bcp14>MUST</bcp14> be constructed as follows:</t>        <ul          <li>The pseudo-header field is set to "CONNECT"</li>          <li>The and pseudo-header fields are omitted</li>          <li>The pseudo-header field contains the host and port to connect to(equivalent to the authority-form of the request-target of CONNECT requests;see <xref        </ul>        <t>The remains open at the end of the request to carry the data tobe transferred.  A CONNECT request that does not conform to these restrictionsis <xref        <t>A proxy that supports CONNECT establishes a TCP connection (<xref to theserver identified in the pseudo-header field.  Once this connectionis successfully established, the proxy sends a frame containing a 2xxseries status code to the client, as defined in <xref        <t>All frames on the stream correspond to data sent or received on the TCPconnection. The payload of any frame sent by the client is transmitted bythe proxy to the TCP server; data received from the TCP server is packaged into frames by the proxy. Note that the size and number of TCP segments is notguaranteed to map predictably to the size and number of HTTP or QUIC STREAMframes.</t>        <t>Once the CONNECT method has completed, only frames are permitted to be senton the stream.  Extension frames          <bcp14>MAY</bcp14> be used if specifically permitted by thedefinition of the extension.  Receipt of any other known frame type          <bcp14>MUST</bcp14> betreated as a of type <xref        <t>The TCP connection can be closed by either peer. When the client ends the (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 in asingle direction are not invalid, but are often handled poorly by servers, soclients          <bcp14>SHOULD NOT</bcp14> close a stream for sending while they still expect to receivedata from the target of the CONNECT.</t>        <t>A TCP 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 a of type <xref if a proxy detects an error with the stream or the QUICconnection, it          <bcp14>MUST</bcp14> close the TCP connection.  If the underlying TCP implementation permits it, the proxy          <bcp14>SHOULD</bcp14> send a TCPsegment with the RST bit set.</t>        <t>Since CONNECT creates a tunnel to an arbitrary server, proxies that supportCONNECT          <bcp14>SHOULD</bcp14> restrict its use to a set of known ports or a list of saferequest targets; see <xref for more      </section>      <section        <name>HTTP Upgrade</name>        <t>HTTP/3 does not support the HTTP Upgrade mechanism (<xref or 101 (Switching Protocols) informational status code(<xref      </section>      <section        <name>Server        <t>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 in<xref but uses different mechanisms.</t>        <t>Each server push is assigned a unique ID by the server.  The ID isused to refer to the push in various contexts throughout the lifetime of theHTTP/3 connection.</t>        <t>The ID space begins at and ends at a maximum value set by the<xref  In particular, a server is notable to push until after the client sends a frame.  A client sends frames to control the number of pushes that a server can promise.  Aserver          <bcp14>SHOULD</bcp14> use IDs sequentially, beginning from zero.  A client          <bcp14>MUST</bcp14>treat receipt of a as a of typewhen no frame has been sent or when the streamreferences a ID that is greater than the maximum ID.</t>        <t>The ID is used in one or more frames that carry the header of the request message.  These frames are sent on the that generated the push.  This allows the server push to beassociated with a client request.  When the same ID is promised on multiple the decompressed request field sections          <bcp14>MUST</bcp14> contain the samefields in the same order, and both the name and the value in each field          <bcp14>MUST</bcp14> beidentical.</t>        <t>The ID is then included with the that ultimately fulfillsthose  The identifies the ID ofthe promise that it fulfills, then contains a response to the promised requestas described in <xref        <t>Finally, the ID can be used in frames; see<xref  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.</t>        <t>Not all requests can be pushed.  A server          <bcp14>MAY</bcp14> push requests that have thefollowing properties:</t>        <ul          <li>cacheable; see <xref          <li>safe; see <xref          <li>does not include request or trailer section</li>        </ul>        <t>The server          <bcp14>MUST</bcp14> include a value in the pseudo-header field forwhich the server is authoritative.  If the client has not yet validated theconnection for the origin indicated by the pushed request, it          <bcp14>MUST</bcp14> perform thesame verification process it would do before sending a request for that originon the connection; see <xref  If this verification fails,the client          <bcp14>MUST NOT</bcp14> consider the server authoritative for that origin.</t>        <t>Clients          <bcp14>SHOULD</bcp14> send a frame upon receipt of a framecarrying a request that is not cacheable, is not known to be safe, thatindicates the presence of request or for which it does not consider theserver authoritative.  Any corresponding responses          <bcp14>MUST NOT</bcp14> be used or cached.</t>        <t>Each pushed response is associated with one or more client requests.  The pushis associated with the on which the frame wasreceived.  The same server push can be associated with additional clientrequests using a frame with the same ID on multiple  These associations do not affect the operation of the protocol, but          <bcp14>MAY</bcp14> be considered by user agents when deciding how to use pushed resources.</t>        <t>Ordering of a frame in relation to certain parts of the response isimportant. The server          <bcp14>SHOULD</bcp14> send frames prior to sendingor frames that reference the promised responses.  This reduces the chancethat a client requests a resource that will be pushed by the server.</t>        <t>Due to reordering, data can arrive before the corresponding frame.  When a client receives a new with anas-yet-unknown ID, both the associated client request and the pushedrequest header fields are unknown.  The client can buffer the stream data inexpectation of the matching The client can use stream flow control to limit the amount of data a server maycommit to the pushed        <t>Push stream data can also arrive after a client has a push. In thiscase, the client can abort reading the stream with an error code of This asks the server not to transfer additional data andindicates that it will be discarded upon receipt.</t>        <t>Pushed responses that are cacheable (see <xref 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; see <xref at thetime the pushed response is received.</t>        <t>Pushed responses that are not cacheable          <bcp14>MUST NOT</bcp14> be stored by any HTTP cache.They          <bcp14>MAY</bcp14> be made available to the application separately.</t>      </section>    </section>    <section      <name>Connection Closure</name>      <t>Once established, an HTTP/3 connection can be used for many requests andresponses over time until the connection is closed.  Connection closure canhappen in any of several different ways.</t>      <section        <name>Idle Connections</name>        <t>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          <bcp14>SHOULD</bcp14> do so if approaching the idle timeout; see<xref        <t>HTTP clients are expected to request that the transport keep connections openwhile there are responses outstanding for requests or server pushes, asdescribed in <xref 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 gateway          <bcp14>MAY</bcp14> maintain connections in anticipation of need rather thanincur the latency cost of connection establishment to servers. Servers          <bcp14>SHOULDNOT</bcp14> actively keep connections open.</t>      </section>      <section        <name>Connection Shutdown</name>        <t>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 a Theframe 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 ID; the client sends a  Requests or pushes with the indicated identifier or greater are rejected(<xref by the sender of the This identifier          <bcp14>MAY</bcp14> bezero if no requests or pushes were processed.</t>        <t>The information in the frame enables a client and server to agree onwhich requests or pushes were accepted prior to the shutdown of the HTTP/3connection. Upon sending a frame, the endpoint          <bcp14>SHOULD</bcp14> explicitly cancel(see <xref and <xref any requestsor pushes that have identifiers greater than or equal to indicated, inorder to clean up transport state for the affected streams. The endpoint          <bcp14>SHOULD</bcp14>continue to do so as more requests or pushes arrive.</t>        <t>Endpoints          <bcp14>MUST NOT</bcp14> initiate new requests or promise new pushes on the connectionafter receipt of a frame from the peer.  Clients          <bcp14>MAY</bcp14> establish a newconnection to send additional requests.</t>        <t>Some requests or pushes might already be in transit:</t>        <ul          <li>            <t>Upon receipt of a frame, if the client has already sent requests witha ID greater than or equal to the identifier contained in theframe, 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 on IDs less than the ID in a frame from theserver might have been processed; their status cannot be known until aresponse is received, the stream is reset individually, another isreceived with a lower ID than that of the request in question,or the connection              <bcp14>MAY</bcp14> reject individual requests on streams below the indicated ID ifthese requests were not processed.</t>          </li>          <li>If a server receives a frame after having promised pushes with a greater than or equal to the identifier contained in the frame,those pushes will not be accepted.</li>        </ul>        <t>Servers          <bcp14>SHOULD</bcp14> send a frame when the closing of a connection is knownin advance, even if the advance notice is small, so that the remote peer canknow whether a request has been partially  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 a frame to indicate what streams itmight have acted on.</t>        <t>An endpoint          <bcp14>MAY</bcp14> send multiple frames indicating different identifiers,but the identifier in each frame          <bcp14>MUST NOT</bcp14> be greater than the identifier in anyprevious frame, since clients might already have retried unprocessed requests onanother HTTP connection.  Receiving a containing a larger identifier thanpreviously received          <bcp14>MUST</bcp14> be treated as a of type <xref        <t>An endpoint that is attempting to gracefully shut down a connection can send a frame with a value set to the maximum possible value (2<sup>62</sup>-4for servers, 2<sup>62</sup>-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 another 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.</t>        <t>A client has more flexibility in the value it chooses for the Push ID in a that it sends.  A value of 2<sup>62</sup>-1 indicates that the server cancontinue fulfilling pushes that have already been promised. A smaller valueindicates the client will reject pushes with IDs greater than or equal tothis value.  Like the server, the client          <bcp14>MAY</bcp14> send subsequent frames solong as the specified is no greater than any previously sent value.</t>        <t>Even when a 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.</t>        <t>Once all accepted requests and pushes have been processed, the endpoint canpermit the connection to become idle, or          <bcp14>MAY</bcp14> initiate an immediate closure ofthe connection.  An endpoint that completes a graceful shutdown          <bcp14>SHOULD</bcp14> use the error code when closing the connection.</t>        <t>If a client has consumed all available bidirectional stream IDs with requests,the server need not send a frame, since the client is unable to makefurther requests.</t>      </section>      <section        <name>Immediate Application Closure</name>        <t>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.See <xref for error codes that can be used when closing a connection inHTTP/3.</t>        <t>Before closing the connection, a frame          <bcp14>MAY</bcp14> be sent to allow the client toretry some requests.  Including the frame in the same packet as the QUICCONNECTION_CLOSE frame improves the chances of the frame being received byclients.</t>        <t>If there are open streams that have not been explicitly closed, they areimplicitly closed when the connection is closed; see<xref      </section>      <section        <name>Transport Closure</name>        <t>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.</t>        <t>If a connection terminates without a frame, clients          <bcp14>MUST</bcp14> assume that anyrequest that was sent, whether in whole or in part, might have been processed.</t>      </section>    </section>    <section      <name>Stream Mapping and Usage</name>      <t>A QUIC stream provides reliable in-order delivery of bytes, but makes noguarantees about order of delivery with regard to bytes on other streams. Inversion 1 of QUIC, the stream data containing HTTP frames is carried by QUICSTREAM frames, but this framing is invisible to the HTTP framing layer. Thetransport layer buffers and orders received stream data, exposing a reliablebyte stream to the application. Although QUIC permits out-of-order deliverywithin a stream, HTTP/3 does not make use of this feature.</t>      <t>QUIC streams can be either unidirectional, carrying data only from initiator toreceiver, or  Streams can beinitiated by either the client or the server.  For more detail on QUIC streams,see <xref      <t>When HTTP fields and data are sent over QUIC, the QUIC layer handles most ofthe stream management.  HTTP does not need to do any separate multiplexing whenusing data sent over a QUIC stream always maps to a particular HTTPtransaction or to the entire HTTP/3 connection context.</t>      <section        <name>Bidirectional        <t>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.</t>        <t>This means that the client's first request occurs on QUIC stream 0, withsubsequent requests on 4, 8, and so on. In order to permit these streamsto open, an HTTP/3 server          <bcp14>SHOULD</bcp14> configure non-zero minimum values for thenumber of permitted streams and the initial stream window.  So asto not unnecessarily limit parallelism, at least 100 request streams          <bcp14>SHOULD</bcp14> bepermitted at a time.</t>        <t>HTTP/3 does not use server-initiated bidirectional streams, though an extensioncould define a use for these streams.  Clients          <bcp14>MUST</bcp14> treat receipt of aserver-initiated bidirectional stream as a of type unless such an extension has beennegotiated.</t>      </section>      <section        <name>Unidirectional Streams</name>        <t>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.</t>          <name>Unidirectional Stream Header</name>          <artworkUnidirectional Stream Header {  Stream Type (i),}]]></artwork>        </figure>        <t>Two stream types are defined in this document:(<xref and (<xref <xref definestwo additional stream types. Other stream types can be defined by extensions toHTTP/3; see <xref for more details. Some stream types are reserved(<xref        <t>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 thewindow 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(<xref with some of the unidirectional streams they are permittedto the transport parameterssent by both clients and servers          <bcp14>MUST</bcp14> allow the peer to create at leastunidirectional          <bcp14>SHOULD</bcp14> provide at least1,024 bytes of credit to each stream.</t>        <t>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. Endpoints          <bcp14>SHOULD</bcp14> create the HTTP 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.</t>        <t>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 types abort reading of thestream error code or areserved error code (<xref          <bcp14>MUST NOT</bcp14> consider to be a of any kind.</t>        <t>Implementations          <bcp14>MAY</bcp14> 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,          <bcp14>MUST NOT</bcp14> besent until the peer is known to support them.</t>        <t>A sender can close or reset a unidirectional stream unless otherwise specified.A receiver          <bcp14>MUST</bcp14> tolerate unidirectional streams being closed or reset prior tothe reception of the unidirectional stream header.</t>        <section          <name>Control          <t>A control stream is indicated by a stream type of 0x00.  Data on this streamconsists of HTTP/3 frames, as defined in <xref          <t>Each side            <bcp14>MUST</bcp14> initiate a single control stream at the beginning of theconnection and send its frame as the first frame on this stream.  Ifthe first frame of the control stream is any other frame type, this            <bcp14>MUST</bcp14> betreated as a of type Only one controlstream per peer is permitted; receipt of a second stream claiming to be acontrol stream            <bcp14>MUST</bcp14> be treated as a of type  The sender            <bcp14>MUST NOT</bcp14> close the control stream, and thereceiver            <bcp14>MUST NOT</bcp14> request that the sender close the control stream.  If eithercontrol stream is closed at any point, this            <bcp14>MUST</bcp14> be treated as a of type  Connection errors are described in<xref          <t>Because the contents of the control stream are used to manage the behavior ofother streams, endpoints            <bcp14>SHOULD</bcp14> provide enough credit to keep thepeer's control stream from becoming blocked.</t>          <t>A pair of unidirectional streams is used rather than a single bidirectionalstream.  This allows either peer to send data as soon as it is able.  Dependingon whether 0-RTT is available on the QUIC connection, either client or servermight be able to send stream data first.</t>        </section>        <section          <name>Push          <t>Server push is an optional feature introduced in HTTP/2 that allows a server toinitiate a response before a request has been made.  See <xref formore details.</t>          <t>A push stream is indicated by a stream type of 0x01, followed by theof the promise that it fulfills, encoded as a variable-length integer. Theremaining data on this stream consists of HTTP/3 frames, as defined in<xref and fulfills a promised server push by zero or more interim HTTPresponses followed by a single final HTTP response, as defined in<xref  Server push and IDs are described in<xref          <t>Only servers can push; if a server receives a client-initiated push stream, this            <bcp14>MUST</bcp14> be treated as a of type <xref            <name>Push Stream Header</name>            <artworkPush Stream Header {  Stream Type (i) = 0x01,  Push ID (i),}]]></artwork>          </figure>          <t>Each            <bcp14>MUST</bcp14> only be used once in a push stream header. If a push stream header includes a that was used in another pushstream header, the client            <bcp14>MUST</bcp14> treat this as a of type<xref        </section>        <section          <name>Reserved Stream Types</name>          <t>Stream types of the format <tt>0x1f * N + 0x21</tt> for non-negative integer values of are reserved to exercise the requirement that unknown types be ignored.These streams have no semantics, and can be sent when application-layerpadding is desired. They            <bcp14>MAY</bcp14> also be sent on connections where no data iscurrently being transferred. Endpoints            <bcp14>MUST NOT</bcp14> consider these streams to haveany meaning upon receipt.</t>          <t>The payload and length of the stream are selected in any manner the sendingimplementation chooses.  When sending a reserved stream type, the implementation            <bcp14>MAY</bcp14> either terminate the stream cleanly or reset it.  When resetting the stream,either the error code or a reserved error code(<xref            <bcp14>SHOULD</bcp14> be used.</t>        </section>      </section>    </section>    <section      <name>HTTP Framing Layer</name>      <t>HTTP frames are carried on QUIC streams, as described in <xrefHTTP/3 defines three stream types: This section describes HTTP/3 frame formats and their permitted streamtypes; see <xref for an overview.  A comparison betweenHTTP/2 and HTTP/3 frames is provided in <xref      <table        <name>HTTP/3 Frames and Stream Type Overview</name>        <thead>          <tr>            <th            <th Stream</th>            <th Stream</th>            <th Stream</th>            <th          </tr>        </thead>        <tbody>          <tr>            <td            <td            <td            <td            <td          </tr>          <tr>            <td            <td            <td            <td            <td          </tr>          <tr>            <td            <td            <td            <td            <td          </tr>          <tr>            <td            <td (1)</td>            <td            <td            <td          </tr>          <tr>            <td            <td            <td            <td            <td          </tr>          <tr>            <td            <td            <td            <td            <td          </tr>          <tr>            <td            <td            <td            <td            <td          </tr>          <tr>            <td            <td            <td            <td            <td          </tr>        </tbody>      </table>      <t>The frame can only occur as the first frame of a Control stream; thisis indicated in <xref with a (1).  Specific guidanceis provided in the relevant section.</t>      <t>Note that, unlike QUIC frames, HTTP/3 frames can span multiple packets.</t>      <section        <name>Frame Layout</name>        <t>All frames have the following format:</t>          <name>HTTP/3 Frame Format</name>          <artworkHTTP/3 Frame Format {  Type (i),  Length (i),  Frame Payload (..),}]]></artwork>        </figure>        <t>A frame includes the following fields:</t>        <dl>          <dd>            <t>A variable-length integer that identifies the frame type.</t>          </dd>          <dd>            <t>A variable-length integer that describes the length in bytes ofthe Frame Payload.</t>          </dd>          <dd>            <t>A payload, the semantics of which are determined by the Type field.</t>          </dd>        </dl>        <t>Each frame's payload          <bcp14>MUST</bcp14> 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 fields          <bcp14>MUST</bcp14> be treated as a of type<xref  In particular, redundant length encodings          <bcp14>MUST</bcp14>be verified to be self-consistent; see <xref        <t>When a stream terminates cleanly, if the last frame on the stream was truncated,this          <bcp14>MUST</bcp14> be treated as a of type <xref Streams thatterminate abruptly may be reset at any point in a frame.</t>      </section>      <section        <name>Frame Definitions</name>        <section          <t>DATA frames convey arbitrary, variable-length sequences of bytesassociated with HTTP request or response content.</t>          <t>DATA frames            <bcp14>MUST</bcp14> be associated with an HTTP request or response.  If a DATAframe is received on a the recipient            <bcp14>MUST</bcp14> respond with a of type <xref            <name>DATA Frame</name>            <artworkDATA Frame {  Type (i) =  Length (i),  Data (..),}]]></artwork>          </figure>        </section>        <section          <t>The HEADERS frame is used to carry an HTTP fieldencoded using QPACK. See <xref for more details.</t>            <name>HEADERS Frame</name>            <artworkHEADERS Frame {  Type (i) =  Length (i),  Encoded Field Section (..),}]]></artwork>          </figure>          <t>HEADERS frames can only be sent on or  If aHEADERS frame is received on a the recipient            <bcp14>MUST</bcp14> respond with a of type        </section>        <section          <t>The CANCEL_PUSH frame is used to request cancellation of a serverpush prior to the being received.  The CANCEL_PUSH frame identifiesa server push by (see <xref encoded as a variable-lengthinteger.</t>          <t>When a client sends it is indicating that it does not wishto receive the promised resource.  The server            <bcp14>SHOULD</bcp14> abort sending the resource,but the mechanism to do so depends on the state of the corresponding  If the server has not yet created a it does not createone.  If the is open, the server            <bcp14>SHOULD</bcp14> abruptly terminate thatstream.  If the has already ended, the server            <bcp14>MAY</bcp14> still abruptlyterminate the stream or            <bcp14>MAY</bcp14> take no action.</t>          <t>A server sends CANCEL_PUSH to indicate that it will not be fulfilling apromise was previously sent.  The client cannot expect the correspondingpromise to be fulfilled, unless it has already received and processed thepromised response. Regardless of whether a has been opened, a server            <bcp14>SHOULD</bcp14> send a CANCEL_PUSH frame when it determines that promise will not befulfilled.  If a stream has already been opened, the server can abort sending onthe stream with an error code of          <t>Sending a CANCEL_PUSH frame has no direct effect on the state of existing A client            <bcp14>SHOULD NOT</bcp14> send a CANCEL_PUSH frame when it has alreadyreceived a corresponding  A could arrive after a clienthas sent a CANCEL_PUSH frame, because a server might not have processed theCANCEL_PUSH. The client            <bcp14>SHOULD</bcp14> abort reading the stream with an error code of          <t>A CANCEL_PUSH frame is sent on the  Receiving a CANCEL_PUSHframe on a stream other than the            <bcp14>MUST</bcp14> be treated as a of type            <name>CANCEL_PUSH Frame</name>            <artworkCANCEL_PUSH Frame {  Type (i) =  Length (i),  Push ID (i),}]]></artwork>          </figure>          <t>The CANCEL_PUSH frame carries a encoded as a variable-length integer.The Push ID identifies the server push that is being cancelled; see<xref  If a CANCEL_PUSH frame is received that references agreater than currently allowed on the connection, this            <bcp14>MUST</bcp14> be treated as a of type          <t>If the client receives a CANCEL_PUSH frame, that frame might identify athat has not yet been mentioned by a frame due to reordering.  If aserver receives a CANCEL_PUSH frame for a that has not yet beenmentioned by a frame, this            <bcp14>MUST</bcp14> be treated as a oftype        </section>        <section          <t>The SETTINGS frame conveys configuration parameters that affect howendpoints communicate, such as preferences and constraints on peer behavior.Individually, a SETTINGS parameter can also be referred to as a "setting"; theidentifier and value of each setting parameter can be referred to as a "settingidentifier" and a "setting value".</t>          <t>SETTINGS frames always apply to an entire HTTP/3 connection, never a singlestream.  A SETTINGS frame            <bcp14>MUST</bcp14> be sent as the first frame of each(see <xref by each peer, and            <bcp14>MUST NOT</bcp14> be sent subsequently. Ifan endpoint receives a second SETTINGS frame on the the endpoint            <bcp14>MUST</bcp14> respond with a of type          <t>SETTINGS frames            <bcp14>MUST NOT</bcp14> be sent on any stream other than theIf an endpoint receives a SETTINGS frame on a different stream, the endpoint            <bcp14>MUST</bcp14> respond with a of type          <t>SETTINGS parameters are not negotiated; they describe characteristics of thesending peer that can be used by the receiving peer. However, a negotiationcan be implied by the use of each peer uses SETTINGS to advertise aset of supported values. The definition of the setting would describe how eachpeer combines the two sets to conclude which choice will be used.  SETTINGS doesnot provide a mechanism to identify when the choice takes effect.</t>          <t>Different values for the same parameter can be advertised by each peer. Forexample, a client might be willing to consume a very large response fieldsection, while servers are more cautious about request size.</t>          <t>The same setting identifier            <bcp14>MUST NOT</bcp14> occur more than once in the SETTINGS frame.A receiver            <bcp14>MAY</bcp14> treat the presence of duplicate setting identifiers as a of type          <t>The payload of a SETTINGS frame consists of zero or more parameters.  Eachparameter consists of a setting identifier and a value, both encoded as QUICvariable-length integers.</t>            <name>SETTINGS Frame</name>            <artworkSetting {  Identifier (i),  Value (i),}SETTINGS Frame {  Type (i) =  Length (i),  Setting (..) ...,}]]></artwork>          </figure>          <t>An implementation            <bcp14>MUST</bcp14> ignore any parameter with an identifier it doesnot understand.</t>          <section            <name>Defined SETTINGS Parameters</name>            <t>The following settings are defined in HTTP/3:</t>            <dl>              <dd> default value is unlimited.  See <xref for usage.</t>              </dd>            </dl>            <t>Setting identifiers of the format <tt>0x1f * N + 0x21</tt> for non-negative integervalues of are reserved to exercise the requirement that unknown identifiersbe ignored.  Such settings have no defined meaning. Endpoints              <bcp14>SHOULD</bcp14> include atleast one such setting in their SETTINGS frame. Endpoints              <bcp14>MUST NOT</bcp14> consider suchsettings to have any meaning upon receipt.</t>            <t>Because the setting has no defined meaning, the value of the setting can be anyvalue the implementation selects.</t>            <t>Setting identifiers were defined in <xref where there is nocorresponding HTTP/3 setting have also been reserved (<xref Thesereserved settings              <bcp14>MUST NOT</bcp14> be sent, and their receipt              <bcp14>MUST</bcp14> be treated as a of type            <t>Additional settings can be defined by extensions to HTTP/3; see <xreffor more details.</t>          </section>          <section            <name>Initialization</name>            <t>An HTTP implementation              <bcp14>MUST NOT</bcp14> send frames or requests that would be invalidbased on its current understanding of the peer's settings.</t>            <t>All settings begin at an initial value.  Each endpoint              <bcp14>SHOULD</bcp14> use these initialvalues to send messages before the peer's SETTINGS frame has arrived, as packetscarrying the settings can be lost or delayed.  When the SETTINGS frame arrives,any settings are changed to their new values.</t>            <t>This removes the need to wait for the SETTINGS frame before sending messages.Endpoints              <bcp14>MUST NOT</bcp14> require any data to be received from the peer prior tosending the SETTINGS frame; settings              <bcp14>MUST</bcp14> be sent as soon as the transport isready to send data.</t>            <t>For servers, the initial value of each client setting is the default value.</t>            <t>For clients using a 1-RTT QUIC connection, the initial value of each serversetting is the default value.  1-RTT keys will always become available prior tothe packet containing SETTINGS being processed by QUIC, even if the server sendsSETTINGS immediately.  Clients              <bcp14>SHOULD NOT</bcp14> wait indefinitely for SETTINGS toarrive before sending requests, but              <bcp14>SHOULD</bcp14> process received datagrams inorder to increase the likelihood of processing SETTINGS before sending the firstrequest.</t>            <t>When a 0-RTT QUIC connection is being used, the initial value of each serversetting is the value used in the previous session. Clients              <bcp14>SHOULD</bcp14> store thesettings the server provided in the HTTP/3 connection where resumptioninformation was provided, but              <bcp14>MAY</bcp14> opt not to store settings in certaincases (e.g., if the session ticket is received before the SETTINGS frame). Aclient              <bcp14>MUST</bcp14> comply with stored settings -- or default if no values arestored -- when attempting 0-RTT. Once a server has provided new settings,clients              <bcp14>MUST</bcp14> comply with those values.</t>            <t>A server can remember the settings that it or store anintegrity-protected copy of the values in the ticket and recover the informationwhen accepting 0-RTT data. A server uses the HTTP/3 settings values indetermining whether to accept 0-RTT data.  If the server cannot determine thatthe settings remembered by a client are compatible with its current settings, it              <bcp14>MUST NOT</bcp14> accept 0-RTT data.  Remembered settings are compatible if a clientcomplying with those settings would not violate the server's current settings.</t>            <t>A server              <bcp14>MAY</bcp14> accept 0-RTT and subsequently provide different settings in itsSETTINGS frame. If 0-RTT data is accepted by the server, its SETTINGS frame              <bcp14>MUSTNOT</bcp14> reduce any limits or alter any values that might be violated by the clientwith its 0-RTT data.  The server              <bcp14>MUST</bcp14> include all settings that differ fromtheir default values.  If a server accepts 0-RTT but then sends settings thatare not compatible with the previously specified settings, this              <bcp14>MUST</bcp14> be treatedas a of type If a server accepts 0-RTT butthen sends a SETTINGS frame that omits a setting value that the clientunderstands (apart from reserved setting identifiers) that was previouslyspecified to have a non-default value, this              <bcp14>MUST</bcp14> be treated as a of type          </section>        </section>        <section          <t>The PUSH_PROMISE frame is used to carry a promised request headersection from server to client on a            <name>PUSH_PROMISE Frame</name>            <artworkPUSH_PROMISE Frame {  Type (i) =  Length (i),  Push ID (i),  Encoded Field Section (..),}]]></artwork>          </figure>          <t>The payload consists of:</t>          <dl>            <dd>              <t>A variable-length integer that identifies the server push operation.  A is used in headers (<xref and            </dd> Field            <dd>              <t>QPACK-encoded request header fields for the promised response.  See<xref for more details.</t>            </dd>          </dl>          <t>A server            <bcp14>MUST NOT</bcp14> use a that is larger than the client has provided in a frame (<xref A client            <bcp14>MUST</bcp14> treat receipt of aPUSH_PROMISE frame that contains a larger than the client has advertisedas a of          <t>A server            <bcp14>MAY</bcp14> use the same in multiple PUSH_PROMISE frames. If so, thedecompressed request header sets            <bcp14>MUST</bcp14> contain the same fields in the same order,and both the name and the value in each field            <bcp14>MUST</bcp14> be exact matches. Clients            <bcp14>SHOULD</bcp14> compare the request header sections for resources promised multipletimes. If a client receives a that has already been promised and detectsa mismatch, it            <bcp14>MUST</bcp14> respond with a of type If the decompressed field sections match exactly, theclient            <bcp14>SHOULD</bcp14> associate the pushed content with each stream on which aPUSH_PROMISE frame was received.</t>          <t>Allowing duplicate references to the same is primarily to reduceduplication caused by concurrent requests.  A server            <bcp14>SHOULD</bcp14> avoid reusing a over a long period.  Clients are likely to consume server push responses andnot retain them for reuse over time.  Clients that see a PUSH_PROMISE frame thatuses a that they have already consumed and discarded are forced toignore the promise.</t>          <t>If a PUSH_PROMISE frame is received on the the client            <bcp14>MUST</bcp14>respond with a of type <xref          <t>A client            <bcp14>MUST NOT</bcp14> send a PUSH_PROMISE frame.  A server            <bcp14>MUST</bcp14> treat the receipt ofa PUSH_PROMISE frame as a of type <xref          <t>See <xref for a description of the overall server push mechanism.</t>        </section>        <section          <t>The GOAWAY frame is used to initiate graceful shutdown of an HTTP/3connection by either endpoint.  GOAWAY allows an endpoint to stop accepting newrequests or pushes while still finishing processing of previously receivedrequests and pushes.  This enables administrative actions, like servermaintenance.  GOAWAY by itself does not close a connection.</t>            <name>GOAWAY Frame</name>            <artworkGOAWAY Frame {  Type (i) =  Length (i),  Stream ID/Push ID}]]></artwork>          </figure>          <t>The GOAWAY frame is always sent on the  In thedirection, it carries a QUIC ID for a client-initiated bidirectionalstream encoded as a variable-length integer.  A client            <bcp14>MUST</bcp14> treat receipt of aGOAWAY frame containing a ID of any other type as a oftype          <t>In the direction, the GOAWAY frame carries a encoded asa variable-length integer.</t>          <t>The GOAWAY frame applies to the entire connection, not a specific stream.  Aclient            <bcp14>MUST</bcp14> treat a GOAWAY frame on a stream other than the as a of type <xref          <t>See <xref for more information on the use of the GOAWAY frame.</t>        </section>        <section          <t>The MAX_PUSH_ID frame is used by clients to control the number ofserver pushes that the server can initiate.  This sets the maximum value for a that the server can use in and frames.Consequently, this also limits the number of that the server caninitiate in addition to the limit maintained by the QUIC transport.</t>          <t>The MAX_PUSH_ID frame is always sent on the  Receipt of aMAX_PUSH_ID frame on any other stream            <bcp14>MUST</bcp14> be treated as a oftype          <t>A server            <bcp14>MUST NOT</bcp14> send a MAX_PUSH_ID frame.  A client            <bcp14>MUST</bcp14> treat the receipt ofa MAX_PUSH_ID frame as a of type          <t>The maximum is unset when an HTTP/3 connection is created, meaning thata server cannot push until it receives a MAX_PUSH_ID frame.  A client thatwishes to manage the number of promised server pushes can increase the maximum by sending MAX_PUSH_ID frames as the server fulfills or cancels serverpushes.</t>            <name>MAX_PUSH_ID Frame</name>            <artworkMAX_PUSH_ID Frame {  Type (i) =  Length (i),  Push ID (i),}]]></artwork>          </figure>          <t>The MAX_PUSH_ID frame carries a single variable-length integer that identifiesthe maximum value for a that the server can use; see <xref  AMAX_PUSH_ID frame cannot reduce the maximum receipt of a MAX_PUSH_IDframe that contains a smaller value than previously received            <bcp14>MUST</bcp14> be treated asa of type        </section>        <section          <name>Reserved Frame Types</name>          <t>Frame types of the format <tt>0x1f * N + 0x21</tt> for non-negative integer values of are reserved to exercise the requirement that unknown types be ignored(<xref  These frames have no semantics, and            <bcp14>MAY</bcp14> be sent on anystream where frames are allowed to be sent. This enables their use forapplication-layer padding.  Endpoints            <bcp14>MUST NOT</bcp14> consider these frames to have anymeaning upon receipt.</t>          <t>The payload and length of the frames are selected in any manner theimplementation chooses.</t>          <t>Frame types that were used in HTTP/2 where there is no corresponding HTTP/3frame have also been reserved (<xref  These frame types            <bcp14>MUST NOT</bcp14> besent, and their receipt            <bcp14>MUST</bcp14> be treated as a of type        </section>      </section>    </section>    <section      <name>Error      <t>When a stream cannot be completed successfully, QUIC allows the application toabruptly terminate (reset) that stream and communicate a reason; see <xref This is referred to as a "stream An HTTP/3implementation can decide to close a QUIC stream and communicate the type oferror. Wire encodings of error codes are defined in <xrefStream errors are distinct from HTTP status codes indicate errorconditions. Stream errors indicate that the sender did not transfer or consumethe full request or response, while HTTP status codes indicate the result of arequest that was successfully received.</t>      <t>If an entire connection needs to be terminated, QUIC similarly providesmechanisms to communicate a reason; see <xref  Thisis referred to as a "connection  Similar to stream errors, an HTTP/3implementation can terminate a QUIC connection and communicate the reason usingan error code from <xref      <t>Although the reasons for closing streams and connections are calledthese actions do not necessarily indicate a problem with the connection oreither implementation. For example, a stream can be reset if the requestedresource is no longer needed.</t>      <t>An endpoint        <bcp14>MAY</bcp14> choose to treat a stream error as a connection error undercertain circumstances, closing the entire connection in response to a conditionon a single stream.  Implementations need to consider the impact on outstandingrequests before making this choice.</t>      <t>Because new error codes can be defined without negotiation (see <xrefuse of an error code in an unexpected context or receipt of an unknown errorcode        <bcp14>MUST</bcp14> be treated as equivalent to  However, closing a streamcan have other effects regardless of the error code; for example, see<xref      <section        <name>HTTP/3 Error Codes</name>        <t>The following error codes are defined for use when abruptly terminating streams,aborting reading of streams, or immediately closing HTTP/3 connections.</t>        <dl>          <dd> error.  This is used when the connection or stream needs to be closed, butthere is no error to signal.</t>          </dd>          <dd> violated protocol requirements in a way that does not match a morespecific error or endpoint declines to use the more specific error code.</t>          </dd>          <dd> internal error has occurred in the HTTP stack.</t>          </dd>          <dd> endpoint detected that its peer created a stream that it will not accept.</t>          </dd>          <dd> stream required by the HTTP/3 connection was closed or reset.</t>          </dd>          <dd> frame was received that was not permitted in the current state or on thecurrent stream.</t>          </dd>          <dd> frame that fails to satisfy layout requirements or with an invalid sizewas received.</t>          </dd>          <dd> endpoint detected that its peer is exhibiting a behavior that might begenerating excessive load.</t>          </dd>          <dd> ID or was used incorrectly, such as exceeding a limit,reducing a limit, or being reused.</t>          </dd>          <dd> endpoint detected an error in the payload of a frame.</t>          </dd> frame was received at the beginning of the          <dd> server rejected a request without performing any application processing.</t>          </dd>          <dd> request or its response (including pushed response) is cancelled.</t>          </dd>          <dd> client's stream terminated without containing a request.</t>          </dd>          <dd> HTTP message was and cannot be processed.</t>          </dd>          <dd> TCP connection established in response to a CONNECT request was reset orabnormally closed.</t>          </dd>          <dd> requested operation cannot be served over HTTP/3.  The peer shouldretry over HTTP/1.1.</t>          </dd>        </dl>        <t>Error codes of the format <tt>0x1f * N + 0x21</tt> for non-negative integer values of are reserved to exercise the requirement that unknown error codes be treatedas equivalent to (<xref Implementations          <bcp14>SHOULD</bcp14> select anerror code from this space with some probability when they would have sent      </section>    </section>    <section      <name>Extensions to HTTP/3</name>      <t>HTTP/3 permits extension of the protocol.  Within the limitations described inthis section, protocol extensions can be used to provide additional services oralter any aspect of the protocol.  Extensions are effective only within thescope of a single HTTP/3 connection.</t>      <t>This applies to the protocol elements defined in this document.  This does notaffect the existing options for extending HTTP, such as defining new methods,status codes, or fields.</t>      <t>Extensions are permitted to use new frame types (<xref new settings(<xref new error codes (<xref or new unidirectionalstream types (<xref  Registries are established formanaging these extension points: frame types (<xref settings(<xref error codes (<xref and stream types(<xref      <t>Implementations        <bcp14>MUST</bcp14> ignore unknown or unsupported values in all extensibleprotocol elements.  Implementations        <bcp14>MUST</bcp14> discard abort reading onunidirectional streams that have unknown or unsupported types.  This means thatany of these extension points can be safely used by extensions without priorarrangement or negotiation.  However, where a known frame type is required to bein a specific location, such as the frame as the first frame of the (see <xref an unknown frame type does not satisfythat requirement and        <bcp14>SHOULD</bcp14> be treated as an error.</t>      <t>Extensions that could change the semantics of existing protocol components        <bcp14>MUST</bcp14>be negotiated before being used.  For example, an extension that changes thelayout of the frame cannot be used until the peer has given a positivesignal that this is acceptable.  Coordinating when such a revised layout comesinto effect could prove complex.  As such, allocating new identifiers fornew definitions of existing protocol elements is likely to be more effective.</t>      <t>This document does not mandate a specific method for negotiating the use of an but notes that a setting (<xref could be usedfor that purpose.  If both peers set a value that indicates willingness to usethe extension, then the extension can be used.  If a setting is used forextension negotiation, the default value        <bcp14>MUST</bcp14> be defined in such a fashion thatthe extension is disabled if the setting is omitted.</t>    </section>    <section      <name>Security Considerations</name>      <t>The security considerations of HTTP/3 should be comparable to those of HTTP/2with TLS.  However, many of the considerations from <xrefapply to <xref and are discussed in that document.</t>      <section        <name>Server Authority</name>        <t>HTTP/3 relies on the HTTP definition of authority. The security considerationsof establishing authority are discussed in <xref      </section>      <section        <name>Cross-Protocol Attacks</name>        <t>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.</t>        <t>This does not guarantee protection from all cross-protocol attacks. <xref describes some ways in which the plaintext of QUICpackets can be used to perform request forgery against endpoints that don't useauthenticated transports.</t>      </section>      <section Attacks</name>        <t>The HTTP/3 field encoding allows the expression of names that are not validfield names in the syntax used by HTTP (<xref Requests orresponses containing invalid field names          <bcp14>MUST</bcp14> be treated as intermediary cannot translate an HTTP/3 request or responsecontaining an invalid field name into an HTTP/1.1 message.</t>        <t>Similarly, HTTP/3 can transport field values that are not valid. While mostvalues that can be encoded will not alter field parsing, carriage return line feed and the character might beexploited by an attacker if they are translated verbatim. Any request orresponse that contains a character not permitted in a field value          <bcp14>MUST</bcp14> betreated as  Valid characters are defined by the"field-content" ABNF rule in <xref      </section>      <section        <name>Cacheability of Pushed Responses</name>        <t>Pushed responses do not have an explicit request from the client; the request isprovided by the server in the frame.</t>        <t>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.</t>        <t>Where multiple tenants share space on the same server, that server          <bcp14>MUST</bcp14> 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.</t>        <t>Clients are required to reject pushed responses for which an origin server isnot authoritative; see <xref      </section>      <section        <name>Denial-of-Service Considerations</name>        <t>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.</t>        <t>The number of frames is constrained in a similar fashion.  A clientthat accepts server push          <bcp14>SHOULD</bcp14> limit the number of IDs it issues at atime.</t>        <t>Processing capacity cannot be guarded as effectively as state capacity.</t>        <t>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 undefined 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.</t>        <t>Compression of field sections also offers some opportunities to waste processingresources; see <xref for more details on potential abuses.</t>        <t>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.</t>        <t>An endpoint that does not monitor such behavior exposes itself to a risk ofdenial-of-service attack.  Implementations          <bcp14>SHOULD</bcp14> track the use of thesefeatures and set limits on their use.  An endpoint          <bcp14>MAY</bcp14> treat activity that issuspicious as a of type butfalse positives will result in disrupting valid connections and requests.</t>        <section          <name>Limits on Field Section Size</name>          <t>A large field section (<xref can cause an implementation tocommit a large amount of state.  Header fields that are critical for routing canappear toward the end of a header section, which prevents streaming of theheader section to its ultimate destination.  This ordering and other reasons,such as ensuring cache correctness, mean that an endpoint likely needs to bufferthe entire header section.  Since there is no hard limit to the size of a fieldsection, some endpoints could be forced to commit a large amount of availablememory for header fields.</t>          <t>An endpoint can use the(<xref setting to advise peers of limits that might applyon the size of field sections. This setting is only advisory, so endpoints            <bcp14>MAY</bcp14>choose to send field sections that exceed this limit and risk having the requestor response being treated as  This setting is specific to an HTTP/3connection, so any request or response could encounter a hop with a lower,unknown limit.  An intermediary can attempt to avoid this problem by passing onvalues presented by different peers, but they are not obligated to do so.</t>          <t>A server that receives a larger field section than it is willing to handle cansend an HTTP 431 (Request Header Fields Too Large) status code (<xrefA client can discard responses that it cannot process.</t>        </section>        <section          <name>CONNECT Issues</name>          <t>The CONNECT method can be used to create disproportionate load on a proxy, sincestream creation is relatively inexpensive when compared to the creation andmaintenance of a TCP connection.  Therefore, a proxy that supports CONNECT mightbe more conservative in the number of simultaneous requests it accepts.</t>          <t>A proxy might also maintain some resources for a TCP connection beyond theclosing of the stream that carries the CONNECT request, since the outgoing TCPconnection remains in the TIME_WAIT state.  To account for this, a proxy mightdelay increasing the QUIC stream limits for some time after a TCP connectionterminates.</t>        </section>      </section>      <section        <name>Use of Compression</name>        <t>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 (<xref the following concerns also apply to the useof HTTP compressed content-codings; see <xref        <t>There are demonstrable attacks on compression that exploit the characteristicsof the web (e.g., <xref  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.</t>        <t>Implementations communicating on a secure channel          <bcp14>MUST NOT</bcp14> compress content thatincludes both confidential and attacker-controlled data unless separatecompression contexts are used for each source of data.  Compression          <bcp14>MUST NOT</bcp14> beused if the source of data cannot be reliably determined.</t>        <t>Further considerations regarding the compression of field sections aredescribed in <xref      </section>      <section        <name>Padding and Traffic Analysis</name>        <t>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.,<xref        <t>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 <xref and <xref  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.</t>        <t>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 credit can limit thesender's ability to send real traffic.</t>        <t>To mitigate attacks that rely on compression, disabling or limiting compressionmight be preferable to padding as a countermeasure.</t>        <t>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.</t>      </section>      <section        <name>Frame Parsing</name>        <t>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 implementation          <bcp14>MUST</bcp14>ensure that the length of a frame exactly matches the length of the fields itcontains.</t>      </section>      <section        <name>Early Data</name>        <t>The use of 0-RTT with HTTP/3 creates an exposure to replay attack.  Theanti-replay mitigations in <xref          <bcp14>MUST</bcp14> be applied when usingHTTP/3 with 0-RTT.  When applying <xref 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.</t>      </section>      <section        <name>Migration</name>        <t>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.</t>      </section>      <section        <name>Privacy Considerations</name>        <t>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.</t>        <t>As far as these create observable differences in behavior, they could be used asa basis for fingerprinting a specific client.</t>        <t>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.</t>        <t>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.</t>      </section>    </section>    <section      <name>IANA Considerations</name>      <t>This document registers a new ALPN protocol ID (<xref and creates newregistries that manage the assignment of in HTTP/3.</t>      <section        <name>Registration of HTTP/3 Identification String</name>        <t>This document creates a new registration for the identification ofHTTP/3 in the Protocol Negotiation (ALPN)Protocol IDs" registry established in <xref        <t>The "h3" string identifies HTTP/3:</t>        <dl>          <dd>            <t>HTTP/3</t>          </dd>          <dd>            <t>0x68 0x33 ("h3")</t>          </dd>          <dd>            <t>This document</t>          </dd>        </dl>      </section>      <section        <name>New Registries</name>        <t>New registries created in this document operate under the QUIC registrationpolicy documented in <xref  These registries allinclude the common set of fields listed in <xrefThese registries collected under "Hypertext Transfer Protocol version 3 heading.</t>        <t>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).</t>        <section          <name>Frame Types</name>          <t>This document establishes a registry for HTTP/3 frame type codes. The "HTTP/3Frame registry governs a 62-bit space.  This registry follows the QUICregistry policy; see <xref  Permanent registrations in this registryare assigned using the Specification Required policy (<xref except forvalues between 0x00 and 0x3f (in hexadecimal; inclusive), which are assignedusing Standards Action or IESG Approval as defined inSections <xref and <xref of <xref          <t>While this registry is separate from the "HTTP/2 Frame Type" registry defined in<xref it is preferable that the assignments parallel each other where thecode spaces overlap.  If an entry is present in only one registry, every effort            <bcp14>SHOULD</bcp14> be made to avoid assigning the corresponding value to an unrelatedoperation.  Expert reviewers            <bcp14>MAY</bcp14> reject unrelated registrations wouldconflict with the same value in the corresponding registry.</t>          <t>In addition to common fields as described in <xref permanentregistrations in this registry            <bcp14>MUST</bcp14> include the following field:</t>          <dl>            <dd>              <t>A name or label for the frame type.</t>            </dd>          </dl>          <t>Specifications of frame types            <bcp14>MUST</bcp14> include a description of the frame layout andits semantics, including any parts of the frame that are conditionally present.</t>          <t>The entries in <xref are registered by this document.</t>          <table            <name>Initial HTTP/3 Frame Types</name>            <thead>              <tr>                <th Type</th>                <th                <th              </tr>            </thead>            <tbody>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>              <tr>                <td                <td                <td              </tr>            </tbody>          </table>          <t>Each code of the format <tt>0x1f * N + 0x21</tt> for non-negative integer values of(that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)            <bcp14>MUST NOT</bcp14> be assigned byIANA and            <bcp14>MUST NOT</bcp14> appear in the listing of assigned values.</t>        </section>        <section          <name>Settings Parameters</name>          <t>This document establishes a registry for HTTP/3 settings.  The "HTTP/3 Settings"registry governs a 62-bit space.  This registry follows the QUIC registrypolicy; see <xref  Permanent registrations in this registry areassigned using the Specification Required policy (<xref except forvalues between 0x00 and 0x3f (in hexadecimal; inclusive), which are assignedusing Standards Action or IESG Approval as defined inSections <xref and <xref of <xref          <t>While this registry is separate from the "HTTP/2 Settings" registry defined in<xref it is preferable that the assignments parallel each other.  If anentry is present in only one registry, every effort            <bcp14>SHOULD</bcp14> be made to avoidassigning the corresponding value to an unrelated operation. Expert reviewers            <bcp14>MAY</bcp14> reject unrelated registrations would conflict with the same value inthe corresponding registry.</t>          <t>In addition to common fields as described in <xref permanentregistrations in this registry            <bcp14>MUST</bcp14> include the following fields:</t>          <dl>            <dd>              <t>A symbolic name for the setting.  Specifying a setting name is optional.</t>            </dd>            <dd>              <t>The value of the setting unless otherwise indicated. A default                <bcp14>SHOULD</bcp14> be themost restrictive possible value.</t>            </dd>          </dl>          <t>The entries in <xref are registered by this document.</t>          <table            <name>Initial HTTP/3 Settings</name>            <thead>              <tr>                <th Name</th>                <th                <th                <th              </tr>            </thead>            <tbody>              <tr>                <td                <td                <td                <td              </tr>              <tr>                <td                <td                <td                <td              </tr>              <tr>                <td                <td                <td                <td              </tr>              <tr>                <td                <td                <td                <td              </tr>              <tr>                <td                <td                <td                <td              </tr>              <tr>                <td                <td                <td                <td              </tr>            </tbody>          </table>          <t>Each code of the format <tt>0x1f * N + 0x21</tt> for non-negative integer values of(that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)            <bcp14>MUST NOT</bcp14> be assigned byIANA and            <bcp14>MUST NOT</bcp14> appear in the listing of assigned values.</t>        </section>        <section          <name>Error Codes</name>          <t>This document establishes a registry for HTTP/3 error codes. The "HTTP/3 Error registry manages a 62-bit space.  This registry follows the QUIC registrypolicy; see <xref  Permanent registrations in this registry areassigned using the Specification Required policy (<xref except forvalues between 0x00 and 0x3f (in hexadecimal; inclusive), which are assignedusing Standards Action or IESG Approval as defined inSections <xref and <xref of <xref          <t>Registrations for error codes are required to include a description of the errorcode.  An expert reviewer is advised to examine new registrations for possibleduplication with existing error codes.  Use of existing registrations is to beencouraged, but not mandated.  Use of values that are registered in the "HTTP/2Error Code" registry is discouraged, and expert reviewers            <bcp14>MAY</bcp14> reject suchregistrations.</t>          <t>In addition to common fields as described in <xref this registryincludes two additional fields.  Permanent registrations in this registry            <bcp14>MUST</bcp14>include the following field:</t>          <dl>            <dd>              <t>A name for the error code.</t>            </dd>            <dd>              <t>A brief description of the error code semantics.</t>            </dd>          </dl>          <t>The entries in <xref are registered by this document. Theseerror codes were selected from the range that operates on a SpecificationRequired policy to avoid collisions with HTTP/2 error codes.</t>          <table            <name>Initial HTTP/3 Error Codes</name>            <thead>              <tr>                <th                <th                <th                <th              </tr>            </thead>            <tbody>              <tr>                <td                <td                <td error</td>                <td              </tr>              <tr>                <td                <td                <td protocol error</td>                <td              </tr>              <tr>                <td                <td                <td error</td>                <td              </tr>              <tr>                <td                <td                <td creation error</td>                <td              </tr>              <tr>                <td                <td                <td stream was closed</td>                <td              </tr>              <tr>                <td                <td                <td not permitted in the current state</td>                <td              </tr>              <tr>                <td                <td                <td violated layout or size rules</td>                <td              </tr>              <tr>                <td                <td                <td generating excessive load</td>                <td              </tr>              <tr>                <td                <td                <td identifier was used incorrectly</td>                <td              </tr>              <tr>                <td frame contained invalid values</td>                <td              </tr>              <tr>                <td frame received</td>                <td              </tr>              <tr>                <td                <td                <td not processed</td>                <td              </tr>              <tr>                <td                <td                <td no longer needed</td>                <td              </tr>              <tr>                <td                <td                <td terminated early</td>                <td              </tr>              <tr>                <td                <td                <td message</td>                <td              </tr>              <tr>                <td                <td                <td reset or error on CONNECT request</td>                <td              </tr>              <tr>                <td                <td                <td over HTTP/1.1</td>                <td              </tr>            </tbody>          </table>          <t>Each code of the format <tt>0x1f * N + 0x21</tt> for non-negative integer values of(that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)            <bcp14>MUST NOT</bcp14> be assigned byIANA and            <bcp14>MUST NOT</bcp14> appear in the listing of assigned values.</t>        </section>        <section          <name>Stream Types</name>          <t>This document establishes a registry for HTTP/3 unidirectional stream types. The"HTTP/3 Stream registry governs a 62-bit space.  This registry followsthe QUIC registry policy; see <xref  Permanent registrations in thisregistry are assigned using the Specification Required policy (<xrefexcept for values between 0x00 and 0x3f (in hexadecimal; inclusive), which areassigned using Standards Action or IESG Approval as defined in Sections <xref and <xref of <xref          <t>In addition to common fields as described in <xref permanentregistrations in this registry            <bcp14>MUST</bcp14> include the following fields:</t>          <dl>            <dd>              <t>A name or label for the stream type.</t>            </dd>            <dd>              <t>Which endpoint on an HTTP/3 connection may initiate a stream of this type.Values are "Client", "Server", or "Both".</t>            </dd>          </dl>          <t>Specifications for permanent registrations            <bcp14>MUST</bcp14> include a description of thestream type, including the layout and semantics of the stream contents.</t>          <t>The entries in are registered by this document.</t>          <table            <thead>              <tr>                <th Type</th>                <th                <th                <th              </tr>            </thead>            <tbody>              <tr>                <td Stream</td>                <td                <td                <td              </tr>              <tr>                <td Stream</td>                <td                <td                <td              </tr>            </tbody>          </table>          <t>Each code of the format <tt>0x1f * N + 0x21</tt> for non-negative integer values of(that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe)            <bcp14>MUST NOT</bcp14> be assigned byIANA and            <bcp14>MUST NOT</bcp14> appear in the listing of assigned values.</t>        </section>      </section>    </section>  </middle>  <back>    <displayreference    <displayreference    <displayreference    <displayreference    <displayreference    <references>      <name>References</name>      <references>        <name>Normative References</name> in of        <reference          <front>            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>            <author            </author>            <author            </author>            <date document defines the core of the QUIC transport protocol.  QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances.  Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control use to the be and for          </front>          <seriesInfo          <seriesInfo        </reference> of RFC        <reference          <front>            <author            </author>            <author            </author>            <author            </author>            <date a for to be used          </front>          <seriesInfo          <seriesInfo        </reference>        <reference          <front>            <title>HTTP            <author            </author>            <author            </author>            <author            </author>            <date month='January' is a for document defines HTTP and header fields that  This document obsoletes RFC          </front>          <seriesInfo          <seriesInfo        </reference>        <reference          <front>            <author            </author>            <author            </author>            <author            </author>            <date a  This document the of of protocol that are by the and  This document and of RFC          </front>          <seriesInfo          <seriesInfo        </reference>      </references>      <references>        <name>Informative References</name>        <reference          <front>            <title>BREACH: Reviving the CRIME Attack</title>            <author              <organization/>            </author>            <author              <organization/>            </author>            <author              <organization/>            </author>            <date          </front>        </reference>      </references>    </references>    <section      <name>Considerations for Transitioning from HTTP/2</name>      <t>HTTP/3 is strongly informed by HTTP/2, and bears many similarities.  Thissection describes the approach taken to design HTTP/3, points out importantdifferences from HTTP/2, and describes how to map HTTP/2 extensions into HTTP/3.</t>      <t>HTTP/3 begins from the premise that similarity to HTTP/2 is preferable, but nota hard requirement.  HTTP/3 departs from HTTP/2 where QUIC differs from TCP,either to take advantage of QUIC features (like streams) or to accommodateimportant shortcomings (such as a lack of total ordering). HTTP/3similar to HTTP/2 in key aspects, such as the relationship of requests andresponses to the details of the HTTP/3 design are substantiallydifferent from HTTP/2.</t>      <t>Some important departures are noted in this section.</t>      <section        <name>Streams</name>        <t>HTTP/3 permits use of a larger number of streams (2<sup>62</sup>-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 connection window.</t>        <t>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.</t>        <t>In HTTP/2, only request and response bodies (the frame payload of frames)are subject to flow control.  All HTTP/3 frames are sent on QUIC streams, so allframes on all streams are in HTTP/3.</t>        <t>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 the frame to control the number of pushes received from an HTTP/3server.</t>      </section>      <section        <name>HTTP Frame Types</name>        <t>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.</t>        <t>Frame payloads are largely drawn from <xref 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.</t>        <t>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.</t>        <t>Some examples of feature adaptations are described below, as well as generalguidance to extension frame implementors converting an HTTP/2 extension toHTTP/3.</t>        <section          <name>Prioritization Differences</name>          <t>HTTP/2 specifies priority assignments in PRIORITY frames and (optionally) in frames. HTTP/3 does not provide a means of signaling priority.</t>          <t>Note while there is no explicit signaling for priority, this does not meanthat prioritization is not important for achieving good performance.</t>        </section>        <section          <name>Field Compression Differences</name>          <t>HPACK was designed with the assumption of in-order delivery. A sequence ofencoded field sections must arrive (and be decoded) at an endpoint in the sameorder in which they were encoded. This ensures that the dynamic state at the twoendpoints remains in sync.</t>          <t>Because this total ordering is not provided by QUIC, HTTP/3 uses a modifiedversion of HPACK, called QPACK.  QPACK uses a single unidirectional stream tomake all modifications to the dynamic table, ensuring a total order of updates.All frames that contain encoded fields merely reference the table state at agiven time without modifying it.</t>          <t><xref provides additional details.</t>        </section>        <section Differences</name>          <t>HTTP/2 specifies a stream mechanism. Although all HTTP/2 frames aredelivered on streams, only the frame payload is subject to flow control.QUIC provides flow control for stream data and all HTTP/3 frame types defined inthis document are sent on streams. Therefore, all frame headers and payload aresubject to flow control.</t>        </section>        <section          <name>Guidance for New Frame Type Definitions</name>          <t>Frame type definitions in HTTP/3 often use the QUIC variable-length integerencoding.  In particular, IDs use this encoding, which allows for alarger range of possible values than the encoding used in HTTP/2.  Some framesin HTTP/3 use an identifier other than a ID (e.g., IDs).Redefinition of the encoding of extension frame types might be necessary if theencoding includes a ID.</t>          <t>Because the Flags field is not present in generic HTTP/3 frames, those framesthat depend on the presence of flags need to allocate space for flags as partof their frame payload.</t>          <t>Other than these issues, frame type HTTP/2 extensions are typically portable toQUIC simply by replacing 0 in HTTP/2 with a in HTTP/3.HTTP/3 extensions will not assume ordering, but would not be harmed by ordering,and are expected to be portable to HTTP/2.</t>        </section>        <section          <name>Comparison HTTP/2 and HTTP/3 Frame Types</name>          <dl>            <dd>              <t>Padding is not defined in HTTP/3 frames.  See <xref            </dd>            <dd>              <t>The PRIORITY region of is not defined in HTTP/3 frames. Padding is notdefined in HTTP/3 frames.  See <xref            </dd>            <dd>              <t>As described in <xref HTTP/3 does not provide a means ofsignaling priority.</t>            </dd>            <dd>              <t>RST_STREAM frames do not exist in HTTP/3, since QUIC provides stream lifecyclemanagement.  The same code point is used for the frame(<xref            <dd> frames are sent only at the beginning of the connection.  See<xref and <xref            </dd>            <dd>              <t>The frame does not reference a stream; thereferences the frame using a  See<xref            </dd>            <dd>              <t>PING frames do not exist in HTTP/3, as QUIC provides equivalentfunctionality.</t>            </dd>            <dd> does not contain an error code.  In the direction,it carries a instead of a stream ID.See <xref            </dd>            <dd>              <t>WINDOW_UPDATE frames do not exist in HTTP/3, since QUIC provides flow control.</t>            </dd>            <dd>              <t>CONTINUATION frames do not exist in HTTP/3; instead, larger frames than HTTP/2 are permitted.</t>            </dd>          </dl>          <t>Frame types defined by extensions to HTTP/2 need to be separately registered forHTTP/3 if still applicable.  The IDs of frames defined in <xref have beenreserved for simplicity.  Note that the frame type space in HTTP/3 issubstantially larger (62 bits versus 8 bits), so many HTTP/3 frame types have noequivalent HTTP/2 code points.  See <xref        </section>      </section>      <section        <name>HTTP/2 SETTINGS Parameters</name>        <t>An important difference from HTTP/2 is that settings are sent once, as the firstframe of the and thereafter cannot change.  This eliminates manycorner cases around synchronization of changes.</t>        <t>Some transport-level options that HTTP/2 specifies via the 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.  See<xref for discussion of both the retained and reserved values.</t>        <t>Below is a listing of how each HTTP/2 parameter is mapped:</t>        <dl>          <dd>            <t>See <xref          </dd>          <dd>            <t>This is removed in favor of the frame, which provides a moregranular control over server push.  Specifying a setting with the identifier (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 frame is an error.</t>          </dd>          <dd>            <t>QUIC controls the largest open ID as part of its logic.Specifying a setting with the identifier (corresponding to theSETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 frame is anerror.</t>          </dd>          <dd>            <t>QUIC requires both stream and connection window sizes to bespecified in the initial transport handshake.  Specifying a setting with theidentifier (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE parameter)in the HTTP/3 frame is an error.</t>          </dd>          <dd>            <t>This setting has no equivalent in HTTP/3.  Specifying a setting with theidentifier (corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) inthe HTTP/3 frame is an error.</t>          </dd>          <dd>            <t>This setting identifier has been renamed          </dd>        </dl>        <t>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 or to make useof the 62-bit space if more than 30 bits are required.</t>        <t>Settings need to be defined separately for HTTP/2 and HTTP/3. The IDs ofsettings defined in <xref 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. See<xref        <t>As QUIC streams might arrive out of order, endpoints are advised not to wait forthe peers' settings to arrive before responding to other streams.  See<xref      </section>      <section        <name>HTTP/2 Error Codes</name>        <t>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.</t>        <t>The HTTP/2 error codes defined in <xref logically map tothe HTTP/3 error codes as follows:</t>        <dl>          <dd> in <xref          </dd>          <dd>            <t>This is mapped to except in cases where morespecific error codes have been defined. Such cases include and definedin <xref          </dd>          <dd> in <xref          </dd>          <dd>            <t>Not applicable, since QUIC handles flow control.</t>          </dd>          <dd>            <t>Not applicable, since no acknowledgment of is defined.</t>          </dd>          <dd>            <t>Not applicable, since QUIC handles stream management.</t>          </dd>          <dd> error code defined in <xref          </dd>          <dd> (in <xref is used to indicate that arequest was not processed. Otherwise, not applicable because QUIC handlesstream management.</t>          </dd>          <dd> in <xref          </dd>          <dd>            <t>Multiple error codes are defined in <xref          </dd>          <dd> in <xref          </dd>          <dd> in <xref          </dd>          <dd>            <t>Not applicable, since QUIC is assumed to provide sufficient security on allconnections.</t>          </dd>          <dd> in <xref          </dd>        </dl>        <t>Error codes need to be defined for HTTP/2 and HTTP/3 separately.  See<xref        <section          <name>Mapping HTTP/2 and HTTP/3 Errors</name>          <t>An intermediary that converts between HTTP/2 and HTTP/3 may encounter errorconditions from either upstream. It is useful to communicate the occurrence of to the but error codes largely reflect connection-localproblems that generally do not make sense to propagate.</t>          <t>An intermediary that encounters an error from an upstream origin can indicatethis by sending an HTTP status code such as which is suitablefor a broad class of errors.</t>          <t>There are some rare cases where it is beneficial to propagate the error bymapping it to the closest matching error type to the receiver. For example, anintermediary that receives an HTTP/2 of type REFUSED_STREAM fromthe origin has a clear signal that the request was not processed and that therequest is safe to retry. Propagating this error condition to the client as anHTTP/3 of type allows the client to take theaction it deems most appropriate. In the reverse direction, the intermediarymight deem it beneficial to pass on client request cancellations that areindicated by terminating a stream with see<xref          <t>Conversion between errors is described in the logical mapping. The error codesare defined in non-overlapping spaces in order to protect against accidentalconversion that could result in the use of inappropriate or unknown error codesfor the target version. An intermediary is permitted to promote to but they should be aware of the cost to the HTTP/3 connectionfor what might be a temporary or intermittent error.</t>        </section>      </section>    </section>    <section      <name>Acknowledgments</name> authors of this      <t>The IETF QUIC Working Group received an enormous amount of support from manypeople. Among others, the following people provided substantial contributions tothis document:</t>          <t><contact fullname="Bence Beky"/></t>          <t><contact fullname="Daan De Meyer"/></t>          <t><contact fullname="Martin Duke"/></t>          <t><contact fullname="Roy Fielding"/></t>          <t><contact fullname="Alan Frindell"/></t>          <t><contact fullname="Alessandro Ghedini"/></t>          <t><contact fullname="Nick Harper"/></t>          <t><contact fullname="Ryan Hamilton"/></t>          <t><contact fullname="Christian Huitema"/></t>          <t><contact fullname="Subodh Iyengar"/></t>          <t><contact fullname="Robin Marx"/></t>          <t><contact fullname="Patrick McManus"/></t>          <t><contact fullname="Luca Niccolini"/></t> asciiFullname="Kazuho Oku" fullname="奥          <t><contact fullname="Lucas Pardue"/></t>          <t><contact fullname="Roberto Peon"/></t>          <t><contact fullname="Julian Reschke"/></t>          <t><contact fullname="Eric Rescorla"/></t>          <t><contact fullname="Martin Seemann"/></t>          <t><contact fullname="Ben Schwartz"/></t>          <t><contact fullname="Ian Swett"/></t>          <t><contact fullname="Willy Taureau"/></t>          <t><contact fullname="Martin Thomson"/></t>          <t><contact fullname="Dmitri Tikhonov"/></t>          <t><contact fullname="Tatsuhiro Tsujikawa"/></t>      <t>A portion of contribution was supported by Microsoft duringhis employment there.</t>    </section>  </back></rfc>