rfc9113.original.xml   rfc9113.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet type="text/xsl" href="lib/rfc2629.xslt"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" category="std"
<?rfc toc="yes" ?> docName="draft-ietf-httpbis-http2bis-latest" tocInclude="true" symRefs="true" s
<?rfc symrefs="yes" ?> ortRefs="true" version="3" submissionType="IETF" consensus="true" number="9113"
<?rfc sortrefs="yes" ?> obsoletes="7540,8740">
<?rfc compact="yes"?>
<?rfc subcompact="no" ?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" xmlns:x="http://purl.org/net/xml
2rfc/ext" ipr="trust200902" category="std" docName="draft-ietf-httpbis-http2bis-
07" tocInclude="true" symRefs="true" sortRefs="true" version="3" submissionType=
"IETF" obsoletes="7540,8740">
<!--
<x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{sect
ion}%22&amp;body=&lt;{ref}&gt;:"/>
-->
<front> <front>
<title>HTTP/2</title> <title>HTTP/2</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-http2bis-07"/> <seriesInfo name="RFC" value="9113"/>
<author initials="M." surname="Thomson" fullname="Martin Thomson" role="edit or"> <author initials="M." surname="Thomson" fullname="Martin Thomson" role="edit or">
<organization>Mozilla</organization> <organization>Mozilla</organization>
<address> <address>
<postal> <postal>
<country>Australia</country> <country>Australia</country>
</postal> </postal>
<email>mt@lowentropy.net</email> <email>mt@lowentropy.net</email>
</address> </address>
</author> </author>
<author initials="C." surname="Benfield" fullname="Cory Benfield" role="edit or"> <author initials="C." surname="Benfield" fullname="Cory Benfield" role="edit or">
<organization>Apple Inc.</organization> <organization>Apple Inc.</organization>
<address> <address>
<email>cbenfield@apple.com</email> <email>cbenfield@apple.com</email>
</address> </address>
</author> </author>
<date month="June" year="2022"/>
<area>Applications and Real-Time</area> <area>Applications and Real-Time</area>
<workgroup>HTTPbis</workgroup> <workgroup>HTTPbis</workgroup>
<keyword>HTTP</keyword> <keyword>HTTP</keyword>
<keyword>SPDY</keyword> <keyword>SPDY</keyword>
<keyword>Web</keyword> <keyword>Web</keyword>
<abstract> <abstract>
<t> <t>This specification describes an optimized expression of the semantics o
This specification describes an optimized expression of the semantics of f the Hypertext
the Hypertext
Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more Transfer Protocol (HTTP), referred to as HTTP version 2 (HTTP/2). HTTP/2 enables a more
efficient use of network resources and a efficient use of network resources and a
reduced latency by introducing field compression and allowing multiple reduced latency by introducing field compression and allowing multiple
concurrent exchanges on the same connection. concurrent exchanges on the same connection.</t>
</t> <t>This document obsoletes RFCs 7540 and 8740.</t>
<t>
This document obsoletes RFC 7540 and RFC 8740.
</t>
</abstract> </abstract>
<note title="Discussion Venues" removeInRFC="true">
<t>
Discussion of this document takes place on the HTTPBIS Working Group mai
ling list
(ietf-http-wg@w3.org), which is archived at <eref target="https://lists.
w3.org/Archives/Public/ietf-http-wg/"/>.
</t>
<t>
Source for this draft and an issue tracker can be found at
<eref target="https://github.com/httpwg/http2-spec"/>.
</t>
</note>
</front> </front>
<middle> <middle>
<section anchor="intro"> <section anchor="intro">
<name>Introduction</name> <name>Introduction</name>
<t> <t>The performance of applications using the Hypertext Transfer Protocol
The performance of applications using the Hypertext Transfer Protocol (HTTP, <xref target="RFC9110"/>) is linked to how each version of HTTP u
(HTTP, <xref target="HTTP"/>) is linked to how each version of HTTP uses ses the underlying
the underlying transport, and the conditions under which the transport operates.</t>
transport, and the conditions under which the transport operates. <t>Making multiple concurrent requests can reduce latency and improve
</t>
<t>
Making multiple concurrent requests can reduce latency and improve
application performance. HTTP/1.0 allowed only one request to be application performance. HTTP/1.0 allowed only one request to be
outstanding at a time on a given TCP <xref target="TCP"/> connection. HT TP/1.1 (<xref target="HTTP11"/>) outstanding at a time on a given TCP <xref target="RFC0793"/> connection . HTTP/1.1 <xref target="RFC9112"/>
added request pipelining, but this only partially addressed request added request pipelining, but this only partially addressed request
concurrency and still suffers from application-layer head-of-line concurrency and still suffers from application-layer head-of-line
blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients use multiple connecti ons blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients use multiple connecti ons
to a server to make concurrent requests. to a server to make concurrent requests.</t>
</t> <t>Furthermore, HTTP fields are often repetitive and verbose, causing unne
<t> cessary
Furthermore, HTTP fields are often repetitive and verbose, causing unnec
essary
network traffic as well as causing the initial TCP congestion network traffic as well as causing the initial TCP congestion
window to quickly fill. This can result in excessive latency when multip le requests are window to quickly fill. This can result in excessive latency when multip le requests are
made on a new TCP connection. made on a new TCP connection.</t>
</t> <t>HTTP/2 addresses these issues by defining an optimized mapping of HTTP'
<t> s semantics to an
HTTP/2 addresses these issues by defining an optimized mapping of HTTP's
semantics to an
underlying connection. Specifically, it allows interleaving of messages on the same underlying connection. Specifically, it allows interleaving of messages on the same
connection and uses an efficient coding for HTTP fields. It also allows prioritization of connection and uses an efficient coding for HTTP fields. It also allows prioritization of
requests, letting more important requests complete more quickly, further improving requests, letting more important requests complete more quickly, further improving
performance. performance.</t>
</t> <t>The resulting protocol is more friendly to the network because fewer TC
<t> P connections can
The resulting protocol is more friendly to the network because fewer TCP
connections can
be used in comparison to HTTP/1.x. This means less competition with othe r flows and be used in comparison to HTTP/1.x. This means less competition with othe r flows and
longer-lived connections, which in turn lead to better utilization of av ailable network longer-lived connections, which in turn lead to better utilization of av ailable network
capacity. Note, however, that TCP head-of-line blocking is not addressed capacity. Note, however, that TCP head-of-line blocking is not addressed
by this protocol. by this protocol.</t>
</t> <t>Finally, HTTP/2 also enables more efficient processing of messages thro
<t> ugh use of binary
Finally, HTTP/2 also enables more efficient processing of messages throu message framing.</t>
gh use of binary <t>This document obsoletes RFCs 7540 and 8740. <xref target="revision-upd
message framing. ates"/> lists notable changes.</t>
</t>
<t>
This document obsoletes <xref target="RFC7540">RFC 7540</xref> and <xref
target="RFC8740">RFC 8740</xref>. <xref target="revision-updates"/> lis
ts notable changes.
</t>
</section> </section>
<section anchor="Overview"> <section anchor="Overview">
<name>HTTP/2 Protocol Overview</name> <name>HTTP/2 Protocol Overview</name>
<t> <t>HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 supp
HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 suppo orts all of the core
rts all of the core features of HTTP but aims to be more efficient than HTTP/1.1.</t>
features of HTTP but aims to be more efficient than HTTP/1.1. <t>HTTP/2 is a connection-oriented application-layer protocol that runs ov
</t> er a TCP connection
<t> (<xref target="RFC0793"/>). The client is the TCP connection initiator.<
HTTP/2 is a connection-oriented application-layer protocol that runs ove /t>
r a TCP connection <t>The basic protocol unit in HTTP/2 is a <xref target="FrameHeader">frame
(<xref target="TCP"/>). The client is the TCP connection initiator. </xref>. Each frame
</t>
<t>
The basic protocol unit in HTTP/2 is a <xref target="FrameHeader">frame<
/xref>. Each frame
type serves a different purpose. For example, <xref target="HEADERS" fo rmat="none">HEADERS</xref> and type serves a different purpose. For example, <xref target="HEADERS" fo rmat="none">HEADERS</xref> and
<xref target="DATA" format="none">DATA</xref> frames form the basis of < xref target="HttpFraming">HTTP requests and <xref target="DATA" format="none">DATA</xref> frames form the basis of < xref target="HttpFraming">HTTP requests and
responses</xref>; other frame types like <xref target="SETTINGS" format= "none">SETTINGS</xref>, responses</xref>; other frame types like <xref target="SETTINGS" format= "none">SETTINGS</xref>,
<xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, and <xr ef target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> are used in support o f other <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, and <xr ef target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> are used in support o f other
HTTP/2 features. HTTP/2 features.</t>
</t> <t>Multiplexing of requests is achieved by having each HTTP request/respon
<t> se exchange
Multiplexing of requests is achieved by having each HTTP request/respons
e exchange
associated with its own <xref target="StreamsLayer">stream</xref>. Strea ms are largely associated with its own <xref target="StreamsLayer">stream</xref>. Strea ms are largely
independent of each other, so a blocked or stalled request or response d oes not prevent independent of each other, so a blocked or stalled request or response d oes not prevent
progress on other streams. progress on other streams.</t>
</t> <t>Effective use of multiplexing depends on flow control and prioritizatio
<t> n. <xref target="FlowControl">Flow control</xref> ensures that it is possible t
Effective use of multiplexing depends on flow control and prioritization o efficiently use
. <xref
target="FlowControl">Flow control</xref> ensures that it is possible to
efficiently use
multiplexed streams by restricting data that is transmitted to what the receiver is able to multiplexed streams by restricting data that is transmitted to what the receiver is able to
handle. <xref target="StreamPriority">Prioritization</xref> ensures tha t limited resources handle. <xref target="StreamPriority">Prioritization</xref> ensures tha t limited resources
are used most effectively. This revision of HTTP/2 deprecates the prior ity signaling scheme are used most effectively. This revision of HTTP/2 deprecates the prior ity signaling scheme
from <xref target="RFC7540"/>. from <xref target="RFC7540"/>.</t>
</t> <t>Because HTTP fields used in a connection can contain large amounts of r
<t> edundant
Because HTTP fields used in a connection can contain large amounts of re
dundant
data, frames that contain them are <xref target="FieldBlock">compressed< /xref>. This has data, frames that contain them are <xref target="FieldBlock">compressed< /xref>. This has
especially advantageous impact upon request sizes in the common case, al lowing many especially advantageous impact upon request sizes in the common case, al lowing many
requests to be compressed into one packet. requests to be compressed into one packet.</t>
</t> <t>Finally, HTTP/2 adds a new, optional interaction mode whereby a server
<t> can <xref target="PushResources">push
Finally, HTTP/2 adds a new, optional interaction mode whereby a server c
an <xref target="PushResources">push
responses to a client</xref>. This is intended to allow a server to spe culatively send data to a responses to a client</xref>. This is intended to allow a server to spe culatively send data to a
client that the server anticipates the client will need, trading off som e network usage client that the server anticipates the client will need, trading off som e network usage
against a potential latency gain. The server does this by synthesizing a request, which it against a potential latency gain. The server does this by synthesizing a request, which it
sends as a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame. The server is then able to send a response to sends as a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame. The server is then able to send a response to
the synthetic request on a separate stream. the synthetic request on a separate stream.</t>
</t>
<section> <section>
<name>Document Organization</name> <name>Document Organization</name>
<t> <t>The HTTP/2 specification is split into four parts:</t>
The HTTP/2 specification is split into four parts:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li><xref target="starting">Starting HTTP/2</xref> covers how an HTTP/ 2 connection is <li><xref target="starting">Starting HTTP/2</xref> covers how an HTTP/ 2 connection is
initiated. initiated.</li>
</li> <li>The <xref target="FramingLayer">frame</xref> and <xref target="Str
<li> eamsLayer">stream</xref> layers describe the way HTTP/2 frames are
The <xref target="FramingLayer">frame</xref> and <xref target="Str structured and formed into multiplexed streams.</li>
eamsLayer">stream</xref> layers describe the way HTTP/2 frames are
structured and formed into multiplexed streams.
</li>
<li><xref target="FrameTypes">Frame</xref> and <xref target="ErrorCode s">error</xref> <li><xref target="FrameTypes">Frame</xref> and <xref target="ErrorCode s">error</xref>
definitions include details of the frame and error types used in H definitions include details of the frame and error types used in H
TTP/2. TTP/2.</li>
</li>
<li><xref target="HttpLayer">HTTP mappings</xref> and <xref target="Ht tpExtra">additional <li><xref target="HttpLayer">HTTP mappings</xref> and <xref target="Ht tpExtra">additional
requirements</xref> describe how HTTP semantics are expressed usin g frames and requirements</xref> describe how HTTP semantics are expressed usin g frames and
streams. streams.</li>
</li>
</ul> </ul>
<t> <t>While some of the frame- and stream-layer concepts are isolated from
While some of the frame and stream layer concepts are isolated from HT HTTP, this
TP, this
specification does not define a completely generic frame layer. The fr ame and stream specification does not define a completely generic frame layer. The fr ame and stream
layers are tailored to the needs of the HTTP protocol. layers are tailored to the needs of HTTP.</t>
</t>
</section> </section>
<section> <section>
<name>Conventions and Terminology</name> <name>Conventions and Terminology</name>
<t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", <t>The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bc p14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bc p14>",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDE D</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDE D</bcp14>",
"<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTI ONAL</bcp14>" in "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and "<bcp14>OPTI ONAL</bcp14>" in
this document are to be interpreted as described in BCP&#xa0;14 <xref ta this document are to be interpreted as described in BCP&#xa0;14 <xref ta
rget="RFC2119" rget="RFC2119"/> <xref target="RFC8174"/> when, and only when, they
format="default"/> <xref target="RFC8174" format="default"/> when, and o
nly when, they
appear in all capitals, as shown here.</t> appear in all capitals, as shown here.</t>
<t> <t>All numeric values are in network byte order. Values are unsigned un
All numeric values are in network byte order. Values are unsigned unl less otherwise
ess otherwise
indicated. Literal values are provided in decimal or hexadecimal as a ppropriate. indicated. Literal values are provided in decimal or hexadecimal as a ppropriate.
Hexadecimal literals are prefixed with "<tt>0x</tt>" to distinguish th em Hexadecimal literals are prefixed with "<tt>0x</tt>" to distinguish th em
from decimal literals. from decimal literals.</t>
</t> <t>This specification describes binary formats using the conventions des
<t> cribed in <xref target="RFC9000" section="1.3">RFC 9000</xref>. Note that this
This specification describes binary formats using the convention descr format uses network byte
ibed in <xref order and that high-valued bits are listed before low-valued bits.</t>
target="QUIC" section="1.3">RFC 9000</xref>. Note that this format us <t>The following terms are used:</t>
es network byte
order and high-valued bits are listed before low-valued bits.
</t>
<t>
The following terms are used:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>client:</dt> <dt>client:</dt>
<dd> <dd>The endpoint that initiates an HTTP/2 connection. Clients send HT
The endpoint that initiates an HTTP/2 connection. Clients send HT TP requests and
TP requests and receive HTTP responses.</dd>
receive HTTP responses.
</dd>
<dt>connection:</dt> <dt>connection:</dt>
<dd> <dd>A transport-layer connection between two endpoints.</dd>
A transport-layer connection between two endpoints.
</dd>
<dt>connection error:</dt> <dt>connection error:</dt>
<dd> <dd>An error that affects the entire HTTP/2 connection.</dd>
An error that affects the entire HTTP/2 connection.
</dd>
<dt>endpoint:</dt> <dt>endpoint:</dt>
<dd> <dd>Either the client or server of the connection.</dd>
Either the client or server of the connection.
</dd>
<dt>frame:</dt> <dt>frame:</dt>
<dd> <dd>The smallest unit of communication within an HTTP/2 connection, co
The smallest unit of communication within an HTTP/2 connection, co nsisting of a header
nsisting of a header and a variable-length sequence of octets structured according to t
and a variable-length sequence of octets structured according to t he frame type.</dd>
he frame type.
</dd>
<dt>peer:</dt> <dt>peer:</dt>
<dd> <dd>An endpoint. When discussing a particular endpoint, "peer" refers
An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint
to the endpoint that is remote to the primary subject of discussion.</dd>
that is remote to the primary subject of discussion.
</dd>
<dt>receiver:</dt> <dt>receiver:</dt>
<dd> <dd>An endpoint that is receiving frames.</dd>
An endpoint that is receiving frames.
</dd>
<dt>sender:</dt> <dt>sender:</dt>
<dd> <dd>An endpoint that is transmitting frames.</dd>
An endpoint that is transmitting frames.
</dd>
<dt>server:</dt> <dt>server:</dt>
<dd> <dd>The endpoint that accepts an HTTP/2 connection. Servers receive H
The endpoint that accepts an HTTP/2 connection. Servers receive H TTP requests and
TTP requests and send HTTP responses.</dd>
send HTTP responses.
</dd>
<dt>stream:</dt> <dt>stream:</dt>
<dd> <dd>A bidirectional flow of frames within the HTTP/2 connection.</dd>
A bidirectional flow of frames within the HTTP/2 connection.
</dd>
<dt>stream error:</dt> <dt>stream error:</dt>
<dd> <dd>An error on the individual HTTP/2 stream.</dd>
An error on the individual HTTP/2 stream.
</dd>
</dl> </dl>
<t> <t>Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" a
Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" ar re defined in
e defined in <xref target="RFC9110" section="3.7"/>. Intermediaries act as both cl
<xref target="HTTP" section="3.7"/>. Intermediaries act as both clien ient
t and server at different times.</t>
and server at different times. <t>The term "content" as it applies to message bodies is defined in <xre
</t> f target="RFC9110" section="6.4"/>.</t>
<t>
The term "content" as it applies to message bodies is defined in <xref
target="HTTP" section="6.4"/>.
</t>
</section> </section>
</section> </section>
<section anchor="starting"> <section anchor="starting">
<name>Starting HTTP/2</name> <name>Starting HTTP/2</name>
<t> <t>Implementations that generate HTTP requests need to discover whether a
Implementations that generate HTTP requests need to discover whether a s server supports
erver supports HTTP/2.</t>
HTTP/2. <t>HTTP/2 uses the "<tt>http</tt>" and "<tt>https</tt>" URI schemes define
</t> d in <xref target="RFC9110" section="4.2"/>, with the same default port numbers
<t> as HTTP/1.1 <xref target="RFC9112"/>. These URIs do not include any indication a
HTTP/2 uses the "http" and "https" URI schemes defined in <xref target=" bout what HTTP versions an
HTTP"
section="4.2"/>, with the same default port numbers as HTTP/1.1 (<xref
target="HTTP11"/>). These URIs do not include any indication about what
HTTP versions an
upstream server (the immediate peer to which the client wishes to establ ish a connection) upstream server (the immediate peer to which the client wishes to establ ish a connection)
supports. supports.</t>
</t> <t>The means by which support for HTTP/2 is determined is different for "<
<t> tt>http</tt>" and "<tt>https</tt>"
The means by which support for HTTP/2 is determined is different for "ht URIs. Discovery for "<tt>https</tt>" URIs is described in <xref target=
tp" and "https" "discover-https"/>. HTTP/2
URIs. Discovery for "https" URIs is described in <xref target="discover support for "<tt>http</tt>" URIs can only be discovered by out-of-band m
-https"/>. HTTP/2 eans and requires prior knowledge
support for "http" URIs can only be discovered by out-of-band means, and of the support as described in <xref target="known-http"/>.</t>
requires prior knowledge
of the support as described in <xref target="known-http"/>.
</t>
<section anchor="versioning"> <section anchor="versioning">
<name>HTTP/2 Version Identification</name> <name>HTTP/2 Version Identification</name>
<t> <t>The protocol defined in this document has two identifiers. Creating a
The protocol defined in this document has two identifiers. Creating a connection based on
connection based on
either implies the use of the transport, framing, and message semantic s described in this either implies the use of the transport, framing, and message semantic s described in this
document. document.</t>
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t> <t>The string "h2" identifies the protocol where HTTP/2 uses Transpo
The string "h2" identifies the protocol where HTTP/2 uses Transp rt Layer Security
ort Layer Security (TLS); see <xref target="TLSUsage"/>. This identifier is used i
(TLS); see <xref target="TLSUsage"/>. This identifier is used i n the <xref target="RFC7301">TLS Application-Layer Protocol Negotiation (ALPN) e
n the <xref xtension</xref>
target="TLS-ALPN">TLS application-layer protocol negotiation (AL field and in any place where HTTP/2 over TLS is identified.</t>
PN) extension</xref> <t>The "h2" string is serialized into an ALPN protocol identifier as
field and in any place where HTTP/2 over TLS is identified. the two-octet
</t> sequence: 0x68, 0x32.</t>
<t>
The "h2" string is serialized into an ALPN protocol identifier a
s the two-octet
sequence: 0x68, 0x32.
</t>
</li> </li>
<li> <li>
<t> <t>The "h2c" string was previously used as a token for use in the HT
The "h2c" string was previously used as a token for use in the H TP Upgrade
TTP Upgrade mechanism's Upgrade header field (<xref target="RFC9110" section
mechanism's Upgrade header field (<xref target="HTTP" section="7 ="7.8"/>). This usage
.8"/>). This usage was never widely deployed and is deprecated by this document. Th
was never widely deployed and is deprecated by this document. Th e same applies to the
e same apples to the HTTP2-Settings header field, which was used with the upgrade to
HTTP2-Settings header field, which was used with the upgrade to "h2c".</t>
"h2c".
</t>
</li> </li>
</ul> </ul>
</section> </section>
<section anchor="discover-https"> <section anchor="discover-https">
<name>Starting HTTP/2 for "https" URIs</name> <name>Starting HTTP/2 for "<tt>https</tt>" URIs</name>
<t> <t>A client that makes a request to an "<tt>https</tt>" URI uses <xref t
A client that makes a request to an "https" URI uses <xref target="TLS arget="RFC8446">TLS</xref> with
13">TLS</xref> with the <xref target="RFC7301">ALPN extension</xref>.</t>
the <xref target="TLS-ALPN">application-layer protocol negotiation (AL <t>HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" protoco
PN) l identifier <bcp14>MUST NOT</bcp14>
extension</xref>.
</t>
<t>
HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" protocol
identifier MUST NOT
be sent by a client or selected by a server; the "h2c" protocol identi fier describes a be sent by a client or selected by a server; the "h2c" protocol identi fier describes a
protocol that does not use TLS. protocol that does not use TLS.</t>
</t> <t>Once TLS negotiation is complete, both the client and the server <bcp
<t> 14>MUST</bcp14> send a <xref target="preface">connection preface</xref>.</t>
Once TLS negotiation is complete, both the client and the server MUST
send a <xref target="preface">connection preface</xref>.
</t>
</section> </section>
<section anchor="known-http"> <section anchor="known-http">
<name>Starting HTTP/2 with Prior Knowledge</name> <name>Starting HTTP/2 with Prior Knowledge</name>
<t> <t>A client can learn that a particular server supports HTTP/2 by other
A client can learn that a particular server supports HTTP/2 by other m means. For example,
eans. For example, a client could be configured with knowledge that a server supports HTT
a client could be configured with knowledge that a server supports HTT P/2.</t>
P/2. <t>A client that knows that a server supports HTTP/2 can establish a TCP
</t> connection and send
<t>
A client that knows that a server supports HTTP/2 can establish a TCP
connection and send
the <xref target="preface">connection preface</xref> followed by HTTP/ 2 frames. the <xref target="preface">connection preface</xref> followed by HTTP/ 2 frames.
Servers can identify these connections by the presence of the connecti on preface. This Servers can identify these connections by the presence of the connecti on preface. This
only affects the establishment of HTTP/2 connections over cleartext TC P; HTTP/2 connections only affects the establishment of HTTP/2 connections over cleartext TC P; HTTP/2 connections
over TLS MUST use <xref target="TLS-ALPN">protocol negotiation in over TLS <bcp14>MUST</bcp14> use <xref target="RFC7301">protocol negot
TLS</xref>. iation in
</t> TLS</xref>.</t>
<t> <t>Likewise, the server <bcp14>MUST</bcp14> send a <xref target="preface
Likewise, the server MUST send a <xref target="preface">connection pre ">connection preface</xref>.</t>
face</xref>. <t>Without additional information, prior support for HTTP/2 is not a str
</t> ong signal that a
<t>
Without additional information, prior support for HTTP/2 is not a stro
ng signal that a
given server will support HTTP/2 for future connections. For example, it is possible for given server will support HTTP/2 for future connections. For example, it is possible for
server configurations to change, for configurations to differ between instances in server configurations to change, for configurations to differ between instances in
clustered servers, or for network conditions to change. clustered servers, or for network conditions to change.</t>
</t>
</section> </section>
<section anchor="preface"> <section anchor="preface">
<name>HTTP/2 Connection Preface</name> <name>HTTP/2 Connection Preface</name>
<t> <t>In HTTP/2, each endpoint is required to send a connection preface as
In HTTP/2, each endpoint is required to send a connection preface as a a final confirmation
final confirmation
of the protocol in use and to establish the initial settings for the H TTP/2 connection. of the protocol in use and to establish the initial settings for the H TTP/2 connection.
The client and server each send a different connection preface. The client and server each send a different connection preface.</t>
</t> <t>The client connection preface starts with a sequence of 24 octets, wh
<t> ich in hex notation
The client connection preface starts with a sequence of 24 octets, whi is:</t>
ch in hex notation
is:
</t>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
]]></artwork> ]]></artwork>
<t> <t>That is, the connection preface starts with the string "<tt>PRI *
That is, the connection preface starts with the string "<tt>PRI *
HTTP/2.0\r\n\r\nSM\r\n\r\n</tt>". This sequence HTTP/2.0\r\n\r\nSM\r\n\r\n</tt>". This sequence
MUST be followed by a <xref target="SETTINGS" format="none">SETTINGS</ <bcp14>MUST</bcp14> be followed by a <xref target="SETTINGS" format="n
xref> frame (<xref target="SETTINGS"/>), which one">SETTINGS</xref> frame (<xref target="SETTINGS"/>), which
MAY be empty. The client sends the client connection preface as the fi <bcp14>MAY</bcp14> be empty. The client sends the client connection pr
rst eface as the first
application data octets of a connection. application data octets of a connection.</t>
</t>
<aside> <aside>
<t>Note: <t>Note:
The client connection preface is selected so that a large proportion of HTTP/1.1 or The client connection preface is selected so that a large proportion of HTTP/1.1 or
HTTP/1.0 servers and intermediaries do not attempt to process furthe r frames. Note HTTP/1.0 servers and intermediaries do not attempt to process furthe r frames. Note
that this does not address the concerns raised in <xref target="TALK that this does not address the concerns raised in <xref target="TALK
ING"/>. ING"/>.</t>
</t>
</aside> </aside>
<t> <t>The server connection preface consists of a potentially empty <xref t
The server connection preface consists of a potentially empty <xref ta arget="SETTINGS" format="none">SETTINGS</xref>
rget="SETTINGS" format="none">SETTINGS</xref> frame (<xref target="SETTINGS"/>) that <bcp14>MUST</bcp14> be the firs
frame (<xref target="SETTINGS"/>) that MUST be the first frame the ser t frame the server sends in the
ver sends in the HTTP/2 connection.</t>
HTTP/2 connection. <t>The <xref target="SETTINGS" format="none">SETTINGS</xref> frames rece
</t> ived from a peer as part of the connection preface
<t> <bcp14>MUST</bcp14> be acknowledged (see <xref target="SettingsSync"/>
The <xref target="SETTINGS" format="none">SETTINGS</xref> frames recei ) after sending the connection
ved from a peer as part of the connection preface preface.</t>
MUST be acknowledged (see <xref target="SettingsSync"/>) after sending <t>To avoid unnecessary latency, clients are permitted to send additiona
the connection l frames to the
preface.
</t>
<t>
To avoid unnecessary latency, clients are permitted to send additional
frames to the
server immediately after sending the client connection preface, withou t waiting to receive server immediately after sending the client connection preface, withou t waiting to receive
the server connection preface. It is important to note, however, that the server the server connection preface. It is important to note, however, that the server
connection preface <xref target="SETTINGS" format="none">SETTINGS</xre f> frame might include settings that necessarily connection preface <xref target="SETTINGS" format="none">SETTINGS</xre f> frame might include settings that necessarily
alter how a client is expected to communicate with the server. Upon re ceiving the alter how a client is expected to communicate with the server. Upon re ceiving the
<xref target="SETTINGS" format="none">SETTINGS</xref> frame, the clien t is expected to honor any settings established. <xref target="SETTINGS" format="none">SETTINGS</xref> frame, the clien t is expected to honor any settings established.
In some configurations, it is possible for the server to transmit <xre f target="SETTINGS" format="none">SETTINGS</xref> In some configurations, it is possible for the server to transmit <xre f target="SETTINGS" format="none">SETTINGS</xref>
before the client sends additional frames, providing an opportunity to before the client sends additional frames, providing an opportunity to
avoid this issue. avoid this issue.</t>
</t> <t>Clients and servers <bcp14>MUST</bcp14> treat an invalid connection p
<t> reface as a <xref target="ConnectionErrorHandler">connection error</xref> of typ
Clients and servers MUST treat an invalid connection preface as a <xre e
f target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. A <xref target="GOAWAY" format="none">GOAWAY</xref> frame (<xref target="GOAWAY"/> ) <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. A <xref target="GOAWAY" format="none">GOAWAY</xref> frame (<xref target="GOAWAY"/> )
MAY be omitted in this case, since an invalid preface indicates that t <bcp14>MAY</bcp14> be omitted in this case, since an invalid preface i
he peer is not using ndicates that the peer is not using
HTTP/2. HTTP/2.</t>
</t>
</section> </section>
</section> </section>
<section anchor="FramingLayer"> <section anchor="FramingLayer">
<name>HTTP Frames</name> <name>HTTP Frames</name>
<t> <t>Once the HTTP/2 connection is established, endpoints can begin exchangi
Once the HTTP/2 connection is established, endpoints can begin exchangin ng frames.</t>
g frames.
</t>
<section anchor="FrameHeader"> <section anchor="FrameHeader">
<name>Frame Format</name> <name>Frame Format</name>
<t> <t>All frames begin with a fixed 9-octet header followed by a variable-l
All frames begin with a fixed 9-octet header followed by a variable-le ength frame payload.</t>
ngth frame payload.
</t>
<figure anchor="FrameLayout"> <figure anchor="FrameLayout">
<name>Frame Layout</name> <name>Frame Layout</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
HTTP Frame { HTTP Frame {
Length (24), Length (24),
Type (8), Type (8),
Flags (8), Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Frame Payload (..), Frame Payload (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The fields of the frame header are defined as:</t>
The fields of the frame header are defined as:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Length:</dt> <dt>Length:</dt>
<dd> <dd>
<t> <t>The length of the frame payload expressed as an unsigned 24-bit i
The length of the frame payload expressed as an unsigned 24-bit nteger in units of octets. Values
integer in units of octets. Values greater than 2<sup>14</sup> (16,384) <bcp14>MUST NOT</bcp14> be
greater than 2<sup>14</sup> (16,384) MUST NOT be sent unless the sent unless the receiver has
receiver has set a larger value for <xref target="SETTINGS_MAX_FRAME_SIZE" fo
set a larger value for <xref target="SETTINGS_MAX_FRAME_SIZE" fo rmat="none">SETTINGS_MAX_FRAME_SIZE</xref>.</t>
rmat="none">SETTINGS_MAX_FRAME_SIZE</xref>. <t>The 9 octets of the frame header are not included in this value.<
</t> /t>
<t>
The 9 octets of the frame header are not included in this value.
</t>
</dd> </dd>
<dt>Type:</dt> <dt>Type:</dt>
<dd> <dd>
<t> <t>The 8-bit type of the frame. The frame type determines the forma
The 8-bit type of the frame. The frame type determines the form t and semantics of
at and semantics of
the frame. Frames defined in this document are listed in <xref target="FrameTypes"/>. the frame. Frames defined in this document are listed in <xref target="FrameTypes"/>.
Implementations MUST ignore and discard frames of unknown types. Implementations <bcp14>MUST</bcp14> ignore and discard frames of
</t> unknown types.</t>
</dd> </dd>
<dt>Flags:</dt> <dt>Flags:</dt>
<dd> <dd>
<t> <t>An 8-bit field reserved for boolean flags specific to the frame t
An 8-bit field reserved for boolean flags specific to the frame ype.</t>
type. <t>Flags are assigned semantics specific to the indicated frame type
</t> . Unused flags are
<t> those that have no defined semantics for a particular frame type.
Flags are assigned semantics specific to the indicated frame type. Unused flags <bcp14>MUST</bcp14> be
Unused flags are ignored on receipt and <bcp14>MUST</bcp14> be left unset (0x00) wh
those that have no defined semantics for a particular frame type. en sending.</t>
Unused flags MUST be
ignored on receipt and MUST be left unset (0x0) when sending.
</t>
</dd> </dd>
<dt>Reserved:</dt> <dt>Reserved:</dt>
<dd> <dd>
<t> <t>A reserved 1-bit field. The semantics of this bit are undefined,
A reserved 1-bit field. The semantics of this bit are undefined and the bit <bcp14>MUST</bcp14>
, and the bit MUST remain unset (0x00) when sending and <bcp14>MUST</bcp14> be igno
remain unset (0x0) when sending and MUST be ignored when receivi red when receiving.</t>
ng.
</t>
</dd> </dd>
<dt>Stream Identifier:</dt> <dt>Stream Identifier:</dt>
<dd> <dd>
<t> <t>A stream identifier (see <xref target="StreamIdentifiers"/>) expr
A stream identifier (see <xref target="StreamIdentifiers"/>) exp essed as an
ressed as an unsigned 31-bit integer. The value 0x00 is reserved for frames
unsigned 31-bit integer. The value 0x0 is reserved for frames t that are associated
hat are associated with the connection as a whole as opposed to an individual strea
with the connection as a whole as opposed to an individual strea m.</t>
m.
</t>
</dd> </dd>
</dl> </dl>
<t> <t>The structure and content of the frame payload are dependent entirely
The structure and content of the frame payload is dependent entirely o on the frame type.</t>
n the frame type.
</t>
</section> </section>
<section anchor="FrameSize"> <section anchor="FrameSize">
<name>Frame Size</name> <name>Frame Size</name>
<t> <t>The size of a frame payload is limited by the maximum size that a rec
The size of a frame payload is limited by the maximum size that a rece eiver advertises in
iver advertises in
the <xref target="SETTINGS_MAX_FRAME_SIZE" format="none">SETTINGS_MAX_ FRAME_SIZE</xref> setting. This setting can have any value the <xref target="SETTINGS_MAX_FRAME_SIZE" format="none">SETTINGS_MAX_ FRAME_SIZE</xref> setting. This setting can have any value
between 2<sup>14</sup> (16,384) and 2<sup>24</sup>-1 (16,777,215) octe ts, between 2<sup>14</sup> (16,384) and 2<sup>24</sup>-1 (16,777,215) octe ts,
inclusive. inclusive.</t>
</t> <t>All implementations <bcp14>MUST</bcp14> be capable of receiving and m
<t> inimally processing frames up to
All implementations MUST be capable of receiving and minimally process
ing frames up to
2<sup>14</sup> octets in length, plus the 9-octet <xref target="FrameH eader">frame 2<sup>14</sup> octets in length, plus the 9-octet <xref target="FrameH eader">frame
header</xref>. The size of the frame header is not included when desc header</xref>. The size of the frame header is not included when desc
ribing frame sizes. ribing frame sizes.</t>
</t>
<aside> <aside>
<t>Note: Certain frame types, such as <xref target="PING">PING</xref>, impose additional limits <t>Note: Certain frame types, such as <xref target="PING">PING</xref>, impose additional limits
on the amount of frame payload data allowed. on the amount of frame payload data allowed.</t>
</t>
</aside> </aside>
<t> <t>An endpoint <bcp14>MUST</bcp14> send an error code of <xref target="F
An endpoint MUST send an error code of <xref target="FRAME_SIZE_ERROR" RAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref> if a frame exceeds the si
format="none">FRAME_SIZE_ERROR</xref> if a frame exceeds the size ze defined in <xref target="SETTINGS_MAX_FRAME_SIZE" format="none">SETTINGS_MAX_
defined in <xref target="SETTINGS_MAX_FRAME_SIZE" format="none">SETTIN FRAME_SIZE</xref>, exceeds any
GS_MAX_FRAME_SIZE</xref>, exceeds any limit defined for the frame type, limit defined for the frame type, or is too small to contain mandatory
or is too small to contain mandatory frame data. A frame size error in frame data. A frame
a frame that size error in a frame that could alter the state of the entire connect
could alter the state of the entire connection MUST be treated as a <x ion <bcp14>MUST</bcp14> be treated
ref target="ConnectionErrorHandler">connection error</xref>; this includes any f as a <xref target="ConnectionErrorHandler">connection error</xref>; th
rame carrying is includes any
a <xref target="FieldBlock">field block</xref> (that is, <xref target= frame carrying a <xref target="FieldBlock">field block</xref> (that is
"HEADERS" format="none">HEADERS</xref>, , <xref target="HEADERS" format="none">HEADERS</xref>, <xref target="PUSH_PROMIS
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>, and <xr E" format="none">PUSH_PROMISE</xref>, and <xref target="CONTINUATION" format="no
ef target="CONTINUATION" format="none">CONTINUATION</xref>), <xref target="SETTI ne">CONTINUATION</xref>), a <xref target="SETTINGS" format="none">SETTINGS</xref
NGS" format="none">SETTINGS</xref>, > frame, and any frame with a stream identifier of 0.</t>
and any frame with a stream identifier of 0. <t>Endpoints are not obligated to use all available space in a frame. Re
</t> sponsiveness can be
<t>
Endpoints are not obligated to use all available space in a frame. Res
ponsiveness can be
improved by using frames that are smaller than the permitted maximum s ize. Sending large improved by using frames that are smaller than the permitted maximum s ize. Sending large
frames can result in delays in sending time-sensitive frames (such as frames can result in delays in sending time-sensitive frames (such as
<xref target="RST_STREAM" format="none">RST_STREAM</xref>, <xref targe t="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, or <xref target="PRIORITY" format="none">PRIORITY</xref>), <xref target="RST_STREAM" format="none">RST_STREAM</xref>, <xref targe t="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, or <xref target="PRIORITY" format="none">PRIORITY</xref>),
which, if blocked by the transmission of a large frame, could affect p which, if blocked by the transmission of a large frame, could affect p
erformance. erformance.</t>
</t>
</section> </section>
<section anchor="FieldBlock"> <section anchor="FieldBlock">
<name>Field Section Compression and Decompression</name> <name>Field Section Compression and Decompression</name>
<t> <t>Field section compression is the process of compressing a set of fiel
Field section compression is the process of compressing a set of field d lines (<xref target="RFC9110" section="5.2"/>) to form a
lines (<xref target="HTTP" section="5.2"/>) to form a
field block. Field section decompression is the process of decoding a field block into a field block. Field section decompression is the process of decoding a field block into a
set of field lines. Details of HTTP/2 field section compression and d set of field lines. Details of HTTP/2 field section compression and d
ecompression is ecompression are
defined in <xref target="COMPRESSION"/>, which, for historical reasons defined in <xref target="RFC7541"/>, which, for historical reasons, re
, refers to these fers to these
processes as header compression and decompression. processes as header compression and decompression.</t>
</t> <t>Each field block carries all of the compressed field lines of a singl
<t> e field section.
Each field block carries all of the compressed field lines of a single Header sections also include control data associated with the message
field section. in the form of <xref target="PseudoHeaderFields">pseudo-header fields</xref> tha
Header sections also include control data associated with the message t use the same format as a
in the form of <xref field line.</t>
target="PseudoHeaderFields">pseudo-header fields</xref> that use the s
ame format as a
field line.
</t>
<aside> <aside>
<t> <t>Note: <xref target="RFC7540">RFC 7540</xref> used the term "header
Note: <xref target="RFC7540">RFC 7540</xref> used the term "header b block" in place of
lock" in place of the more generic "field block".</t>
the more generic "field block".
</t>
</aside> </aside>
<t> <t>Field blocks carry control data and header sections for requests, res
Field blocks carry control data and header sections for requests, resp ponses, promised
onses, promised
requests, and pushed responses (see <xref target="PushResources"/>). All these messages, requests, and pushed responses (see <xref target="PushResources"/>). All these messages,
except for interim responses and requests contained in <xref target="P USH_PROMISE">PUSH_PROMISE</xref> frames, can optionally include a field block th at except for interim responses and requests contained in <xref target="P USH_PROMISE">PUSH_PROMISE</xref> frames, can optionally include a field block th at
carries a trailer section. carries a trailer section.</t>
</t> <t>A field section is a collection of field lines. Each of the field li
<t> nes in a
A field section is a collection of field lines. Each of the field lin field block carries a single value. The serialized field block is the
es in a n divided into one or
field block carry a single value. The serialized field block is then
divided into one or
more octet sequences, called field block fragments. The first field b lock fragment is transmitted within the frame more octet sequences, called field block fragments. The first field b lock fragment is transmitted within the frame
payload of <xref target="HEADERS">HEADERS</xref> or <xref target="PUSH payload of <xref target="HEADERS">HEADERS</xref> or <xref target="PUSH
_PROMISE">PUSH_PROMISE</xref>, each of which could be followed by <xref target=" _PROMISE">PUSH_PROMISE</xref>, each of which could be followed by <xref target="
CONTINUATION">CONTINUATION</xref> frames to carry subsequent field block fragmen CONTINUATION">CONTINUATION</xref> frames to carry subsequent field block fragmen
ts. ts.</t>
</t> <t>The <xref target="RFC6265">Cookie header field</xref> is treated spec
<t> ially by the HTTP
The <xref target="COOKIE">Cookie header field</xref> is treated specia mapping (see <xref target="CompressCookie"/>).</t>
lly by the HTTP <t>A receiving endpoint reassembles the field block by concatenating its
mapping (see <xref target="CompressCookie"/>). fragments and then
</t> decompresses the block to reconstruct the field section.</t>
<t> <t>A complete field section consists of either:</t>
A receiving endpoint reassembles the field block by concatenating its
fragments and then
decompresses the block to reconstruct the field section.
</t>
<t>
A complete field section consists of either:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>a single <xref target="HEADERS" format="none">HEADERS</xref> or <x
a single <xref target="HEADERS" format="none">HEADERS</xref> or <x ref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame,
ref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame, with the END_HEADERS flag set, or</li>
with the END_HEADERS flag set, or <li>a <xref target="HEADERS" format="none">HEADERS</xref> or <xref tar
</li> get="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame with the END_HEADERS
<li>
a <xref target="HEADERS" format="none">HEADERS</xref> or <xref tar
get="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame with the END_HEADERS
flag unset and one or more <xref target="CONTINUATION" format="non e">CONTINUATION</xref> frames, flag unset and one or more <xref target="CONTINUATION" format="non e">CONTINUATION</xref> frames,
where the last <xref target="CONTINUATION" format="none">CONTINUAT where the last <xref target="CONTINUATION" format="none">CONTINUAT
ION</xref> frame has the END_HEADERS flag set. ION</xref> frame has the END_HEADERS flag set.</li>
</li>
</ul> </ul>
<t> <t>Each field block is processed as a discrete unit.
Each field block is processed as a discrete unit. Field blocks <bcp14>MUST</bcp14> be transmitted as a contiguous sequen
Field blocks MUST be transmitted as a contiguous sequence of frames, w ce of frames, with no interleaved
ith no interleaved
frames of any other type or from any other stream. The last frame in a sequence of frames of any other type or from any other stream. The last frame in a sequence of
<xref target="HEADERS" format="none">HEADERS</xref> or <xref target="C ONTINUATION" format="none">CONTINUATION</xref> frames has the END_HEADERS flag s et. <xref target="HEADERS" format="none">HEADERS</xref> or <xref target="C ONTINUATION" format="none">CONTINUATION</xref> frames has the END_HEADERS flag s et.
The last frame in a sequence of <xref target="PUSH_PROMISE" format="no ne">PUSH_PROMISE</xref> or <xref target="CONTINUATION" format="none">CONTINUATIO N</xref> The last frame in a sequence of <xref target="PUSH_PROMISE" format="no ne">PUSH_PROMISE</xref> or <xref target="CONTINUATION" format="none">CONTINUATIO N</xref>
frames has the END_HEADERS flag set. This allows a field block to be logically frames has the END_HEADERS flag set. This allows a field block to be logically
equivalent to a single frame. equivalent to a single frame.</t>
</t> <t>Field block fragments can only be sent as the frame payload of <xref
<t> target="HEADERS" format="none">HEADERS</xref>,
Field block fragments can only be sent as the frame payload of <xref t
arget="HEADERS" format="none">HEADERS</xref>,
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>, or <xre f target="CONTINUATION" format="none">CONTINUATION</xref> frames because these f rames <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>, or <xre f target="CONTINUATION" format="none">CONTINUATION</xref> frames because these f rames
carry data that can modify the compression context maintained by a rec eiver. An endpoint carry data that can modify the compression context maintained by a rec eiver. An endpoint
receiving <xref target="HEADERS" format="none">HEADERS</xref>, <xref t arget="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>, or receiving <xref target="HEADERS" format="none">HEADERS</xref>, <xref t arget="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>, or
<xref target="CONTINUATION" format="none">CONTINUATION</xref> frames n eeds to reassemble field blocks and perform <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames n eeds to reassemble field blocks and perform
decompression even if the frames are to be discarded. A receiver MUST terminate the decompression even if the frames are to be discarded. A receiver <bcp 14>MUST</bcp14> terminate the
connection with a <xref target="ConnectionErrorHandler">connection err or</xref> of type connection with a <xref target="ConnectionErrorHandler">connection err or</xref> of type
<xref target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref <xref target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref
> if it does not decompress a field block. > if it does not decompress a field block.</t>
</t> <t>A decoding error in a field block <bcp14>MUST</bcp14> be treated as a
<t> <xref target="ConnectionErrorHandler">connection error</xref> of type <xref tar
A decoding error in a field block MUST be treated as a <xref get="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref>.</t>
target="ConnectionErrorHandler">connection error</xref> of type <xref
target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref>.
</t>
<section anchor="dynamic-table"> <section anchor="dynamic-table">
<name>Compression State</name> <name>Compression State</name>
<t> <t>Field compression is stateful. Each endpoint has an HPACK encoder
Field compression is stateful. Each endpoint has an HPACK encoder c context and an HPACK
ontext and an HPACK
decoder context that are used for encoding and decoding all field bl ocks on a decoder context that are used for encoding and decoding all field bl ocks on a
connection. <xref target="COMPRESSION" section="4"/> defines the dy connection. <xref target="RFC7541" section="4"/> defines the dynami
namic table, which c table, which
is the primary state for each context. is the primary state for each context.</t>
</t> <t>The dynamic table has a maximum size that is set by an HPACK decode
<t> r. An endpoint
The dynamic table has a maximum size that is set by an HPACK decoder
. An endpoint
communicates the size chosen by its HPACK decoder context using the communicates the size chosen by its HPACK decoder context using the
SETTINGS_HEADER_TABLE_SIZE setting; see <xref target="SettingValues" />. When a SETTINGS_HEADER_TABLE_SIZE setting; see <xref target="SettingValues" />. When a
connection is established, the dynamic table size for the HPACK deco der and encoder at connection is established, the dynamic table size for the HPACK deco der and encoder at
both endpoints starts at 4,096 bytes, the initial value of the both endpoints starts at 4,096 bytes, the initial value of the
SETTINGS_HEADER_TABLE_SIZE setting. SETTINGS_HEADER_TABLE_SIZE setting.</t>
</t> <t>Any change to the maximum value set using SETTINGS_HEADER_TABLE_SIZ
<t> E takes effect when
Any change to the maximum value set using SETTINGS_HEADER_TABLE_SIZE
takes effect when
the endpoint <xref target="SettingsSync">acknowledges settings</xref >. The HPACK the endpoint <xref target="SettingsSync">acknowledges settings</xref >. The HPACK
encoder at that endpoint can set the dynamic table to any size up to the maximum value encoder at that endpoint can set the dynamic table to any size up to the maximum value
set by the decoder. An HPACK encoder declares the size of the dynam ic table with a set by the decoder. An HPACK encoder declares the size of the dynam ic table with a
Dynamic Table Size Update instruction (<xref target="COMPRESSION" se Dynamic Table Size Update instruction (<xref target="RFC7541" sectio
ction="6.3"/>). n="6.3"/>).</t>
</t> <t>Once an endpoint acknowledges a change to SETTINGS_HEADER_TABLE_SIZ
<t> E that reduces the
Once an endpoint acknowledges a change to SETTINGS_HEADER_TABLE_SIZE maximum below the current size of the dynamic table, its HPACK encod
that reduces the er <bcp14>MUST</bcp14> start the
maximum below the current size of the dynamic table, its HPACK encod
er MUST start the
next field block with a Dynamic Table Size Update instruction that s ets the dynamic next field block with a Dynamic Table Size Update instruction that s ets the dynamic
table to a size that is less than or equal to the reduced maximum; s table to a size that is less than or equal to the reduced maximum; s
ee <xref ee <xref target="RFC7541" section="4.2"/>. An endpoint <bcp14>MUST</bcp14> trea
target="COMPRESSION" section="4.2"/>. An endpoint MUST treat a fiel t a field block that follows
d block that follows an acknowledgment of the reduction to the maximum dynamic table size
an acknowledgment of the reduction to the maximum dynamic table size as a <xref target="ConnectionErrorHandler">connection error</xref> of type <xre
as a <xref f target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref> if it does n
target="ConnectionErrorHandler">connection error</xref> of type <xre ot start
f with a conformant Dynamic Table Size Update instruction.</t>
target="COMPRESSION_ERROR" format="none">COMPRESSION_ERROR</xref> if
it does not start
with a conformant Dynamic Table Size Update instruction.
</t>
<aside> <aside>
<t> <t>Implementers are advised that reducing the value of SETTINGS_HEAD
Implementers are advised that reducing the value of SETTINGS_HEADE ER_TABLE_SIZE is not
R_TABLE_SIZE is not
widely interoperable. Use of the connection preface to reduce the value below the widely interoperable. Use of the connection preface to reduce the value below the
initial value of 4,096 is somewhat better supported, but this migh t fail with some initial value of 4,096 is somewhat better supported, but this migh t fail with some
implementations. implementations.</t>
</t>
</aside> </aside>
</section> </section>
</section> </section>
</section> </section>
<section anchor="StreamsLayer"> <section anchor="StreamsLayer">
<name>Streams and Multiplexing</name> <name>Streams and Multiplexing</name>
<t> <t>A "stream" is an independent, bidirectional sequence of frames exchange
A "stream" is an independent, bidirectional sequence of frames exchanged d between the client
between the client and server within an HTTP/2 connection. Streams have several important
and server within an HTTP/2 connection. Streams have several important characteristics:</t>
characteristics:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>A single HTTP/2 connection can contain multiple concurrently open st
A single HTTP/2 connection can contain multiple concurrently open st reams, with either
reams, with either endpoint interleaving frames from multiple streams.</li>
endpoint interleaving frames from multiple streams. <li>Streams can be established and used unilaterally or shared by either
</li> endpoint.</li>
<li> <li>Streams can be closed by either endpoint.</li>
Streams can be established and used unilaterally or shared by either <li>The order in which frames are sent is significant. Recipients proces
endpoint. s frames
</li>
<li>
Streams can be closed by either endpoint.
</li>
<li>
The order in which frames are sent is significant. Recipients proces
s frames
in the order they are received. In particular, the order of <xref t arget="HEADERS" format="none">HEADERS</xref> in the order they are received. In particular, the order of <xref t arget="HEADERS" format="none">HEADERS</xref>
and <xref target="DATA" format="none">DATA</xref> frames is semantic and <xref target="DATA" format="none">DATA</xref> frames is semantic
ally significant. ally significant.</li>
</li> <li>Streams are identified by an integer. Stream identifiers are assign
<li> ed to streams by the
Streams are identified by an integer. Stream identifiers are assign endpoint initiating the stream.</li>
ed to streams by the
endpoint initiating the stream.
</li>
</ul> </ul>
<section anchor="StreamStates"> <section anchor="StreamStates">
<name>Stream States</name> <name>Stream States</name>
<t> <t>The lifecycle of a stream is shown in <xref target="StreamStatesFigur
The lifecycle of a stream is shown in <xref target="StreamStatesFigure e"/>.</t>
"/>.
</t>
<figure anchor="StreamStatesFigure"> <figure anchor="StreamStatesFigure">
<name>Stream States</name> <name>Stream States</name>
<artset> <artset>
<artwork type="svg"> <artwork type="svg">
<svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="480" width="488" viewBox="0 0 488 480" class="diagram" text-anchor="middle" font-fam ily="monospace" font-size="13px"> <svg xmlns="http://www.w3.org/2000/svg" version="1.1" height="480" width="488" viewBox="0 0 488 480" class="diagram" text-anchor="middle" font-fam ily="monospace" font-size="13px">
<g transform="translate(8,16)"> <g transform="translate(8,16)">
<path d="M 0,112 L 0,416" fill="none" stroke="black"/> <path d="M 0,112 L 0,416" fill="none" stroke="black"/>
<path d="M 56,80 L 56,144" fill="none" stroke="black"/> <path d="M 56,80 L 56,144" fill="none" stroke="black"/>
<path d="M 56,240 L 56,304" fill="none" stroke="black"/> <path d="M 56,240 L 56,304" fill="none" stroke="black"/>
<path d="M 88,144 L 88,232" fill="none" stroke="black"/> <path d="M 88,144 L 88,232" fill="none" stroke="black"/>
skipping to change at line 767 skipping to change at line 527
<text x="100" y="116">reserved</text> <text x="100" y="116">reserved</text>
<text x="268" y="116">recv H</text> <text x="268" y="116">recv H</text>
<text x="372" y="116">reserved</text> <text x="372" y="116">reserved</text>
<text x="96" y="132">(local)</text> <text x="96" y="132">(local)</text>
<text x="372" y="132">(remote)</text> <text x="372" y="132">(remote)</text>
<text x="160" y="180">recv ES</text> <text x="160" y="180">recv ES</text>
<text x="312" y="180">send ES</text> <text x="312" y="180">send ES</text>
<text x="52" y="196">send H</text> <text x="52" y="196">send H</text>
<text x="236" y="196">open</text> <text x="236" y="196">open</text>
<text x="420" y="196">recv H</text> <text x="420" y="196">recv H</text>
<text x="100" y="260">half</text> <text x="100" y="260">half-</text>
<text x="372" y="260">half</text> <text x="372" y="260">half-</text>
<text x="100" y="276">closed</text> <text x="100" y="276">closed</text>
<text x="276" y="276">send R /</text> <text x="276" y="276">send R /</text>
<text x="372" y="276">closed</text> <text x="372" y="276">closed</text>
<text x="100" y="292">(remote)</text> <text x="100" y="292">(remote)</text>
<text x="268" y="292">recv R</text> <text x="268" y="292">recv R</text>
<text x="368" y="292">(local)</text> <text x="368" y="292">(local)</text>
<text x="144" y="340">send ES /</text> <text x="144" y="340">send ES /</text>
<text x="328" y="340">recv ES /</text> <text x="328" y="340">recv ES /</text>
<text x="148" y="356">send R /</text> <text x="148" y="356">send R /</text>
<text x="332" y="356">send R /</text> <text x="332" y="356">send R /</text>
skipping to change at line 807 skipping to change at line 567
| | | send H / | | | | | send H / | |
,------+ reserved | | recv H | reserved +------. ,------+ reserved | | recv H | reserved +------.
| | (local) | | | (remote) | | | | (local) | | | (remote) | |
| +---+------+ v +------+---+ | | +---+------+ v +------+---+ |
| | +--------+ | | | | +--------+ | |
| | recv ES | | send ES | | | | recv ES | | send ES | |
| send H | ,-------+ open +-------. | recv H | | send H | ,-------+ open +-------. | recv H |
| | / | | \ | | | | / | | \ | |
| v v +---+----+ v v | | v v +---+----+ v v |
| +----------+ | +----------+ | | +----------+ | +----------+ |
| | half | | | half | | | | half- | | | half- | |
| | closed | | send R / | closed | | | | closed | | send R / | closed | |
| | (remote) | | recv R | (local) | | | | (remote) | | recv R | (local) | |
| +----+-----+ | +-----+----+ | | +----+-----+ | +-----+----+ |
| | | | | | | | | |
| | send ES / | recv ES / | | | | send ES / | recv ES / | |
| | send R / v send R / | | | | send R / v send R / | |
| | recv R +--------+ recv R | | | | recv R +--------+ recv R | |
| send R / `----------->| |<-----------' send R / | | send R / `----------->| |<-----------' send R / |
| recv R | closed | recv R | | recv R | closed | recv R |
`----------------------->| |<-----------------------' `----------------------->| |<-----------------------'
skipping to change at line 836 skipping to change at line 596
<dd>endpoint receives this frame</dd> <dd>endpoint receives this frame</dd>
<dt><tt>H</tt>:</dt> <dt><tt>H</tt>:</dt>
<dd><xref target="HEADERS" format="none">HEADERS</xref> frame (with im plied <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames)</dd> <dd><xref target="HEADERS" format="none">HEADERS</xref> frame (with im plied <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames)</dd>
<dt><tt>ES</tt>:</dt> <dt><tt>ES</tt>:</dt>
<dd>END_STREAM flag</dd> <dd>END_STREAM flag</dd>
<dt><tt>R</tt>:</dt> <dt><tt>R</tt>:</dt>
<dd><xref target="RST_STREAM" format="none">RST_STREAM</xref> frame</d d> <dd><xref target="RST_STREAM" format="none">RST_STREAM</xref> frame</d d>
<dt><tt>PP</tt>:</dt> <dt><tt>PP</tt>:</dt>
<dd><xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fram e (with implied <xref target="CONTINUATION" format="none">CONTINUATION</xref> fr ames); state transitions are for the promised stream</dd> <dd><xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fram e (with implied <xref target="CONTINUATION" format="none">CONTINUATION</xref> fr ames); state transitions are for the promised stream</dd>
</dl> </dl>
<t> <t>Note that this diagram shows stream state transitions and the frames
Note that this diagram shows stream state transitions and the frames a and flags that affect
nd flags that affect
those transitions only. In this regard, <xref target="CONTINUATION" f ormat="none">CONTINUATION</xref> frames do not result those transitions only. In this regard, <xref target="CONTINUATION" f ormat="none">CONTINUATION</xref> frames do not result
in state transitions; they are effectively part of the <xref target="H EADERS" format="none">HEADERS</xref> or in state transitions; they are effectively part of the <xref target="H EADERS" format="none">HEADERS</xref> or
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> that the y follow. For the purpose of state transitions, the <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> that the y follow. For the purpose of state transitions, the
END_STREAM flag is processed as a separate event to the frame that bea rs it; a END_STREAM flag is processed as a separate event to the frame that bea rs it; a
<xref target="HEADERS" format="none">HEADERS</xref> frame with the END <xref target="HEADERS" format="none">HEADERS</xref> frame with the END
_STREAM flag set can cause two state transitions. _STREAM flag set can cause two state transitions.</t>
</t> <t>Both endpoints have a subjective view of the state of a stream that c
<t> ould be different
Both endpoints have a subjective view of the state of a stream that co
uld be different
when frames are in transit. Endpoints do not coordinate the creation of streams; they are when frames are in transit. Endpoints do not coordinate the creation of streams; they are
created unilaterally by either endpoint. The negative consequences of a mismatch in created unilaterally by either endpoint. The negative consequences of a mismatch in
states are limited to the "closed" state after sending <xref target="R ST_STREAM" format="none">RST_STREAM</xref>, where states are limited to the "closed" state after sending <xref target="R ST_STREAM" format="none">RST_STREAM</xref>, where
frames might be received for some time after closing. frames might be received for some time after closing.</t>
</t> <t>Streams have the following states:</t>
<t>
Streams have the following states:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>idle:</dt> <dt>idle:</dt>
<dd> <dd>
<t> <t>All streams start in the "idle" state.</t>
All streams start in the "idle" state. <t>The following transitions are valid from this state:</t>
</t>
<t>
The following transitions are valid from this state:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Sending a <xref target="HEADERS" format="none">HEADERS</xref>
Sending a <xref target="HEADERS" format="none">HEADERS</xref frame as a client, or receiving a HEADERS frame
> frame as a client, or receiving a HEADERS frame
as a server, causes the stream to become "open". The stream identifier is selected as described in as a server, causes the stream to become "open". The stream identifier is selected as described in
<xref target="StreamIdentifiers"/>. The same <xref target=" HEADERS" format="none">HEADERS</xref> frame can also <xref target="StreamIdentifiers"/>. The same <xref target=" HEADERS" format="none">HEADERS</xref> frame can also
cause a stream to immediately become "half-closed". cause a stream to immediately become "half-closed".</li>
</li> <li>Sending a <xref target="PUSH_PROMISE" format="none">PUSH_PROMI
<li> SE</xref> frame on another stream reserves the idle
Sending a <xref target="PUSH_PROMISE" format="none">PUSH_PRO
MISE</xref> frame on another stream reserves the idle
stream that is identified for later use. The stream state f or the reserved stream that is identified for later use. The stream state f or the reserved
stream transitions to "reserved (local)". Only a server may stream transitions to "reserved (local)". Only a server may
send <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames. send <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames.</li>
</li> <li>Receiving a <xref target="PUSH_PROMISE" format="none">PUSH_PRO
<li> MISE</xref> frame on another stream reserves an idle
Receiving a <xref target="PUSH_PROMISE" format="none">PUSH_P
ROMISE</xref> frame on another stream reserves an idle
stream that is identified for later use. The stream state f or the reserved stream that is identified for later use. The stream state f or the reserved
stream transitions to "reserved (remote)". Only a client ma stream transitions to "reserved (remote)". Only a client ma
y receive <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames. y receive <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames.<
</li> /li>
<li> <li>Note that the <xref target="PUSH_PROMISE" format="none">PUSH_P
Note that the <xref target="PUSH_PROMISE" format="none">PUSH ROMISE</xref> frame is not sent on the idle
_PROMISE</xref> frame is not sent on the idle
stream but references the newly reserved stream in the Promi sed Stream ID stream but references the newly reserved stream in the Promi sed Stream ID
field. field.</li>
</li> <li>Opening a stream with a higher-valued stream identifier causes
<li> the stream to
Opening a stream with a higher-valued stream identifier causes t
he stream to
transition immediately to a "closed" state; note that this trans ition is not shown transition immediately to a "closed" state; note that this trans ition is not shown
in the diagram. in the diagram.</li>
</li>
</ul> </ul>
<t> <t>Receiving any frame other than <xref target="HEADERS" format="non
Receiving any frame other than <xref target="HEADERS" format="no e">HEADERS</xref> or <xref target="PRIORITY" format="none">PRIORITY</xref> on
ne">HEADERS</xref> or <xref target="PRIORITY" format="none">PRIORITY</xref> on a stream in this state <bcp14>MUST</bcp14> be treated as a <xref
a stream in this state MUST be treated as a <xref target="Connec target="ConnectionErrorHandler">connection error</xref> of type
tionErrorHandler">connection error</xref> of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref >. If this stream is initiated by the server, as described in
>. If this stream is server-initiated, as described in <xref target="StreamIdentifiers"/>, then receiving a <xref targe
<xref target="StreamIdentifiers"/>, then receiving a <xref targe t="HEADERS" format="none">HEADERS</xref> frame <bcp14>MUST</bcp14> also
t="HEADERS" format="none">HEADERS</xref> frame MUST also
be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of type be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref
>. >.</t>
</t>
</dd> </dd>
<dt>reserved (local):</dt> <dt>reserved (local):</dt>
<dd> <dd>
<t> <t>A stream in the "reserved (local)" state is one that has been pro
mised by sending a
A stream in the "reserved (local)" state is one that has been pr
omised by sending a
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fr ame. A <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame rese rves an <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fr ame. A <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame rese rves an
idle stream by associating the stream with an open stream that w as initiated by the idle stream by associating the stream with an open stream that w as initiated by the
remote peer (see <xref target="PushResources"/>). remote peer (see <xref target="PushResources"/>).</t>
</t> <t>In this state, only the following transitions are possible:</t>
<t>
In this state, only the following transitions are possible:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>The endpoint can send a <xref target="HEADERS" format="none">H
The endpoint can send a <xref target="HEADERS" format="none" EADERS</xref> frame. This causes the stream to
>HEADERS</xref> frame. This causes the stream to open in a "half-closed (remote)" state.</li>
open in a "half-closed (remote)" state. <li>Either endpoint can send a <xref target="RST_STREAM" format="n
</li> one">RST_STREAM</xref> frame to cause the stream
<li> to become "closed". This releases the stream reservation.</
Either endpoint can send a <xref target="RST_STREAM" format= li>
"none">RST_STREAM</xref> frame to cause the stream
to become "closed". This releases the stream reservation.
</li>
</ul> </ul>
<t> <t>An endpoint <bcp14>MUST NOT</bcp14> send any type of frame other
An endpoint MUST NOT send any type of frame other than <xref tar than <xref target="HEADERS" format="none">HEADERS</xref>,
get="HEADERS" format="none">HEADERS</xref>, <xref target="RST_STREAM" format="none">RST_STREAM</xref>, or <x
<xref target="RST_STREAM" format="none">RST_STREAM</xref>, or <x ref target="PRIORITY" format="none">PRIORITY</xref> in this state.</t>
ref target="PRIORITY" format="none">PRIORITY</xref> in this state. <t>A <xref target="PRIORITY" format="none">PRIORITY</xref> or <xref
</t> target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frame <bcp14>MAY</bcp1
<t> 4> be received in
A <xref target="PRIORITY" format="none">PRIORITY</xref> or <xref
target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frame MAY be received
in
this state. Receiving any type of frame other than <xref target ="RST_STREAM" format="none">RST_STREAM</xref>, this state. Receiving any type of frame other than <xref target ="RST_STREAM" format="none">RST_STREAM</xref>,
<xref target="PRIORITY" format="none">PRIORITY</xref>, or <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> on a stream in this st ate <xref target="PRIORITY" format="none">PRIORITY</xref>, or <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> on a stream in this st ate
MUST be treated as a <xref target="ConnectionErrorHandler">conne <bcp14>MUST</bcp14> be treated as a <xref target="ConnectionErro
ction error</xref> rHandler">connection error</xref>
of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERR of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERR
OR</xref>. OR</xref>.</t>
</t>
</dd> </dd>
<dt>reserved (remote):</dt> <dt>reserved (remote):</dt>
<dd> <dd>
<t> <t>A stream in the "reserved (remote)" state has been reserved by a
remote peer.</t>
A stream in the "reserved (remote)" state has been reserved by a <t>In this state, only the following transitions are possible:</t>
remote peer.
</t>
<t>
In this state, only the following transitions are possible:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Receiving a <xref target="HEADERS" format="none">HEADERS</xref
Receiving a <xref target="HEADERS" format="none">HEADERS</xr > frame causes the stream to transition to
ef> frame causes the stream to transition to "half-closed (local)".</li>
"half-closed (local)". <li>Either endpoint can send a <xref target="RST_STREAM" format="n
</li> one">RST_STREAM</xref> frame to cause the stream
<li> to become "closed". This releases the stream reservation.</
Either endpoint can send a <xref target="RST_STREAM" format= li>
"none">RST_STREAM</xref> frame to cause the stream
to become "closed". This releases the stream reservation.
</li>
</ul> </ul>
<t> <t>An endpoint <bcp14>MUST NOT</bcp14> send any type of frame other
An endpoint MUST NOT send any type of frame other than <xref tar than <xref target="RST_STREAM" format="none">RST_STREAM</xref>, <xref target="WI
get="RST_STREAM" format="none">RST_STREAM</xref>, <xref target="WINDOW_UPDATE" f NDOW_UPDATE" format="none">WINDOW_UPDATE</xref>, or <xref target="PRIORITY" form
ormat="none">WINDOW_UPDATE</xref>, or <xref target="PRIORITY" format="none">PRIO at="none">PRIORITY</xref> in this state.</t>
RITY</xref> in this state. <t>Receiving any type of frame other than <xref target="HEADERS" for
</t> mat="none">HEADERS</xref>,
<t> <xref target="RST_STREAM" format="none">RST_STREAM</xref>, or <x
Receiving any type of frame other than <xref target="HEADERS" fo ref target="PRIORITY" format="none">PRIORITY</xref> on a stream in this state <b
rmat="none">HEADERS</xref>, cp14>MUST</bcp14>
<xref target="RST_STREAM" format="none">RST_STREAM</xref>, or <x
ref target="PRIORITY" format="none">PRIORITY</xref> on a stream in this state MU
ST
be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR< type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR<
/xref>. /xref>.</t>
</t>
</dd> </dd>
<dt>open:</dt> <dt>open:</dt>
<dd> <dd>
<t> <t>A stream in the "open" state may be used by both peers to send fr
ames of any type.
A stream in the "open" state may be used by both peers to send f
rames of any type.
In this state, sending peers observe advertised <xref target="Fl owControl">stream-level In this state, sending peers observe advertised <xref target="Fl owControl">stream-level
flow-control limits</xref>. flow-control limits</xref>.</t>
</t> <t>From this state, either endpoint can send a frame with an END_STR
<t> EAM flag set, which
From this state, either endpoint can send a frame with an END_ST
REAM flag set, which
causes the stream to transition into one of the "half-closed" st ates. An endpoint causes the stream to transition into one of the "half-closed" st ates. An endpoint
sending an END_STREAM flag causes the stream state to become "ha lf-closed (local)"; sending an END_STREAM flag causes the stream state to become "ha lf-closed (local)";
an endpoint receiving an END_STREAM flag causes the stream state to become "half-closed an endpoint receiving an END_STREAM flag causes the stream state to become "half-closed
(remote)". (remote)".</t>
</t> <t>Either endpoint can send a <xref target="RST_STREAM" format="none
<t> ">RST_STREAM</xref> frame from this state, causing
Either endpoint can send a <xref target="RST_STREAM" format="non it to transition immediately to "closed".</t>
e">RST_STREAM</xref> frame from this state, causing
it to transition immediately to "closed".
</t>
</dd> </dd>
<dt>half-closed (local):</dt> <dt>half-closed (local):</dt>
<dd> <dd>
<t> <t>A stream that is in the "half-closed (local)" state cannot be use
d for sending
A stream that is in the "half-closed (local)" state cannot be us
ed for sending
frames other than <xref target="WINDOW_UPDATE" format="none">WIN DOW_UPDATE</xref>, <xref target="PRIORITY" format="none">PRIORITY</xref>, and frames other than <xref target="WINDOW_UPDATE" format="none">WIN DOW_UPDATE</xref>, <xref target="PRIORITY" format="none">PRIORITY</xref>, and
<xref target="RST_STREAM" format="none">RST_STREAM</xref>. <xref target="RST_STREAM" format="none">RST_STREAM</xref>.</t>
</t> <t>A stream transitions from this state to "closed" when a frame is
<t> received with the
A stream transitions from this state to "closed" when a frame is
received with the
END_STREAM flag set or when either peer sends a <xref target="RS T_STREAM" format="none">RST_STREAM</xref> END_STREAM flag set or when either peer sends a <xref target="RS T_STREAM" format="none">RST_STREAM</xref>
frame. frame.</t>
</t> <t>An endpoint can receive any type of frame in this state. Providi
<t> ng flow-control
An endpoint can receive any type of frame in this state. Provid
ing flow-control
credit using <xref target="WINDOW_UPDATE" format="none">WINDOW_U PDATE</xref> frames is necessary to continue receiving credit using <xref target="WINDOW_UPDATE" format="none">WINDOW_U PDATE</xref> frames is necessary to continue receiving
flow-controlled frames. In this state, a receiver can ignore <x ref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frames, flow-controlled frames. In this state, a receiver can ignore <x ref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> frames,
which might arrive for a short period after a frame with the END which might arrive for a short period after a frame with the END
_STREAM flag set is sent. _STREAM flag set is sent.</t>
</t> <t><xref target="PRIORITY" format="none">PRIORITY</xref> frames can
<t><xref target="PRIORITY" format="none">PRIORITY</xref> frames can be received in this state.</t>
be received in this state.
</t>
</dd> </dd>
<dt>half-closed (remote):</dt> <dt>half-closed (remote):</dt>
<dd> <dd>
<t> <t>A stream that is "half-closed (remote)" is no longer being used b
y the peer to send
A stream that is "half-closed (remote)" is no longer being used
by the peer to send
frames. In this state, an endpoint is no longer obligated to ma intain a receiver frames. In this state, an endpoint is no longer obligated to ma intain a receiver
flow-control window. flow-control window.</t>
</t> <t>If an endpoint receives additional frames, other
<t>
If an endpoint receives additional frames, other
than <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</x ref>, <xref target="PRIORITY" format="none">PRIORITY</xref>, or than <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</x ref>, <xref target="PRIORITY" format="none">PRIORITY</xref>, or
<xref target="RST_STREAM" format="none">RST_STREAM</xref>, for <xref target="RST_STREAM" format="none">RST_STREAM</xref>, for
a stream that is in this state, it MUST respond with a <xref target="StreamError a stream that is in this state, it <bcp14>MUST</bcp14> respond with a <xref targ
Handler">stream error</xref> of type et="StreamErrorHandler">stream error</xref> of type
<xref target="STREAM_CLOSED" format="none">STREAM_CLOSED</xref>. <xref target="STREAM_CLOSED" format="none">STREAM_CLOSED</xref>.
</t> </t>
<t> <t>A stream that is "half-closed (remote)" can be used by the endpoi
A stream that is "half-closed (remote)" can be used by the endpo nt to send frames
int to send frames of any type. In this state, the endpoint continues to observe ad
of any type. In this state, the endpoint continues to observe ad vertised <xref target="FlowControl">stream-level flow-control limits</xref>.</t>
vertised <xref target="FlowControl">stream-level flow-control limits</xref>. <t>A stream can transition from this state to "closed" by sending a
</t> frame with the
<t> END_STREAM flag set or when either peer sends a <xref target="RS
A stream can transition from this state to "closed" by sending a T_STREAM" format="none">RST_STREAM</xref> frame.</t>
frame with the
END_STREAM flag set or when either peer sends a <xref target="RS
T_STREAM" format="none">RST_STREAM</xref> frame.
</t>
</dd> </dd>
<dt>closed:</dt> <dt>closed:</dt>
<dd> <dd>
<t> <t>The "closed" state is the terminal state.</t>
The "closed" state is the terminal state. <t>A stream enters the "closed" state after an endpoint both sends a
</t> nd receives a frame
<t>
A stream enters the "closed" state after an endpoint both sends an
d receives a frame
with an END_STREAM flag set. A stream also enters the "closed" sta te after an endpoint with an END_STREAM flag set. A stream also enters the "closed" sta te after an endpoint
either sends or receives a <xref target="RST_STREAM" format="none" >RST_STREAM</xref> either sends or receives a <xref target="RST_STREAM" format="none" >RST_STREAM</xref>
frame. frame.</t>
</t> <t>An endpoint <bcp14>MUST NOT</bcp14> send frames other than <xref
<t> target="PRIORITY" format="none">PRIORITY</xref> on a closed stream. An endpoint
An endpoint MUST NOT send frames other than <xref target="PRIORITY <bcp14>MAY</bcp14> treat receipt of
" format="none">PRIORITY</xref> on a closed stream. An endpoint MAY treat recei any other type of frame on a closed stream as a <xref target="Conn
pt of ectionErrorHandler">connection error</xref> of type <xref target="STREAM_CLOSED"
any other type of frame on a closed stream as a <xref target="Conn format="none">STREAM_CLOSED</xref>, except as noted below.</t>
ectionErrorHandler">connection error</xref> of type <xref target="STREAM_CLOSED" <t>An endpoint that sends a frame with the END_STREAM flag set or a
format="none">STREAM_CLOSED</xref>, except as noted below. <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame might receive a
</t> <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> or <xref target=
<t> "RST_STREAM" format="none">RST_STREAM</xref> frame from its peer in the time bef
An endpoint that sends a frame with the END_STREAM flag set or a < ore the peer
xref target="RST_STREAM" format="none">RST_STREAM</xref> frame might receive a < receives and processes the frame that closes the stream.</t>
xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> or <xref target=" <t>An endpoint that sends a <xref target="RST_STREAM" format="none">
RST_STREAM" format="none">RST_STREAM</xref> frame from its peer in the time befo RST_STREAM</xref>
re the peer
receives and processes the frame that closes the stream.
</t>
<t>
An endpoint that sends a <xref target="RST_STREAM" format="none">R
ST_STREAM</xref>
frame on a stream that is in the "open" or "half-closed (local)" state could receive any type of frame. The frame on a stream that is in the "open" or "half-closed (local)" state could receive any type of frame. The
peer might have sent or enqueued for sending these frames before p rocessing the <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame. A n endpoint MUST minimally peer might have sent or enqueued for sending these frames before p rocessing the <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame. A n endpoint <bcp14>MUST</bcp14> minimally
process and then discard any frames it receives in this state. Th is means updating process and then discard any frames it receives in this state. Th is means updating
header compression state for <xref target="HEADERS" format="none"> HEADERS</xref> and header compression state for <xref target="HEADERS" format="none"> HEADERS</xref> and
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fram <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fram
es; <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames also ca es. Receiving a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> f
use the promised rame also causes the promised
stream to become "reserved", even when the <xref target="PUSH_PROM stream to become "reserved (remote)", even when the <xref target="
ISE" format="none">PUSH_PROMISE</xref> frame is received on a closed stream; and PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame is received on a closed st
, the ream. Additionally, the
content of <xref target="DATA" format="none">DATA</xref> frames co content of <xref target="DATA" format="none">DATA</xref> frames co
unt toward the unts toward the
connection flow-control window. connection flow-control window.</t>
</t> <t>An endpoint can perform this minimal processing for all streams t
<t> hat are in the
An endpoint can perform this minimal processing for all streams th "closed" state. Endpoints <bcp14>MAY</bcp14> use other signals to
at are in the detect that a peer has received
"closed" state. Endpoints MAY use other signals to detect that a
peer has received
the frames that caused the stream to enter the "closed" state and treat receipt of any frame other the frames that caused the stream to enter the "closed" state and treat receipt of any frame other
than <xref target="PRIORITY" format="none">PRIORITY</xref> as a <x ref target="ConnectionErrorHandler">connection error</xref> of type <xref target ="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Endpoints can use frames than <xref target="PRIORITY" format="none">PRIORITY</xref> as a <x ref target="ConnectionErrorHandler">connection error</xref> of type <xref target ="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Endpoints can use frames
that indicate that the peer has received the closing signal to dri ve this. Endpoints that indicate that the peer has received the closing signal to dri ve this. Endpoints
SHOULD NOT use timers for this purpose. For example, an endpoint that sends a <xref target="SETTINGS" format="none">SETTINGS</xref> frame after c losing a stream can <bcp14>SHOULD NOT</bcp14> use timers for this purpose. For exampl e, an endpoint that sends a <xref target="SETTINGS" format="none">SETTINGS</xref > frame after closing a stream can
safely treat receipt of a <xref target="DATA" format="none">DATA</ xref> frame on that safely treat receipt of a <xref target="DATA" format="none">DATA</ xref> frame on that
stream as an error after receiving an acknowledgment of the settin gs. Other things stream as an error after receiving an acknowledgment of the settin gs. Other things
that might be used are <xref target="PING" format="none">PING</xre f> frames, receiving that might be used are <xref target="PING" format="none">PING</xre f> frames, receiving
data on streams that were created after closing the stream, or res ponses to requests data on streams that were created after closing the stream, or res ponses to requests
created after closing the stream. created after closing the stream.</t>
</t>
</dd> </dd>
</dl> </dl>
<t> <t>In the absence of more specific rules, implementations <bcp14>SHOULD<
In the absence of more specific rules, implementations SHOULD treat th /bcp14> treat the receipt of a frame
e receipt of a frame that is not expressly permitted in the description of a state as a <xr
that is not expressly permitted in the description of a state as a <xr ef target="ConnectionErrorHandler">connection error</xref> of type <xref target=
ef "PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Note that <xref target="P
target="ConnectionErrorHandler">connection error</xref> of type <xref RIORITY" format="none">PRIORITY</xref> can be sent and received in any stream
target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Note tha state.</t>
t <xref <t>The rules in this section only apply to frames defined in this docume
target="PRIORITY" format="none">PRIORITY</xref> can be sent and receiv nt. Receipt of
ed in any stream frames for which the semantics are unknown cannot be treated as an err
state. or, as the conditions
</t> for sending and receiving those frames are also unknown; see <xref tar
<t> get="extensibility"/>.</t>
The rules in this section only apply to frames defined in this documen <t>An example of the state transitions for an HTTP request/response exch
t. Receipt of ange can be found in
frames for which the semantics are unknown cannot be treated as an err
or as the conditions
for sending and receiving those frames are also unknown; see <xref
target="extensibility"/>.
</t>
<t>
An example of the state transitions for an HTTP request/response excha
nge can be found in
<xref target="HttpExamples"/>. An example of the state transitions fo r server push can be <xref target="HttpExamples"/>. An example of the state transitions fo r server push can be
found in Sections <xref target="PushRequests" format="counter"/> and < found in Sections&#xa0;<xref target="PushRequests" format="counter"/>
xref target="PushResponses" format="counter"/>. and <xref target="PushResponses" format="counter"/>.</t>
</t>
<section anchor="StreamIdentifiers"> <section anchor="StreamIdentifiers">
<name>Stream Identifiers</name> <name>Stream Identifiers</name>
<t> <t>Streams are identified by an unsigned 31-bit integer. Streams init
Streams are identified by an unsigned 31-bit integer. Streams initi iated by a client
ated by a client <bcp14>MUST</bcp14> use odd-numbered stream identifiers; those initi
MUST use odd-numbered stream identifiers; those initiated by the ser ated by the server <bcp14>MUST</bcp14> use
ver MUST use even-numbered stream identifiers. A stream identifier of zero (0x00
even-numbered stream identifiers. A stream identifier of zero (0x0) ) is used for
is used for
connection control messages; the stream identifier of zero cannot be used to establish a connection control messages; the stream identifier of zero cannot be used to establish a
new stream. new stream.</t>
</t> <t>The identifier of a newly established stream <bcp14>MUST</bcp14> be
<t> numerically greater than all
The identifier of a newly established stream MUST be numerically gre
ater than all
streams that the initiating endpoint has opened or reserved. This g overns streams that streams that the initiating endpoint has opened or reserved. This g overns streams that
are opened using a <xref target="HEADERS" format="none">HEADERS</xre f> frame and streams that are reserved using are opened using a <xref target="HEADERS" format="none">HEADERS</xre f> frame and streams that are reserved using
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>. An e ndpoint that receives an unexpected stream identifier <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>. An e ndpoint that receives an unexpected stream identifier
MUST respond with a <xref target="ConnectionErrorHandler">connection <bcp14>MUST</bcp14> respond with a <xref target="ConnectionErrorHand
error</xref> of ler">connection error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xre type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xre
f>. f>.</t>
</t> <t>A <xref target="HEADERS" format="none">HEADERS</xref> frame will tr
<t> ansition the client-initiated stream identified
A <xref target="HEADERS" format="none">HEADERS</xref> frame will tra
nsition the client-initiated stream identified
by the stream identifier in the frame header from "idle" to "open". A <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> by the stream identifier in the frame header from "idle" to "open". A <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>
frame will transition the server-initiated stream identified by the frame will transition the server-initiated stream identified by the
"Promised Stream ID" field in the frame payload from "idle" to "reserved". When Promised Stream ID field in the frame payload from "idle" to "reserved (local)"
a stream transitions out of the "idle" state, all "idle" streams tha or "reserved (remote)". When
t might have been opened by the peer with a lower-valued a stream transitions out of the "idle" state, all streams in the "id
le" state that might have been opened by the peer with a lower-valued
stream identifier immediately transition to "closed". That is, an en dpoint may skip a stream identifier, with the stream identifier immediately transition to "closed". That is, an en dpoint may skip a stream identifier, with the
effect being that the skipped stream is immediately closed. effect being that the skipped stream is immediately closed.</t>
</t> <t>Stream identifiers cannot be reused. Long-lived connections can re
<t> sult in an endpoint
Stream identifiers cannot be reused. Long-lived connections can res
ult in an endpoint
exhausting the available range of stream identifiers. A client that is unable to exhausting the available range of stream identifiers. A client that is unable to
establish a new stream identifier can establish a new connection for new streams. A establish a new stream identifier can establish a new connection for new streams. A
server that is unable to establish a new stream identifier can send a server that is unable to establish a new stream identifier can send a
<xref target="GOAWAY" format="none">GOAWAY</xref> frame so that the client is forced to open a new connection for <xref target="GOAWAY" format="none">GOAWAY</xref> frame so that the client is forced to open a new connection for
new streams. new streams.</t>
</t>
</section> </section>
<section> <section>
<name>Stream Concurrency</name> <name>Stream Concurrency</name>
<t> <t>A peer can limit the number of concurrently active streams using th
A peer can limit the number of concurrently active streams using the e
<xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTING S_MAX_CONCURRENT_STREAMS</xref> parameter (see <xref target="SettingValues"/>) w ithin a <xref target="SETTINGS" format="none">SETTINGS</xref> frame. The maximum concurrent <xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTING S_MAX_CONCURRENT_STREAMS</xref> parameter (see <xref target="SettingValues"/>) w ithin a <xref target="SETTINGS" format="none">SETTINGS</xref> frame. The maximum concurrent
streams setting is specific to each endpoint and applies only to the peer that receives streams setting is specific to each endpoint and applies only to the peer that receives
the setting. That is, clients specify the maximum number of concurre nt streams the the setting. That is, clients specify the maximum number of concurre nt streams the
server can initiate, and servers specify the maximum number of concu rrent streams the server can initiate, and servers specify the maximum number of concu rrent streams the
client can initiate. client can initiate.</t>
</t> <t>Streams that are in the "open" state or in either of the "half-clos
<t> ed" states count toward
Streams that are in the "open" state or in either of the "half-close
d" states count toward
the maximum number of streams that an endpoint is permitted to open. Streams in any of the maximum number of streams that an endpoint is permitted to open. Streams in any of
these three states count toward the limit advertised in the these three states count toward the limit advertised in the
<xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTING S_MAX_CONCURRENT_STREAMS</xref> setting. Streams in either of the <xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTING S_MAX_CONCURRENT_STREAMS</xref> setting. Streams in either of the
"reserved" states do not count toward the stream limit. "reserved" states do not count toward the stream limit.</t>
</t> <t>Endpoints <bcp14>MUST NOT</bcp14> exceed the limit set by their pee
<t> r. An endpoint that receives a
Endpoints MUST NOT exceed the limit set by their peer. An endpoint
that receives a
<xref target="HEADERS" format="none">HEADERS</xref> frame that cause s its advertised concurrent stream limit to be <xref target="HEADERS" format="none">HEADERS</xref> frame that cause s its advertised concurrent stream limit to be
exceeded MUST treat this as a <xref target="StreamErrorHandler">stre am error</xref> of exceeded <bcp14>MUST</bcp14> treat this as a <xref target="StreamErr orHandler">stream error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xre f> or <xref target="REFUSED_STREAM" format="none">REFUSED_STREAM</xref>. The ch oice of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xre f> or <xref target="REFUSED_STREAM" format="none">REFUSED_STREAM</xref>. The ch oice of
error code determines whether the endpoint wishes to enable automati error code determines whether the endpoint wishes to enable automati
c retry (see <xref target="Reliability"/> for details). c retry (see <xref target="Reliability"/> for details).</t>
</t> <t>An endpoint that wishes to reduce the value of
<t>
An endpoint that wishes to reduce the value of
<xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTING S_MAX_CONCURRENT_STREAMS</xref> to a value that is below the current <xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTING S_MAX_CONCURRENT_STREAMS</xref> to a value that is below the current
number of open streams can either close streams that exceed the new value or allow number of open streams can either close streams that exceed the new value or allow
streams to complete. streams to complete.</t>
</t>
</section> </section>
</section> </section>
<section anchor="FlowControl"> <section anchor="FlowControl">
<name>Flow Control</name> <name>Flow Control</name>
<t> <t>Using streams for multiplexing introduces contention over use of the
Using streams for multiplexing introduces contention over use of the T TCP connection,
CP connection,
resulting in blocked streams. A flow-control scheme ensures that stre ams on the same resulting in blocked streams. A flow-control scheme ensures that stre ams on the same
connection do not destructively interfere with each other. Flow contr ol is used for both connection do not destructively interfere with each other. Flow contr ol is used for both
individual streams and for the connection as a whole. individual streams and the connection as a whole.</t>
</t> <t>HTTP/2 provides for flow control through use of the <xref target="WIN
<t> DOW_UPDATE">WINDOW_UPDATE frame</xref>.</t>
HTTP/2 provides for flow control through use of the <xref target="WIND
OW_UPDATE">WINDOW_UPDATE frame</xref>.
</t>
<section anchor="fc-principles"> <section anchor="fc-principles">
<name>Flow-Control Principles</name> <name>Flow-Control Principles</name>
<t> <t>HTTP/2 stream flow control aims to allow a variety of flow-control
HTTP/2 stream flow control aims to allow a variety of flow-control a algorithms to be
lgorithms to be
used without requiring protocol changes. Flow control in HTTP/2 has the following used without requiring protocol changes. Flow control in HTTP/2 has the following
characteristics: characteristics:</t>
</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>Flow control is specific to a connection. HTTP/2 flow control o
Flow control is specific to a connection. HTTP/2 flow control o perates between
perates between the endpoints of a single hop and not over the entire end-to-end
the endpoints of a single hop and not over the entire end-to-end path.</li>
path. <li>Flow control is based on <xref target="WINDOW_UPDATE" format="no
</li> ne">WINDOW_UPDATE</xref> frames. Receivers advertise how many octets
<li>
Flow control is based on <xref target="WINDOW_UPDATE" format="no
ne">WINDOW_UPDATE</xref> frames. Receivers advertise how many octets
they are prepared to receive on a stream and for the entire conn ection. This is a they are prepared to receive on a stream and for the entire conn ection. This is a
credit-based scheme. credit-based scheme.</li>
</li> <li>Flow control is directional with overall control provided by the
<li> receiver. A
Flow control is directional with overall control provided by the receiver <bcp14>MAY</bcp14> choose to set any window size that i
receiver. A t desires for each stream and for
receiver MAY choose to set any window size that it desires for e the entire connection. A sender <bcp14>MUST</bcp14> respect flo
ach stream and for w-control limits imposed by a
the entire connection. A sender MUST respect flow-control limit
s imposed by a
receiver. Clients, servers, and intermediaries all independentl y advertise their receiver. Clients, servers, and intermediaries all independentl y advertise their
flow-control window as a receiver and abide by the flow-control limits set by flow-control window as a receiver and abide by the flow-control limits set by
their peer when sending. their peer when sending.</li>
</li> <li>The initial value for the flow-control window is 65,535 octets f
<li> or both new streams
The initial value for the flow-control window is 65,535 octets f and the overall connection.</li>
or both new streams <li>The frame type determines whether flow control applies to a fram
and the overall connection. e. Of the frames
</li>
<li>
The frame type determines whether flow control applies to a fram
e. Of the frames
specified in this document, only <xref target="DATA" format="non e">DATA</xref> frames are subject to flow specified in this document, only <xref target="DATA" format="non e">DATA</xref> frames are subject to flow
control; all other frame types do not consume space in the adver tised flow-control control; all other frame types do not consume space in the adver tised flow-control
window. This ensures that important control frames are not bloc window. This ensures that important control frames are not bloc
ked by flow control. ked by flow control.</li>
</li> <li>An endpoint can choose to disable its own flow control, but an e
<li> ndpoint cannot ignore
An endpoint can choose to disable its own flow control, but an end flow-control signals from its peer.</li>
point cannot ignore <li>HTTP/2 defines only the format and semantics of the <xref target
flow control signals from its peer. ="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>
</li>
<li>
HTTP/2 defines only the format and semantics of the <xref target
="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref>
frame (<xref target="WINDOW_UPDATE"/>). This document does not stipulate how a frame (<xref target="WINDOW_UPDATE"/>). This document does not stipulate how a
receiver decides when to send this frame or the value that it se nds, nor does it receiver decides when to send this frame or the value that it se nds, nor does it
specify how a sender chooses to send packets. Implementations a re able to select specify how a sender chooses to send packets. Implementations a re able to select
any algorithm that suits their needs. any algorithm that suits their needs.</li>
</li>
</ol> </ol>
<t> <t>Implementations are also responsible for prioritizing the sending o
Implementations are also responsible for prioritizing the sending of f requests and
requests and
responses, choosing how to avoid head-of-line blocking for requests, and managing the responses, choosing how to avoid head-of-line blocking for requests, and managing the
creation of new streams. Algorithm choices for these could interact with any creation of new streams. Algorithm choices for these could interact with any
flow-control algorithm. flow-control algorithm.</t>
</t>
</section> </section>
<section anchor="DisableFlowControl"> <section anchor="DisableFlowControl">
<name>Appropriate Use of Flow Control</name> <name>Appropriate Use of Flow Control</name>
<t> <t>Flow control is defined to protect endpoints that are operating und
Flow control is defined to protect endpoints that are operating unde er resource
r resource
constraints. For example, a proxy needs to share memory between man y connections and constraints. For example, a proxy needs to share memory between man y connections and
also might have a slow upstream connection and a fast downstream one . Flow control also might have a slow upstream connection and a fast downstream one . Flow control
addresses cases where the receiver is unable to process data on one stream yet wants to addresses cases where the receiver is unable to process data on one stream yet wants to
continue to process other streams in the same connection. continue to process other streams in the same connection.</t>
</t> <t>Deployments that do not require this capability can advertise a flo
<t> w-control window of
Deployments that do not require this capability can advertise a flow
-control window of
the maximum size (2<sup>31</sup>-1) and can maintain this window by sending a the maximum size (2<sup>31</sup>-1) and can maintain this window by sending a
<xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> fram e when any data is received. This effectively disables <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> fram e when any data is received. This effectively disables
flow control for that receiver. Conversely, a sender is always subj ect to the flow control for that receiver. Conversely, a sender is always subj ect to the
flow-control window advertised by the receiver. flow-control window advertised by the receiver.</t>
</t> <t>Deployments with constrained resources (for example, memory) can em
<t> ploy flow control to
Deployments with constrained resources (for example, memory) can emp
loy flow control to
limit the amount of memory a peer can consume. Note, however, that this can lead to limit the amount of memory a peer can consume. Note, however, that this can lead to
suboptimal use of available network resources if flow control is ena bled without suboptimal use of available network resources if flow control is ena bled without
knowledge of the bandwidth-delay product (see <xref target="RFC7323" knowledge of the bandwidth * delay product (see <xref target="RFC732
/>). 3"/>).</t>
</t> <t>Even with full awareness of the current bandwidth * delay product,
<t> implementation of
Even with full awareness of the current bandwidth-delay product, imp flow control can be difficult. Endpoints <bcp14>MUST</bcp14> read a
lementation of flow nd process HTTP/2 frames from the
control can be difficult. Endpoints MUST read and process HTTP/2 fr TCP receive buffer as soon as data is available. Failure to read pr
ames from the TCP omptly could lead to
receive buffer as soon as data is available. Failure to read prompt a deadlock when critical frames, such as <xref target="WINDOW_UPDATE
ly could lead to a " format="none">WINDOW_UPDATE</xref>, are not read and acted upon. Reading frame
deadlock when critical frames, such as <xref target="WINDOW_UPDATE" s promptly
format="none">WINDOW_UPDATE</xref>, are not read and acted upon. Rea does not expose endpoints to resource exhaustion attacks, as HTTP/2
ding frames promptly flow control limits
does not expose endpoints to resource exhaustion attacks as HTTP/2 f resource commitments.</t>
low control limits
resource commitments.
</t>
</section> </section>
<section anchor="FlowControlPerformance"> <section anchor="FlowControlPerformance">
<name>Flow Control Performance</name> <name>Flow-Control Performance</name>
<t> <t>If an endpoint cannot ensure that its peer always has available flo
If an endpoint cannot ensure that its peer always has available flow w-control window
control window space that is greater than the peer's space that is greater than the peer's bandwidth * delay product on t
bandwidth-delay product on this connection, its receive throughput w his connection, its
ill be limited by HTTP/2 flow control. This will result receive throughput will be limited by HTTP/2 flow control. This will
in degraded performance. result in degraded
</t> performance.</t>
<t> <t>Sending timely <xref target="WINDOW_UPDATE" format="none">WINDOW_UP
Sending timely <xref target="WINDOW_UPDATE" format="none">WINDOW_UPD DATE</xref> frames
ATE</xref> frames can improve performance. Endpoints will can improve performance. Endpoints will want to balance the need to
want to balance the need to improve receive throughput with the need improve receive
to manage resource exhaustion risks, and should take throughput with the need to manage resource exhaustion risks and sho
careful note of <xref target="dos"/> in defining their strategy to m uld take careful
anage window sizes. note of <xref target="dos"/> in defining their strategy to manage wi
</t> ndow sizes.</t>
</section> </section>
</section> </section>
<section anchor="StreamPriority"> <section anchor="StreamPriority">
<name>Prioritization</name> <name>Prioritization</name>
<t> <t>In a multiplexed protocol like HTTP/2, prioritizing allocation of ban
In a multiplexed protocol like HTTP/2, prioritizing allocation of band dwidth and
width and
computation resources to streams can be critical to attaining good per formance. A poor computation resources to streams can be critical to attaining good per formance. A poor
prioritization scheme can result in HTTP/2 providing poor performance. With no parallelism prioritization scheme can result in HTTP/2 providing poor performance. With no parallelism
at the TCP layer, performance could be significantly worse than HTTP/1 at the TCP layer, performance could be significantly worse than HTTP/1
.1. .1.</t>
</t> <t>A good prioritization scheme benefits from the application of context
<t> ual knowledge such as
A good prioritization scheme benefits from the application of contextu
al knowledge such as
the content of resources, how resources are interrelated, and how thos e resources will be the content of resources, how resources are interrelated, and how thos e resources will be
used by a peer. In particular, clients can possess knowledge about th e priority of used by a peer. In particular, clients can possess knowledge about th e priority of
requests that is relevant to server prioritization. In those cases, h aving clients requests that is relevant to server prioritization. In those cases, h aving clients
provide priority information can improve performance. provide priority information can improve performance.</t>
</t>
<section anchor="PriorityHistory"> <section anchor="PriorityHistory">
<name>Background on Priority in RFC 7540</name> <name>Background on Priority in RFC 7540</name>
<t> <t>RFC 7540 defined a rich system for signaling priority of requests.
RFC 7540 defined a rich system for signaling priority of requests. However, this system
However, this system proved to be complex, and it was not uniformly implemented.</t>
proved to be complex and it was not uniformly implemented. <t>The flexible scheme meant that it was possible for clients to expre
</t> ss priorities in very
<t>
The flexible scheme meant that it was possible for clients to expres
s priorities in very
different ways, with little consistency in the approaches that were adopted. For different ways, with little consistency in the approaches that were adopted. For
servers, implementing generic support for the scheme was complex. I mplementation of servers, implementing generic support for the scheme was complex. I mplementation of
priorities was uneven in both clients and servers. Many server depl oyments ignored priorities was uneven in both clients and servers. Many server depl oyments ignored
client signals when prioritizing their handling of requests. client signals when prioritizing their handling of requests.</t>
</t> <t>In short, the prioritization signaling in <xref target="RFC7540">RF
<t> C 7540</xref> was not
In short, the prioritization signaling in <xref target="RFC7540">RFC successful.</t>
7540</xref> was not
successful.
</t>
</section> </section>
<section anchor="PriorityHere"> <section anchor="PriorityHere">
<name>Priority Signaling in this Document</name> <name>Priority Signaling in This Document</name>
<t> <t>This update to HTTP/2 deprecates the priority signaling defined in
This update to HTTP/2 deprecates the priority signaling defined in < <xref target="RFC7540">RFC 7540</xref>. The bulk of the text related to priorit
xref target="RFC7540">RFC 7540</xref>. The bulk of the text related to priority y signals is
signals is
not included in this document. The description of frame fields and some of the not included in this document. The description of frame fields and some of the
mandatory handling is retained to ensure that implementations of thi s document remain mandatory handling is retained to ensure that implementations of thi s document remain
interoperable with implementations that use the priority signaling d escribed in RFC interoperable with implementations that use the priority signaling d escribed in RFC
7540. 7540.</t>
</t> <t>A thorough description of the RFC 7540 priority scheme remains in <
<t> xref target="RFC7540" section="5.3"/>.</t>
A thorough description of the RFC 7540 priority scheme remains in <x <t>Signaling priority information is necessary to attain good performa
ref target="RFC7540" section="5.3"/>. nce in many cases.
</t>
<t>
Signaling priority information is necessary to attain good performan
ce in many cases.
Where signaling priority information is important, endpoints are enc ouraged to use an Where signaling priority information is important, endpoints are enc ouraged to use an
alternative scheme, such as <xref target="I-D.ietf-httpbis-priority" alternative scheme, such as the scheme described in <xref target="RF
/>. C9218"/>.</t>
</t> <t>Though the priority signaling from RFC 7540 was not widely adopted,
<t> the information it
Though the priority signaling from RFC 7540 was not widely adopted,
the information it
provides can still be useful in the absence of better information. Endpoints that provides can still be useful in the absence of better information. Endpoints that
receive priority signals in <xref target="HEADERS" format="none">HEA DERS</xref> or <xref target="PRIORITY" format="none">PRIORITY</xref> frames can benefit from applying that receive priority signals in <xref target="HEADERS" format="none">HEA DERS</xref> or <xref target="PRIORITY" format="none">PRIORITY</xref> frames can benefit from applying that
information. In particular, implementations that consume these sign als would not information. In particular, implementations that consume these sign als would not
benefit from discarding these priority signals in the absence of alt benefit from discarding these priority signals in the absence of alt
ernatives. ernatives.</t>
</t> <t>Servers <bcp14>SHOULD</bcp14> use other contextual information in d
<t> etermining priority of requests in
Servers SHOULD use other contextual information in determining prior the absence of any priority signals. Servers <bcp14>MAY</bcp14> int
ity of requests in erpret the complete absence of
the absence of any priority signals. Servers MAY interpret the comp
lete absence of
signals as an indication that the client has not implemented the fea ture. The defaults signals as an indication that the client has not implemented the fea ture. The defaults
described in <xref target="RFC7540" section="5.3.5"/> are known to h ave poor performance described in <xref target="RFC7540" section="5.3.5"/> are known to h ave poor performance
under most conditions and their use is unlikely to be deliberate. under most conditions, and their use is unlikely to be deliberate.</
</t> t>
</section> </section>
</section> </section>
<section anchor="ErrorHandler"> <section anchor="ErrorHandler">
<name>Error Handling</name> <name>Error Handling</name>
<t> <t>HTTP/2 framing permits two classes of errors:</t>
HTTP/2 framing permits two classes of error:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>An error condition that renders the entire connection unusable is
An error condition that renders the entire connection unusable is a connection error.</li>
a connection error. <li>An error in an individual stream is a stream error.</li>
</li>
<li>
An error in an individual stream is a stream error.
</li>
</ul> </ul>
<t> <t>A list of error codes is included in <xref target="ErrorCodes"/>.</t>
A list of error codes is included in <xref target="ErrorCodes"/>. <t>It is possible that an endpoint will encounter frames that would caus
</t> e multiple errors. Implementations <bcp14>MAY</bcp14> discover
<t> multiple errors during processing, but they <bcp14>SHOULD</bcp14> repo
It is possible that an endpoint will encounter frames that would cause rt at most one stream and one connection error as a result.</t>
multiple errors. Implementations MAY discover <t>The first stream error reported for a given stream prevents any other
multiple errors during processing, but they SHOULD report at most one errors on that stream from being reported.
stream and one connection error as a result.
</t>
<t>
The first stream error reported for a given stream prevents any other
errors on that stream from being reported.
In comparison, the protocol permits multiple <xref target="GOAWAY" for mat="none">GOAWAY</xref> frames, though an In comparison, the protocol permits multiple <xref target="GOAWAY" for mat="none">GOAWAY</xref> frames, though an
endpoint SHOULD report just one type of connection error unless an err endpoint <bcp14>SHOULD</bcp14> report just one type of connection erro
or is encountered during graceful shutdown. r unless an error is encountered during graceful shutdown.
If this occurs, an endpoint MAY send an additional GOAWAY frame with t If this occurs, an endpoint <bcp14>MAY</bcp14> send an additional GOAW
he new error code, in addition to any prior AY frame with the new error code, in addition to any prior
GOAWAY that contained <xref target="NO_ERROR" format="none">NO_ERROR</ GOAWAY that contained <xref target="NO_ERROR" format="none">NO_ERROR</
xref>. xref>.</t>
</t> <t>If an endpoint detects multiple different errors, it <bcp14>MAY</bcp1
<t> 4> choose to report any one of those
If an endpoint detects multiple different errors, it MAY choose to rep errors. If a frame causes a connection error, that error <bcp14>MUST</
ort any one of those bcp14> be reported. Additionally,
errors. If a frame causes a connection error, that error MUST be repor an endpoint <bcp14>MAY</bcp14> use any applicable error code when it d
ted. Additionally, etects an error condition; a
an endpoint MAY use any applicable error code when it detects an error
condition; a
generic error code (such as <xref target="PROTOCOL_ERROR" format="none ">PROTOCOL_ERROR</xref> or <xref target="INTERNAL_ERROR" format="none">INTERNAL_ ERROR</xref>) can always be used in place of more specific error generic error code (such as <xref target="PROTOCOL_ERROR" format="none ">PROTOCOL_ERROR</xref> or <xref target="INTERNAL_ERROR" format="none">INTERNAL_ ERROR</xref>) can always be used in place of more specific error
codes. codes.</t>
</t>
<section anchor="ConnectionErrorHandler"> <section anchor="ConnectionErrorHandler">
<name>Connection Error Handling</name> <name>Connection Error Handling</name>
<t> <t>A connection error is any error that prevents further processing of
A connection error is any error that prevents further processing of the frame
the frame layer or corrupts any connection state.</t>
layer or corrupts any connection state. <t>An endpoint that encounters a connection error <bcp14>SHOULD</bcp14
</t> > first send a <xref target="GOAWAY" format="none">GOAWAY</xref>
<t>
An endpoint that encounters a connection error SHOULD first send a <
xref target="GOAWAY" format="none">GOAWAY</xref>
frame (<xref target="GOAWAY"/>) with the stream identifier of the la st stream that it frame (<xref target="GOAWAY"/>) with the stream identifier of the la st stream that it
successfully received from its peer. The <xref target="GOAWAY" form at="none">GOAWAY</xref> frame includes an <xref target="ErrorCodes">error successfully received from its peer. The <xref target="GOAWAY" form at="none">GOAWAY</xref> frame includes an <xref target="ErrorCodes">error
code</xref> that indicates why the connection is terminating. After sending the code</xref> that indicates why the connection is terminating. After sending the
<xref target="GOAWAY" format="none">GOAWAY</xref> frame for an error <xref target="GOAWAY" format="none">GOAWAY</xref> frame for an error
condition, the endpoint MUST close the TCP condition, the endpoint <bcp14>MUST</bcp14> close the TCP
connection. connection.</t>
</t> <t>It is possible that the <xref target="GOAWAY" format="none">GOAWAY<
<t> /xref> will not be reliably received by the
It is possible that the <xref target="GOAWAY" format="none">GOAWAY</
xref> will not be reliably received by the
receiving endpoint. In the event of a connection error, receiving endpoint. In the event of a connection error,
<xref target="GOAWAY" format="none">GOAWAY</xref> only provides a be st-effort attempt to communicate with the peer <xref target="GOAWAY" format="none">GOAWAY</xref> only provides a be st-effort attempt to communicate with the peer
about why the connection is being terminated. about why the connection is being terminated.</t>
</t> <t>An endpoint can end a connection at any time. In particular, an en
<t> dpoint <bcp14>MAY</bcp14> choose to
An endpoint can end a connection at any time. In particular, an end treat a stream error as a connection error. Endpoints <bcp14>SHOULD
point MAY choose to </bcp14> send a
treat a stream error as a connection error. Endpoints SHOULD send a
<xref target="GOAWAY" format="none">GOAWAY</xref> frame when ending a connection, providing that circumstances <xref target="GOAWAY" format="none">GOAWAY</xref> frame when ending a connection, providing that circumstances
permit it. permit it.</t>
</t>
</section> </section>
<section anchor="StreamErrorHandler"> <section anchor="StreamErrorHandler">
<name>Stream Error Handling</name> <name>Stream Error Handling</name>
<t> <t>A stream error is an error related to a specific stream that does n
A stream error is an error related to a specific stream that does no ot affect processing
t affect processing of other streams.</t>
of other streams. <t>An endpoint that detects a stream error sends a <xref target="RST_S
</t> TREAM" format="none">RST_STREAM</xref> frame (<xref target="RST_STREAM"/>) that
<t> contains the stream identifier of the stream where the error
An endpoint that detects a stream error sends a <xref target="RST_ST
REAM" format="none">RST_STREAM</xref> frame (<xref target="RST_STREAM"/>) that c
ontains the stream identifier of the stream where the error
occurred. The <xref target="RST_STREAM" format="none">RST_STREAM</x ref> frame includes an error code that indicates the occurred. The <xref target="RST_STREAM" format="none">RST_STREAM</x ref> frame includes an error code that indicates the
type of error. type of error.</t>
</t> <t>A <xref target="RST_STREAM" format="none">RST_STREAM</xref> is the
<t> last frame that an endpoint can send on a stream.
A <xref target="RST_STREAM" format="none">RST_STREAM</xref> is the l The peer that sends the <xref target="RST_STREAM" format="none">RST_
ast frame that an endpoint can send on a stream. STREAM</xref> frame <bcp14>MUST</bcp14> be prepared to receive any
The peer that sends the <xref target="RST_STREAM" format="none">RST_
STREAM</xref> frame MUST be prepared to receive any
frames that were sent or enqueued for sending by the remote peer. T hese frames can be frames that were sent or enqueued for sending by the remote peer. T hese frames can be
ignored, except where they modify connection state (such as the stat e maintained for ignored, except where they modify connection state (such as the stat e maintained for
<xref target="FieldBlock">field section compression</xref> or flow c <xref target="FieldBlock">field section compression</xref> or flow c
ontrol). ontrol).</t>
</t> <t>Normally, an endpoint <bcp14>SHOULD NOT</bcp14> send more than one
<t> <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame for
Normally, an endpoint SHOULD NOT send more than one <xref target="RS any stream. However, an endpoint <bcp14>MAY</bcp14> send additional
T_STREAM" format="none">RST_STREAM</xref> frame for <xref target="RST_STREAM" format="none">RST_STREAM</xref> frames if
any stream. However, an endpoint MAY send additional <xref target="R
ST_STREAM" format="none">RST_STREAM</xref> frames if
it receives frames on a closed stream after more than a round-trip t ime. This behavior it receives frames on a closed stream after more than a round-trip t ime. This behavior
is permitted to deal with misbehaving implementations. is permitted to deal with misbehaving implementations.</t>
</t> <t>To avoid looping, an endpoint <bcp14>MUST NOT</bcp14> send a <xref
<t> target="RST_STREAM" format="none">RST_STREAM</xref> in response to a
To avoid looping, an endpoint MUST NOT send a <xref target="RST_STRE <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame.</t>
AM" format="none">RST_STREAM</xref> in response to a
<xref target="RST_STREAM" format="none">RST_STREAM</xref> frame.
</t>
</section> </section>
<section> <section>
<name>Connection Termination</name> <name>Connection Termination</name>
<t> <t>If the TCP connection is closed or reset while streams remain in th
If the TCP connection is closed or reset while streams remain in the e "open" or "half-closed"
"open" or "half-closed" states, then the affected streams cannot be automatically retried (s
states, then the affected streams cannot be automatically retried (s ee <xref target="Reliability"/> for details).</t>
ee <xref target="Reliability"/> for details).
</t>
</section> </section>
</section> </section>
<section anchor="extensibility"> <section anchor="extensibility">
<name>Extending HTTP/2</name> <name>Extending HTTP/2</name>
<t> <t>HTTP/2 permits extension of the protocol. Within the limitations des
HTTP/2 permits extension of the protocol. Within the limitations desc cribed in this
ribed in this
section, protocol extensions can be used to provide additional service s or alter section, protocol extensions can be used to provide additional service s or alter
any aspect of the protocol. Extensions are effective only within the s cope of a single HTTP/2 any aspect of the protocol. Extensions are effective only within the s cope of a single HTTP/2
connection. connection.</t>
</t> <t>This applies to the protocol elements defined in this document. This
<t> does not affect the
This applies to the protocol elements defined in this document. This
does not affect the
existing options for extending HTTP, such as defining new methods, sta tus codes, or fields existing options for extending HTTP, such as defining new methods, sta tus codes, or fields
(see <xref target="HTTP" section="16"/>). (see <xref target="RFC9110" section="16"/>).</t>
</t> <t>Extensions are permitted to use new <xref target="FrameHeader">frame
<t> types</xref>, new
Extensions are permitted to use new <xref target="FrameHeader">frame t
ypes</xref>, new
<xref target="SETTINGS">settings</xref>, or new <xref target="ErrorCod es">error <xref target="SETTINGS">settings</xref>, or new <xref target="ErrorCod es">error
codes</xref>. Registries for managing these extension points are defi codes</xref>. Registries for managing these extension points are defi
ned in <xref ned in <xref section="11" target="RFC7540"/>.</t>
section="11" target="RFC7540"/>. <t>Implementations <bcp14>MUST</bcp14> ignore unknown or unsupported val
</t> ues in all extensible protocol
<t> elements. Implementations <bcp14>MUST</bcp14> discard frames that hav
Implementations MUST ignore unknown or unsupported values in all exten e unknown or unsupported types.
sible protocol
elements. Implementations MUST discard frames that have unknown or un
supported types.
This means that any of these extension points can be safely used by ex tensions without This means that any of these extension points can be safely used by ex tensions without
prior arrangement or negotiation. However, extension frames that appe ar in the middle of prior arrangement or negotiation. However, extension frames that appe ar in the middle of
a <xref target="FieldBlock">field block</xref> are not permitted; thes e MUST be treated a <xref target="FieldBlock">field block</xref> are not permitted; thes e <bcp14>MUST</bcp14> be treated
as a <xref target="ConnectionErrorHandler">connection error</xref> of type as a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
</t> <t>Extensions <bcp14>SHOULD</bcp14> avoid changing protocol elements def
<t> ined in this document or
Extensions SHOULD avoid changing protocol elements defined in this doc
ument or
elements for which no extension mechanism is defined. This includes c hanges to the elements for which no extension mechanism is defined. This includes c hanges to the
layout of frames, additions or changes to the way that frames are comp osed into <xref target="HttpFraming">HTTP messages</xref>, the definition of pse udo-header fields, or layout of frames, additions or changes to the way that frames are comp osed into <xref target="HttpFraming">HTTP messages</xref>, the definition of pse udo-header fields, or
changes to any protocol element that a compliant endpoint might treat changes to any protocol element that a compliant endpoint might treat
as a <xref target="ConnectionErrorHandler">connection error</xref>. as a <xref target="ConnectionErrorHandler">connection error</xref>.</t>
</t> <t>An extension that changes existing protocol elements or state <bcp14>
<t> MUST</bcp14> be negotiated before
An extension that changes existing protocol elements or state MUST be being used. For example, an extension that changes the layout of the
negotiated before <xref target="HEADERS" format="none">HEADERS</xref> frame cannot be used until t
being used. For example, an extension that changes the layout of the he peer has
<xref
target="HEADERS" format="none">HEADERS</xref> frame cannot be used unt
il the peer has
given a positive signal that this is acceptable. In this case, it cou ld also be necessary given a positive signal that this is acceptable. In this case, it cou ld also be necessary
to coordinate when the revised layout comes into effect. For example, treating frames to coordinate when the revised layout comes into effect. For example, treating frames
other than <xref target="DATA" format="none">DATA</xref> frames as flo w controlled other than <xref target="DATA" format="none">DATA</xref> frames as flo w controlled
requires a change in semantics that both endpoints need to understand, so this can only be requires a change in semantics that both endpoints need to understand, so this can only be
done through negotiation. done through negotiation.</t>
</t> <t>This document doesn't mandate a specific method for negotiating the u
<t> se of an extension
This document doesn't mandate a specific method for negotiating the us
e of an extension
but notes that a <xref target="SettingValues">setting</xref> could be used for that but notes that a <xref target="SettingValues">setting</xref> could be used for that
purpose. If both peers set a value that indicates willingness to use the extension, then purpose. If both peers set a value that indicates willingness to use the extension, then
the extension can be used. If a setting is used for extension negotia tion, the initial the extension can be used. If a setting is used for extension negotia tion, the initial
value MUST be defined in such a fashion that the extension is initiall value <bcp14>MUST</bcp14> be defined in such a fashion that the extens
y disabled. ion is initially disabled.</t>
</t>
</section> </section>
</section> </section>
<section anchor="FrameTypes"> <section anchor="FrameTypes">
<name>Frame Definitions</name> <name>Frame Definitions</name>
<t> <t>This specification defines a number of frame types, each identified by
This specification defines a number of frame types, each identified by a a unique 8-bit type
unique 8-bit type code. Each frame type serves a distinct purpose in the establishment and
code. Each frame type serves a distinct purpose in the establishment and management of either
management either the connection as a whole or individual streams.</t>
of the connection as a whole or of individual streams. <t>The transmission of specific frame types can alter the state of a conne
</t> ction. If endpoints
<t>
The transmission of specific frame types can alter the state of a connec
tion. If endpoints
fail to maintain a synchronized view of the connection state, successful communication fail to maintain a synchronized view of the connection state, successful communication
within the connection will no longer be possible. Therefore, it is impor tant that endpoints within the connection will no longer be possible. Therefore, it is impor tant that endpoints
have a shared comprehension of how the state is affected by the use of a have a shared comprehension of how the state is affected by the use of a
ny given frame. ny given frame.</t>
</t>
<section anchor="DATA"> <section anchor="DATA">
<name>DATA</name> <name>DATA</name>
<t> <t>DATA frames (type=0x00) convey arbitrary, variable-length sequences o
DATA frames (type=0x0) convey arbitrary, variable-length sequences of f octets associated
octets associated
with a stream. One or more DATA frames are used, for instance, to carr y HTTP request or with a stream. One or more DATA frames are used, for instance, to carr y HTTP request or
response message contents. response message contents.</t>
</t> <t>DATA frames <bcp14>MAY</bcp14> also contain padding. Padding can be
<t> added to DATA frames to obscure the
DATA frames MAY also contain padding. Padding can be added to DATA fr size of messages. Padding is a security feature; see <xref target="pa
ames to obscure the dding"/>.</t>
size of messages. Padding is a security feature; see <xref target="pa
dding"/>.
</t>
<figure anchor="DATAFrameFormat"> <figure anchor="DATAFrameFormat">
<name>DATA Frame Format</name> <name>DATA Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
DATA Frame { DATA Frame {
Length (24), Length (24),
Type (8) = 0x0, Type (8) = 0x00,
Unused Flags (4), Unused Flags (4),
PADDED Flag (1), PADDED Flag (1),
Unused Flags (2), Unused Flags (2),
END_STREAM Flag (1), END_STREAM Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
[Pad Length (8)], [Pad Length (8)],
Data (..), Data (..),
Padding (..2040), Padding (..2040),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.
ds are described in <xref target="FramingLayer"/>. The DATA frame contains the following additional fields:</t>
The DATA frame contains the following additional fields:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Pad Length:</dt> <dt>Pad Length:</dt>
<dd> <dd>An 8-bit field containing the length of the frame padding in units
An 8-bit field containing the length of the frame padding in units of octets. This
of octets. This field is conditional and is only present if the PADDED flag is set
field is conditional and is only present if the PADDED flag is set .</dd>
.
</dd>
<dt>Data:</dt> <dt>Data:</dt>
<dd> <dd>Application data. The amount of data is the remainder of the fram
Application data. The amount of data is the remainder of the fram e payload after
e payload after subtracting the length of the other fields that are present.</dd>
subtracting the length of the other fields that are present.
</dd>
<dt>Padding:</dt> <dt>Padding:</dt>
<dd> <dd>Padding octets that contain no application semantic value. Paddin
Padding octets that contain no application semantic value. Paddin g octets <bcp14>MUST</bcp14> be set
g octets MUST be set to zero when sending. A receiver is not obligated to verify paddi
to zero when sending. A receiver is not obligated to verify paddi ng but <bcp14>MAY</bcp14> treat
ng but MAY treat
non-zero padding as a <xref target="ConnectionErrorHandler">connec tion error</xref> of non-zero padding as a <xref target="ConnectionErrorHandler">connec tion error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</x type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</x
ref>. ref>.</dd>
</dd>
</dl> </dl>
<t> <t>The DATA frame defines the following flags:</t>
The DATA frame defines the following flags:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>PADDED (0x8):</dt> <dt>PADDED (0x08):</dt>
<dd> <dd>When set, the PADDED flag indicates that the Pad Length field and
When set, the PADDED flag indicates that the Pad Length field and any padding that it describes
any padding that it describes are present.</dd>
are present. <dt>END_STREAM (0x01):</dt>
</dd> <dd>When set, the END_STREAM flag indicates that this frame is the las
<dt>END_STREAM (0x1):</dt> t that the endpoint will send for
<dd> the identified stream. Setting this flag causes the stream to ent
When set, the END_STREAM flag indicates that this frame is the las er one of <xref target="StreamStates">the "half-closed" states or the "closed" s
t that the endpoint will send for tate</xref>.</dd>
the identified stream. Setting this flag causes the stream to ent
er one of <xref target="StreamStates">the "half-closed" states or the "closed" s
tate</xref>.
</dd>
</dl> </dl>
<aside> <aside>
<t> <t>Note: An endpoint that learns of stream closure after sending all d
Note: An endpoint that learns of stream closure after sending all da ata can close a
ta can close a
stream by sending a STREAM frame with a zero-length Data field and t he END_STREAM flag stream by sending a STREAM frame with a zero-length Data field and t he END_STREAM flag
set. This is only possible if the endpoint does not send trailers as set. This is only possible if the endpoint does not send trailers, a
the END_STREAM flag s the END_STREAM
appears on a HEADERS frame in that case; see <xref target="HttpFrami flag appears on a HEADERS frame in that case; see <xref target="Http
ng"/>. Framing"/>.</t>
</t>
</aside> </aside>
<t> <t>DATA frames <bcp14>MUST</bcp14> be associated with a stream. If a DAT
DATA frames MUST be associated with a stream. If a DATA frame is recei A frame is received whose Stream
ved whose stream Identifier field is 0x00, the recipient <bcp14>MUST</bcp14> respond wi
identifier field is 0x0, the recipient MUST respond with a <xref targe th a <xref target="ConnectionErrorHandler">connection error</xref> of type
t="ConnectionErrorHandler">connection error</xref> of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. <t>DATA frames are subject to flow control and can only be sent when a s
</t> tream is in the
<t>
DATA frames are subject to flow control and can only be sent when a st
ream is in the
"open" or "half-closed (remote)" state. The entire DATA frame payload is included in flow "open" or "half-closed (remote)" state. The entire DATA frame payload is included in flow
control, including the Pad Length and Padding fields if present. If a DATA frame is received control, including the Pad Length and Padding fields if present. If a DATA frame is received
whose stream is not in "open" or "half-closed (local)" state, the reci pient MUST respond whose stream is not in the "open" or "half-closed (local)" state, the recipient <bcp14>MUST</bcp14> respond
with a <xref target="StreamErrorHandler">stream error</xref> of type with a <xref target="StreamErrorHandler">stream error</xref> of type
<xref target="STREAM_CLOSED" format="none">STREAM_CLOSED</xref>. <xref target="STREAM_CLOSED" format="none">STREAM_CLOSED</xref>.</t>
</t> <t>The total number of padding octets is determined by the value of the
<t> Pad Length field. If
The total number of padding octets is determined by the value of the P
ad Length field. If
the length of the padding is the length of the frame payload or greate r, the recipient the length of the padding is the length of the frame payload or greate r, the recipient
MUST treat this as a <xref target="ConnectionErrorHandler">connection <bcp14>MUST</bcp14> treat this as a <xref target="ConnectionErrorHandl
error</xref> of er">connection error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref> type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>
. .</t>
</t>
<aside> <aside>
<t>Note: <t>Note:
A frame can be increased in size by one octet by including a Pad Len gth field with a A frame can be increased in size by one octet by including a Pad Len gth field with a
value of zero. value of zero.</t>
</t>
</aside> </aside>
</section> </section>
<section anchor="HEADERS"> <section anchor="HEADERS">
<name>HEADERS</name> <name>HEADERS</name>
<t> <t>The HEADERS frame (type=0x01) is used to <xref target="StreamStates">
The HEADERS frame (type=0x1) is used to <xref target="StreamStates">op open a stream</xref>,
en a stream</xref>,
and additionally carries a field block fragment. Despite the name, a H EADERS frame can carry and additionally carries a field block fragment. Despite the name, a H EADERS frame can carry
a header section or a trailer section. HEADERS frames can be sent on a stream a header section or a trailer section. HEADERS frames can be sent on a stream
in the "idle", "reserved (local)", "open", or "half-closed (remote)" s in the "idle", "reserved (local)", "open", or "half-closed (remote)" s
tate. tate.</t>
</t>
<figure anchor="HEADERSFrameFormat"> <figure anchor="HEADERSFrameFormat">
<name>HEADERS Frame Format</name> <name>HEADERS Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
HEADERS Frame { HEADERS Frame {
Length (24), Length (24),
Type (8) = 0x1, Type (8) = 0x01,
Unused Flags (2), Unused Flags (2),
PRIORITY Flag (1), PRIORITY Flag (1),
Unused Flag (1), Unused Flag (1),
PADDED Flag (1), PADDED Flag (1),
END_HEADERS Flag (1), END_HEADERS Flag (1),
Unused Flag (1), Unused Flag (1),
END_STREAM Flag (1), END_STREAM Flag (1),
Reserved (1), Reserved (1),
skipping to change at line 1639 skipping to change at line 1152
[Pad Length (8)], [Pad Length (8)],
[Exclusive (1)], [Exclusive (1)],
[Stream Dependency (31)], [Stream Dependency (31)],
[Weight (8)], [Weight (8)],
Field Block Fragment (..), Field Block Fragment (..),
Padding (..2040), Padding (..2040),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.
ds are described in <xref target="FramingLayer"/>. The HEADERS frame payload has the following additional fields:</t>
The HEADERS frame payload has the following additional fields:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Pad Length:</dt> <dt>Pad Length:</dt>
<dd> <dd>An 8-bit field containing the length of the frame padding in units
An 8-bit field containing the length of the frame padding in units o of octets. This
f octets. This field is only present if the PADDED flag is set.</dd>
field is only present if the PADDED flag is set.
</dd>
<dt>Exclusive:</dt> <dt>Exclusive:</dt>
<dd> <dd>A single-bit flag. This field is only present if the PRIORITY fla
A single-bit flag. This field is only present if the PRIORITY flag g is set. Priority
is set. Priority signals in HEADERS frames are deprecated; see <xref target="Priority
signals in HEADERS frames are deprecated; see <xref target="Priority Here"/>.</dd>
Here"/>.
</dd>
<dt>Stream Dependency:</dt> <dt>Stream Dependency:</dt>
<dd> <dd>A 31-bit stream identifier. This field is only present if the PRI
A 31-bit stream identifier. This field is only present if the PRIOR ORITY flag is set.</dd>
ITY flag is set.
</dd>
<dt>Weight:</dt> <dt>Weight:</dt>
<dd> <dd>An unsigned 8-bit integer. This field is only present if the PRIO
An unsigned 8-bit integer. This field is only present if the PRIORI RITY flag is set.</dd>
TY flag is set.
</dd>
<dt>Field Block Fragment:</dt> <dt>Field Block Fragment:</dt>
<dd> <dd>A <xref target="FieldBlock">field block fragment</xref>.</dd>
A <xref target="FieldBlock">field block fragment</xref>.
</dd>
<dt>Padding:</dt> <dt>Padding:</dt>
<dd> <dd>Padding octets that contain no application semantic value. Paddin
Padding octets that contain no application semantic value. Paddin g octets <bcp14>MUST</bcp14> be set
g octets MUST be set to zero when sending. A receiver is not obligated to verify paddi
to zero when sending. A receiver is not obligated to verify paddi ng but <bcp14>MAY</bcp14> treat
ng but MAY treat
non-zero padding as a <xref target="ConnectionErrorHandler">connec tion error</xref> of non-zero padding as a <xref target="ConnectionErrorHandler">connec tion error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</x type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</x
ref>. ref>.</dd>
</dd>
</dl> </dl>
<t> <t>The HEADERS frame defines the following flags:</t>
The HEADERS frame defines the following flags:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>PRIORITY (0x20):</dt> <dt>PRIORITY (0x20):</dt>
<dd> <dd>
<t> <t>When set, the PRIORITY flag indicates that the Exclusive, Stream
When set, the PRIORITY flag indicates that the Exclusive, Stream D Dependency, and Weight
ependency, and Weight fields are present.</t>
fields are present.
</t>
</dd> </dd>
<dt>PADDED (0x8):</dt> <dt>PADDED (0x08):</dt>
<dd> <dd>
<t> <t>When set, the PADDED flag indicates that the Pad Length field and
When set, the PADDED flag indicates that the Pad Length field an any padding that it
d any padding that it describes are present.</t>
describes are present.
</t>
</dd> </dd>
<dt>END_HEADERS (0x4):</dt> <dt>END_HEADERS (0x04):</dt>
<dd> <dd>
<t> <t>When set, the END_HEADERS flag indicates that this frame contains
When set, the END_HEADERS flag indicates that this frame contain an entire <xref target="FieldBlock">field block</xref> and is not followed by a
s an entire <xref target="FieldBlock">field block</xref> and is not followed by ny
any <xref target="CONTINUATION" format="none">CONTINUATION</xref> fr
<xref target="CONTINUATION" format="none">CONTINUATION</xref> fr ames.</t>
ames. <t>A HEADERS frame without the END_HEADERS flag set <bcp14>MUST</bcp
</t> 14> be followed by a
<t> <xref target="CONTINUATION" format="none">CONTINUATION</xref> fr
A HEADERS frame without the END_HEADERS flag set MUST be followe ame for the same stream. A receiver <bcp14>MUST</bcp14> treat the
d by a
<xref target="CONTINUATION" format="none">CONTINUATION</xref> fr
ame for the same stream. A receiver MUST treat the
receipt of any other type of frame or a frame on a different str eam as a <xref target="ConnectionErrorHandler">connection error</xref> of type receipt of any other type of frame or a frame on a different str eam as a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref
>. >.</t>
</t>
</dd> </dd>
<dt>END_STREAM (0x1):</dt> <dt>END_STREAM (0x01):</dt>
<dd> <dd>
<t> <t>When set, the END_STREAM flag indicates that the <xref target="Fi
When set, the END_STREAM flag indicates that the <xref target="F eldBlock">field block</xref> is
ieldBlock">field block</xref> is the last that the endpoint will send for the identified stream.<
the last that the endpoint will send for the identified stream. /t>
</t> <t>A HEADERS frame with the END_STREAM flag set signals the end of a
<t> stream.
A HEADERS frame with the END_STREAM flag set signals the end of
a stream.
However, a HEADERS frame with the END_STREAM flag set can be fol lowed by However, a HEADERS frame with the END_STREAM flag set can be fol lowed by
<xref target="CONTINUATION" format="none">CONTINUATION</xref> fr ames on the same stream. Logically, the <xref target="CONTINUATION" format="none">CONTINUATION</xref> fr ames on the same stream. Logically, the
<xref target="CONTINUATION" format="none">CONTINUATION</xref> fr <xref target="CONTINUATION" format="none">CONTINUATION</xref> fr
ames are part of the HEADERS frame. ames are part of the HEADERS frame.</t>
</t>
</dd> </dd>
</dl> </dl>
<t> <t>The frame payload of a HEADERS frame contains a <xref target="FieldBl
The frame payload of a HEADERS frame contains a <xref target="FieldBlo ock">field block
ck">field block
fragment</xref>. A field block that does not fit within a HEADERS fra me is continued in fragment</xref>. A field block that does not fit within a HEADERS fra me is continued in
a <xref target="CONTINUATION">CONTINUATION frame</xref>. a <xref target="CONTINUATION">CONTINUATION frame</xref>.</t>
</t> <t>HEADERS frames <bcp14>MUST</bcp14> be associated with a stream. If a
<t> HEADERS frame is received whose
HEADERS frames MUST be associated with a stream. If a HEADERS frame is Stream Identifier field is 0x00, the recipient <bcp14>MUST</bcp14> res
received whose pond with a <xref target="ConnectionErrorHandler">connection error</xref> of typ
stream identifier field is 0x0, the recipient MUST respond with a <xre e
f target="ConnectionErrorHandler">connection error</xref> of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. <t>The HEADERS frame changes the connection state as described in <xref
</t> target="FieldBlock"/>.</t>
<t> <t>The total number of padding octets is determined by the value of the
The HEADERS frame changes the connection state as described in <xref t Pad Length field. If
arget="FieldBlock"/>.
</t>
<t>
The total number of padding octets is determined by the value of the P
ad Length field. If
the length of the padding is the length of the frame payload or greate r, the recipient the length of the padding is the length of the frame payload or greate r, the recipient
MUST treat this as a <xref target="ConnectionErrorHandler">connection <bcp14>MUST</bcp14> treat this as a <xref target="ConnectionErrorHandl
error</xref> of er">connection error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref> type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>
. .</t>
</t>
<aside> <aside>
<t>Note: <t>Note:
A frame can be increased in size by one octet by including a Pad Len gth field with a A frame can be increased in size by one octet by including a Pad Len gth field with a
value of zero. value of zero.</t>
</t>
</aside> </aside>
</section> </section>
<section anchor="PRIORITY"> <section anchor="PRIORITY">
<name>PRIORITY</name> <name>PRIORITY</name>
<t> <t>The PRIORITY frame (type=0x02) is deprecated; see <xref target="Prior
The PRIORITY frame (type=0x2) is deprecated; see <xref target="Priorit ityHere"/>. A
yHere"/>. A PRIORITY frame can be sent in any stream state, including idle or clos
PRIORITY frame can be sent in any stream state, including idle or clos ed streams.</t>
ed streams.
</t>
<figure anchor="PRIORITYFrameFormat"> <figure anchor="PRIORITYFrameFormat">
<name>PRIORITY Frame Format</name> <name>PRIORITY Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
PRIORITY Frame { PRIORITY Frame {
Length (24) = 0x5, Length (24) = 0x05,
Type (8) = 0x2, Type (8) = 0x02,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Exclusive (1), Exclusive (1),
Stream Dependency (31), Stream Dependency (31),
Weight (8), Weight (8),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.
ds are described in <xref target="FramingLayer"/>. The frame payload of a PRIORITY frame contains the following additiona
The frame payload of a PRIORITY frame contains the following additiona l fields:</t>
l fields:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Exclusive:</dt> <dt>Exclusive:</dt>
<dd> <dd>A single-bit flag.</dd>
A single-bit flag.
</dd>
<dt>Stream Dependency:</dt> <dt>Stream Dependency:</dt>
<dd> <dd>A 31-bit stream identifier.</dd>
A 31-bit stream identifier.
</dd>
<dt>Weight:</dt> <dt>Weight:</dt>
<dd> <dd>An unsigned 8-bit integer.</dd>
An unsigned 8-bit integer.
</dd>
</dl> </dl>
<t> <t>The PRIORITY frame does not define any flags.</t>
The PRIORITY frame does not define any flags. <t>The PRIORITY frame always identifies a stream. If a PRIORITY frame i
</t> s received with a
<t> stream identifier of 0x00, the recipient <bcp14>MUST</bcp14> respond w
The PRIORITY frame always identifies a stream. If a PRIORITY frame is ith a <xref target="ConnectionErrorHandler">connection error</xref> of type <xre
received with a f target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
stream identifier of 0x0, the recipient MUST respond with a <xref targ <t>Sending or receiving a PRIORITY frame does not affect the state of an
et="ConnectionErrorHandler">connection error</xref> of type <xref target="PROTOC y stream (<xref target="StreamStates"/>). The PRIORITY frame can be sent on a s
OL_ERROR" format="none">PROTOCOL_ERROR</xref>. tream in any state,
</t>
<t>
Sending or receiving a PRIORITY frame does not affect the state of any
stream (<xref target="StreamStates"/>). The PRIORITY frame can be sent on a st
ream in any state,
including "idle" or "closed". A PRIORITY frame cannot be sent between consecutive frames including "idle" or "closed". A PRIORITY frame cannot be sent between consecutive frames
that comprise a single <xref target="FieldBlock">field block</xref>. that comprise a single <xref target="FieldBlock">field block</xref>.</
</t> t>
<t> <t>A PRIORITY frame with a length other than 5 octets <bcp14>MUST</bcp14
A PRIORITY frame with a length other than 5 octets MUST be treated as > be treated as a <xref target="StreamErrorHandler">stream error</xref> of type
a <xref target="StreamErrorHandler">stream error</xref> of type <xref target="FR <xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.</t>
AME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.
</t>
</section> </section>
<section anchor="RST_STREAM"> <section anchor="RST_STREAM">
<name>RST_STREAM</name> <name>RST_STREAM</name>
<t> <t>The RST_STREAM frame (type=0x03) allows for immediate termination of
The RST_STREAM frame (type=0x3) allows for immediate termination of a a stream. RST_STREAM
stream. RST_STREAM
is sent to request cancellation of a stream or to indicate that an err or condition has is sent to request cancellation of a stream or to indicate that an err or condition has
occurred. occurred.</t>
</t>
<figure anchor="RST_STREAMFrameFormat"> <figure anchor="RST_STREAMFrameFormat">
<name>RST_STREAM Frame Format</name> <name>RST_STREAM Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
RST_STREAM Frame { RST_STREAM Frame {
Length (24) = 0x4, Length (24) = 0x04,
Type (8) = 0x3, Type (8) = 0x03,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Error Code (32), Error Code (32),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.
ds are described in <xref target="FramingLayer"/>.
Additionally, the RST_STREAM frame contains a single unsigned, 32-bit integer identifying the <xref target="ErrorCodes">error code</xref>. The error code indicates why the stream is being Additionally, the RST_STREAM frame contains a single unsigned, 32-bit integer identifying the <xref target="ErrorCodes">error code</xref>. The error code indicates why the stream is being
terminated. terminated.</t>
</t> <t>The RST_STREAM frame does not define any flags.</t>
<t> <t>The RST_STREAM frame fully terminates the referenced stream and cause
The RST_STREAM frame does not define any flags. s it to enter the
</t> "closed" state. After receiving a RST_STREAM on a stream, the receiver
<t> <bcp14>MUST NOT</bcp14> send
The RST_STREAM frame fully terminates the referenced stream and causes
it to enter the
"closed" state. After receiving a RST_STREAM on a stream, the receiver
MUST NOT send
additional frames for that stream, except for <xref target="PRIORITY" format="none">PRIORITY</xref>. However, additional frames for that stream, except for <xref target="PRIORITY" format="none">PRIORITY</xref>. However,
after sending the RST_STREAM, the sending endpoint MUST be prepared to receive and process after sending the RST_STREAM, the sending endpoint <bcp14>MUST</bcp14> be prepared to receive and process
additional frames sent on the stream that might have been sent by the peer prior to the additional frames sent on the stream that might have been sent by the peer prior to the
arrival of the RST_STREAM. arrival of the RST_STREAM.</t>
</t> <t>RST_STREAM frames <bcp14>MUST</bcp14> be associated with a stream. I
<t> f a RST_STREAM frame is received
RST_STREAM frames MUST be associated with a stream. If a RST_STREAM f with a stream identifier of 0x00, the recipient <bcp14>MUST</bcp14> tr
rame is received eat this as a <xref target="ConnectionErrorHandler">connection error</xref> of t
with a stream identifier of 0x0, the recipient MUST treat this as a <x ype
ref target="ConnectionErrorHandler">connection error</xref> of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. <t>RST_STREAM frames <bcp14>MUST NOT</bcp14> be sent for a stream in the
</t> "idle" state. If a RST_STREAM
<t> frame identifying an idle stream is received, the recipient <bcp14>MUS
RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. T</bcp14> treat this as a <xref target="ConnectionErrorHandler">connection error
If a RST_STREAM </xref> of type
frame identifying an idle stream is received, the recipient MUST treat <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
this as a <xref target="ConnectionErrorHandler">connection error</xref> of type <t>A RST_STREAM frame with a length other than 4 octets <bcp14>MUST</bcp
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. 14> be treated as a <xref target="ConnectionErrorHandler">connection error</xref
</t> > of type
<t> <xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.
A RST_STREAM frame with a length other than 4 octets MUST be treated a </t>
s a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.
</t>
</section> </section>
<section anchor="SETTINGS"> <section anchor="SETTINGS">
<name>SETTINGS</name> <name>SETTINGS</name>
<t> <t>The SETTINGS frame (type=0x04) conveys configuration parameters that
The SETTINGS frame (type=0x4) conveys configuration parameters that af affect how endpoints
fect how endpoints
communicate, such as preferences and constraints on peer behavior. Th e SETTINGS frame is communicate, such as preferences and constraints on peer behavior. Th e SETTINGS frame is
also used to acknowledge the receipt of those settings. Individually, a configuration also used to acknowledge the receipt of those settings. Individually, a configuration
parameter from a SETTINGS frame is referred to as a "setting". parameter from a SETTINGS frame is referred to as a "setting".</t>
</t> <t>Settings are not negotiated; they describe characteristics of the sen
<t> ding peer,
Settings are not negotiated; they describe characteristics of the send
ing peer,
which are used by the receiving peer. Different values for the same se tting can be which are used by the receiving peer. Different values for the same se tting can be
advertised by each peer. For example, a client might set a high initia l flow-control advertised by each peer. For example, a client might set a high initia l flow-control
window, whereas a server might set a lower value to conserve resources window, whereas a server might set a lower value to conserve resources
. .</t>
</t> <t>A SETTINGS frame <bcp14>MUST</bcp14> be sent by both endpoints at the
<t> start of a connection and <bcp14>MAY</bcp14> be
A SETTINGS frame MUST be sent by both endpoints at the start of a conn
ection and MAY be
sent at any other time by either endpoint over the lifetime of the con nection. sent at any other time by either endpoint over the lifetime of the con nection.
Implementations MUST support all of the settings defined by this speci Implementations <bcp14>MUST</bcp14> support all of the settings define
fication. d by this specification.</t>
</t> <t>Each parameter in a SETTINGS frame replaces any existing value for th
<t> at parameter.
Each parameter in a SETTINGS frame replaces any existing value for tha
t parameter.
Settings are processed in the order in which they appear, and a receiv er of a SETTINGS Settings are processed in the order in which they appear, and a receiv er of a SETTINGS
frame does not need to maintain any state other than the current value of each setting. frame does not need to maintain any state other than the current value of each setting.
Therefore, the value of a SETTINGS parameter is the last value that is seen by Therefore, the value of a SETTINGS parameter is the last value that is seen by
a receiver. a receiver.</t>
</t> <t>SETTINGS frames are acknowledged by the receiving peer. To enable thi
<t> s, the SETTINGS
SETTINGS frames are acknowledged by the receiving peer. To enable this frame defines the ACK flag:</t>
, the SETTINGS
frame defines the ACK flag:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>ACK (0x1):</dt> <dt>ACK (0x01):</dt>
<dd> <dd>When set, the ACK flag indicates that this frame acknowledges rece
When set, the ACK flag indicates that this frame acknowledges rece ipt and application of the
ipt and application of the peer's SETTINGS frame. When this bit is set, the frame payload of
peer's SETTINGS frame. When this bit is set, the frame payload of the SETTINGS frame <bcp14>MUST</bcp14>
the SETTINGS frame MUST
be empty. Receipt of a SETTINGS frame with the ACK flag set and a length field value be empty. Receipt of a SETTINGS frame with the ACK flag set and a length field value
other than 0 MUST be treated as a <xref target="ConnectionErrorHan other than 0 <bcp14>MUST</bcp14> be treated as a <xref target="Con
dler">connection nectionErrorHandler">connection
error</xref> of type <xref target="FRAME_SIZE_ERROR" format="none" error</xref> of type <xref target="FRAME_SIZE_ERROR" format="none"
>FRAME_SIZE_ERROR</xref>. For more information, see <xref target="SettingsSync" >FRAME_SIZE_ERROR</xref>. For more information, see <xref target="SettingsSync"
/> ("<xref target="SettingsSync" format="title"/>"). /> ("<xref target="SettingsSync" format="title"/>").</dd>
</dd>
</dl> </dl>
<t> <t>SETTINGS frames always apply to a connection, never a single stream.
SETTINGS frames always apply to a connection, never a single stream. The stream
The stream identifier for a SETTINGS frame <bcp14>MUST</bcp14> be zero (0x00). If
identifier for a SETTINGS frame MUST be zero (0x0). If an endpoint rec an endpoint receives a SETTINGS
eives a SETTINGS frame whose Stream Identifier field is anything other than 0x00, the e
frame whose stream identifier field is anything other than 0x0, the en ndpoint <bcp14>MUST</bcp14> respond
dpoint MUST respond
with a <xref target="ConnectionErrorHandler">connection error</xref> o f type with a <xref target="ConnectionErrorHandler">connection error</xref> o f type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
</t> <t>The SETTINGS frame affects connection state. A badly formed or incom
<t> plete SETTINGS frame
The SETTINGS frame affects connection state. A badly formed or incomp <bcp14>MUST</bcp14> be treated as a <xref target="ConnectionErrorHandl
lete SETTINGS frame er">connection error</xref> of type
MUST be treated as a <xref target="ConnectionErrorHandler">connection <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
error</xref> of type <t>A SETTINGS frame with a length other than a multiple of 6 octets <bcp
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. 14>MUST</bcp14> be treated as a <xref target="ConnectionErrorHandler">connection
</t> error</xref> of type
<t> <xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.
A SETTINGS frame with a length other than a multiple of 6 octets MUST </t>
be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of
type
<xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.
</t>
<section anchor="SettingFormat"> <section anchor="SettingFormat">
<name>SETTINGS Format</name> <name>SETTINGS Format</name>
<t> <t>The frame payload of a SETTINGS frame consists of zero or more sett
The frame payload of a SETTINGS frame consists of zero or more setti ings, each consisting of
ngs, each consisting of an unsigned 16-bit setting identifier and an unsigned 32-bit value.<
an unsigned 16-bit setting identifier and an unsigned 32-bit value. /t>
</t>
<figure anchor="SettingFrameFormat"> <figure anchor="SettingFrameFormat">
<name>SETTINGS Frame Format</name> <name>SETTINGS Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
SETTINGS Frame { SETTINGS Frame {
Length (24), Length (24),
Type (8) = 0x4, Type (8) = 0x04,
Unused Flags (7), Unused Flags (7),
ACK Flag (1), ACK Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31) = 0, Stream Identifier (31) = 0,
Setting (48) ..., Setting (48) ...,
} }
Setting { Setting {
Identifier (16), Identifier (16),
Value (32), Value (32),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier f
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fi ields are described
elds are described
in <xref target="FramingLayer"/>. The frame payload of a SETTINGS f rame contains any in <xref target="FramingLayer"/>. The frame payload of a SETTINGS f rame contains any
number of Setting fields, each of which consists of: number of Setting fields, each of which consists of:</t>
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Identifier:</dt> <dt>Identifier:</dt>
<dd> <dd>A 16-bit setting identifier; see <xref target="SettingValues"/>.
A 16-bit setting identifier; see <xref target="SettingValues"/>. </dd>
</dd>
<dt>Value:</dt> <dt>Value:</dt>
<dd> <dd>A 32-bit value for the setting.</dd>
A 32-bit value for the setting.
</dd>
</dl> </dl>
</section> </section>
<section anchor="SettingValues"> <section anchor="SettingValues">
<name>Defined Settings</name> <name>Defined Settings</name>
<t> <t>The following settings are defined:</t>
The following settings are defined:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt anchor="SETTINGS_HEADER_TABLE_SIZE">SETTINGS_HEADER_TABLE_SIZE ( 0x1):</dt> <dt anchor="SETTINGS_HEADER_TABLE_SIZE">SETTINGS_HEADER_TABLE_SIZE ( 0x01):</dt>
<dd> <dd>
<t> <t>This setting allows the sender to inform the remote endpoint of
Allows the sender to inform the remote endpoint of the maximum the maximum size of the
size of the
compression table used to decode field blocks, in units of oct ets. The encoder can select compression table used to decode field blocks, in units of oct ets. The encoder can select
any size equal to or less than this value by using signaling s pecific to the any size equal to or less than this value by using signaling s pecific to the
compression format inside a field block (see <xref target="COM compression format inside a field block (see <xref target="RFC
PRESSION"/>). The initial value is 4,096 octets. 7541"/>). The initial value is 4,096 octets.</t>
</t>
</dd> </dd>
<dt anchor="SETTINGS_ENABLE_PUSH">SETTINGS_ENABLE_PUSH (0x2):</dt> <dt anchor="SETTINGS_ENABLE_PUSH">SETTINGS_ENABLE_PUSH (0x02):</dt>
<dd> <dd>
<t> <t>This setting can be used to enable or disable server push. A s
This setting can be used to disable <xref target="PushResources" erver <bcp14>MUST NOT</bcp14> send a
>server <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fr
push</xref>. A server MUST NOT send a <xref target="PUSH_PROMISE ame if it receives
" format="none">PUSH_PROMISE</xref> frame if it receives this parameter set to a this parameter set to a value of 0; see <xref target="PushResour
value ces"/>. A client
of 0. A client that has both set this parameter to 0 and had it that has both set this parameter to 0 and had it acknowledged <b
acknowledged MUST cp14>MUST</bcp14> treat the receipt
treat the receipt of a <xref target="PUSH_PROMISE" format="none" of a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xre
>PUSH_PROMISE</xref> f> frame as a <xref target="ConnectionErrorHandler">connection error</xref> of t
frame as a <xref target="ConnectionErrorHandler">connection erro ype <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
r</xref> of type <t>The initial value of SETTINGS_ENABLE_PUSH is 1. For a client,
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref this value indicates that it
>. is willing to receive PUSH_PROMISE frames. For a server, this i
</t> nitial value has no effect, and
<t> is equivalent to the value 0. Any value other than 0 or 1 <bcp1
The initial value of SETTINGS_ENABLE_PUSH is 1. For a client th 4>MUST</bcp14> be treated as a
is value indicates that it
is willing to receive PUSH_PROMISE frames. For a server this in
itial value has no effect, and
is equivalent to the value 0. Any value other than 0 or 1 MUST
be treated as a
<xref target="ConnectionErrorHandler">connection error</xref> of type <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref
>. >.</t>
</t> <t>A server <bcp14>MUST NOT</bcp14> explicitly set this value to 1
<t> . A server <bcp14>MAY</bcp14> choose to omit this
A server MUST NOT explicitly set this value to 1. A server MAY setting when it sends a SETTINGS frame, but if a server does inc
choose to omit this lude a value, it <bcp14>MUST</bcp14>
setting when it sends a SETTINGS frame, but if a server does inc be 0. A client <bcp14>MUST</bcp14> treat receipt of a SETTINGS
lude a value it MUST frame with SETTINGS_ENABLE_PUSH set
be 0. A client MUST treat receipt of a SETTINGS frame with SETT
INGS_ENABLE_PUSH set
to 1 as a <xref target="ConnectionErrorHandler">connection error </xref> of type to 1 as a <xref target="ConnectionErrorHandler">connection error </xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref
>. >.</t>
</t>
</dd> </dd>
<dt anchor="SETTINGS_MAX_CONCURRENT_STREAMS">SETTINGS_MAX_CONCURRENT _STREAMS (0x3):</dt> <dt anchor="SETTINGS_MAX_CONCURRENT_STREAMS">SETTINGS_MAX_CONCURRENT _STREAMS (0x03):</dt>
<dd> <dd>
<t> <t>This setting indicates the maximum number of concurrent streams
Indicates the maximum number of concurrent streams that the se that the sender will allow.
nder will allow.
This limit is directional: it applies to the number of streams that the sender This limit is directional: it applies to the number of streams that the sender
permits the receiver to create. Initially, there is no limit t o this value. It is permits the receiver to create. Initially, there is no limit t o this value. It is
recommended that this value be no smaller than 100, so as to n ot unnecessarily recommended that this value be no smaller than 100, so as to n ot unnecessarily
limit parallelism. limit parallelism.</t>
</t> <t>A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS <bcp14>SHOULD
<t> NOT</bcp14> be treated as special
A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be
treated as special
by endpoints. A zero value does prevent the creation of new s treams; however, this by endpoints. A zero value does prevent the creation of new s treams; however, this
can also happen for any limit that is exhausted with active st reams. Servers can also happen for any limit that is exhausted with active st reams. Servers
SHOULD only set a zero value for short durations; if a server <bcp14>SHOULD</bcp14> only set a zero value for short duration
does not wish to s; if a server does not wish to
accept requests, closing the connection is more appropriate. accept requests, closing the connection is more appropriate.</
</t> t>
</dd> </dd>
<dt anchor="SETTINGS_INITIAL_WINDOW_SIZE">SETTINGS_INITIAL_WINDOW_SI ZE (0x4):</dt> <dt anchor="SETTINGS_INITIAL_WINDOW_SIZE">SETTINGS_INITIAL_WINDOW_SI ZE (0x04):</dt>
<dd> <dd>
<t> <t>This setting indicates the sender's initial window size (in uni
Indicates the sender's initial window size (in units of octets ts of octets) for stream-level flow
) for stream-level flow control. The initial value is 2<sup>16</sup>-1 (65,535) octet
control. The initial value is 2<sup>16</sup>-1 (65,535) octet s.</t>
s. <t>This setting affects the window size of all streams (see <xref
</t> target="InitialWindowSize"/>).</t>
<t> <t>Values above the maximum flow-control window size of 2<sup>31</
This setting affects the window size of all streams (see <xref sup>-1 <bcp14>MUST</bcp14>
target="InitialWindowSize"/>).
</t>
<t>
Values above the maximum flow-control window size of 2<sup>31<
/sup>-1 MUST
be treated as a <xref target="ConnectionErrorHandler">connecti on error</xref> of be treated as a <xref target="ConnectionErrorHandler">connecti on error</xref> of
type <xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONT type <xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONT
ROL_ERROR</xref>. ROL_ERROR</xref>.</t>
</t>
</dd> </dd>
<dt anchor="SETTINGS_MAX_FRAME_SIZE">SETTINGS_MAX_FRAME_SIZE (0x5):< /dt> <dt anchor="SETTINGS_MAX_FRAME_SIZE">SETTINGS_MAX_FRAME_SIZE (0x05): </dt>
<dd> <dd>
<t> <t>This setting indicates the size of the largest frame payload th
Indicates the size of the largest frame payload that the sende at the sender is willing to
r is willing to receive, in units of octets.</t>
receive, in units of octets. <t>The initial value is 2<sup>14</sup> (16,384) octets. The value
</t> advertised by
<t> an endpoint <bcp14>MUST</bcp14> be between this initial value
The initial value is 2<sup>14</sup> (16,384) octets. The valu and the maximum allowed frame size
e advertised by
an endpoint MUST be between this initial value and the maximum
allowed frame size
(2<sup>24</sup>-1 or 16,777,215 octets), inclusive. Values ou tside this range (2<sup>24</sup>-1 or 16,777,215 octets), inclusive. Values ou tside this range
MUST be treated as a <xref target="ConnectionErrorHandler">con <bcp14>MUST</bcp14> be treated as a <xref target="ConnectionEr
nection error</xref> rorHandler">connection error</xref>
of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_E of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_E
RROR</xref>. RROR</xref>.</t>
</t>
</dd> </dd>
<dt anchor="SETTINGS_MAX_HEADER_LIST_SIZE">SETTINGS_MAX_HEADER_LIST_ SIZE (0x6):</dt> <dt anchor="SETTINGS_MAX_HEADER_LIST_SIZE">SETTINGS_MAX_HEADER_LIST_ SIZE (0x06):</dt>
<dd> <dd>
<t> <t>This advisory setting informs a peer of the maximum field secti
This advisory setting informs a peer of the maximum size of fi on size that the
eld section that the
sender is prepared to accept, in units of octets. The value is based on the uncompressed sender is prepared to accept, in units of octets. The value is based on the uncompressed
size of field lines, including the length of the name and valu e in units of octets plus size of field lines, including the length of the name and valu e in units of octets plus
an overhead of 32 octets for each field line. an overhead of 32 octets for each field line.</t>
</t> <t>For any given request, a lower limit than what is advertised <b
<t> cp14>MAY</bcp14> be enforced. The
For any given request, a lower limit than what is advertised M initial value of this setting is unlimited.</t>
AY be enforced. The
initial value of this setting is unlimited.
</t>
</dd> </dd>
</dl> </dl>
<t> <t>An endpoint that receives a SETTINGS frame with any unknown or unsu
An endpoint that receives a SETTINGS frame with any unknown or unsup pported identifier
ported identifier <bcp14>MUST</bcp14> ignore that setting.</t>
MUST ignore that setting.
</t>
</section> </section>
<section anchor="SettingsSync"> <section anchor="SettingsSync">
<name>Settings Synchronization</name> <name>Settings Synchronization</name>
<t> <t>Most values in SETTINGS benefit from or require an understanding of
Most values in SETTINGS benefit from or require an understanding of when the peer has
when the peer has
received and applied the changed parameter values. In order to provi de such received and applied the changed parameter values. In order to provi de such
synchronization timepoints, the recipient of a SETTINGS frame in whi ch the ACK flag is synchronization timepoints, the recipient of a SETTINGS frame in whi ch the ACK flag is
not set MUST apply the updated settings as soon as possible upon rec not set <bcp14>MUST</bcp14> apply the updated settings as soon as po
eipt. SETTINGS ssible upon receipt. SETTINGS
frames are acknowledged in the order in which they are received. frames are acknowledged in the order in which they are received.</t>
</t> <t>The values in the SETTINGS frame <bcp14>MUST</bcp14> be processed i
<t> n the order they appear, with no
The values in the SETTINGS frame MUST be processed in the order they other frame processing between values. Unsupported settings <bcp14>
appear, with no MUST</bcp14> be ignored. Once
other frame processing between values. Unsupported settings MUST be all values have been processed, the recipient <bcp14>MUST</bcp14> im
ignored. Once mediately emit a SETTINGS frame
all values have been processed, the recipient MUST immediately emit
a SETTINGS frame
with the ACK flag set. Upon receiving a SETTINGS frame with the ACK flag set, the sender with the ACK flag set. Upon receiving a SETTINGS frame with the ACK flag set, the sender
of the altered settings can rely on the values from the oldest unack nowledged SETTINGS frame of the altered settings can rely on the values from the oldest unack nowledged SETTINGS frame
having been applied. having been applied.</t>
</t> <t>If the sender of a SETTINGS frame does not receive an acknowledgmen
<t> t within a
If the sender of a SETTINGS frame does not receive an acknowledgment reasonable amount of time, it <bcp14>MAY</bcp14> issue a <xref targe
within a t="ConnectionErrorHandler">connection error</xref> of type <xref target="SETTING
reasonable amount of time, it MAY issue a <xref S_TIMEOUT" format="none">SETTINGS_TIMEOUT</xref>. In setting a timeout,
target="ConnectionErrorHandler">connection error</xref> of type <xre
f
target="SETTINGS_TIMEOUT" format="none">SETTINGS_TIMEOUT</xref>. In
setting a timeout,
some allowance needs to be made for processing delays at the peer; a timeout that is some allowance needs to be made for processing delays at the peer; a timeout that is
solely based on the round trip time between endpoints might result i solely based on the round-trip time between endpoints might result i
n spurious errors. n spurious errors.</t>
</t>
</section> </section>
</section> </section>
<section anchor="PUSH_PROMISE"> <section anchor="PUSH_PROMISE">
<name>PUSH_PROMISE</name> <name>PUSH_PROMISE</name>
<t> <t>The PUSH_PROMISE frame (type=0x05) is used to notify the peer endpoin
The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint t in advance of
in advance of
streams the sender intends to initiate. The PUSH_PROMISE frame includ es the unsigned streams the sender intends to initiate. The PUSH_PROMISE frame includ es the unsigned
31-bit identifier of the stream the endpoint plans to create along wit h a field section 31-bit identifier of the stream the endpoint plans to create along wit h a field section
that provides additional context for the stream. <xref target="PushRe sources"/> contains a that provides additional context for the stream. <xref target="PushRe sources"/> contains a
thorough description of the use of PUSH_PROMISE frames. thorough description of the use of PUSH_PROMISE frames.</t>
</t>
<figure anchor="PUSH_PROMISEFrameFormat"> <figure anchor="PUSH_PROMISEFrameFormat">
<name>PUSH_PROMISE Frame Format</name> <name>PUSH_PROMISE Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
PUSH_PROMISE Frame { PUSH_PROMISE Frame {
Length (24), Length (24),
Type (8) = 0x5, Type (8) = 0x05,
Unused Flags (4), Unused Flags (4),
PADDED Flag (1), PADDED Flag (1),
END_HEADERS Flag (1), END_HEADERS Flag (1),
Unused Flags (2), Unused Flags (2),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
[Pad Length (8)], [Pad Length (8)],
Reserved (1), Reserved (1),
Promised Stream ID (31), Promised Stream ID (31),
Field Block Fragment (..), Field Block Fragment (..),
Padding (..2040), Padding (..2040),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.
ds are described in <xref target="FramingLayer"/>. The PUSH_PROMISE frame payload has the following additional fields:</t
The PUSH_PROMISE frame payload has the following additional fields: >
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Pad Length:</dt> <dt>Pad Length:</dt>
<dd> <dd>An 8-bit field containing the length of the frame padding in units
An 8-bit field containing the length of the frame padding in units of octets. This
of octets. This field is only present if the PADDED flag is set.</dd>
field is only present if the PADDED flag is set.
</dd>
<dt>Reserved:</dt>
<dd>
A single reserved bit.
</dd>
<dt>Promised Stream ID:</dt> <dt>Promised Stream ID:</dt>
<dd> <dd>An unsigned 31-bit integer that identifies the stream that is rese
An unsigned 31-bit integer that identifies the stream that is rese rved by the
rved by the PUSH_PROMISE. The promised stream identifier <bcp14>MUST</bcp14>
PUSH_PROMISE. The promised stream identifier MUST be a valid choi be a valid choice for the next
ce for the next stream sent by the sender (see "new stream identifier" in <xref ta
stream sent by the sender (see "new stream identifier" in <xref ta rget="StreamIdentifiers"/>).</dd>
rget="StreamIdentifiers"/>).
</dd>
<dt>Field Block Fragment:</dt> <dt>Field Block Fragment:</dt>
<dd> <dd>A <xref target="FieldBlock">field block fragment</xref> containing
A <xref target="FieldBlock">field block fragment</xref> containing the request control
request control data and data and a header section.</dd>
header section.
</dd>
<dt>Padding:</dt> <dt>Padding:</dt>
<dd> <dd>Padding octets that contain no application semantic value. Paddin
Padding octets that contain no application semantic value. Paddin g octets <bcp14>MUST</bcp14> be set
g octets MUST be set to zero when sending. A receiver is not obligated to verify paddi
to zero when sending. A receiver is not obligated to verify paddi ng but <bcp14>MAY</bcp14> treat
ng but MAY treat
non-zero padding as a <xref target="ConnectionErrorHandler">connec tion error</xref> of non-zero padding as a <xref target="ConnectionErrorHandler">connec tion error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</x type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</x
ref>. ref>.</dd>
</dd>
</dl> </dl>
<t> <t>The PUSH_PROMISE frame defines the following flags:</t>
The PUSH_PROMISE frame defines the following flags:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>PADDED (0x8):</dt> <dt>PADDED (0x08):</dt>
<dd> <dd>
<t> <t>When set, the PADDED flag indicates that the Pad Length field and
When set, the PADDED flag indicates that the Pad Length field an any padding that it
d any padding that it describes are present.</t>
describes are present.
</t>
</dd> </dd>
<dt>END_HEADERS (0x4):</dt> <dt>END_HEADERS (0x04):</dt>
<dd> <dd>
<t> <t>When set, the END_HEADERS flag indicates that this frame contains
When set, the END_HEADERS flag indicates that this frame contain an entire <xref target="FieldBlock">field block</xref> and is not followed by a
s an entire <xref target="FieldBlock">field block</xref> and is not followed by ny
any <xref target="CONTINUATION" format="none">CONTINUATION</xref> fr
<xref target="CONTINUATION" format="none">CONTINUATION</xref> fr ames.</t>
ames. <t>A PUSH_PROMISE frame without the END_HEADERS flag set <bcp14>MUST
</t> </bcp14> be followed by a
<t> CONTINUATION frame for the same stream. A receiver <bcp14>MUST<
A PUSH_PROMISE frame without the END_HEADERS flag set MUST be fo /bcp14> treat the receipt of any
llowed by a
CONTINUATION frame for the same stream. A receiver MUST treat t
he receipt of any
other type of frame or a frame on a different stream as a <xref target="ConnectionErrorHandler">connection error</xref> of type other type of frame or a frame on a different stream as a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref
>. >.</t>
</t>
</dd> </dd>
</dl> </dl>
<t> <t>PUSH_PROMISE frames <bcp14>MUST</bcp14> only be sent on a peer-initia
PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that ted stream that is in either the
is in either the
"open" or "half-closed (remote)" state. The stream identifier of a PUS H_PROMISE frame "open" or "half-closed (remote)" state. The stream identifier of a PUS H_PROMISE frame
indicates the stream it is associated with. If the stream identifier indicates the stream it is associated with. If the Stream Identifier
field specifies the field specifies the
value 0x0, a recipient MUST respond with a <xref target="ConnectionErr value 0x00, a recipient <bcp14>MUST</bcp14> respond with a <xref targe
orHandler">connection error</xref> of type t="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
</t> <t>Promised streams are not required to be used in the order they are pr
<t> omised. The
Promised streams are not required to be used in the order they are pro PUSH_PROMISE only reserves stream identifiers for later use.</t>
mised. The <t>PUSH_PROMISE <bcp14>MUST NOT</bcp14> be sent if the <xref target="SET
PUSH_PROMISE only reserves stream identifiers for later use. TINGS_ENABLE_PUSH" format="none">SETTINGS_ENABLE_PUSH</xref> setting of the
</t>
<t>
PUSH_PROMISE MUST NOT be sent if the <xref target="SETTINGS_ENABLE_PUS
H" format="none">SETTINGS_ENABLE_PUSH</xref> setting of the
peer endpoint is set to 0. An endpoint that has set this setting and has received peer endpoint is set to 0. An endpoint that has set this setting and has received
acknowledgment MUST treat the receipt of a PUSH_PROMISE frame as a <xr acknowledgment <bcp14>MUST</bcp14> treat the receipt of a PUSH_PROMISE
ef target="ConnectionErrorHandler">connection error</xref> of type frame as a <xref target="ConnectionErrorHandler">connection error</xref> of typ
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. e
</t> <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
<t> <t>Recipients of PUSH_PROMISE frames can choose to reject promised strea
Recipients of PUSH_PROMISE frames can choose to reject promised stream ms by returning a
s by returning a
<xref target="RST_STREAM" format="none">RST_STREAM</xref> referencing the promised stream identifier back to the sender of <xref target="RST_STREAM" format="none">RST_STREAM</xref> referencing the promised stream identifier back to the sender of
the PUSH_PROMISE. the PUSH_PROMISE.</t>
</t> <t>A PUSH_PROMISE frame modifies the connection state in two ways. Firs
<t> t, the inclusion of a <xref target="FieldBlock">field block</xref> potentially m
A PUSH_PROMISE frame modifies the connection state in two ways. First odifies the state maintained for
, the inclusion of a <xref target="FieldBlock">field block</xref> potentially mo
difies the state maintained for
field section compression. Second, PUSH_PROMISE also reserves a strea m for later use, causing the field section compression. Second, PUSH_PROMISE also reserves a strea m for later use, causing the
promised stream to enter the "reserved" state. A sender MUST NOT send promised stream to enter the "reserved (local)" or "reserved (remote)"
a PUSH_PROMISE on a state. A sender <bcp14>MUST NOT</bcp14> send a PUSH_PROMISE on a
stream unless that stream is either "open" or "half-closed (remote)"; stream unless that stream is either "open" or "half-closed (remote)";
the sender MUST the sender <bcp14>MUST</bcp14>
ensure that the promised stream is a valid choice for a <xref target=" ensure that the promised stream is a valid choice for a <xref target="
StreamIdentifiers">new stream identifier</xref> (that is, the promised stream MU StreamIdentifiers">new stream identifier</xref> (that is, the promised stream <b
ST cp14>MUST</bcp14>
be in the "idle" state). be in the "idle" state).</t>
</t> <t>Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame c
<t> auses the stream
Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame ca state to become indeterminate. A receiver <bcp14>MUST</bcp14> treat t
uses the stream he receipt of a PUSH_PROMISE on a
state to become indeterminate. A receiver MUST treat the receipt of a
PUSH_PROMISE on a
stream that is neither "open" nor "half-closed (local)" as a <xref tar get="ConnectionErrorHandler">connection error</xref> of type stream that is neither "open" nor "half-closed (local)" as a <xref tar get="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Ho wever, an endpoint that has sent <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Ho wever, an endpoint that has sent
<xref target="RST_STREAM" format="none">RST_STREAM</xref> on the assoc iated stream MUST handle PUSH_PROMISE frames that <xref target="RST_STREAM" format="none">RST_STREAM</xref> on the assoc iated stream <bcp14>MUST</bcp14> handle PUSH_PROMISE frames that
might have been created before the <xref target="RST_STREAM" format="n one">RST_STREAM</xref> frame is received and might have been created before the <xref target="RST_STREAM" format="n one">RST_STREAM</xref> frame is received and
processed. processed.</t>
</t> <t>A receiver <bcp14>MUST</bcp14> treat the receipt of a PUSH_PROMISE th
<t> at promises an <xref target="StreamIdentifiers">illegal stream identifier</xref>
A receiver MUST treat the receipt of a PUSH_PROMISE that promises an < as a <xref target="ConnectionErrorHandler">connection error</xref> of type
xref target="StreamIdentifiers">illegal stream identifier</xref> as a <xref targ
et="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Not e that an illegal stream identifier <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Not e that an illegal stream identifier
is an identifier for a stream that is not currently in the "idle" stat is an identifier for a stream that is not currently in the "idle" stat
e. e.</t>
</t> <t>The total number of padding octets is determined by the value of the
<t> Pad Length field. If
The total number of padding octets is determined by the value of the P
ad Length field. If
the length of the padding is the length of the frame payload or greate r, the recipient the length of the padding is the length of the frame payload or greate r, the recipient
MUST treat this as a <xref target="ConnectionErrorHandler">connection <bcp14>MUST</bcp14> treat this as a <xref target="ConnectionErrorHandl
error</xref> of er">connection error</xref> of
type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref> type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>
. .</t>
</t>
<aside> <aside>
<t>Note: <t>Note:
A frame can be increased in size by one octet by including a Pad Len gth field with a A frame can be increased in size by one octet by including a Pad Len gth field with a
value of zero. value of zero.</t>
</t> </aside>
</aside> </section> </section>
<section anchor="PING"> <section anchor="PING">
<name>PING</name> <name>PING</name>
<t> <t>The PING frame (type=0x06) is a mechanism for measuring a minimal rou
The PING frame (type=0x6) is a mechanism for measuring a minimal round nd-trip time from the
-trip time from the
sender, as well as determining whether an idle connection is still fun ctional. PING sender, as well as determining whether an idle connection is still fun ctional. PING
frames can be sent from any endpoint. frames can be sent from any endpoint.</t>
</t>
<figure anchor="PINGFrameFormat"> <figure anchor="PINGFrameFormat">
<name>PING Frame Format</name> <name>PING Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
PING Frame { PING Frame {
Length (24) = 0x8, Length (24) = 0x08,
Type (8) = 0x6, Type (8) = 0x06,
Unused Flags (7), Unused Flags (7),
ACK Flag (1), ACK Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31) = 0, Stream Identifier (31) = 0,
Opaque Data (64), Opaque Data (64),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.</t>
ds are described in <xref target="FramingLayer"/>. <t>In addition to the frame header, PING frames <bcp14>MUST</bcp14> cont
</t> ain 8 octets of opaque data in the frame payload.
<t> A sender can include any value it chooses and use those octets in any
In addition to the frame header, PING frames MUST contain 8 octets of fashion.</t>
opaque data in the frame payload. <t>Receivers of a PING frame that does not include an ACK flag <bcp14>MU
A sender can include any value it chooses and use those octets in any ST</bcp14> send a PING frame with
fashion. the ACK flag set in response, with an identical frame payload. PING r
</t> esponses <bcp14>SHOULD</bcp14> be given
<t> higher priority than any other frame.</t>
Receivers of a PING frame that does not include an ACK flag MUST send <t>The PING frame defines the following flags:</t>
a PING frame with
the ACK flag set in response, with an identical frame payload. PING r
esponses SHOULD be given
higher priority than any other frame.
</t>
<t>
The PING frame defines the following flags:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>ACK (0x1):</dt> <dt>ACK (0x01):</dt>
<dd> <dd>When set, the ACK flag indicates that this PING frame is a PING re
When set, the ACK flag indicates that this PING frame is a PING re sponse. An endpoint <bcp14>MUST</bcp14>
sponse. An endpoint MUST set this flag in PING responses. An endpoint <bcp14>MUST NOT</bcp
set this flag in PING responses. An endpoint MUST NOT respond to 14> respond to PING frames
PING frames containing this flag.</dd>
containing this flag.
</dd>
</dl> </dl>
<t> <t>PING frames are not associated with any individual stream. If a PING
PING frames are not associated with any individual stream. If a PING f frame is received
rame is received with a Stream Identifier field value other than 0x00, the recipient <b
with a stream identifier field value other than 0x0, the recipient MUS cp14>MUST</bcp14> respond with a
T respond with a
<xref target="ConnectionErrorHandler">connection error</xref> of type <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
</t> <t>Receipt of a PING frame with a length field value other than 8 <bcp14
<t> >MUST</bcp14> be treated as a <xref target="ConnectionErrorHandler">connection e
Receipt of a PING frame with a length field value other than 8 MUST be rror</xref> of type
treated as a <xref target="ConnectionErrorHandler">connection error</xref> of t <xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.
ype </t>
<xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.
</t>
</section> </section>
<section anchor="GOAWAY"> <section anchor="GOAWAY">
<name>GOAWAY</name> <name>GOAWAY</name>
<t> <t>The GOAWAY frame (type=0x07) is used to initiate shutdown of a connec
The GOAWAY frame (type=0x7) is used to initiate shutdown of a connecti tion or to signal
on or to signal
serious error conditions. GOAWAY allows an endpoint to gracefully sto p accepting new serious error conditions. GOAWAY allows an endpoint to gracefully sto p accepting new
streams while still finishing processing of previously established str eams. This enables streams while still finishing processing of previously established str eams. This enables
administrative actions, like server maintenance. administrative actions, like server maintenance.</t>
</t> <t>There is an inherent race condition between an endpoint starting new
<t> streams and the
There is an inherent race condition between an endpoint starting new s remote peer sending a GOAWAY frame. To deal with this case, the GOAWA
treams and the Y contains the stream
remote sending a GOAWAY frame. To deal with this case, the GOAWAY con
tains the stream
identifier of the last peer-initiated stream that was or might be proc essed on the identifier of the last peer-initiated stream that was or might be proc essed on the
sending endpoint in this connection. For instance, if the server send s a GOAWAY frame, sending endpoint in this connection. For instance, if the server send s a GOAWAY frame,
the identified stream is the highest-numbered stream initiated by the the identified stream is the highest-numbered stream initiated by the
client. client.</t>
</t> <t>Once the GOAWAY is sent, the sender will ignore frames sent on stream
<t> s initiated by the
Once sent, the sender will ignore frames sent on streams initiated by receiver if the stream has an identifier higher than the included last
the receiver if the stream identifier.
stream has an identifier higher than the included last stream identifi Receivers of a GOAWAY frame <bcp14>MUST NOT</bcp14> open additional st
er. Receivers of a reams on the connection, although a
GOAWAY frame MUST NOT open additional streams on the connection, altho new connection can be established for new streams.</t>
ugh a new connection <t>If the receiver of the GOAWAY has sent data on streams with a higher
can be established for new streams. stream identifier
</t>
<t>
If the receiver of the GOAWAY has sent data on streams with a higher s
tream identifier
than what is indicated in the GOAWAY frame, those streams are not or w ill not be than what is indicated in the GOAWAY frame, those streams are not or w ill not be
processed. The receiver of the GOAWAY frame can treat the streams as though they had processed. The receiver of the GOAWAY frame can treat the streams as though they had
never been created at all, thereby allowing those streams to be retrie d later on a new never been created at all, thereby allowing those streams to be retrie d later on a new
connection. connection.</t>
</t> <t>Endpoints <bcp14>SHOULD</bcp14> always send a GOAWAY frame before clo
<t> sing a connection so that the remote
Endpoints SHOULD always send a GOAWAY frame before closing a connectio
n so that the remote
peer can know whether a stream has been partially processed or not. F or example, if an peer can know whether a stream has been partially processed or not. F or example, if an
HTTP client sends a POST at the same time that a server closes a conne ction, the client HTTP client sends a POST at the same time that a server closes a conne ction, the client
cannot know if the server started to process that POST request if the server does not send cannot know if the server started to process that POST request if the server does not send
a GOAWAY frame to indicate what streams it might have acted on. a GOAWAY frame to indicate what streams it might have acted on.</t>
</t> <t>An endpoint might choose to close a connection without sending a GOAW
<t> AY for misbehaving
An endpoint might choose to close a connection without sending a GOAWA peers.</t>
Y for misbehaving <t>A GOAWAY frame might not immediately precede closing of the connectio
peers. n; a receiver of a
</t> GOAWAY that has no more use for the connection <bcp14>SHOULD</bcp14> s
<t> till send a GOAWAY frame before
A GOAWAY frame might not immediately precede closing of the connection terminating the connection.</t>
; a receiver of a
GOAWAY that has no more use for the connection SHOULD still send a GOA
WAY frame before
terminating the connection.
</t>
<figure anchor="GOAWAYFrameFormat"> <figure anchor="GOAWAYFrameFormat">
<name>GOAWAY Frame Format</name> <name>GOAWAY Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
GOAWAY Frame { GOAWAY Frame {
Length (24), Length (24),
Type (8) = 0x7, Type (8) = 0x07,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31) = 0, Stream Identifier (31) = 0,
Reserved (1), Reserved (1),
Last-Stream-ID (31), Last-Stream-ID (31),
Error Code (32), Error Code (32),
Additional Debug Data (..), Additional Debug Data (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.</t>
ds are described in <xref target="FramingLayer"/>. <t>The GOAWAY frame does not define any flags.</t>
</t> <t>The GOAWAY frame applies to the connection, not a specific stream. A
<t> n endpoint <bcp14>MUST</bcp14> treat
The GOAWAY frame does not define any flags. a <xref target="GOAWAY" format="none">GOAWAY</xref> frame with a strea
</t> m identifier other than 0x00 as a <xref target="ConnectionErrorHandler">connecti
<t> on error</xref> of type
The GOAWAY frame applies to the connection, not a specific stream. An <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
endpoint MUST treat <t>The last stream identifier in the GOAWAY frame contains the highest-n
a <xref target="GOAWAY" format="none">GOAWAY</xref> frame with a strea umbered stream
m identifier other than 0x0 as a <xref target="ConnectionErrorHandler">connectio
n error</xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.
</t>
<t>
The last stream identifier in the GOAWAY frame contains the highest-nu
mbered stream
identifier for which the sender of the GOAWAY frame might have taken s ome action on or identifier for which the sender of the GOAWAY frame might have taken s ome action on or
might yet take action on. All streams up to and including the identif ied stream might might yet take action on. All streams up to and including the identif ied stream might
have been processed in some way. The last stream identifier can be se t to 0 if no streams have been processed in some way. The last stream identifier can be se t to 0 if no streams
were processed. were processed.</t>
</t>
<aside> <aside>
<t>Note: <t>Note:
In this context, "processed" means that some data from the stream wa s passed to some In this context, "processed" means that some data from the stream wa s passed to some
higher layer of software that might have taken some action as a resu higher layer of software that might have taken some action as a resu
lt. lt.</t>
</t>
</aside> </aside>
<t> <t>If a connection terminates without a GOAWAY frame, the last stream id
If a connection terminates without a GOAWAY frame, the last stream ide entifier is
ntifier is effectively the highest possible stream identifier.</t>
effectively the highest possible stream identifier. <t>On streams with lower- or equal-numbered identifiers that were not cl
</t> osed completely prior
<t>
On streams with lower- or equal-numbered identifiers that were not clo
sed completely prior
to the connection being closed, reattempting requests, transactions, o r any protocol to the connection being closed, reattempting requests, transactions, o r any protocol
activity is not possible, except for idempotent actions like HTTP GET, PUT, or activity is not possible, except for idempotent actions like HTTP GET, PUT, or
DELETE. Any protocol activity that uses higher-numbered streams can b e safely retried DELETE. Any protocol activity that uses higher-numbered streams can b e safely retried
using a new connection. using a new connection.</t>
</t> <t>Activity on streams numbered lower than or equal to the last stream i
<t> dentifier might still
Activity on streams numbered lower or equal to the last stream identif
ier might still
complete successfully. The sender of a GOAWAY frame might gracefully shut down a complete successfully. The sender of a GOAWAY frame might gracefully shut down a
connection by sending a GOAWAY frame, maintaining the connection in an "open" state until connection by sending a GOAWAY frame, maintaining the connection in an "open" state until
all in-progress streams complete. all in-progress streams complete.</t>
</t> <t>An endpoint <bcp14>MAY</bcp14> send multiple GOAWAY frames if circums
<t> tances change. For instance, an
An endpoint MAY send multiple GOAWAY frames if circumstances change.
For instance, an
endpoint that sends GOAWAY with <xref target="NO_ERROR" format="none"> NO_ERROR</xref> during graceful shutdown could endpoint that sends GOAWAY with <xref target="NO_ERROR" format="none"> NO_ERROR</xref> during graceful shutdown could
subsequently encounter a condition that requires immediate termination of the connection. subsequently encounter a condition that requires immediate termination of the connection.
The last stream identifier from the last GOAWAY frame received indicat es which streams The last stream identifier from the last GOAWAY frame received indicat es which streams
could have been acted upon. Endpoints MUST NOT increase the value the y send in the last could have been acted upon. Endpoints <bcp14>MUST NOT</bcp14> increas e the value they send in the last
stream identifier, since the peers might already have retried unproces sed requests on stream identifier, since the peers might already have retried unproces sed requests on
another connection. another connection.</t>
</t> <t>A client that is unable to retry requests loses all requests that are
<t> in flight when the
A client that is unable to retry requests loses all requests that are
in flight when the
server closes the connection. This is especially true for intermediar ies that might not server closes the connection. This is especially true for intermediar ies that might not
be serving clients using HTTP/2. A server that is attempting to grace fully shut down a be serving clients using HTTP/2. A server that is attempting to grace fully shut down a
connection SHOULD send an initial GOAWAY frame with the last stream id entifier set to connection <bcp14>SHOULD</bcp14> send an initial GOAWAY frame with the last stream identifier set to
2<sup>31</sup>-1 and a <xref target="NO_ERROR" format="none">NO_ERROR< /xref> code. This signals to the client that 2<sup>31</sup>-1 and a <xref target="NO_ERROR" format="none">NO_ERROR< /xref> code. This signals to the client that
a shutdown is imminent and that initiating further requests is prohibi ted. After allowing a shutdown is imminent and that initiating further requests is prohibi ted. After allowing
time for any in-flight stream creation (at least one round-trip time), the server MAY time for any in-flight stream creation (at least one round-trip time), the server <bcp14>MAY</bcp14>
send another GOAWAY frame with an updated last stream identifier. Thi s ensures that a send another GOAWAY frame with an updated last stream identifier. Thi s ensures that a
connection can be cleanly shut down without losing requests. connection can be cleanly shut down without losing requests.</t>
</t> <t>After sending a GOAWAY frame, the sender can discard frames for strea
<t> ms initiated by the
After sending a GOAWAY frame, the sender can discard frames for stream
s initiated by the
receiver with identifiers higher than the identified last stream. How ever, any frames receiver with identifiers higher than the identified last stream. How ever, any frames
that alter connection state cannot be completely ignored. For instanc e, that alter connection state cannot be completely ignored. For instanc e,
<xref target="HEADERS" format="none">HEADERS</xref>, <xref target="PUS H_PROMISE" format="none">PUSH_PROMISE</xref>, and <xref target="CONTINUATION" fo rmat="none">CONTINUATION</xref> frames <xref target="HEADERS" format="none">HEADERS</xref>, <xref target="PUS H_PROMISE" format="none">PUSH_PROMISE</xref>, and <xref target="CONTINUATION" fo rmat="none">CONTINUATION</xref> frames
MUST be minimally processed to ensure the state maintained for field s <bcp14>MUST</bcp14> be minimally processed to ensure that the state ma
ection compression is intained for field section compression is
consistent (see <xref target="FieldBlock"/>); similarly, DATA frames M consistent (see <xref target="FieldBlock"/>); similarly, DATA frames <
UST be counted bcp14>MUST</bcp14> be counted
toward the connection flow-control window. Failure to process these f rames can cause flow toward the connection flow-control window. Failure to process these f rames can cause flow
control or field section compression state to become unsynchronized. control or field section compression state to become unsynchronized.</
</t> t>
<t> <t>The GOAWAY frame also contains a 32-bit <xref target="ErrorCodes">err
The GOAWAY frame also contains a 32-bit <xref target="ErrorCodes">erro or code</xref> that
r code</xref> that contains the reason for closing the connection.</t>
contains the reason for closing the connection. <t>Endpoints <bcp14>MAY</bcp14> append opaque data to the frame payload
</t> of any GOAWAY frame. Additional debug
<t>
Endpoints MAY append opaque data to the frame payload of any GOAWAY fr
ame. Additional debug
data is intended for diagnostic purposes only and carries no semantic value. Debug data is intended for diagnostic purposes only and carries no semantic value. Debug
information could contain security- or privacy-sensitive data. Logged or otherwise information could contain security- or privacy-sensitive data. Logged or otherwise
persistently stored debug data MUST have adequate safeguards to preven persistently stored debug data <bcp14>MUST</bcp14> have adequate safeg
t unauthorized uards to prevent unauthorized
access. access.</t>
</t>
</section> </section>
<section anchor="WINDOW_UPDATE"> <section anchor="WINDOW_UPDATE">
<name>WINDOW_UPDATE</name> <name>WINDOW_UPDATE</name>
<t> <t>The WINDOW_UPDATE frame (type=0x08) is used to implement flow control
The WINDOW_UPDATE frame (type=0x8) is used to implement flow control; ; see <xref target="FlowControl"/> for an overview.</t>
see <xref target="FlowControl"/> for an overview. <t>Flow control operates at two levels: on each individual stream and on
</t> the entire
<t> connection.</t>
Flow control operates at two levels: on each individual stream and on <t>Both types of flow control are hop by hop, that is, only between the
the entire two endpoints.
connection.
</t>
<t>
Both types of flow control are hop by hop, that is, only between the t
wo endpoints.
Intermediaries do not forward WINDOW_UPDATE frames between dependent c onnections. Intermediaries do not forward WINDOW_UPDATE frames between dependent c onnections.
However, throttling of data transfer by any receiver can indirectly ca use the propagation However, throttling of data transfer by any receiver can indirectly ca use the propagation
of flow-control information toward the original sender. of flow-control information toward the original sender.</t>
</t> <t>Flow control only applies to frames that are identified as being subj
<t> ect to flow control.
Flow control only applies to frames that are identified as being subje
ct to flow control.
Of the frame types defined in this document, this includes only <xref target="DATA" format="none">DATA</xref> frames. Of the frame types defined in this document, this includes only <xref target="DATA" format="none">DATA</xref> frames.
Frames that are exempt from flow control MUST be accepted and processe Frames that are exempt from flow control <bcp14>MUST</bcp14> be accept
d, unless the ed and processed, unless the
receiver is unable to assign resources to handling the frame. A recei receiver is unable to assign resources to handling the frame. A recei
ver MAY respond with ver <bcp14>MAY</bcp14> respond with
a <xref target="StreamErrorHandler">stream error</xref> or <xref targe t="ConnectionErrorHandler">connection error</xref> of type a <xref target="StreamErrorHandler">stream error</xref> or <xref targe t="ConnectionErrorHandler">connection error</xref> of type
<xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONTROL_ERROR</xr <xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONTROL_ERROR</xr
ef> if it is unable to accept a frame. ef> if it is unable to accept a frame.</t>
</t>
<figure anchor="WINDOW_UPDATEFrameFormat"> <figure anchor="WINDOW_UPDATEFrameFormat">
<name>WINDOW_UPDATE Frame Format</name> <name>WINDOW_UPDATE Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
WINDOW_UPDATE Frame { WINDOW_UPDATE Frame {
Length (24) = 0x4, Length (24) = 0x04,
Type (8) = 0x8, Type (8) = 0x08,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Reserved (1), Reserved (1),
Window Size Increment (31), Window Size Increment (31),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.
ds are described in <xref target="FramingLayer"/>.
The frame payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer The frame payload of a WINDOW_UPDATE frame is one reserved bit plus an unsigned 31-bit integer
indicating the number of octets that the sender can transmit in additi on to the existing indicating the number of octets that the sender can transmit in additi on to the existing
flow-control window. The legal range for the increment to the flow-co ntrol window is 1 to flow-control window. The legal range for the increment to the flow-co ntrol window is 1 to
2<sup>31</sup>-1 (2,147,483,647) octets. 2<sup>31</sup>-1 (2,147,483,647) octets.</t>
</t> <t>The WINDOW_UPDATE frame does not define any flags.</t>
<t> <t>The WINDOW_UPDATE frame can be specific to a stream or to the entire
The WINDOW_UPDATE frame does not define any flags. connection. In the
</t>
<t>
The WINDOW_UPDATE frame can be specific to a stream or to the entire c
onnection. In the
former case, the frame's stream identifier indicates the affected stre am; in the latter, former case, the frame's stream identifier indicates the affected stre am; in the latter,
the value "0" indicates that the entire connection is the subject of t the value "0" indicates that the entire connection is the subject of t
he frame. he frame.</t>
</t> <t>A receiver <bcp14>MUST</bcp14> treat the receipt of a WINDOW_UPDATE f
<t> rame with a flow-control window
A receiver MUST treat the receipt of a WINDOW_UPDATE frame with a flow
-control window
increment of 0 as a <xref target="StreamErrorHandler">stream error</xr ef> of type increment of 0 as a <xref target="StreamErrorHandler">stream error</xr ef> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>; err <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>; err
ors on the connection flow-control window MUST be ors on the connection flow-control window <bcp14>MUST</bcp14> be
treated as a <xref target="ConnectionErrorHandler">connection error</x treated as a <xref target="ConnectionErrorHandler">connection error</x
ref>. ref>.</t>
</t> <t>WINDOW_UPDATE can be sent by a peer that has sent a frame with the EN
<t> D_STREAM flag set.
WINDOW_UPDATE can be sent by a peer that has sent a frame with the END This means that a receiver could receive a WINDOW_UPDATE frame on a st
_STREAM flag set. ream in a "half-closed (remote)"
This means that a receiver could receive a WINDOW_UPDATE frame on a "h or "closed" state. A receiver <bcp14>MUST NOT</bcp14> treat this as a
alf-closed (remote)" n error (see <xref target="StreamStates"/>).</t>
or "closed" stream. A receiver MUST NOT treat this as an error (see < <t>A receiver that receives a flow-controlled frame <bcp14>MUST</bcp14>
xref target="StreamStates"/>). always account for its contribution
</t>
<t>
A receiver that receives a flow-controlled frame MUST always account f
or its contribution
against the connection flow-control window, unless the receiver treats this as a <xref target="ConnectionErrorHandler">connection error</xref>. This is necessary even if the against the connection flow-control window, unless the receiver treats this as a <xref target="ConnectionErrorHandler">connection error</xref>. This is necessary even if the
frame is in error. The sender counts the frame toward the flow-contro l window, but if frame is in error. The sender counts the frame toward the flow-contro l window, but if
the receiver does not, the flow-control window at the sender and recei ver can become the receiver does not, the flow-control window at the sender and recei ver can become
different. different.</t>
</t> <t>A WINDOW_UPDATE frame with a length other than 4 octets <bcp14>MUST</
<t> bcp14> be treated as a <xref target="ConnectionErrorHandler">connection error</x
A WINDOW_UPDATE frame with a length other than 4 octets MUST be treate ref> of type
d as a <xref target="ConnectionErrorHandler">connection error</xref> of type <xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>.
<xref target="FRAME_SIZE_ERROR" format="none">FRAME_SIZE_ERROR</xref>. </t>
</t>
<section> <section>
<name>The Flow-Control Window</name> <name>The Flow-Control Window</name>
<t> <t>Flow control in HTTP/2 is implemented using a window kept by each s
Flow control in HTTP/2 is implemented using a window kept by each se ender on every
nder on every
stream. The flow-control window is a simple integer value that indic ates how many octets stream. The flow-control window is a simple integer value that indic ates how many octets
of data the sender is permitted to transmit; as such, its size is a measure of the of data the sender is permitted to transmit; as such, its size is a measure of the
buffering capacity of the receiver. buffering capacity of the receiver.</t>
</t> <t>Two flow-control windows are applicable: the stream flow-control wi
<t> ndow and the
Two flow-control windows are applicable: the stream flow-control win connection flow-control window. The sender <bcp14>MUST NOT</bcp14>
dow and the send a flow-controlled frame with a
connection flow-control window. The sender MUST NOT send a flow-con
trolled frame with a
length that exceeds the space available in either of the flow-contro l windows advertised length that exceeds the space available in either of the flow-contro l windows advertised
by the receiver. Frames with zero length with the END_STREAM flag s et (that is, an by the receiver. Frames with zero length with the END_STREAM flag s et (that is, an
empty <xref target="DATA" format="none">DATA</xref> frame) MAY be se empty <xref target="DATA" format="none">DATA</xref> frame) <bcp14>MA
nt if there is no available space in either Y</bcp14> be sent if there is no available space in either
flow-control window. flow-control window.</t>
</t> <t>For flow-control calculations, the 9-octet frame header is not coun
<t> ted.</t>
For flow-control calculations, the 9-octet frame header is not count <t>After sending a flow-controlled frame, the sender reduces the space
ed. available in both
</t> windows by the length of the transmitted frame.</t>
<t> <t>The receiver of a frame sends a WINDOW_UPDATE frame as it consumes
After sending a flow-controlled frame, the sender reduces the space data and frees up
available in both
windows by the length of the transmitted frame.
</t>
<t>
The receiver of a frame sends a WINDOW_UPDATE frame as it consumes d
ata and frees up
space in flow-control windows. Separate WINDOW_UPDATE frames are se nt for the stream- space in flow-control windows. Separate WINDOW_UPDATE frames are se nt for the stream-
and connection-level flow-control windows. Receivers are advised to have mechanisms in and connection-level flow-control windows. Receivers are advised to have mechanisms in
place to avoid sending WINDOW_UPDATE frames with very small incremen place to avoid sending WINDOW_UPDATE frames with very small incremen
ts; see <xref ts; see <xref target="RFC1122" section="4.2.3.3"/>.</t>
target="RFC1122" section="4.2.3.3"/>. <t>A sender that receives a WINDOW_UPDATE frame updates the correspond
</t> ing window by the
<t> amount specified in the frame.</t>
A sender that receives a WINDOW_UPDATE frame updates the correspondi <t>A sender <bcp14>MUST NOT</bcp14> allow a flow-control window to exc
ng window by the eed 2<sup>31</sup>-1 octets.
amount specified in the frame.
</t>
<t>
A sender MUST NOT allow a flow-control window to exceed 2<sup>31</su
p>-1 octets.
If a sender receives a WINDOW_UPDATE that causes a flow-control wind ow to exceed this If a sender receives a WINDOW_UPDATE that causes a flow-control wind ow to exceed this
maximum, it MUST terminate either the stream or the connection, as a ppropriate. For maximum, it <bcp14>MUST</bcp14> terminate either the stream or the c onnection, as appropriate. For
streams, the sender sends a <xref target="RST_STREAM" format="none"> RST_STREAM</xref> with an error code of streams, the sender sends a <xref target="RST_STREAM" format="none"> RST_STREAM</xref> with an error code of
<xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONTROL_ERROR</ xref>; for the connection, a <xref target="GOAWAY" format="none">GOAWAY</xref> <xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONTROL_ERROR</ xref>; for the connection, a <xref target="GOAWAY" format="none">GOAWAY</xref>
frame with an error code of <xref target="FLOW_CONTROL_ERROR" format frame with an error code of <xref target="FLOW_CONTROL_ERROR" format
="none">FLOW_CONTROL_ERROR</xref> is sent. ="none">FLOW_CONTROL_ERROR</xref> is sent.</t>
</t> <t>Flow-controlled frames from the sender and WINDOW_UPDATE frames fro
<t> m the receiver are
Flow-controlled frames from the sender and WINDOW_UPDATE frames from
the receiver are
completely asynchronous with respect to each other. This property al lows a receiver to completely asynchronous with respect to each other. This property al lows a receiver to
aggressively update the window size kept by the sender to prevent st aggressively update the window size kept by the sender to prevent st
reams from stalling. reams from stalling.</t>
</t>
</section> </section>
<section anchor="InitialWindowSize"> <section anchor="InitialWindowSize">
<name>Initial Flow-Control Window Size</name> <name>Initial Flow-Control Window Size</name>
<t> <t>When an HTTP/2 connection is first established, new streams are cre
When an HTTP/2 connection is first established, new streams are crea ated with an initial
ted with an initial
flow-control window size of 65,535 octets. The connection flow-contr ol window is also 65,535 flow-control window size of 65,535 octets. The connection flow-contr ol window is also 65,535
octets. Both endpoints can adjust the initial window size for new st reams by including octets. Both endpoints can adjust the initial window size for new st reams by including
a value for <xref target="SETTINGS_INITIAL_WINDOW_SIZE" format="none ">SETTINGS_INITIAL_WINDOW_SIZE</xref> in the <xref target="SETTINGS" format="non e">SETTINGS</xref> a value for <xref target="SETTINGS_INITIAL_WINDOW_SIZE" format="none ">SETTINGS_INITIAL_WINDOW_SIZE</xref> in the <xref target="SETTINGS" format="non e">SETTINGS</xref>
frame. The connection flow-control window can frame. The connection flow-control window can
only be changed using WINDOW_UPDATE frames. only be changed using WINDOW_UPDATE frames.</t>
</t> <t>Prior to receiving a <xref target="SETTINGS" format="none">SETTINGS
<t> </xref> frame that sets a value for
Prior to receiving a <xref target="SETTINGS" format="none">SETTINGS<
/xref> frame that sets a value for
<xref target="SETTINGS_INITIAL_WINDOW_SIZE" format="none">SETTINGS_I NITIAL_WINDOW_SIZE</xref>, an endpoint can only use the default <xref target="SETTINGS_INITIAL_WINDOW_SIZE" format="none">SETTINGS_I NITIAL_WINDOW_SIZE</xref>, an endpoint can only use the default
initial window size when sending flow-controlled frames. Similarly, the connection flow-control initial window size when sending flow-controlled frames. Similarly, the connection flow-control
window is set based on the default initial window size until a WINDO W_UPDATE frame is window is set based on the default initial window size until a WINDO W_UPDATE frame is
received. received.</t>
</t> <t>In addition to changing the flow-control window for streams that ar
<t> e not yet active, a
In addition to changing the flow-control window for streams that are
not yet active, a
<xref target="SETTINGS" format="none">SETTINGS</xref> frame can alte r the initial flow-control window size for streams <xref target="SETTINGS" format="none">SETTINGS</xref> frame can alte r the initial flow-control window size for streams
with active flow-control windows (that is, streams in the "open" or "half-closed with active flow-control windows (that is, streams in the "open" or "half-closed
(remote)" state). When the value of <xref target="SETTINGS_INITIAL_ WINDOW_SIZE" format="none">SETTINGS_INITIAL_WINDOW_SIZE</xref> (remote)" state). When the value of <xref target="SETTINGS_INITIAL_ WINDOW_SIZE" format="none">SETTINGS_INITIAL_WINDOW_SIZE</xref>
changes, a receiver MUST adjust the size of all stream flow-control changes, a receiver <bcp14>MUST</bcp14> adjust the size of all strea
windows that it m flow-control windows that it
maintains by the difference between the new value and the old value. maintains by the difference between the new value and the old value.
</t> </t>
<t> <t>A change to <xref target="SETTINGS_INITIAL_WINDOW_SIZE" format="non
A change to <xref target="SETTINGS_INITIAL_WINDOW_SIZE" format="none e">SETTINGS_INITIAL_WINDOW_SIZE</xref> can cause the available space in
">SETTINGS_INITIAL_WINDOW_SIZE</xref> can cause the available space in a flow-control window to become negative. A sender <bcp14>MUST</bcp
a flow-control window to become negative. A sender MUST track the n 14> track the negative flow-control
egative flow-control window and <bcp14>MUST NOT</bcp14> send new flow-controlled frames u
window and MUST NOT send new flow-controlled frames until it receive ntil it receives WINDOW_UPDATE
s WINDOW_UPDATE frames that cause the flow-control window to become positive.</t>
frames that cause the flow-control window to become positive. <t>For example, if the client sends 60 KB immediately on connection es
</t> tablishment and the
<t>
For example, if the client sends 60 KB immediately on connection est
ablishment and the
server sets the initial window size to be 16 KB, the client will rec alculate the server sets the initial window size to be 16 KB, the client will rec alculate the
available flow-control window to be -44 KB on receipt of the <xref t arget="SETTINGS" format="none">SETTINGS</xref> available flow-control window to be -44 KB on receipt of the <xref t arget="SETTINGS" format="none">SETTINGS</xref>
frame. The client retains a negative flow-control window until WIND OW_UPDATE frames frame. The client retains a negative flow-control window until WIND OW_UPDATE frames
restore the window to being positive, after which the client can res restore the window to being positive, after which the client can res
ume sending. ume sending.</t>
</t> <t>A <xref target="SETTINGS" format="none">SETTINGS</xref> frame canno
<t> t alter the connection flow-control window.</t>
A <xref target="SETTINGS" format="none">SETTINGS</xref> frame cannot <t>An endpoint <bcp14>MUST</bcp14> treat a change to <xref target="SET
alter the connection flow-control window. TINGS_INITIAL_WINDOW_SIZE" format="none">SETTINGS_INITIAL_WINDOW_SIZE</xref> tha
</t> t
<t>
An endpoint MUST treat a change to <xref target="SETTINGS_INITIAL_WI
NDOW_SIZE" format="none">SETTINGS_INITIAL_WINDOW_SIZE</xref> that
causes any flow-control window to exceed the maximum size as a <xref target="ConnectionErrorHandler">connection error</xref> of type causes any flow-control window to exceed the maximum size as a <xref target="ConnectionErrorHandler">connection error</xref> of type
<xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONTROL_ERROR</ <xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONTROL_ERROR</
xref>. xref>.</t>
</t>
</section> </section>
<section> <section>
<name>Reducing the Stream Window Size</name> <name>Reducing the Stream Window Size</name>
<t> <t>A receiver that wishes to use a smaller flow-control window than th
A receiver that wishes to use a smaller flow-control window than the e current size can
current size can send a new <xref target="SETTINGS" format="none">SETTINGS</xref> fra
send a new <xref target="SETTINGS" format="none">SETTINGS</xref> fra me. However, the receiver <bcp14>MUST</bcp14> be prepared to
me. However, the receiver MUST be prepared to
receive data that exceeds this window size, since the sender might s end data that receive data that exceeds this window size, since the sender might s end data that
exceeds the lower limit prior to processing the <xref target="SETTIN exceeds the lower limit prior to processing the <xref target="SETTIN
GS" format="none">SETTINGS</xref> frame. GS" format="none">SETTINGS</xref> frame.</t>
</t> <t>After sending a SETTINGS frame that reduces the initial flow-contro
<t> l window size, a
After sending a SETTINGS frame that reduces the initial flow-control receiver <bcp14>MAY</bcp14> continue to process streams that exceed
window size, a flow-control limits. Allowing
receiver MAY continue to process streams that exceed flow-control li
mits. Allowing
streams to continue does not allow the receiver to immediately reduc e the space it streams to continue does not allow the receiver to immediately reduc e the space it
reserves for flow-control windows. Progress on these streams can al so stall, since reserves for flow-control windows. Progress on these streams can al so stall, since
<xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> fram es are needed to allow the sender to resume sending. <xref target="WINDOW_UPDATE" format="none">WINDOW_UPDATE</xref> fram es are needed to allow the sender to resume sending.
The receiver MAY instead send a <xref target="RST_STREAM" format="no The receiver <bcp14>MAY</bcp14> instead send a <xref target="RST_STR
ne">RST_STREAM</xref> with an error code of EAM" format="none">RST_STREAM</xref> with an error code of
<xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONTROL_ERROR</ <xref target="FLOW_CONTROL_ERROR" format="none">FLOW_CONTROL_ERROR</
xref> for the affected streams. xref> for the affected streams.</t>
</t>
</section> </section>
</section> </section>
<section anchor="CONTINUATION"> <section anchor="CONTINUATION">
<name>CONTINUATION</name> <name>CONTINUATION</name>
<t> <t>The CONTINUATION frame (type=0x09) is used to continue a sequence of
The CONTINUATION frame (type=0x9) is used to continue a sequence of <x <xref target="FieldBlock">field block fragments</xref>. Any number of CONTINUAT
ref target="FieldBlock">field block fragments</xref>. Any number of CONTINUATIO ION frames can
N frames can
be sent, as long as the preceding frame is on the same stream and is a be sent, as long as the preceding frame is on the same stream and is a
<xref target="HEADERS" format="none">HEADERS</xref>, <xref target="PUS H_PROMISE" format="none">PUSH_PROMISE</xref>, or CONTINUATION frame without the <xref target="HEADERS" format="none">HEADERS</xref>, <xref target="PUS H_PROMISE" format="none">PUSH_PROMISE</xref>, or CONTINUATION frame without the
END_HEADERS flag set. END_HEADERS flag set.</t>
</t>
<figure anchor="CONTINUATIONFrameFormat"> <figure anchor="CONTINUATIONFrameFormat">
<name>CONTINUATION Frame Format</name> <name>CONTINUATION Frame Format</name>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
CONTINUATION Frame { CONTINUATION Frame {
Length (24), Length (24),
Type (8) = 0x9, Type (8) = 0x09,
Unused Flags (5), Unused Flags (5),
END_HEADERS Flag (1), END_HEADERS Flag (1),
Unused Flags (2), Unused Flags (2),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Field Block Fragment (..), Field Block Fragment (..),
} }
]]></artwork> ]]></artwork>
</figure> </figure>
<t> <t>The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fie
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier fiel lds are described in <xref target="FramingLayer"/>.
ds are described in <xref target="FramingLayer"/>.
The CONTINUATION frame payload contains a <xref target="FieldBlock">fi eld block The CONTINUATION frame payload contains a <xref target="FieldBlock">fi eld block
fragment</xref>. fragment</xref>.</t>
</t> <t>The CONTINUATION frame defines the following flag:</t>
<t>
The CONTINUATION frame defines the following flag:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>END_HEADERS (0x4):</dt> <dt>END_HEADERS (0x04):</dt>
<dd> <dd>
<t> <t>When set, the END_HEADERS flag indicates that this frame ends a <
When set, the END_HEADERS flag indicates that this frame ends a xref target="FieldBlock">field
<xref target="FieldBlock">field block</xref>.</t>
block</xref>. <t>If the END_HEADERS flag is not set, this frame <bcp14>MUST</bcp14
</t> > be followed by another
<t> CONTINUATION frame. A receiver <bcp14>MUST</bcp14> treat the re
If the END_HEADERS flag is not set, this frame MUST be followed ceipt of any other type of frame or
by another
CONTINUATION frame. A receiver MUST treat the receipt of any ot
her type of frame or
a frame on a different stream as a <xref target="ConnectionError Handler">connection a frame on a different stream as a <xref target="ConnectionError Handler">connection
error</xref> of type <xref target="PROTOCOL_ERROR" format="none" error</xref> of type <xref target="PROTOCOL_ERROR" format="none"
>PROTOCOL_ERROR</xref>. >PROTOCOL_ERROR</xref>.</t>
</t>
</dd> </dd>
</dl> </dl>
<t> <t>The CONTINUATION frame changes the connection state as defined in <xr
The CONTINUATION frame changes the connection state as defined in <xre ef target="FieldBlock"/>.</t>
f target="FieldBlock"/>. <t>CONTINUATION frames <bcp14>MUST</bcp14> be associated with a stream.
</t> If a CONTINUATION frame is received
<t> with a Stream Identifier field of 0x00, the recipient <bcp14>MUST</bcp
CONTINUATION frames MUST be associated with a stream. If a CONTINUATIO 14> respond with a <xref target="ConnectionErrorHandler">connection error</xref>
N frame is received of type PROTOCOL_ERROR.</t>
whose stream identifier field is 0x0, the recipient MUST respond with <t>A CONTINUATION frame <bcp14>MUST</bcp14> be preceded by a <xref targe
a <xref target="ConnectionErrorHandler">connection error</xref> of type PROTOCOL t="HEADERS" format="none">HEADERS</xref>,
_ERROR.
</t>
<t>
A CONTINUATION frame MUST be preceded by a <xref target="HEADERS" form
at="none">HEADERS</xref>,
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> or CONTI NUATION frame without the END_HEADERS flag set. A <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> or CONTI NUATION frame without the END_HEADERS flag set. A
recipient that observes violation of this rule MUST respond with a <xr recipient that observes violation of this rule <bcp14>MUST</bcp14> res
ef target="ConnectionErrorHandler"> connection error</xref> of type pond with a <xref target="ConnectionErrorHandler">connection error</xref> of typ
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. e
</t> <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
</section> </section>
</section> </section>
<section anchor="ErrorCodes"> <section anchor="ErrorCodes">
<name>Error Codes</name> <name>Error Codes</name>
<t> <t>Error codes are 32-bit fields that are used in <xref target="RST_STREAM
Error codes are 32-bit fields that are used in <xref target="RST_STREAM" " format="none">RST_STREAM</xref> and
format="none">RST_STREAM</xref> and <xref target="GOAWAY" format="none">GOAWAY</xref> frames to convey the r
<xref target="GOAWAY" format="none">GOAWAY</xref> frames to convey the r easons for the stream or connection error.</t>
easons for the stream or connection error. <t>Error codes share a common code space. Some error codes apply only to
</t> either streams or the
<t> entire connection and have no defined semantics in the other context.</t
Error codes share a common code space. Some error codes apply only to e >
ither streams or the <t>The following error codes are defined:</t>
entire connection and have no defined semantics in the other context.
</t>
<t>
The following error codes are defined:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>NO_ERROR (0x0):</dt> <dt>NO_ERROR (0x00):</dt>
<dd anchor="NO_ERROR"> <dd anchor="NO_ERROR">The associated condition is not a result of an err
The associated condition is not a result of an error. For example, or. For example, a
a
<xref target="GOAWAY" format="none">GOAWAY</xref> might include this code to indicate graceful shutdown of a <xref target="GOAWAY" format="none">GOAWAY</xref> might include this code to indicate graceful shutdown of a
connection. connection.</dd>
</dd> <dt>PROTOCOL_ERROR (0x01):</dt>
<dt>PROTOCOL_ERROR (0x1):</dt> <dd anchor="PROTOCOL_ERROR">The endpoint detected an unspecific protocol
<dd anchor="PROTOCOL_ERROR"> error. This error is for use when a more
The endpoint detected an unspecific protocol error. This error is f specific error code is not available.</dd>
or use when a more <dt>INTERNAL_ERROR (0x02):</dt>
specific error code is not available. <dd anchor="INTERNAL_ERROR">The endpoint encountered an unexpected inter
</dd> nal error.</dd>
<dt>INTERNAL_ERROR (0x2):</dt> <dt>FLOW_CONTROL_ERROR (0x03):</dt>
<dd anchor="INTERNAL_ERROR"> <dd anchor="FLOW_CONTROL_ERROR">The endpoint detected that its peer viol
The endpoint encountered an unexpected internal error. ated the flow-control protocol.</dd>
</dd> <dt>SETTINGS_TIMEOUT (0x04):</dt>
<dt>FLOW_CONTROL_ERROR (0x3):</dt> <dd anchor="SETTINGS_TIMEOUT">The endpoint sent a <xref target="SETTINGS
<dd anchor="FLOW_CONTROL_ERROR"> " format="none">SETTINGS</xref> frame but did not receive a response in a
The endpoint detected that its peer violated the flow-control protoc timely manner. See <xref target="SettingsSync"/> ("Settings Synchro
ol. nization").</dd>
</dd> <dt>STREAM_CLOSED (0x05):</dt>
<dt>SETTINGS_TIMEOUT (0x4):</dt> <dd anchor="STREAM_CLOSED">The endpoint received a frame after a stream
<dd anchor="SETTINGS_TIMEOUT"> was half-closed.</dd>
The endpoint sent a <xref target="SETTINGS" format="none">SETTINGS</ <dt>FRAME_SIZE_ERROR (0x06):</dt>
xref> frame but did not receive a response in a <dd anchor="FRAME_SIZE_ERROR">The endpoint received a frame with an inva
timely manner. See <xref target="SettingsSync"/> ("Settings Synchro lid size.</dd>
nization"). <dt>REFUSED_STREAM (0x07):</dt>
</dd> <dd anchor="REFUSED_STREAM">The endpoint refused the stream prior to per
<dt>STREAM_CLOSED (0x5):</dt> forming any application processing (see
<dd anchor="STREAM_CLOSED"> <xref target="Reliability"/> for details).</dd>
The endpoint received a frame after a stream was half-closed. <dt>CANCEL (0x08):</dt>
</dd> <dd anchor="CANCEL">The endpoint uses this error code to indicate that t
<dt>FRAME_SIZE_ERROR (0x6):</dt> he stream is no longer needed.</dd>
<dd anchor="FRAME_SIZE_ERROR"> <dt>COMPRESSION_ERROR (0x09):</dt>
The endpoint received a frame with an invalid size. <dd anchor="COMPRESSION_ERROR">The endpoint is unable to maintain the fi
</dd> eld section compression context for the
<dt>REFUSED_STREAM (0x7):</dt> connection.</dd>
<dd anchor="REFUSED_STREAM"> <dt>CONNECT_ERROR (0x0a):</dt>
The endpoint refused the stream prior to performing any application <dd anchor="CONNECT_ERROR">The connection established in response to a <
processing (see xref target="CONNECT">CONNECT
<xref target="Reliability"/> for details). request</xref> was reset or abnormally closed.</dd>
</dd> <dt>ENHANCE_YOUR_CALM (0x0b):</dt>
<dt>CANCEL (0x8):</dt> <dd anchor="ENHANCE_YOUR_CALM">The endpoint detected that its peer is ex
<dd anchor="CANCEL"> hibiting a behavior that might be generating
Used by the endpoint to indicate that the stream is no longer needed excessive load.</dd>
. <dt>INADEQUATE_SECURITY (0x0c):</dt>
</dd> <dd anchor="INADEQUATE_SECURITY">The underlying transport has properties
<dt>COMPRESSION_ERROR (0x9):</dt> that do not meet minimum security
<dd anchor="COMPRESSION_ERROR"> requirements (see <xref target="TLSUsage"/>).</dd>
The endpoint is unable to maintain the field section compression con <dt>HTTP_1_1_REQUIRED (0x0d):</dt>
text for the <dd anchor="HTTP_1_1_REQUIRED">The endpoint requires that HTTP/1.1 be us
connection. ed instead of HTTP/2.</dd>
</dd>
<dt>CONNECT_ERROR (0xa):</dt>
<dd anchor="CONNECT_ERROR">
The connection established in response to a <xref target="CONNECT">C
ONNECT
request</xref> was reset or abnormally closed.
</dd>
<dt>ENHANCE_YOUR_CALM (0xb):</dt>
<dd anchor="ENHANCE_YOUR_CALM">
The endpoint detected that its peer is exhibiting a behavior that mi
ght be generating
excessive load.
</dd>
<dt>INADEQUATE_SECURITY (0xc):</dt>
<dd anchor="INADEQUATE_SECURITY">
The underlying transport has properties that do not meet minimum sec
urity
requirements (see <xref target="TLSUsage"/>).
</dd>
<dt>HTTP_1_1_REQUIRED (0xd):</dt>
<dd anchor="HTTP_1_1_REQUIRED">
The endpoint requires that HTTP/1.1 be used instead of HTTP/2.
</dd>
</dl> </dl>
<t> <t>Unknown or unsupported error codes <bcp14>MUST NOT</bcp14> trigger any
Unknown or unsupported error codes MUST NOT trigger any special behavior special behavior. These <bcp14>MAY</bcp14> be
. These MAY be treated by an implementation as being equivalent to <xref target="INTERN
treated by an implementation as being equivalent to <xref target="INTERN AL_ERROR" format="none">INTERNAL_ERROR</xref>.</t>
AL_ERROR" format="none">INTERNAL_ERROR</xref>.
</t>
</section> </section>
<section anchor="HttpLayer"> <section anchor="HttpLayer">
<name>Expressing HTTP Semantics in HTTP/2</name> <name>Expressing HTTP Semantics in HTTP/2</name>
<t> <t>HTTP/2 is an instantiation of the HTTP message abstraction (<xref targe
HTTP/2 is an instantiation of the HTTP message abstraction (<xref target t="RFC9110" section="6"/>).</t>
="HTTP"
section="6"/>).
</t>
<section anchor="HttpFraming"> <section anchor="HttpFraming">
<name>HTTP Message Framing</name> <name>HTTP Message Framing</name>
<t> <t>A client sends an HTTP request on a new stream, using a previously un
A client sends an HTTP request on a new stream, using a previously unu used <xref target="StreamIdentifiers">stream identifier</xref>. A server sends a
sed <xref n HTTP response on
target="StreamIdentifiers">stream identifier</xref>. A server sends an the same stream as the request.</t>
HTTP response on <t>An HTTP message (request or response) consists of:</t>
the same stream as the request.
</t>
<t>
An HTTP message (request or response) consists of:
</t>
<ol spacing="normal" type="1"> <ol spacing="normal" type="1">
<li> <li>one <xref target="HEADERS" format="none">HEADERS</xref> frame (fol
one <xref target="HEADERS" format="none">HEADERS</xref> frame (follo lowed by zero or
wed by zero or
more <xref target="CONTINUATION" format="none">CONTINUATION</xref> f rames) containing more <xref target="CONTINUATION" format="none">CONTINUATION</xref> f rames) containing
the header section (see <xref target="HTTP" section="6.3"/>), the header section (see <xref target="RFC9110" section="6.3"/>),</li
</li> >
<li> <li>zero or more <xref target="DATA" format="none">DATA</xref> frames
zero or more <xref target="DATA" format="none">DATA</xref> frames co containing the
ntaining the message content (see <xref target="RFC9110" section="6.4"/>), and</l
message content (see <xref target="HTTP" section="6.4"/>), and i>
</li> <li>optionally, one <xref target="HEADERS" format="none">HEADERS</xref
<li> > frame (followed by
optionally, one <xref target="HEADERS" format="none">HEADERS</xref>
frame (followed by
zero or more <xref target="CONTINUATION" format="none">CONTINUATION< /xref> frames) zero or more <xref target="CONTINUATION" format="none">CONTINUATION< /xref> frames)
containing the trailer section, if present (see <xref target="HTTP" containing the trailer section, if present (see <xref target="RFC911
section="6.5"/>). 0" section="6.5"/>).</li>
</li>
</ol> </ol>
<t> <t>For a response only, a server <bcp14>MAY</bcp14> send any number of i
For a response only, a server MAY send any number of interim responses nterim responses before the <xref target="HEADERS" format="none">HEADERS</xref>
before the <xref frame containing a final response. An
target="HEADERS" format="none">HEADERS</xref> frame containing a final
response. An
interim response consists of a <xref target="HEADERS" format="none">HE ADERS</xref> frame interim response consists of a <xref target="HEADERS" format="none">HE ADERS</xref> frame
(which might be followed by zero or more <xref target="CONTINUATION" (which might be followed by zero or more <xref target="CONTINUATION" f
format="none">CONTINUATION</xref> frames) containing the control data ormat="none">CONTINUATION</xref> frames) containing the control data and header
and header section section
of an interim (1xx) HTTP response (see <xref target="HTTP" section="15 of an interim (1xx) HTTP response (see <xref target="RFC9110" section=
"/>). A <xref "15"/>). A <xref target="HEADERS" format="none">HEADERS</xref> frame with the EN
target="HEADERS" format="none">HEADERS</xref> frame with the END_STREA D_STREAM flag set that carries
M flag set that carries an informational status code is <xref target="malformed">malformed</xr
an informational status code is <xref target="malformed">malformed</xr ef>.</t>
ef>. <t>The last frame in the sequence bears an END_STREAM flag, noting that
</t> a <xref target="HEADERS" format="none">HEADERS</xref> frame with the END_STREAM
<t> flag set can be
The last frame in the sequence bears an END_STREAM flag, noting that a
<xref
target="HEADERS" format="none">HEADERS</xref> frame with the END_STREA
M flag set can be
followed by <xref target="CONTINUATION" format="none">CONTINUATION</xr ef> frames that followed by <xref target="CONTINUATION" format="none">CONTINUATION</xr ef> frames that
carry any remaining fragments of the field block. carry any remaining fragments of the field block.</t>
</t> <t>Other frames (from any stream) <bcp14>MUST NOT</bcp14> occur between
<t> the <xref target="HEADERS" format="none">HEADERS</xref> frame
Other frames (from any stream) MUST NOT occur between the <xref target and any <xref target="CONTINUATION" format="none">CONTINUATION</xref>
="HEADERS" format="none">HEADERS</xref> frame frames that might follow.</t>
and any <xref target="CONTINUATION" format="none">CONTINUATION</xref> <t>HTTP/2 uses DATA frames to carry message content. The <tt>chunked</t
frames that might follow. t> transfer encoding
</t> defined in <xref target="RFC9112" section="7.1"/> cannot be used in HT
<t> TP/2; see <xref target="ConnectionSpecific"/>.</t>
HTTP/2 uses DATA frames to carry message content. The <tt>chunked</tt <t>Trailer fields are carried in a field block that also terminates the
> transfer encoding stream. That is,
defined in <xref target="HTTP11" section="7.1"/> cannot be used in HTT trailer fields comprise a sequence starting with a <xref target="HEADE
P/2; see <xref RS" format="none">HEADERS</xref> frame, followed by zero or more <xref target="C
target="ConnectionSpecific"/>. ONTINUATION" format="none">CONTINUATION</xref> frames, where the <xref target="H
</t> EADERS" format="none">HEADERS</xref> frame bears an END_STREAM flag. Trailers <b
<t> cp14>MUST NOT</bcp14> include
Trailer fields are carried in a field block that also terminates the s
tream. That is,
trailer fields comprise a sequence starting with a <xref target="HEADE
RS"
format="none">HEADERS</xref> frame, followed by zero or more <xref tar
get="CONTINUATION"
format="none">CONTINUATION</xref> frames, where the <xref target="HEAD
ERS"
format="none">HEADERS</xref> frame bears an END_STREAM flag. Trailers
MUST NOT include
<xref target="PseudoHeaderFields">pseudo-header fields</xref>. An endp oint that receives <xref target="PseudoHeaderFields">pseudo-header fields</xref>. An endp oint that receives
pseudo-header fields in trailers MUST treat the request or response as pseudo-header fields in trailers <bcp14>MUST</bcp14> treat the request
<xref or response as <xref target="malformed">malformed</xref>.</t>
target="malformed">malformed</xref>. <t>An endpoint that receives a <xref target="HEADERS" format="none">HEAD
</t> ERS</xref> frame
<t> without the END_STREAM flag set after receiving the <xref target="HEAD
An endpoint that receives a <xref target="HEADERS" format="none">HEADE ERS" format="none">HEADERS</xref> frame that opens a request or after receiving
RS</xref> frame a final
without the END_STREAM flag set after receiving the <xref target="HEAD (non-informational) status code <bcp14>MUST</bcp14> treat the correspo
ERS" nding request or response as <xref target="malformed">malformed</xref>.</t>
format="none">HEADERS</xref> frame that opens a request or after recei <t>An HTTP request/response exchange fully consumes a single stream. A r
ving a final equest starts with
(non-informational) status code MUST treat the corresponding request o
r response as <xref
target="malformed">malformed</xref>.
</t>
<t>
An HTTP request/response exchange fully consumes a single stream. A re
quest starts with
the <xref target="HEADERS" format="none">HEADERS</xref> frame that put s the stream into the <xref target="HEADERS" format="none">HEADERS</xref> frame that put s the stream into
the "open" state. The request ends with a frame with the END_STREAM fl ag set, which causes the the "open" state. The request ends with a frame with the END_STREAM fl ag set, which causes the
stream to become "half-closed (local)" for the client and "half-closed (remote)" for the stream to become "half-closed (local)" for the client and "half-closed (remote)" for the
server. A response stream starts with zero or more interim responses i server. A response stream starts with zero or more interim responses i
n <xref n <xref target="HEADERS" format="none">HEADERS</xref> frames, followed by a <xre
target="HEADERS" format="none">HEADERS</xref> frames, followed by a <x f target="HEADERS" format="none">HEADERS</xref> frame containing a final status
ref target="HEADERS" code.</t>
format="none">HEADERS</xref> frame containing a final status code. <t>An HTTP response is complete after the server sends -- or the client
</t> receives -- a frame
<t> with the END_STREAM flag set (including any <xref target="CONTINUATION
An HTTP response is complete after the server sends -- or the client r " format="none">CONTINUATION</xref> frames needed to complete a field block). A
eceives -- a frame server can
with the END_STREAM flag set (including any <xref target="CONTINUATION
"
format="none">CONTINUATION</xref> frames needed to complete a field bl
ock). A server can
send a complete response prior to the client sending an entire request if the response send a complete response prior to the client sending an entire request if the response
does not depend on any portion of the request that has not been sent a nd received. When does not depend on any portion of the request that has not been sent a nd received. When
this is true, a server MAY request that the client abort transmission of a request this is true, a server <bcp14>MAY</bcp14> request that the client abor t transmission of a request
without error by sending a <xref target="RST_STREAM" format="none">RST _STREAM</xref> with without error by sending a <xref target="RST_STREAM" format="none">RST _STREAM</xref> with
an error code of <xref target="NO_ERROR" format="none">NO_ERROR</xref> after sending a an error code of <xref target="NO_ERROR" format="none">NO_ERROR</xref> after sending a
complete response (i.e., a frame with the END_STREAM flag set). Client complete response (i.e., a frame with the END_STREAM flag set). Client
s MUST NOT discard s <bcp14>MUST NOT</bcp14> discard
responses as a result of receiving such a <xref target="RST_STREAM" responses as a result of receiving such a <xref target="RST_STREAM" fo
format="none">RST_STREAM</xref>, though clients can always discard res rmat="none">RST_STREAM</xref>, though clients can always discard responses at th
ponses at their eir
discretion for other reasons. discretion for other reasons.</t>
</t>
<section anchor="malformed"> <section anchor="malformed">
<name>Malformed Messages</name> <name>Malformed Messages</name>
<t> <t>A malformed request or response is one that is an otherwise valid s
A malformed request or response is one that is an otherwise valid se equence of HTTP/2
quence of HTTP/2
frames but is invalid due to the presence of extraneous frames, proh ibited fields or frames but is invalid due to the presence of extraneous frames, proh ibited fields or
pseudo-header fields, the absence of mandatory pseudo-header fields, the inclusion of pseudo-header fields, the absence of mandatory pseudo-header fields, the inclusion of
uppercase field names, or invalid field names and/or values (in cert ain circumstances; uppercase field names, or invalid field names and/or values (in cert ain circumstances;
see <xref target="HttpHeaders"/>). see <xref target="HttpHeaders"/>).</t>
</t> <t>A request or response that includes message content can include a
<t>
A request or response that includes message content can include a
<tt>content-length</tt> header field. A request or response is also malformed if the <tt>content-length</tt> header field. A request or response is also malformed if the
value of a <tt>content-length</tt> header field does not equal the s value of a <tt>content-length</tt> header field does not equal the s
um of the <xref um of the <xref target="DATA" format="none">DATA</xref> frame payload lengths th
target="DATA" format="none">DATA</xref> frame payload lengths that f at form the content,
orm the content,
unless the message is defined as having no content. For example, 20 4 or 304 responses unless the message is defined as having no content. For example, 20 4 or 304 responses
contain no content, as does the response to a HEAD request. A respo nse that is defined contain no content, as does the response to a HEAD request. A respo nse that is defined
to have no content, as described in <xref target="HTTP" section="6.4 .1"/>, MAY have a to have no content, as described in <xref target="RFC9110" section=" 6.4.1"/>, <bcp14>MAY</bcp14> have a
non-zero <tt>content-length</tt> header field, even though no conten t is included in non-zero <tt>content-length</tt> header field, even though no conten t is included in
<xref target="DATA" format="none">DATA</xref> frames. <xref target="DATA" format="none">DATA</xref> frames.</t>
</t> <t>Intermediaries that process HTTP requests or responses (i.e., any i
<t> ntermediary not
Intermediaries that process HTTP requests or responses (i.e., any in acting as a tunnel) <bcp14>MUST NOT</bcp14> forward a malformed requ
termediary not est or response. Malformed
acting as a tunnel) MUST NOT forward a malformed request or response requests or responses that are detected <bcp14>MUST</bcp14> be treat
. Malformed ed as a <xref target="StreamErrorHandler">stream error</xref> of type <xref targ
requests or responses that are detected MUST be treated as a <xref et="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
target="StreamErrorHandler">stream error</xref> of type <xref target <t>For malformed requests, a server <bcp14>MAY</bcp14> send an HTTP re
="PROTOCOL_ERROR" sponse prior to closing or
format="none">PROTOCOL_ERROR</xref>. resetting the stream. Clients <bcp14>MUST NOT</bcp14> accept a malf
</t> ormed response.</t>
<t> <t>Endpoints that progressively process messages might have performed
For malformed requests, a server MAY send an HTTP response prior to some processing
closing or
resetting the stream. Clients MUST NOT accept a malformed response.
</t>
<t>
Endpoints that progressively process messages might have performed s
ome processing
before identifying a request or response as malformed. For instance, it might be before identifying a request or response as malformed. For instance, it might be
possible to generate an informational or 404 status code without hav ing received a possible to generate an informational or 404 status code without hav ing received a
complete request. Similarly, intermediaries might forward incomplete messages before complete request. Similarly, intermediaries might forward incomplete messages before
detecting errors. A server MAY generate a final response before rece iving an entire detecting errors. A server <bcp14>MAY</bcp14> generate a final respo nse before receiving an entire
request when the response does not depend on the remainder of the re quest being request when the response does not depend on the remainder of the re quest being
correct. correct.</t>
</t> <t>These requirements are intended to protect against several types of
<t> common attacks
These requirements are intended to protect against several types of
common attacks
against HTTP; they are deliberately strict because being permissive can expose against HTTP; they are deliberately strict because being permissive can expose
implementations to these vulnerabilities. implementations to these vulnerabilities.</t>
</t>
</section> </section>
</section> </section>
<section anchor="HttpHeaders"> <section anchor="HttpHeaders">
<name>HTTP Fields</name> <name>HTTP Fields</name>
<t> <t>HTTP fields (<xref target="RFC9110" section="5"/>) are conveyed by HT
HTTP fields (<xref target="HTTP" section="5"/>) are conveyed by HTTP/2 TP/2 in the HEADERS,
in the HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with <xref target="R
CONTINUATION, and PUSH_PROMISE frames, compressed with <xref target="C FC7541">HPACK</xref>.</t>
OMPRESSION">HPACK</xref>. <t>Field names <bcp14>MUST</bcp14> be converted to lowercase when constr
</t> ucting an HTTP/2 message.</t>
<t>
Field names MUST be converted to lowercase when constructing an HTTP/2
message.
</t>
<section> <section>
<name>Field Validity</name> <name>Field Validity</name>
<t> <t>The definitions of field names and values in HTTP prohibit some cha
The definitions of field names and values in HTTP prohibit some char racters that HPACK
acters that HPACK might be able to convey. HTTP/2 implementations <bcp14>SHOULD</bcp1
might be able to convey. HTTP/2 implementations SHOULD validate fie 4> validate field names and values
ld names and values according to their definitions in Sections <xref target="RFC9110" se
according to their definitions in Sections <xref target="HTTP" secti ction="5.1" sectionFormat="bare"/> and <xref target="RFC9110" section="5.5" sect
on="5.1" ionFormat="bare"/> of <xref target="RFC9110"/>, respectively, and treat messages
sectionFormat="bare"/> and <xref target="HTTP" section="5.5" section that contain prohibited characters as
Format="bare"/> of <xref <xref target="malformed">malformed</xref>.</t>
target="HTTP"/> respectively and treat messages that contain prohibi <t>Failure to validate fields can be exploited for request smuggling a
ted characters as ttacks. In
<xref target="malformed">malformed</xref>.
</t>
<t>
Failure to validate fields can be exploited for request smuggling at
tacks. In
particular, unvalidated fields might enable attacks when messages ar e forwarded using particular, unvalidated fields might enable attacks when messages ar e forwarded using
<xref target="HTTP11">HTTP 1.1</xref>, where characters such as CR, <xref target="RFC9112">HTTP/1.1</xref>, where characters such as car
LF, and COLON are riage return (CR), line feed (LF), and COLON are
used as delimiters. Implementations MUST perform the following mini used as delimiters. Implementations <bcp14>MUST</bcp14> perform the
mal validation of following minimal validation of
field names and values: field names and values:</t>
</t>
<ul> <ul>
<li> <li>A field name <bcp14>MUST NOT</bcp14> contain characters in the r
A field name MUST NOT contain characters in the ranges 0x00-0x20, anges 0x00-0x20, 0x41-0x5a, or
0x41-0x5a, or
0x7f-0xff (all ranges inclusive). This specifically excludes all non-visible ASCII 0x7f-0xff (all ranges inclusive). This specifically excludes all non-visible ASCII
characters, ASCII SP (0x20), and uppercase characters ('A' to 'Z', ASCII 0x41 to characters, ASCII SP (0x20), and uppercase characters ('A' to 'Z', ASCII 0x41 to
0x5a). 0x5a).</li>
</li> <li>With the exception of <xref target="PseudoHeaderFields">pseudo-h
<li> eader fields</xref>,
With the exception of <xref target="PseudoHeaderFields">pseudo-hea which have a name that starts with a single colon, field names <bc
der fields</xref>, p14>MUST NOT</bcp14> include a
which have a name that starts with a single colon, field names MUS colon (ASCII COLON, 0x3a).</li>
T NOT include a <li>A field value <bcp14>MUST NOT</bcp14> contain the zero value (AS
colon (ASCII COLON, 0x3a). CII NUL, 0x00), line feed (ASCII LF,
</li> 0x0a), or carriage return (ASCII CR, 0x0d) at any position.</li>
<li> <li>A field value <bcp14>MUST NOT</bcp14> start or end with an ASCII
A field value MUST NOT contain the zero value (ASCII NUL, 0x0), li whitespace character (ASCII SP or
ne feed (ASCII LF, HTAB, 0x20 or 0x09).</li>
0xa), or carriage return (ASCII CR, 0xd) at any position.
</li>
<li>
A field value MUST NOT start or end with an ASCII whitespace chara
cter (ASCII SP or
HTAB, 0x20 or 0x9).
</li>
</ul> </ul>
<aside> <aside>
<t> <t>Note: An implementation that validates fields according to the de
Note: An implementation that validates fields according the definiti finitions in Sections
ons in Sections <xref target="RFC9110" section="5.1" sectionFormat="bare"/> and <xre
<xref target="HTTP" section="5.1" sectionFormat="bare"/> and <xref t f target="RFC9110" section="5.5" sectionFormat="bare"/> of <xref target="RFC9110
arget="HTTP" "/> only needs an additional check
section="5.5" sectionFormat="bare"/> of <xref target="HTTP"/> only n that field names do not include uppercase characters.</t>
eeds an additional check </aside>
that field names do not include uppercase characters. <t>A request or response that contains a field that violates any of th
</t> ese conditions <bcp14>MUST</bcp14>
</aside>
<t>
A request or response that contains a field that violates any of the
se conditions MUST
be treated as <xref target="malformed">malformed</xref>. In particu lar, an intermediary be treated as <xref target="malformed">malformed</xref>. In particu lar, an intermediary
that does not process fields when forwarding messages MUST NOT forwa that does not process fields when forwarding messages <bcp14>MUST NO
rd fields that T</bcp14> forward fields that
contain any of the values that are listed as prohibited above. contain any of the values that are listed as prohibited above.</t>
</t> <t>When a request message violates one of these requirements, an imple
<t> mentation <bcp14>SHOULD</bcp14>
When a request message violates one of these requirements, an implem generate a 400 (Bad Request) status code (see <xref target="RFC9110"
entation SHOULD section="15.5.1"/>),
generate a 400 (Bad Request) status code (see <xref target="HTTP" se
ction="15.5.1"/>),
unless a more suitable status code is defined or the status code can not be sent (e.g., unless a more suitable status code is defined or the status code can not be sent (e.g.,
because the error occurs in a trailer field). because the error occurs in a trailer field).</t>
</t>
<aside> <aside>
<t> <t>Note: Field values that are not valid according to the definition
Note: Field values that are not valid according to the definition of the corresponding
of the corresponding field do not cause a request to be <xref target="malformed" format
field do not cause a request to be <xref target="malformed" ="none">malformed</xref>; the requirements above only apply to the generic
format="none">malformed</xref>; the requirements above only apply syntax for fields as defined in <xref target="RFC9110" section="5"
to the generic />.</t>
syntax for fields as defined in <xref target="HTTP" section="5"/>.
</t>
</aside> </aside>
</section> </section>
<section anchor="ConnectionSpecific"> <section anchor="ConnectionSpecific">
<name>Connection-Specific Header Fields</name> <name>Connection-Specific Header Fields</name>
<t> <t>HTTP/2 does not use the <tt>Connection</tt> header field (<xref tar
HTTP/2 does not use the <tt>Connection</tt> header field (<xref targ get="RFC9110" section="7.6.1"/>) to indicate connection-specific header fields;
et="HTTP" in this protocol,
section="7.6.1"/>) to indicate connection-specific header fields; in connection-specific metadata is conveyed by other means. An endpoin
this protocol, t <bcp14>MUST NOT</bcp14> generate
connection-specific metadata is conveyed by other means. An endpoin
t MUST NOT generate
an HTTP/2 message containing connection-specific header fields. Thi s includes the an HTTP/2 message containing connection-specific header fields. Thi s includes the
<tt>Connection</tt> header field and those listed as having connecti on-specific <tt>Connection</tt> header field and those listed as having connecti on-specific
semantics in <xref target="HTTP" section="7.6.1"/> (that is, <tt>Pro xy-Connection</tt>, semantics in <xref target="RFC9110" section="7.6.1"/> (that is, <tt> Proxy-Connection</tt>,
<tt>Keep-Alive</tt>, <tt>Transfer-Encoding</tt>, and <tt>Upgrade</tt >). Any message <tt>Keep-Alive</tt>, <tt>Transfer-Encoding</tt>, and <tt>Upgrade</tt >). Any message
containing connection-specific header fields MUST be treated as <xre containing connection-specific header fields <bcp14>MUST</bcp14> be
f treated as <xref target="malformed">malformed</xref>.</t>
target="malformed">malformed</xref>. <t>The only exception to this is the TE header field, which <bcp14>MAY
</t> </bcp14> be present in an HTTP/2
<t> request; when it is, it <bcp14>MUST NOT</bcp14> contain any value ot
The only exception to this is the TE header field, which MAY be pres her than "trailers".</t>
ent in an HTTP/2 <t>An intermediary transforming an HTTP/1.x message to HTTP/2 <bcp14>M
request; when it is, it MUST NOT contain any value other than "trail UST</bcp14> remove connection-specific
ers". header fields as discussed in <xref target="RFC9110" section="7.6.1"
</t> />,
<t> or their messages will be treated by other HTTP/2 endpoints as <xref
An intermediary transforming an HTTP/1.x message to HTTP/2 MUST remo target="malformed">malformed</xref>.</t>
ve connection-specific
header fields as discussed in <xref target="HTTP" section="7.6.1"/>,
or their messages will be treated by other HTTP/2 endpoints as <xref
target="malformed">malformed</xref>.
</t>
<aside> <aside>
<t>Note: <t>Note:
HTTP/2 purposefully does not support upgrade to another protocol. The handshake HTTP/2 purposefully does not support upgrade to another protocol. The handshake
methods described in <xref target="starting"/> are believed suffic ient to methods described in <xref target="starting"/> are believed suffic ient to
negotiate the use of alternative protocols. negotiate the use of alternative protocols.</t>
</t>
</aside> </aside>
</section> </section>
<section anchor="CompressCookie"> <section anchor="CompressCookie">
<name>Compressing the Cookie Header Field</name> <name>Compressing the Cookie Header Field</name>
<t> <t>The <xref target="RFC6265">Cookie header field</xref> uses a semico
The <xref target="COOKIE">Cookie header field</xref> uses a semicolo lon (";") to delimit
n (";") to cookie-pairs (or "crumbs"). This header field contains multiple val
delimit cookie-pairs (or "crumbs"). This header field contains mult ues, but does not use
iple values, but a COMMA (",") as a separator, thereby preventing cookie-pairs from b
does not use a COMMA (",") as a separator, which prevents cookie-pai eing sent on
rs from being sent multiple field lines (see <xref target="RFC9110" section="5.2"/>).
on multiple field lines (see <xref target="HTTP" section="5.2"/>). This can significantly
This can reduce compression efficiency, as updates to individual cookie-pairs
significantly reduce compression efficiency as updates to individual would invalidate any
cookie-pairs field lines that are stored in the HPACK table.</t>
would invalidate any field lines that are stored in the HPACK table. <t>To allow for better compression efficiency, the Cookie header field
</t> <bcp14>MAY</bcp14> be split into
<t>
To allow for better compression efficiency, the Cookie header field
MAY be split into
separate header fields, each with one or more cookie-pairs. If ther e are multiple separate header fields, each with one or more cookie-pairs. If ther e are multiple
Cookie header fields after decompression, these MUST be concatenated into a single Cookie header fields after decompression, these <bcp14>MUST</bcp14> be concatenated into a single
octet string using the two-octet delimiter of 0x3b, 0x20 (the ASCII string "; ") octet string using the two-octet delimiter of 0x3b, 0x20 (the ASCII string "; ")
before being passed into a non-HTTP/2 context, such as an HTTP/1.1 c onnection, or a before being passed into a non-HTTP/2 context, such as an HTTP/1.1 c onnection, or a
generic HTTP server application. generic HTTP server application.</t>
</t> <t keepWithNext="true">Therefore, the following two lists of Cookie he
<t keepWithNext="true"> ader fields are semantically
Therefore, the following two lists of Cookie header fields are sem equivalent.</t>
antically
equivalent.
</t>
<artwork type="inline"><![CDATA[ <artwork type="inline"><![CDATA[
cookie: a=b; c=d; e=f cookie: a=b; c=d; e=f
cookie: a=b cookie: a=b
cookie: c=d cookie: c=d
cookie: e=f cookie: e=f
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
<section anchor="PseudoHeaderFields"> <section anchor="PseudoHeaderFields">
<name>HTTP Control Data</name> <name>HTTP Control Data</name>
<t> <t>HTTP/2 uses special pseudo-header fields beginning with a ':' charact
HTTP/2 uses special pseudo-header fields beginning with ':' character er (ASCII 0x3a) to
(ASCII 0x3a) to convey message control data (see <xref target="RFC9110" section="6.2"/
convey message control data (see <xref target="HTTP" section="6.2"/>). >).</t>
</t> <t>Pseudo-header fields are not HTTP header fields. Endpoints <bcp14>MU
<t> ST NOT</bcp14> generate
Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT g
enerate
pseudo-header fields other than those defined in this document. Note that an pseudo-header fields other than those defined in this document. Note that an
extension could negotiate the use of additional pseudo-header fields; see extension could negotiate the use of additional pseudo-header fields; see
<xref target="extensibility"/>. <xref target="extensibility"/>.</t>
</t> <t>Pseudo-header fields are only valid in the context in which they are
<t> defined.
Pseudo-header fields are only valid in the context in which they are d Pseudo-header fields defined for requests <bcp14>MUST NOT</bcp14> appe
efined. ar in responses; pseudo-header
Pseudo-header fields defined for requests MUST NOT appear in responses fields defined for responses <bcp14>MUST NOT</bcp14> appear in request
; pseudo-header s. Pseudo-header fields <bcp14>MUST
fields defined for responses MUST NOT appear in requests. Pseudo-head NOT</bcp14> appear in a trailer section. Endpoints <bcp14>MUST</bcp14
er fields MUST > treat a request or response that contains
NOT appear in a trailer section. Endpoints MUST treat a request or re undefined or invalid pseudo-header fields as <xref target="malformed">
sponse that contains malformed</xref>.</t>
undefined or invalid pseudo-header fields as <xref target="malformed"> <t>All pseudo-header fields <bcp14>MUST</bcp14> appear in a field block
malformed</xref>. before all regular field lines.
</t>
<t>
All pseudo-header fields MUST appear in a field block before all regul
ar field lines.
Any request or response that contains a pseudo-header field that appea rs in a field Any request or response that contains a pseudo-header field that appea rs in a field
block after a regular field line MUST be treated as <xref target="malf block after a regular field line <bcp14>MUST</bcp14> be treated as <xr
ormed">malformed</xref>. ef target="malformed">malformed</xref>.</t>
</t> <t>The same pseudo-header field name <bcp14>MUST NOT</bcp14> appear more
<t> than once in a field block. A
The same pseudo-header field name MUST NOT appear more than once in a
field block. A
field block for an HTTP request or response that contains a repeated p seudo-header field field block for an HTTP request or response that contains a repeated p seudo-header field
name MUST be treated as <xref target="malformed">malformed</xref>. name <bcp14>MUST</bcp14> be treated as <xref target="malformed">malfor
</t> med</xref>.</t>
<section anchor="HttpRequest"> <section anchor="HttpRequest">
<name>Request Pseudo-Header Fields</name> <name>Request Pseudo-Header Fields</name>
<t> <t>The following pseudo-header fields are defined for HTTP/2 requests:
The following pseudo-header fields are defined for HTTP/2 requests: </t>
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>
<t> <t>The "<tt>:method</tt>" pseudo-header field includes the HTTP
The <tt>:method</tt> pseudo-header field includes the HTTP method (<xref target="RFC9110" section="9"/>).</t>
method (<xref target="HTTP" section="9"/>).
</t>
</li> </li>
<li> <li>
<t> <t>The "<tt>:scheme</tt>" pseudo-header field includes the scheme
The <tt>:scheme</tt> pseudo-header field includes the scheme por portion of the request
tion of the request target. The scheme is taken from the target URI (<xref target="R
target. The scheme is taken from the target URI (<xref target="R FC3986" section="3.1"/>) when generating a request directly, or from the scheme
FC3986" of a
section="3.1"/>) when generating a request directly, or from the translated request (for example, see <xref target="RFC9112" sect
scheme of a ion="3.3"/>). Scheme
translated request (for example, see <xref target="HTTP11" secti is omitted for <xref target="CONNECT">CONNECT requests</xref>.</
on="3.3"/>). Scheme t>
is omitted for <xref target="CONNECT">CONNECT requests</xref>. <t>"<tt>:scheme</tt>" is not restricted to "<tt>http</tt>" and "<t
</t> t>https</tt>" schemed
<t><tt>:scheme</tt> is not restricted to <tt>http</tt> and <tt>htt
ps</tt> schemed
URIs. A proxy or gateway can translate requests for non-HTTP sc hemes, enabling URIs. A proxy or gateway can translate requests for non-HTTP sc hemes, enabling
the use of HTTP to interact with non-HTTP services. the use of HTTP to interact with non-HTTP services.</t>
</t>
</li> </li>
<li> <li>
<t> <t>The "<tt>:authority</tt>" pseudo-header field conveys the autho
The <tt>:authority</tt> pseudo-header field conveys the authorit rity portion (<xref target="RFC3986" section="3.2"/>) of the target URI (<xref t
y portion (<xref arget="RFC9110" section="7.1"/>). The recipient of an HTTP/2 request <bcp14>MUST
target="RFC3986" section="3.2"/>) of the target URI (<xref targe NOT</bcp14> use the <tt>Host</tt>
t="HTTP" header field to determine the target URI if "<tt>:authority</tt>
section="7.1"/>). The recipient of a HTTP/2 request MUST NOT use " is present.</t>
the <tt>Host</tt> <t>Clients that generate HTTP/2 requests directly <bcp14>MUST</bcp
header field to determine the target URI if <tt>:authority</tt> 14> use the "<tt>:authority</tt>"
is present.
</t>
<t>
Clients that generate HTTP/2 requests directly MUST use the <tt>
:authority</tt>
pseudo-header field to convey authority information, unless ther e is no authority pseudo-header field to convey authority information, unless ther e is no authority
information to convey (in which case it MUST NOT generate :autho information to convey (in which case it <bcp14>MUST NOT</bcp14>
rity). generate "<tt>:authority</tt>").</t>
</t> <t>Clients <bcp14>MUST NOT</bcp14> generate a request with a <tt>H
<t> ost</tt> header field that differs
Clients MUST NOT generate a request with a <tt>Host</tt> header from the "<tt>:authority</tt>" pseudo-header field. A
field that differs server <bcp14>SHOULD</bcp14> treat a request as malformed if it
from the <tt>:authority</tt> pseudo-header field. A contains a <tt>Host</tt> header
server SHOULD treat a request as malformed if it contains a <tt> field that identifies an entity that differs from the entity in
Host</tt> header the "<tt>:authority</tt>" pseudo-header
field that identifies a different entity to the <tt>:authority</ field. The values of fields need to be normalized to compare th
tt> pseudo-header em (see <xref target="RFC3986" section="6.2"/>). An origin server can apply any
field. The values of fields need to be normalized to compare th normalization
em (see <xref method, whereas other servers <bcp14>MUST</bcp14> perform scheme
target="RFC3986" section="6.2"/>). An origin server can apply a -based normalization (see <xref target="RFC3986" section="6.2.3"/>) of the two f
ny normalization ields.</t>
method, whereas other servers MUST perform scheme-based normaliz <t>An intermediary that forwards a request over HTTP/2 <bcp14>MUST
ation (see <xref </bcp14> construct an
target="RFC3986" section="6.2.3"/>) of the two fields. "<tt>:authority</tt>" pseudo-header field using the authority in
</t> formation from the
<t>
An intermediary that forwards a request over HTTP/2 MUST constru
ct an
<tt>:authority</tt> pseudo-header field using the authority info
rmation from the
control data of the original request, unless the original reques t's target URI control data of the original request, unless the original reques t's target URI
does not contain authority information (in which case it MUST NO does not contain authority information (in which case it <bcp14>
T generate MUST NOT</bcp14> generate
<tt>:authority</tt>). Note that the <tt>Host</tt> header field i "<tt>:authority</tt>"). Note that the <tt>Host</tt> header field
s not the sole is not the sole
source of this information; see <xref target="HTTP" section="7.2 source of this information; see <xref target="RFC9110" section="
"/>. 7.2"/>.</t>
</t> <t>An intermediary that needs to generate a <tt>Host</tt> header f
<t> ield (which might be
An intermediary that needs to generate a <tt>Host</tt> header fi necessary to construct an HTTP/1.1 request) <bcp14>MUST</bcp14>
eld (which might be use the value from the "<tt>:authority</tt>"
necessary to construct an HTTP/1.1 request) MUST use the value f
rom the <tt>:authority</tt>
pseudo-header field as the value of the <tt>Host</tt> field, pseudo-header field as the value of the <tt>Host</tt> field,
unless the intermediary also changes the request target. This re places any existing unless the intermediary also changes the request target. This re places any existing
<tt>Host</tt> field to avoid potential vulnerabilities in HTTP r <tt>Host</tt> field to avoid potential vulnerabilities in HTTP r
outing. outing.</t>
</t> <t>An intermediary that forwards a request over HTTP/2 <bcp14>MAY<
<t> /bcp14> retain any <tt>Host</tt>
An intermediary that forwards a request over HTTP/2 MAY retain a header field.</t>
ny <tt>Host</tt> <t>Note that request targets for CONNECT or asterisk-form OPTIONS
header field. requests never
</t> include authority information; see Sections <xref target="RFC911
<t> 0" section="7.1" sectionFormat="bare"/> and <xref target="RFC9110" section="7.2"
Note that request targets for CONNECT or asterisk-form OPTIONS r sectionFormat="bare"/>
equests never of <xref target="RFC9110"/>.</t>
include authority information; see <xref target="HTTP" section=" <t>"<tt>:authority</tt>" <bcp14>MUST NOT</bcp14> include the depre
7.1"/>. cated userinfo subcomponent for
</t> "<tt>http</tt>" or "<tt>https</tt>" schemed URIs.</t>
<t>
<tt>:authority</tt> MUST NOT include the deprecated userinfo sub
component for
<tt>http</tt> or <tt>https</tt> schemed URIs.
</t>
</li> </li>
<li> <li>
<t> <t>The "<tt>:path</tt>" pseudo-header field includes the path and
The <tt>:path</tt> pseudo-header field includes the path and
query parts of the target URI (the <tt>absolute-path</tt> query parts of the target URI (the <tt>absolute-path</tt>
production and optionally a '?' character followed by the production and, optionally, a '?' character followed by the
<tt>query</tt> production; see <xref target="HTTP" section="4. <tt>query</tt> production; see <xref target="RFC9110" section=
1"/>). "4.1"/>).
A request in asterisk form (for OPTIONS) includes the value '* ' for the A request in asterisk form (for OPTIONS) includes the value '* ' for the
<tt>:path</tt> pseudo-header field. "<tt>:path</tt>" pseudo-header field.</t>
</t> <t>This pseudo-header field <bcp14>MUST NOT</bcp14> be empty for "
<t> <tt>http</tt>" or "<tt>https</tt>"
This pseudo-header field MUST NOT be empty for <tt>http</tt> o URIs; "<tt>http</tt>" or "<tt>https</tt>" URIs that do not con
r <tt>https</tt> tain a path component
URIs; <tt>http</tt> or <tt>https</tt> URIs that do not contain <bcp14>MUST</bcp14> include a value of '/'. The exceptions to
a path component this rule are:</t>
MUST include a value of '/'. The exceptions to this rule are:
</t>
<ul> <ul>
<li> <li>an OPTIONS request for an "<tt>http</tt>" or "<tt>https</tt>
an OPTIONS request for an <tt>http</tt> or <tt>https</tt> URI " URI that does not include a path
that does not include a path component; these <bcp14>MUST</bcp14> include a "<tt>:path</tt>
component; these MUST include a <tt>:path</tt> pseudo-header f " pseudo-header field with a value
ield with a value of '*' (see <xref target="RFC9110" section="7.1"/>).</li>
of '*' (see <xref target="HTTP" section="7.1"/>) <li><xref target="CONNECT">CONNECT requests</xref>, where the "<
</li> tt>:path</tt>" pseudo-header field is omitted.</li>
<li>
<xref target="CONNECT">CONNECT requests</xref>, where the <tt>
:path</tt> pseudo-header field is omitted.
</li>
</ul> </ul>
</li> </li>
</ul> </ul>
<t> <t>All HTTP/2 requests <bcp14>MUST</bcp14> include exactly one valid v
All HTTP/2 requests MUST include exactly one valid value for the <tt alue for the "<tt>:method</tt>",
>:method</tt>, "<tt>:scheme</tt>", and "<tt>:path</tt>" pseudo-header fields, unles
<tt>:scheme</tt>, and <tt>:path</tt> pseudo-header fields, unless it s they are <xref target="CONNECT">CONNECT requests</xref>. An HTTP request that
is a <xref omits mandatory
target="CONNECT">CONNECT request</xref>. An HTTP request that omits pseudo-header fields is <xref target="malformed">malformed</xref>.</
mandatory t>
pseudo-header fields is <xref target="malformed">malformed</xref>. <t>Individual HTTP/2 requests do not carry an explicit indicator of pr
</t> otocol version.
<t>
Individual HTTP/2 requests do not carry an explicit indicator of pro
tocol version.
All HTTP/2 requests implicitly have a protocol version of "2.0" (see All HTTP/2 requests implicitly have a protocol version of "2.0" (see
<xref target="HTTP" section="6.2"/>). <xref target="RFC9110" section="6.2"/>).</t>
</t>
</section> </section>
<section anchor="HttpResponse"> <section anchor="HttpResponse">
<name>Response Pseudo-Header Fields</name> <name>Response Pseudo-Header Fields</name>
<t> <t>For HTTP/2 responses, a single "<tt>:status</tt>" pseudo-header
For HTTP/2 responses, a single <tt>:status</tt> pseudo-header
field is defined that carries the HTTP status code field (see field is defined that carries the HTTP status code field (see
<xref target="HTTP" section="15"/>). This pseudo-header field MUST b e included in all <xref target="RFC9110" section="15"/>). This pseudo-header field <bc p14>MUST</bcp14> be included in all
responses, including interim responses; otherwise, the response is responses, including interim responses; otherwise, the response is
<xref target="malformed">malformed</xref>. <xref target="malformed">malformed</xref>.</t>
</t> <t>HTTP/2 responses implicitly have a protocol version of "2.0".</t>
<t>
HTTP/2 responses implicitly have a protocol version of "2.0".
</t>
</section> </section>
</section> </section>
<section anchor="PushResources"> <section anchor="PushResources">
<name>Server Push</name> <name>Server Push</name>
<t> <t>HTTP/2 allows a server to preemptively send (or "push") responses (al
HTTP/2 allows a server to preemptively send (or "push") responses (alo ong with
ng with
corresponding "promised" requests) to a client in association with a p revious corresponding "promised" requests) to a client in association with a p revious
client-initiated request. client-initiated request.</t>
</t> <t>Server push was designed to allow a server to improve client-perceive
<t> d performance by
Server push was designed to allow a server to improve client-perceived
performance by
predicting what requests will follow those that it receives, thereby r emoving a round predicting what requests will follow those that it receives, thereby r emoving a round
trip for them. For example, a request for HTML is often followed by re quests trip for them. For example, a request for HTML is often followed by re quests
for stylesheets and scripts referenced by that page. When these reques ts for stylesheets and scripts referenced by that page. When these reques ts
are pushed, the client does not need to wait to receive the references to them in the HTML are pushed, the client does not need to wait to receive the references to them in the HTML
and issue separate requests. and issue separate requests.</t>
</t> <t>In practice, server push is difficult to use effectively, because it
<t> requires the
In practice, server push is difficult to use effectively, because it r
equires the
server to correctly anticipate the additional requests the client will make, taking into server to correctly anticipate the additional requests the client will make, taking into
account factors such as caching, content negotiation, and user behavio r. Errors in account factors such as caching, content negotiation, and user behavio r. Errors in
prediction can lead to performance degradation, due to the opportunity cost that the prediction can lead to performance degradation, due to the opportunity cost that the
additional data on the wire represents. In particular, pushing any sig nificant amount of additional data on the wire represents. In particular, pushing any sig nificant amount of
data can cause contention issues with more-important responses. data can cause contention issues with responses that are more importan
</t> t.</t>
<t> <t>A client can request that server push be disabled, though this is neg
A client can request that server push be disabled, though this is nego otiated for each hop
tiated for each hop independently. The <xref target="SETTINGS_ENABLE_PUSH" format="none">S
independently. The <xref target="SETTINGS_ENABLE_PUSH" ETTINGS_ENABLE_PUSH</xref> setting can be set to 0 to indicate that server
format="none">SETTINGS_ENABLE_PUSH</xref> setting can be set to 0 to i push is disabled.</t>
ndicate that server <t>Promised requests <bcp14>MUST</bcp14> be safe (see <xref target="RFC9
push is disabled. 110" section="9.2.1"/>) and cacheable
</t> (see <xref target="RFC9110" section="9.2.3"/>). Promised requests cann
<t> ot include any content
Promised requests MUST be safe (see <xref target="HTTP" section="9.2.1
"/>) and cacheable
(see <xref target="HTTP" section="9.2.3"/>). Promised requests cannot
include any content
or a trailer section. Clients that receive a promised request that is not cacheable, that or a trailer section. Clients that receive a promised request that is not cacheable, that
is not known to be safe, or that indicates the presence of request con tent MUST reset the is not known to be safe, or that indicates the presence of request con tent <bcp14>MUST</bcp14> reset the
promised stream with a <xref target="StreamErrorHandler">stream error< /xref> of type promised stream with a <xref target="StreamErrorHandler">stream error< /xref> of type
<xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Not e this could result <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. Not e that this could result
in the promised stream being reset if the client does not recognize a newly defined in the promised stream being reset if the client does not recognize a newly defined
method as being safe. method as being safe.</t>
</t> <t>Pushed responses that are cacheable (see <xref target="RFC9111" secti
<t> on="3"/>) can be
Pushed responses that are cacheable (see <xref target="CACHE" section=
"3"/>) can be
stored by the client, if it implements an HTTP cache. Pushed responses are considered stored by the client, if it implements an HTTP cache. Pushed responses are considered
successfully validated on the origin server (e.g., if the "no-cache" c ache response successfully validated on the origin server (e.g., if the "no-cache" c ache response
directive is present; see <xref target="CACHE" section="5.2.2.4"/>) wh directive is present; see <xref target="RFC9111" section="5.2.2.4"/>)
ile the stream while the stream
identified by the promised stream ID is still open. identified by the promised stream identifier is still open.</t>
</t> <t>Pushed responses that are not cacheable <bcp14>MUST NOT</bcp14> be st
<t> ored by any HTTP cache. They <bcp14>MAY</bcp14>
Pushed responses that are not cacheable MUST NOT be stored by any HTTP be made available to the application separately.</t>
cache. They MAY <t>The server <bcp14>MUST</bcp14> include a value in the "<tt>:authority
be made available to the application separately. </tt>" pseudo-header field for which
</t> the server is authoritative (see <xref target="authority"/>). A client
<t> <bcp14>MUST</bcp14> treat a <xref target="PUSH_PROMISE" format="none">PUSH_PROM
The server MUST include a value in the <tt>:authority</tt> pseudo-head ISE</xref> for which the server is not
er field for which authoritative as a <xref target="StreamErrorHandler">stream error</xre
the server is authoritative (see <xref target="authority"/>). A client f> of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t
MUST treat a <xref >
target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> for which the <t>An intermediary can receive pushes from the server and choose not to
server is not forward them on to
authoritative as a <xref target="StreamErrorHandler">stream error</xre
f> of type <xref
target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.
</t>
<t>
An intermediary can receive pushes from the server and choose not to f
orward them on to
the client. In other words, how to make use of the pushed information is up to that the client. In other words, how to make use of the pushed information is up to that
intermediary. Equally, the intermediary might choose to make additiona l pushes to the intermediary. Equally, the intermediary might choose to make additiona l pushes to the
client, without any action taken by the server. client, without any action taken by the server.</t>
</t> <t>A client cannot push. Thus, servers <bcp14>MUST</bcp14> treat the rec
<t> eipt of a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame as
A client cannot push. Thus, servers MUST treat the receipt of a <xref a <xref target="ConnectionErrorHandler">connection error</xref> of type <xref t
target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame as a <xr arget="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. A server cannot set
ef the
target="ConnectionErrorHandler">connection error</xref> of type <xref
target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>. A server
cannot set the
<xref target="SETTINGS_ENABLE_PUSH" format="none">SETTINGS_ENABLE_PUSH </xref> setting to <xref target="SETTINGS_ENABLE_PUSH" format="none">SETTINGS_ENABLE_PUSH </xref> setting to
a value other than 0 (see <xref target="SettingValues"/>). a value other than 0 (see <xref target="SettingValues"/>).</t>
</t>
<section anchor="PushRequests"> <section anchor="PushRequests">
<name>Push Requests</name> <name>Push Requests</name>
<t> <t>Server push is semantically equivalent to a server responding to a
Server push is semantically equivalent to a server responding to a r request; however, in
equest; however, in
this case, that request is also sent by the server, as a <xref targe t="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> this case, that request is also sent by the server, as a <xref targe t="PUSH_PROMISE" format="none">PUSH_PROMISE</xref>
frame. frame.</t>
</t> <t>The <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> f
<t> rame includes a
The <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fr
ame includes a
field block that contains control data and a complete field block that contains control data and a complete
set of request header fields that the server attributes to the reque st. It is not set of request header fields that the server attributes to the reque st. It is not
possible to push a response to a request that includes message conte possible to push a response to a request that includes message conte
nt. nt.</t>
</t> <t>Promised requests are always associated with an explicit request fr
<t> om the client. The
Promised requests are always associated with an explicit request fro
m the client. The
<xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames sent by the server are sent on that explicit <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames sent by the server are sent on that explicit
request's stream. The <xref target="PUSH_PROMISE" format="none">PUSH _PROMISE</xref> frame also includes a promised stream request's stream. The <xref target="PUSH_PROMISE" format="none">PUSH _PROMISE</xref> frame also includes a promised stream
identifier, chosen from the stream identifiers available to the serv identifier, chosen from the stream identifiers available to the serv
er (see <xref target="StreamIdentifiers"/>). er (see <xref target="StreamIdentifiers"/>).</t>
</t> <t>The header fields in <xref target="PUSH_PROMISE" format="none">PUSH
<t> _PROMISE</xref> and
The header fields in <xref target="PUSH_PROMISE" format="none">PUSH_ any subsequent <xref target="CONTINUATION" format="none">CONTINUATIO
PROMISE</xref> and N</xref> frames <bcp14>MUST</bcp14>
any subsequent <xref target="CONTINUATION" format="none">CONTINUATIO
N</xref> frames MUST
be a valid and complete set of <xref target="HttpRequest">request he ader be a valid and complete set of <xref target="HttpRequest">request he ader
fields</xref>. The server MUST include a method in the <tt>:method</ fields</xref>. The server <bcp14>MUST</bcp14> include a method in th
tt> pseudo-header e "<tt>:method</tt>" pseudo-header
field that is safe and cacheable. If a client receives a <xref targe field that is safe and cacheable. If a client receives a <xref targe
t="PUSH_PROMISE" t="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> that does not include a compl
format="none">PUSH_PROMISE</xref> that does not include a complete a ete and valid set of
nd valid set of header fields or the "<tt>:method</tt>" pseudo-header field identifi
header fields or the <tt>:method</tt> pseudo-header field identifies es a method that is
a method that is not safe, it <bcp14>MUST</bcp14> respond on the promised stream with
not safe, it MUST respond on the promised stream with a <xref a <xref target="StreamErrorHandler">stream error</xref> of type <xref target="P
target="StreamErrorHandler">stream error</xref> of type <xref target ROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
="PROTOCOL_ERROR" <t>The server <bcp14>SHOULD</bcp14> send <xref target="PUSH_PROMISE" f
format="none">PROTOCOL_ERROR</xref>. ormat="none">PUSH_PROMISE</xref>
</t>
<t>
The server SHOULD send <xref target="PUSH_PROMISE" format="none">PUS
H_PROMISE</xref>
(<xref target="PUSH_PROMISE"/>) frames prior to sending any frames t hat reference the (<xref target="PUSH_PROMISE"/>) frames prior to sending any frames t hat reference the
promised responses. This avoids a race where clients issue requests prior to receiving promised responses. This avoids a race where clients issue requests prior to receiving
any <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fr any <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> fr
ames. ames.</t>
</t> <t>For example, if the server receives a request for a document contai
<t> ning embedded links
For example, if the server receives a request for a document contain
ing embedded links
to multiple image files and the server chooses to push those additio nal images to the to multiple image files and the server chooses to push those additio nal images to the
client, sending <xref target="PUSH_PROMISE" format="none">PUSH_PROMI SE</xref> frames client, sending <xref target="PUSH_PROMISE" format="none">PUSH_PROMI SE</xref> frames
before the <xref target="DATA" format="none">DATA</xref> frames that contain the image before the <xref target="DATA" format="none">DATA</xref> frames that contain the image
links ensures that the client is able to see that a resource will be pushed before links ensures that the client is able to see that a resource will be pushed before
discovering embedded links. Similarly, if the server pushes resource s referenced by the discovering embedded links. Similarly, if the server pushes resource s referenced by the
field block (for instance, in Link header fields), sending a <xref field block (for instance, in Link header fields), sending a <xref t
target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> before sendi arget="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> before sending the header
ng the header ensures that clients do not request those resources.</t>
ensures that clients do not request those resources. <t><xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame
</t> s <bcp14>MUST NOT</bcp14> be sent by the client.</t>
<t><xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame
s MUST NOT be sent by the client.
</t>
<t><xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame s can be sent by the server on any <t><xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frame s can be sent by the server on any
client-initiated stream, but the stream MUST be in either the "open" or "half-closed client-initiated stream, but the stream <bcp14>MUST</bcp14> be in ei ther the "open" or "half-closed
(remote)" state with respect to the server. <xref target="PUSH_PROM ISE" format="none">PUSH_PROMISE</xref> frames are (remote)" state with respect to the server. <xref target="PUSH_PROM ISE" format="none">PUSH_PROMISE</xref> frames are
interspersed with the frames that comprise a response, though they c annot be interspersed with the frames that comprise a response, though they c annot be
interspersed with <xref target="HEADERS" format="none">HEADERS</xref > and <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames that interspersed with <xref target="HEADERS" format="none">HEADERS</xref > and <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames that
comprise a single field block. comprise a single field block.</t>
</t> <t>Sending a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</x
<t> ref> frame creates a new stream and puts the stream
Sending a <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</xr
ef> frame creates a new stream and puts the stream
into the "reserved (local)" state for the server and the "reserved ( remote)" state for into the "reserved (local)" state for the server and the "reserved ( remote)" state for
the client. the client.</t>
</t>
</section> </section>
<section anchor="PushResponses"> <section anchor="PushResponses">
<name>Push Responses</name> <name>Push Responses</name>
<t> <t>After sending the <xref target="PUSH_PROMISE" format="none">PUSH_PR
After sending the <xref target="PUSH_PROMISE" format="none">PUSH_PRO OMISE</xref> frame,
MISE</xref> frame, the server can begin delivering the pushed response as a <xref targe
the server can begin delivering the pushed response as a <xref t="HttpResponse">response</xref> on a server-initiated stream that uses the
target="HttpResponse">response</xref> on a server-initiated stream t
hat uses the
promised stream identifier. The server uses this stream to transmit an HTTP response, promised stream identifier. The server uses this stream to transmit an HTTP response,
using the same sequence of frames as defined in <xref target="HttpFr aming"/>. This using the same sequence of frames as that defined in <xref target="H ttpFraming"/>. This
stream becomes <xref target="StreamStates">"half-closed" to the clie nt</xref> after the stream becomes <xref target="StreamStates">"half-closed" to the clie nt</xref> after the
initial <xref target="HEADERS" format="none">HEADERS</xref> frame is initial <xref target="HEADERS" format="none">HEADERS</xref> frame is
sent. sent.</t>
</t> <t>Once a client receives a <xref target="PUSH_PROMISE" format="none">
<t> PUSH_PROMISE</xref> frame and chooses to accept the
Once a client receives a <xref target="PUSH_PROMISE" format="none">P pushed response, the client <bcp14>SHOULD NOT</bcp14> issue any requ
USH_PROMISE</xref> frame and chooses to accept the ests for the promised response
pushed response, the client SHOULD NOT issue any requests for the pr until after the promised stream has closed.</t>
omised response <t>If the client determines, for any reason, that it does not wish to
until after the promised stream has closed. receive the pushed
</t>
<t>
If the client determines, for any reason, that it does not wish to r
eceive the pushed
response from the server or if the server takes too long to begin se nding the promised response from the server or if the server takes too long to begin se nding the promised
response, the client can send a <xref target="RST_STREAM" response, the client can send a <xref target="RST_STREAM" format="no
format="none">RST_STREAM</xref> frame, using either the <xref target ne">RST_STREAM</xref> frame, using either the <xref target="CANCEL" format="none
="CANCEL" ">CANCEL</xref> or <xref target="REFUSED_STREAM" format="none">REFUSED_STREAM</x
format="none">CANCEL</xref> or <xref target="REFUSED_STREAM" ref> code and referencing the pushed stream's identifier.</t>
format="none">REFUSED_STREAM</xref> code and referencing the pushed <t>A client can use the <xref target="SETTINGS_MAX_CONCURRENT_STREAMS"
stream's identifier. format="none">SETTINGS_MAX_CONCURRENT_STREAMS</xref> setting to limit the numbe
</t> r of
<t> responses that can be concurrently pushed by a server. Advertising a
A client can use the <xref target="SETTINGS_MAX_CONCURRENT_STREAMS" <xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTINGS_MAX_CONCU
format="none">SETTINGS_MAX_CONCURRENT_STREAMS</xref> setting to limi RRENT_STREAMS</xref> value of zero prevents the server
t the number of
responses that can be concurrently pushed by a server. Advertising a
<xref
target="SETTINGS_MAX_CONCURRENT_STREAMS"
format="none">SETTINGS_MAX_CONCURRENT_STREAMS</xref> value of zero p
revents the server
from opening the streams necessary to push responses. However, this does not prevent the from opening the streams necessary to push responses. However, this does not prevent the
server from reserving streams using <xref target="PUSH_PROMISE" server from reserving streams using <xref target="PUSH_PROMISE" form
format="none">PUSH_PROMISE</xref> frames, because "reserved" streams at="none">PUSH_PROMISE</xref> frames, because reserved streams do not count towa
do not count toward rd
the concurrent stream limit. Clients that do not wish to receive pus hed resources need the concurrent stream limit. Clients that do not wish to receive pus hed resources need
to reset any unwanted reserved streams or set <xref target="SETTINGS to reset any unwanted reserved streams or set <xref target="SETTINGS
_ENABLE_PUSH" _ENABLE_PUSH" format="none">SETTINGS_ENABLE_PUSH</xref> to 0.</t>
format="none">SETTINGS_ENABLE_PUSH</xref> to 0. <t>Clients receiving a pushed response <bcp14>MUST</bcp14> validate th
</t> at either the server is
<t>
Clients receiving a pushed response MUST validate that either the se
rver is
authoritative (see <xref target="authority"/>) or the proxy that pro vided the pushed authoritative (see <xref target="authority"/>) or the proxy that pro vided the pushed
response is configured for the corresponding request. For example, a server that offers response is configured for the corresponding request. For example, a server that offers
a certificate for only the <tt>example.com</tt> DNS-ID (see <xref ta rget="RFC6125"/>) a certificate for only the <tt>example.com</tt> DNS-ID (see <xref ta rget="RFC6125"/>)
is not permitted to push a response for <tt>https://www.example.org/ is not permitted to push a response for &lt;<tt>https://www.example.
doc</tt>. org/doc</tt>&gt;.</t>
</t> <t>The response for a <xref target="PUSH_PROMISE" format="none">PUSH_P
<t> ROMISE</xref> stream begins with a
The response for a <xref target="PUSH_PROMISE" format="none">PUSH_PR
OMISE</xref> stream begins with a
<xref target="HEADERS" format="none">HEADERS</xref> frame, which imm ediately puts the stream into the "half-closed <xref target="HEADERS" format="none">HEADERS</xref> frame, which imm ediately puts the stream into the "half-closed
(remote)" state for the server and "half-closed (local)" state for t he client, and ends (remote)" state for the server and "half-closed (local)" state for t he client, and ends
with a frame with the END_STREAM flag set, which places the stream i with a frame with the END_STREAM flag set, which places the stream i
n the "closed" state. n the "closed" state.</t>
</t>
<aside> <aside>
<t>Note: <t>Note:
The client never sends a frame with the END_STREAM flag set for a The client never sends a frame with the END_STREAM flag set for a
server push. server push.</t>
</t>
</aside> </aside>
</section> </section>
</section> </section>
<section anchor="CONNECT"> <section anchor="CONNECT">
<name>The CONNECT Method</name> <name>The CONNECT Method</name>
<t> <t>The CONNECT method (<xref target="RFC9110" section="9.3.6"/>) is
The CONNECT method (<xref target="HTTP" section="9.3.6"/>) is
used to convert an HTTP connection into a tunnel to a remote host. used to convert an HTTP connection into a tunnel to a remote host.
CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin
server for the purposes of interacting with <tt>https</tt> resources. server for the purposes of interacting with "<tt>https</tt>" resources
</t> .</t>
<t> <t>In HTTP/2, the CONNECT method establishes a tunnel over a single HTTP
In HTTP/2, the CONNECT method establishes a tunnel over a single HTTP/ /2 stream to a
2 stream to a
remote host, rather than converting the entire connection to a tunnel. A CONNECT header remote host, rather than converting the entire connection to a tunnel. A CONNECT header
section is constructed as defined in <xref target="HttpRequest"/> ("<x section is constructed as defined in <xref target="HttpRequest"/> ("<x
ref ref target="HttpRequest" format="title"/>"), with a few differences. Specificall
target="HttpRequest" format="title"/>"), with a few differences. Speci y:</t>
fically:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>The "<tt>:method</tt>" pseudo-header field is set to <tt>CONNECT</
The <tt>:method</tt> pseudo-header field is set to <tt>CONNECT</tt tt>.</li>
>. <li>The "<tt>:scheme</tt>" and "<tt>:path</tt>" pseudo-header
</li> fields <bcp14>MUST</bcp14> be omitted.</li>
<li> <li>The "<tt>:authority</tt>" pseudo-header field contains the host an
The <tt>:scheme</tt> and <tt>:path</tt> pseudo-header d port to
fields MUST be omitted.
</li>
<li>
The <tt>:authority</tt> pseudo-header field contains the host and
port to
connect to (equivalent to the authority-form of the request-target of CONNECT connect to (equivalent to the authority-form of the request-target of CONNECT
requests; see <xref target="HTTP11" section="3.2.3"/>). requests; see <xref target="RFC9112" section="3.2.3"/>).</li>
</li>
</ul> </ul>
<t> <t>A CONNECT request that does not conform to these restrictions is <xre
A CONNECT request that does not conform to these restrictions is <xref f target="malformed">malformed</xref>.</t>
target="malformed">malformed</xref>. <t>A proxy that supports CONNECT establishes a <xref target="RFC0793">TC
</t> P connection</xref> to
<t> the host and port identified in the "<tt>:authority</tt>" pseudo-heade
A proxy that supports CONNECT establishes a <xref target="TCP">TCP con r field. Once
nection</xref> to
the host and port identified in the <tt>:authority</tt> pseudo-header
field. Once
this connection is successfully established, the proxy sends a <xref t arget="HEADERS" format="none">HEADERS</xref> this connection is successfully established, the proxy sends a <xref t arget="HEADERS" format="none">HEADERS</xref>
frame containing a 2xx series status code to the client, as defined in frame containing a 2xx-series status code to the client, as defined in
<xref target="HTTP" section="9.3.6"/>. <xref target="RFC9110" section="9.3.6"/>.</t>
</t> <t>After the initial <xref target="HEADERS" format="none">HEADERS</xref>
<t> frame sent by each
After the initial <xref target="HEADERS" format="none">HEADERS</xref>
frame sent by each
peer, all subsequent <xref target="DATA" format="none">DATA</xref> fra mes correspond to peer, all subsequent <xref target="DATA" format="none">DATA</xref> fra mes correspond to
data sent on the TCP connection. The frame payload of any <xref target data sent on the TCP connection. The frame payload of any <xref target
="DATA" ="DATA" format="none">DATA</xref> frames sent by the client is transmitted by th
format="none">DATA</xref> frames sent by the client is transmitted by e proxy to the
the proxy to the TCP server; data received from the TCP server is assembled into <xref
TCP server; data received from the TCP server is assembled into <xref target="DATA" format="none">DATA</xref> frames by the proxy. Frame types other t
target="DATA" han <xref target="DATA" format="none">DATA</xref> or stream management frames (<
format="none">DATA</xref> frames by the proxy. Frame types other than xref target="RST_STREAM" format="none">RST_STREAM</xref>, <xref target="WINDOW_U
<xref target="DATA" PDATE" format="none">WINDOW_UPDATE</xref>, and <xref target="PRIORITY" format="n
format="none">DATA</xref> or stream management frames (<xref target="R one">PRIORITY</xref>) <bcp14>MUST NOT</bcp14> be sent on a connected stream and
ST_STREAM" <bcp14>MUST</bcp14> be treated
format="none">RST_STREAM</xref>, <xref target="WINDOW_UPDATE" as a <xref target="StreamErrorHandler">stream error</xref> if received
format="none">WINDOW_UPDATE</xref>, and <xref target="PRIORITY" .</t>
format="none">PRIORITY</xref>) MUST NOT be sent on a connected stream <t>The TCP connection can be closed by either peer. The END_STREAM flag
and MUST be treated on a
as a <xref target="StreamErrorHandler">stream error</xref> if received
.
</t>
<t>
The TCP connection can be closed by either peer. The END_STREAM flag
on a
<xref target="DATA" format="none">DATA</xref> frame is treated as bein g equivalent to the TCP FIN bit. A client is <xref target="DATA" format="none">DATA</xref> frame is treated as bein g equivalent to the TCP FIN bit. A client is
expected to send a <xref target="DATA" format="none">DATA</xref> frame with the END_STREAM flag set after receiving expected to send a <xref target="DATA" format="none">DATA</xref> frame with the END_STREAM flag set after receiving
a frame with the END_STREAM flag set. A proxy that receives a <xref t arget="DATA" format="none">DATA</xref> frame a frame with the END_STREAM flag set. A proxy that receives a <xref t arget="DATA" format="none">DATA</xref> frame
with the END_STREAM flag set sends the attached data with the FIN bit set on the last TCP with the END_STREAM flag set sends the attached data with the FIN bit set on the last TCP
segment. A proxy that receives a TCP segment with the FIN bit set sen ds a segment. A proxy that receives a TCP segment with the FIN bit set sen ds a
<xref target="DATA" format="none">DATA</xref> frame with the END_STREA M flag set. Note that the final TCP segment <xref target="DATA" format="none">DATA</xref> frame with the END_STREA M flag set. Note that the final TCP segment
or <xref target="DATA" format="none">DATA</xref> frame could be empty. or <xref target="DATA" format="none">DATA</xref> frame could be empty.
</t> </t>
<t> <t>A TCP connection error is signaled with <xref target="RST_STREAM" for
A TCP connection error is signaled with <xref target="RST_STREAM" form mat="none">RST_STREAM</xref>. A proxy treats any
at="none">RST_STREAM</xref>. A proxy treats any
error in the TCP connection, which includes receiving a TCP segment wi th the RST bit set, error in the TCP connection, which includes receiving a TCP segment wi th the RST bit set,
as a <xref target="StreamErrorHandler">stream error</xref> of type as a <xref target="StreamErrorHandler">stream error</xref> of type
<xref target="CONNECT_ERROR" format="none">CONNECT_ERROR</xref>. Corr <xref target="CONNECT_ERROR" format="none">CONNECT_ERROR</xref>. Corr
espondingly, a proxy MUST send a TCP segment with the espondingly, a proxy <bcp14>MUST</bcp14> send a TCP segment with the
RST bit set if it detects an error with the stream or the HTTP/2 conne RST bit set if it detects an error with the stream or the HTTP/2 conne
ction. ction.</t>
</t>
</section> </section>
<section anchor="informational-responses"> <section anchor="informational-responses">
<name>The Upgrade Header Field</name> <name>The Upgrade Header Field</name>
<t> <t>HTTP/2 does not support the 101 (Switching Protocols) informational s
HTTP/2 does not support the 101 (Switching Protocols) informational st tatus code
atus code (<xref target="RFC9110" section="15.2.2"/>).</t>
(<xref target="HTTP" section="15.2.2"/>). <t>The semantics of 101 (Switching Protocols) aren't applicable to a mul
</t> tiplexed protocol.
<t>
The semantics of 101 (Switching Protocols) aren't applicable to a mult
iplexed protocol.
Similar functionality might be enabled through the use of <xref target ="RFC8441">extended Similar functionality might be enabled through the use of <xref target ="RFC8441">extended
CONNECT</xref> and other protocols are able to use the same mechanisms CONNECT</xref>, and other protocols are able to use the same mechanism
that HTTP/2 uses to s that HTTP/2 uses to
negotiate their use (see <xref target="starting"/>). negotiate their use (see <xref target="starting"/>).</t>
</t>
</section> </section>
<section anchor="Reliability"> <section anchor="Reliability">
<name>Request Reliability</name> <name>Request Reliability</name>
<t> <t>In general, an HTTP client is unable to retry a non-idempotent reques
In general, an HTTP client is unable to retry a non-idempotent request t when an error
when an error occurs because there is no means to determine the nature of the error
occurs because there is no means to determine the nature of the error (see <xref target="RFC9110" section="9.2.2"/>). It is possible
(see <xref target="HTTP" section="9.2.2"/>). It is possible
that some server processing occurred prior to the error, which could r esult in that some server processing occurred prior to the error, which could r esult in
undesirable effects if the request were reattempted. undesirable effects if the request were reattempted.</t>
</t> <t>HTTP/2 provides two mechanisms for providing a guarantee to a client
<t> that a request has
HTTP/2 provides two mechanisms for providing a guarantee to a client t not been processed:</t>
hat a request has
not been processed:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>The <xref target="GOAWAY" format="none">GOAWAY</xref> frame indica
The <xref target="GOAWAY" format="none">GOAWAY</xref> frame indica tes the highest stream number that might have
tes the highest stream number that might have
been processed. Requests on streams with higher numbers are there fore guaranteed to been processed. Requests on streams with higher numbers are there fore guaranteed to
be safe to retry. be safe to retry.</li>
</li> <li>The <xref target="REFUSED_STREAM" format="none">REFUSED_STREAM</xr
<li> ef> error code can be included in a
The <xref target="REFUSED_STREAM" format="none">REFUSED_STREAM</xr
ef> error code can be included in a
<xref target="RST_STREAM" format="none">RST_STREAM</xref> frame to indicate that the stream is being closed prior to <xref target="RST_STREAM" format="none">RST_STREAM</xref> frame to indicate that the stream is being closed prior to
any processing having occurred. Any request that was sent on the reset stream can any processing having occurred. Any request that was sent on the reset stream can
be safely retried. be safely retried.</li>
</li>
</ul> </ul>
<t> <t>Requests that have not been processed have not failed; clients <bcp14
Requests that have not been processed have not failed; clients MAY aut >MAY</bcp14> automatically retry
omatically retry them, even those with non-idempotent methods.</t>
them, even those with non-idempotent methods. <t>A server <bcp14>MUST NOT</bcp14> indicate that a stream has not been
</t> processed unless it can guarantee
<t>
A server MUST NOT indicate that a stream has not been processed unless
it can guarantee
that fact. If frames that are on a stream are passed to the applicati on layer for any that fact. If frames that are on a stream are passed to the applicati on layer for any
stream, then <xref target="REFUSED_STREAM" format="none">REFUSED_STREA stream, then <xref target="REFUSED_STREAM" format="none">REFUSED_STREA
M</xref> MUST NOT be used for that stream, and a M</xref> <bcp14>MUST NOT</bcp14> be used for that stream, and a
<xref target="GOAWAY" format="none">GOAWAY</xref> frame MUST include a <xref target="GOAWAY" format="none">GOAWAY</xref> frame <bcp14>MUST</b
stream identifier that is greater than or cp14> include a stream identifier that is greater than or
equal to the given stream identifier. equal to the given stream identifier.</t>
</t> <t>In addition to these mechanisms, the <xref target="PING" format="none
<t> ">PING</xref> frame provides a way for a
In addition to these mechanisms, the <xref target="PING" format="none" client to easily test a connection. Connections that remain idle can
>PING</xref> frame provides a way for a become broken, because
client to easily test a connection. Connections that remain idle can
become broken as
some middleboxes (for instance, network address translators or load ba lancers) silently some middleboxes (for instance, network address translators or load ba lancers) silently
discard connection bindings. The <xref target="PING" format="none">PI NG</xref> frame allows a client to safely discard connection bindings. The <xref target="PING" format="none">PI NG</xref> frame allows a client to safely
test whether a connection is still active without sending a request. test whether a connection is still active without sending a request.</
</t> t>
</section> </section>
<section anchor="HttpExamples"> <section anchor="HttpExamples">
<name>Examples</name> <name>Examples</name>
<t> <t>This section shows HTTP/1.1 requests and responses, with illustration
This section shows HTTP/1.1 requests and responses, with illustratio s of equivalent
ns of equivalent HTTP/2 requests and responses.</t>
HTTP/2 requests and responses. <section>
</t> <name>Simple Request</name>
<section><name>Simple Request</name> <t>An HTTP GET request includes control data and a request header with
<t> no message content and is therefore
An HTTP GET request includes control data and a request header with
no message content and is therefore
transmitted as a single <xref target="HEADERS" format="none">HEADERS </xref> frame, followed by zero or more transmitted as a single <xref target="HEADERS" format="none">HEADERS </xref> frame, followed by zero or more
<xref target="CONTINUATION" format="none">CONTINUATION</xref> frames containing the serialized block of request header <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames containing the serialized block of request header
fields. The <xref target="HEADERS" format="none">HEADERS</xref> fra me in the following has both the END_HEADERS and fields. The <xref target="HEADERS" format="none">HEADERS</xref> fra me in the following has both the END_HEADERS and
END_STREAM flags set; no <xref target="CONTINUATION" format="none">C END_STREAM flags set; no <xref target="CONTINUATION" format="none">C
ONTINUATION</xref> frames are sent. ONTINUATION</xref> frames are sent.</t>
</t> <artwork type="inline"><![CDATA[
<artwork type="inline"><![CDATA[
GET /resource HTTP/1.1 HEADERS GET /resource HTTP/1.1 HEADERS
Host: example.org ==> + END_STREAM Host: example.org ==> + END_STREAM
Accept: image/jpeg + END_HEADERS Accept: image/jpeg + END_HEADERS
:method = GET :method = GET
:scheme = https :scheme = https
:authority = example.org :authority = example.org
:path = /resource :path = /resource
host = example.org host = example.org
accept = image/jpeg accept = image/jpeg
]]></artwork> ]]></artwork>
</section> </section>
<section><name>Simple Response</name> <section>
<t> <name>Simple Response</name>
Similarly, a response that includes only control data and a response <t>Similarly, a response that includes only control data and a respons
header is transmitted as a e header is transmitted as a
<xref target="HEADERS" format="none">HEADERS</xref> frame (again, fo llowed by zero or more <xref target="HEADERS" format="none">HEADERS</xref> frame (again, fo llowed by zero or more
<xref target="CONTINUATION" format="none">CONTINUATION</xref> frames ) containing the serialized block of response header <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames ) containing the serialized block of response header
fields. fields.</t>
</t> <artwork type="inline"><![CDATA[
<artwork type="inline"><![CDATA[
HTTP/1.1 304 Not Modified HEADERS HTTP/1.1 304 Not Modified HEADERS
ETag: "xyzzy" ==> + END_STREAM ETag: "xyzzy" ==> + END_STREAM
Expires: Thu, 23 Jan ... + END_HEADERS Expires: Thu, 23 Jan ... + END_HEADERS
:status = 304 :status = 304
etag = "xyzzy" etag = "xyzzy"
expires = Thu, 23 Jan ... expires = Thu, 23 Jan ...
]]></artwork> ]]></artwork>
</section> </section>
<section><name>Complex Request</name> <section>
<t> <name>Complex Request</name>
An HTTP POST request that includes control data and a request header <t>An HTTP POST request that includes control data and a request heade
and message content is transmitted r with message content is transmitted
as one <xref target="HEADERS" format="none">HEADERS</xref> frame, fo llowed by zero or more as one <xref target="HEADERS" format="none">HEADERS</xref> frame, fo llowed by zero or more
<xref target="CONTINUATION" format="none">CONTINUATION</xref> frames containing the request header, followed by one <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames containing the request header, followed by one
or more <xref target="DATA" format="none">DATA</xref> frames, with t he last <xref target="CONTINUATION" format="none">CONTINUATION</xref> (or or more <xref target="DATA" format="none">DATA</xref> frames, with t he last <xref target="CONTINUATION" format="none">CONTINUATION</xref> (or
<xref target="HEADERS" format="none">HEADERS</xref>) frame having th e END_HEADERS flag set and the final <xref target="HEADERS" format="none">HEADERS</xref>) frame having th e END_HEADERS flag set and the final
<xref target="DATA" format="none">DATA</xref> frame having the END_S <xref target="DATA" format="none">DATA</xref> frame having the END_S
TREAM flag set: TREAM flag set:</t>
</t> <artwork type="inline"><![CDATA[
<artwork type="inline"><![CDATA[
POST /resource HTTP/1.1 HEADERS POST /resource HTTP/1.1 HEADERS
Host: example.org ==> - END_STREAM Host: example.org ==> - END_STREAM
Content-Type: image/jpeg - END_HEADERS Content-Type: image/jpeg - END_HEADERS
Content-Length: 123 :method = POST Content-Length: 123 :method = POST
:authority = example.org :authority = example.org
:path = /resource :path = /resource
{binary data} :scheme = https {binary data} :scheme = https
CONTINUATION CONTINUATION
+ END_HEADERS + END_HEADERS
content-type = image/jpeg content-type = image/jpeg
host = example.org host = example.org
content-length = 123 content-length = 123
DATA DATA
+ END_STREAM + END_STREAM
{binary data} {binary data}
]]></artwork> ]]></artwork>
<t keepWithPrevious="true"> <t keepWithPrevious="true">Note that data contributing to any given fi
Note that data contributing to any given field line could be sprea eld line could be spread between field
d between field
block fragments. The allocation of field lines to frames in this example is block fragments. The allocation of field lines to frames in this example is
illustrative only. illustrative only.</t>
</t>
</section> </section>
<section><name>Response with Body</name> <section>
<t> <name>Response with Body</name>
A response that includes control data and a response header and mess <t>A response that includes control data and a response header with me
age content is ssage content is
transmitted as a <xref target="HEADERS" format="none">HEADERS</xref> frame, followed by transmitted as a <xref target="HEADERS" format="none">HEADERS</xref> frame, followed by
zero or more <xref target="CONTINUATION" format="none">CONTINUATION< /xref> frames, zero or more <xref target="CONTINUATION" format="none">CONTINUATION< /xref> frames,
followed by one or more <xref target="DATA" format="none">DATA</xref > frames, with the followed by one or more <xref target="DATA" format="none">DATA</xref > frames, with the
last <xref target="DATA" format="none">DATA</xref> frame in the sequ ence having the last <xref target="DATA" format="none">DATA</xref> frame in the sequ ence having the
END_STREAM flag set: END_STREAM flag set:</t>
</t> <artwork type="inline"><![CDATA[
<artwork type="inline"><![CDATA[
HTTP/1.1 200 OK HEADERS HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM Content-Type: image/jpeg ==> - END_STREAM
Content-Length: 123 + END_HEADERS Content-Length: 123 + END_HEADERS
:status = 200 :status = 200
{binary data} content-type = image/jpeg {binary data} content-type = image/jpeg
content-length = 123 content-length = 123
DATA DATA
+ END_STREAM + END_STREAM
{binary data} {binary data}
]]></artwork> ]]></artwork>
</section> </section>
<section><name>Informational Responses</name> <section>
<t> <name>Informational Responses</name>
An informational response using a 1xx status code other than 101 is <t>An informational response using a 1xx status code other than 101 is
transmitted as a transmitted as a
<xref target="HEADERS" format="none">HEADERS</xref> frame, followed by zero or more <xref target="HEADERS" format="none">HEADERS</xref> frame, followed by zero or more
<xref target="CONTINUATION" format="none">CONTINUATION</xref> frames <xref target="CONTINUATION" format="none">CONTINUATION</xref> frames
. .</t>
</t> <t>A trailer section is sent as a field block after both the request o
<t> r response
A trailer section is sent as a field block after both the request or
response
field block and all the <xref target="DATA" format="none">DATA</xref > frames have been sent. The field block and all the <xref target="DATA" format="none">DATA</xref > frames have been sent. The
<xref target="HEADERS" format="none">HEADERS</xref> frame starting t he field block that comprises <xref target="HEADERS" format="none">HEADERS</xref> frame starting t he field block that comprises
the trailer section has the END_STREAM flag set. the trailer section has the END_STREAM flag set.</t>
</t> <t keepWithNext="true">The following example includes both a 100 (Cont
<t keepWithNext="true"> inue) status code, which is sent in
The following example includes both a 100 (Continue) status code,
which is sent in
response to a request containing a "100-continue" token in the Exp ect header field, response to a request containing a "100-continue" token in the Exp ect header field,
and a trailer section: and a trailer section:</t>
</t> <artwork type="inline"><![CDATA[
<artwork type="inline"><![CDATA[
HTTP/1.1 100 Continue HEADERS HTTP/1.1 100 Continue HEADERS
Extension-Field: bar ==> - END_STREAM Extension-Field: bar ==> - END_STREAM
+ END_HEADERS + END_HEADERS
:status = 100 :status = 100
extension-field = bar extension-field = bar
HTTP/1.1 200 OK HEADERS HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM Content-Type: image/jpeg ==> - END_STREAM
Transfer-Encoding: chunked + END_HEADERS Transfer-Encoding: chunked + END_HEADERS
Trailer: Foo :status = 200 Trailer: Foo :status = 200
skipping to change at line 3675 skipping to change at line 2567
HEADERS HEADERS
+ END_STREAM + END_STREAM
+ END_HEADERS + END_HEADERS
foo = bar foo = bar
]]></artwork> ]]></artwork>
</section> </section>
</section> </section>
</section> </section>
<section anchor="HttpExtra"> <section anchor="HttpExtra">
<name>HTTP/2 Connections</name> <name>HTTP/2 Connections</name>
<t> <t>This section outlines attributes of HTTP that improve interoperability,
This section outlines attributes of the HTTP protocol that improve inter reduce exposure to
operability, reduce known security vulnerabilities, or reduce the potential for implementati
exposure to known security vulnerabilities, or reduce the potential for on variation.</t>
implementation
variation.
</t>
<section> <section>
<name>Connection Management</name> <name>Connection Management</name>
<t> <t>HTTP/2 connections are persistent. For best performance, it is expec
HTTP/2 connections are persistent. For best performance, it is expect ted that clients will not
ed that clients will not
close connections until it is determined that no further communication with a server is close connections until it is determined that no further communication with a server is
necessary (for example, when a user navigates away from a particular w eb page) or until necessary (for example, when a user navigates away from a particular w eb page) or until
the server closes the connection. the server closes the connection.</t>
</t> <t>Clients <bcp14>SHOULD NOT</bcp14> open more than one HTTP/2 connectio
<t> n to a given host and port pair,
Clients SHOULD NOT open more than one HTTP/2 connection to a given hos where the host is derived from a URI, a selected <xref target="RFC7838
t and port pair, ">alternative
where the host is derived from a URI, a selected <xref target="ALT-SVC service</xref>, or a configured proxy.</t>
">alternative <t>A client can create additional connections as replacements, either to
service</xref>, or a configured proxy. replace connections
</t>
<t>
A client can create additional connections as replacements, either to
replace connections
that are near to exhausting the available <xref target="StreamIdentifi ers">stream that are near to exhausting the available <xref target="StreamIdentifi ers">stream
identifier space</xref>, to refresh the keying material for a TLS conn ection, or to identifier space</xref>, to refresh the keying material for a TLS conn ection, or to
replace connections that have encountered <xref target="ConnectionErro replace connections that have encountered <xref target="ConnectionErro
rHandler">errors</xref>. rHandler">errors</xref>.</t>
</t> <t>A client <bcp14>MAY</bcp14> open multiple connections to the same IP
<t> address and TCP port using different
A client MAY open multiple connections to the same IP address and TCP <xref target="RFC6066">Server Name Indication</xref> values or to prov
port using different ide different TLS
<xref target="TLS-EXT">Server Name Indication</xref> values or to prov client certificates but <bcp14>SHOULD</bcp14> avoid creating multiple
ide different TLS connections with the same
client certificates but SHOULD avoid creating multiple connections wit configuration.</t>
h the same <t>Servers are encouraged to maintain open connections for as long as po
configuration. ssible but are
</t>
<t>
Servers are encouraged to maintain open connections for as long as pos
sible but are
permitted to terminate idle connections if necessary. When either end point chooses to permitted to terminate idle connections if necessary. When either end point chooses to
close the transport-layer TCP connection, the terminating endpoint SHO ULD first send a close the transport-layer TCP connection, the terminating endpoint <bc p14>SHOULD</bcp14> first send a
<xref target="GOAWAY" format="none">GOAWAY</xref> (<xref target="GOAWA Y"/>) frame so that both endpoints can reliably <xref target="GOAWAY" format="none">GOAWAY</xref> (<xref target="GOAWA Y"/>) frame so that both endpoints can reliably
determine whether previously sent frames have been processed and grace fully complete or determine whether previously sent frames have been processed and grace fully complete or
terminate any necessary remaining tasks. terminate any necessary remaining tasks.</t>
</t>
<section anchor="reuse"> <section anchor="reuse">
<name>Connection Reuse</name> <name>Connection Reuse</name>
<t> <t>Connections that are made to an origin server, either directly or t
Connections that are made to an origin server, either directly or th hrough a tunnel
rough a tunnel created using the <xref target="CONNECT">CONNECT method</xref>, <bcp
created using the <xref target="CONNECT">CONNECT method</xref>, MAY 14>MAY</bcp14> be reused for
be reused for
requests with multiple different URI authority components. A connec tion can be reused requests with multiple different URI authority components. A connec tion can be reused
as long as the origin server is <xref target="authority">authoritati ve</xref>. For TCP as long as the origin server is <xref target="authority">authoritati ve</xref>. For TCP
connections without TLS, this depends on the host having resolved to the same IP connections without TLS, this depends on the host having resolved to the same IP
address. address.</t>
</t> <t>For "<tt>https</tt>" resources, connection reuse additionally depen
<t> ds
For <tt>https</tt> resources, connection reuse additionally depends
on having a certificate that is valid for the host in the URI. The certificate on having a certificate that is valid for the host in the URI. The certificate
presented by the server MUST satisfy any checks that the client woul d perform when presented by the server <bcp14>MUST</bcp14> satisfy any checks that the client would perform when
forming a new TLS connection for the host in the URI. A single cert ificate can be forming a new TLS connection for the host in the URI. A single cert ificate can be
used to establish authority for multiple origins. <xref target="HTT used to establish authority for multiple origins. <xref target="RFC
P" section="4.3"/> 9110" section="4.3"/>
describes how a client determines whether a server is authoritative describes how a client determines whether a server is authoritative
for a URI. for a URI.</t>
</t> <t>In some deployments, reusing a connection for multiple origins can
<t> result in requests
In some deployments, reusing a connection for multiple origins can r
esult in requests
being directed to the wrong origin server. For example, TLS termina tion might be being directed to the wrong origin server. For example, TLS termina tion might be
performed by a middlebox that uses the TLS <xref target="TLS-EXT">Se performed by a middlebox that uses the TLS <xref target="RFC6066">Se
rver Name Indication rver Name
(SNI)</xref> extension to select an origin server. This means that Indication</xref> extension to select an origin server. This means
it is possible that it is possible
for clients to send requests to servers that might not be the intend for clients to send requests to servers that might not be the intend
ed ed target for the
target for the request, even though the server is otherwise authorit request, even though the server is otherwise authoritative.</t>
ative. <t>A server that does not wish clients to reuse connections can indica
</t> te that it is not
<t>
A server that does not wish clients to reuse connections can indicat
e that it is not
authoritative for a request by sending a 421 (Misdirected Request) s tatus code in response authoritative for a request by sending a 421 (Misdirected Request) s tatus code in response
to the request (see <xref target="HTTP" section="15.5.20"/>). to the request (see <xref target="RFC9110" section="15.5.20"/>).</t>
</t> <t>A client that is configured to use a proxy over HTTP/2 directs requ
<t> ests to that proxy
A client that is configured to use a proxy over HTTP/2 directs reque
sts to that proxy
through a single connection. That is, all requests sent via a proxy reuse the through a single connection. That is, all requests sent via a proxy reuse the
connection to the proxy. connection to the proxy.</t>
</t>
</section> </section>
</section> </section>
<section anchor="TLSUsage"> <section anchor="TLSUsage">
<name>Use of TLS Features</name> <name>Use of TLS Features</name>
<t> <t>Implementations of HTTP/2 <bcp14>MUST</bcp14> use <xref target="RFC52
Implementations of HTTP/2 MUST use <xref target="TLS12">TLS version 1. 46">TLS version 1.2</xref> or higher
2</xref> or higher for HTTP/2 over TLS. The general TLS usage guidance in <xref target="
for HTTP/2 over TLS. The general TLS usage guidance in <xref target=" RFC7525"/> <bcp14>SHOULD</bcp14> be
TLSBCP"/> SHOULD be followed, with some additional restrictions that are specific to HTTP/
followed, with some additional restrictions that are specific to HTTP/ 2.</t>
2. <t>The TLS implementation <bcp14>MUST</bcp14> support the <xref target="
</t> RFC6066">Server Name Indication
<t> (SNI)</xref> extension to TLS. If the server is identified by a <xref
The TLS implementation MUST support the <xref target="TLS-EXT">Server target="RFC8499">domain name</xref>, clients <bcp14>MUST</bcp14> send the server
Name Indication _name TLS extension
(SNI)</xref> extension to TLS. If the server is identified by a <xref unless an alternative mechanism to indicate the target host is used.</
target="DNS-TERMS">domain name</xref>, clients MUST send the server_na t>
me TLS extension <t>Requirements for deployments of HTTP/2 that negotiate <xref target="R
unless an alternative mechanism to indicate the target host is used. FC8446">TLS 1.3</xref>
</t>
<t>
Requirements for deployments of HTTP/2 that negotiate <xref target="TL
S13">TLS 1.3</xref>
are included in <xref target="tls13features"/>. Deployments of TLS 1. 2 are subject to are included in <xref target="tls13features"/>. Deployments of TLS 1. 2 are subject to
the requirements in <xref target="tls12features"/> and <xref target="t ls12ciphers"/>. the requirements in Sections&#xa0;<xref target="tls12features" format= "counter"/> and <xref target="tls12ciphers" format="counter"/>.
Implementations are encouraged to provide defaults that comply, but it is recognized that Implementations are encouraged to provide defaults that comply, but it is recognized that
deployments are ultimately responsible for compliance. deployments are ultimately responsible for compliance.</t>
</t>
<section anchor="tls12features"> <section anchor="tls12features">
<name>TLS 1.2 Features</name> <name>TLS 1.2 Features</name>
<t> <t>This section describes restrictions on the TLS 1.2 feature set that
This section describes restrictions on the TLS 1.2 feature set that can be used with
can be used with
HTTP/2. Due to deployment limitations, it might not be possible to f ail TLS negotiation HTTP/2. Due to deployment limitations, it might not be possible to f ail TLS negotiation
when these restrictions are not met. An endpoint MAY immediately ter when these restrictions are not met. An endpoint <bcp14>MAY</bcp14>
minate an HTTP/2 immediately terminate an HTTP/2
connection that does not meet these TLS requirements with a <xref connection that does not meet these TLS requirements with a <xref ta
target="ConnectionErrorHandler">connection error</xref> of type <xre rget="ConnectionErrorHandler">connection error</xref> of type <xref target="INAD
f EQUATE_SECURITY" format="none">INADEQUATE_SECURITY</xref>.</t>
target="INADEQUATE_SECURITY" format="none">INADEQUATE_SECURITY</xref <t>A deployment of HTTP/2 over TLS 1.2 <bcp14>MUST</bcp14> disable com
>. pression. TLS compression can lead
to the exposure of information that would not otherwise be revealed
</t> <xref target="RFC3749"/>. Generic compression is unnecessary, since HTTP/2 provi
<t> des
A deployment of HTTP/2 over TLS 1.2 MUST disable compression. TLS co
mpression can lead
to the exposure of information that would not otherwise be revealed
<xref
target="RFC3749"/>. Generic compression is unnecessary since HTTP/2
provides
compression features that are more aware of context and therefore li kely to be more compression features that are more aware of context and therefore li kely to be more
appropriate for use for performance, security, or other reasons. appropriate for use for performance, security, or other reasons.</t>
<t>A deployment of HTTP/2 over TLS 1.2 <bcp14>MUST</bcp14> disable ren
</t> egotiation. An endpoint <bcp14>MUST</bcp14> treat
<t>
A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation. An e
ndpoint MUST treat
a TLS renegotiation as a <xref target="ConnectionErrorHandler">conne ction error</xref> a TLS renegotiation as a <xref target="ConnectionErrorHandler">conne ction error</xref>
of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</ xref>. Note that of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</ xref>. Note that
disabling renegotiation can result in long-lived connections becomin g unusable due to disabling renegotiation can result in long-lived connections becomin g unusable due to
limits on the number of messages the underlying cipher suite can enc limits on the number of messages the underlying cipher suite can enc
ipher. ipher.</t>
<t>An endpoint <bcp14>MAY</bcp14> use renegotiation to provide confide
</t> ntiality protection for client
<t> credentials offered in the handshake, but any renegotiation <bcp14>M
An endpoint MAY use renegotiation to provide confidentiality protect UST</bcp14> occur prior to sending
ion for client the connection preface. A server <bcp14>SHOULD</bcp14> request a cl
credentials offered in the handshake, but any renegotiation MUST occ ient certificate if it sees a
ur prior to sending renegotiation request immediately after establishing a connection.</
the connection preface. A server SHOULD request a client certificat t>
e if it sees a <t>This effectively prevents the use of renegotiation in response to a
renegotiation request immediately after establishing a connection. request for a
</t>
<t>
This effectively prevents the use of renegotiation in response to a
request for a
specific protected resource. A future specification might provide a way to support this specific protected resource. A future specification might provide a way to support this
use case. Alternatively, a server might use an <xref target="ErrorHa use case. Alternatively, a server might use an <xref target="ErrorHa
ndler"> ndler">error</xref> of type <xref target="HTTP_1_1_REQUIRED" format="none">HTTP_
error</xref> of type <xref target="HTTP_1_1_REQUIRED" format="none"> 1_1_REQUIRED</xref> to request that the client
HTTP_1_1_REQUIRED</xref> to request the client use a protocol that supports renegotiation.</t>
use a protocol that supports renegotiation. <t>Implementations <bcp14>MUST</bcp14> support ephemeral key exchange
</t> sizes of at least 2048 bits for
<t> cipher suites that use ephemeral finite field Diffie-Hellman (DHE) (
Implementations MUST support ephemeral key exchange sizes of at leas <xref target="RFC5246" section="8.1.2"/>) and 224 bits for cipher suites that us
t 2048 bits for e ephemeral elliptic curve
cipher suites that use ephemeral finite field Diffie-Hellman (DHE) ( Diffie-Hellman (ECDHE) <xref target="RFC8422"/>. Clients <bcp14>MUST
<xref </bcp14> accept DHE sizes of up to
target="TLS12" section="8.1.2"/> and 224 bits for cipher suites that 4096 bits. Endpoints <bcp14>MAY</bcp14> treat negotiation of key siz
use ephemeral elliptic curve es smaller than the lower limits
Diffie-Hellman (ECDHE) <xref target="RFC8422"/>. Clients MUST accept as a <xref target="ConnectionErrorHandler">connection error</xref> o
DHE sizes of up to f type <xref target="INADEQUATE_SECURITY" format="none">INADEQUATE_SECURITY</xre
4096 bits. Endpoints MAY treat negotiation of key sizes smaller than f>.</t>
the lower limits
as a <xref target="ConnectionErrorHandler">connection error</xref> o
f type <xref
target="INADEQUATE_SECURITY" format="none">INADEQUATE_SECURITY</xref
>.
</t>
</section> </section>
<section anchor="tls12ciphers"> <section anchor="tls12ciphers">
<name>TLS 1.2 Cipher Suites</name> <name>TLS 1.2 Cipher Suites</name>
<t> <t>A deployment of HTTP/2 over TLS 1.2 <bcp14>SHOULD NOT</bcp14> use a
A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher ny of the prohibited cipher suites listed in <xref target="BadCipherSuites"/>.</
suites that are t>
listed in the <xref target="BadCipherSuites">list of prohibited cip <t>Endpoints <bcp14>MAY</bcp14> choose to generate a <xref target="Con
her suites</xref>. nectionErrorHandler">connection
</t> error</xref> of type <xref target="INADEQUATE_SECURITY" format="none
<t> ">INADEQUATE_SECURITY</xref> if one of the prohibited cipher suites is
Endpoints MAY choose to generate a <xref target="ConnectionErrorHand
ler">connection
error</xref> of type <xref target="INADEQUATE_SECURITY"
format="none">INADEQUATE_SECURITY</xref> if one of the prohibited ci
pher suites is
negotiated. A deployment that chooses to use a prohibited cipher sui te risks triggering negotiated. A deployment that chooses to use a prohibited cipher sui te risks triggering
a connection error unless the set of potential peers is known to acc ept that cipher a connection error unless the set of potential peers is known to acc ept that cipher
suite. suite.</t>
<t>Implementations <bcp14>MUST NOT</bcp14> generate this error in reac
</t> tion to the negotiation of a cipher
<t>
Implementations MUST NOT generate this error in reaction to the nego
tiation of a cipher
suite that is not prohibited. Consequently, when clients offer a ci pher suite suite that is not prohibited. Consequently, when clients offer a ci pher suite
that is not prohibited, they have to be prepared to use that cipher suite with that is not prohibited, they have to be prepared to use that cipher suite with
HTTP/2. HTTP/2.</t>
</t> <t>The list of prohibited cipher suites includes the cipher suite that
<t> TLS 1.2 makes
The list of prohibited cipher suites includes the cipher suite that mandatory, which means that TLS 1.2 deployments could have non-inter
TLS 1.2 makes mandatory, secting sets of
which means that TLS 1.2 deployments could have non-intersecting set permitted cipher suites. To avoid this problem, which causes TLS ha
s of permitted cipher ndshake failures,
suites. To avoid this problem causing TLS handshake failures, deplo deployments of HTTP/2 that use TLS 1.2 <bcp14>MUST</bcp14> support
yments of HTTP/2 that use TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 <xref target="RFC5289"/> with
TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 <xref tar the P-256 elliptic
get="TLS-ECDHE"/> with curve <xref target="RFC8422"/>.</t>
the P-256 elliptic curve <xref target="RFC8422"/>. <t>Note that clients might advertise support of cipher suites that are
</t> prohibited in
<t>
Note that clients might advertise support of cipher suites that are
prohibited in
order to allow for connection to servers that do not support HTTP/2. This allows order to allow for connection to servers that do not support HTTP/2. This allows
servers to select HTTP/1.1 with a cipher suite that is prohibited in HTTP/2. servers to select HTTP/1.1 with a cipher suite that is prohibited in HTTP/2.
However, this can result in HTTP/2 being negotiated with a prohibite d cipher suite if However, this can result in HTTP/2 being negotiated with a prohibite d cipher suite if
the application protocol and cipher suite are independently selected the application protocol and cipher suite are independently selected
. .</t>
</t>
</section> </section>
<section anchor="tls13features"> <section anchor="tls13features">
<name>TLS 1.3 Features</name> <name>TLS 1.3 Features</name>
<t> <t>TLS 1.3 includes a number of features not available in earlier vers
TLS 1.3 includes a number of features not available in earlier versi ions. This section
ons. This section discusses the use of these features.</t>
discusses the use of these features. <t>HTTP/2 servers <bcp14>MUST NOT</bcp14> send post-handshake TLS 1.3
</t> CertificateRequest messages. HTTP/2
<t> clients <bcp14>MUST</bcp14> treat a TLS post-handshake CertificateRe
HTTP/2 servers MUST NOT send post-handshake TLS 1.3 CertificateReque quest message as a <xref target="ConnectionErrorHandler">connection error</xref>
st messages. HTTP/2 of type <xref target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.</t>
clients MUST treat a TLS post-handshake CertificateRequest message a <t>The prohibition on post-handshake authentication applies even if th
s a <xref e client offered the
target="ConnectionErrorHandler">connection error</xref> of type <xre
f
target="PROTOCOL_ERROR" format="none">PROTOCOL_ERROR</xref>.
</t>
<t>
The prohibition on post-handshake authentication applies even if the
client offered the
"post_handshake_auth" TLS extension. Post-handshake authentication support might be "post_handshake_auth" TLS extension. Post-handshake authentication support might be
advertised independently of <xref target="TLS-ALPN">ALPN</xref>. Cl ients might offer advertised independently of <xref target="RFC7301">ALPN</xref>. Cli ents might offer
the capability for use in other protocols, but inclusion of the exte nsion cannot imply the capability for use in other protocols, but inclusion of the exte nsion cannot imply
support within HTTP/2. support within HTTP/2.</t>
</t> <t><xref target="RFC8446"/> defines other post-handshake messages, New
<t><xref target="TLS13"/> defines other post-handshake messages, NewSe SessionTicket and
ssionTicket and
KeyUpdate, which can be used as they have no direct interaction with HTTP/2. Unless the KeyUpdate, which can be used as they have no direct interaction with HTTP/2. Unless the
use of a new type of TLS message depends on an interaction with the application-layer use of a new type of TLS message depends on an interaction with the application-layer
protocol, that TLS message can be sent after the handshake completes protocol, that TLS message can be sent after the handshake completes
. .</t>
</t> <t>TLS early data <bcp14>MAY</bcp14> be used to send requests, provide
<t> d that the guidance in <xref target="RFC8470"/> is observed. Clients send reques
TLS early data MAY be used to send requests, provided that the guida ts in early data assuming initial
nce in <xref values for all server settings.</t>
target="RFC8470"/> is observed. Clients send requests in early data
assuming initial
values for all server settings.
</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="security"> <section anchor="security">
<name>Security Considerations</name> <name>Security Considerations</name>
<t> <t>The use of TLS is necessary to provide many of the security properties
The use of TLS is necessary to provide many of the security properties o of this protocol.
f this protocol. Many of the claims in this section do not hold unless TLS is used as des
Many of the claims in this section do not hold unless TLS is used as des cribed in <xref target="TLSUsage"/>.</t>
cribed in <xref
target="TLSUsage"/>.
</t>
<section anchor="authority"> <section anchor="authority">
<name>Server Authority</name> <name>Server Authority</name>
<t> <t>HTTP/2 relies on the HTTP definition of authority for determining whe
HTTP/2 relies on the HTTP definition of authority for determining whet ther a server is
her a server is authoritative in providing a given response (see <xref target="RFC9110
authoritative in providing a given response (see <xref target="HTTP" s " section="4.3"/>).
ection="4.3"/>). This relies on local name resolution for the "<tt>http</tt>" URI schem
This relies on local name resolution for the "http" URI scheme and the e and the authenticated server
authenticated server identity for the "<tt>https</tt>" scheme.</t>
identity for the "https" scheme.
</t>
</section> </section>
<section> <section>
<name>Cross-Protocol Attacks</name> <name>Cross-Protocol Attacks</name>
<t> <t>In a cross-protocol attack, an attacker causes a client to initiate a
In a cross-protocol attack, an attacker causes a client to initiate a transaction in one
transaction in one
protocol toward a server that understands a different protocol. An at tacker might be able protocol toward a server that understands a different protocol. An at tacker might be able
to cause the transaction to appear as a valid transaction in the secon d protocol. In to cause the transaction to appear as a valid transaction in the secon d protocol. In
combination with the capabilities of the web context, this can be used to interact with combination with the capabilities of the web context, this can be used to interact with
poorly protected servers in private networks. poorly protected servers in private networks.</t>
</t> <t>Completing a TLS handshake with an ALPN identifier for HTTP/2 can be
<t> considered sufficient
Completing a TLS handshake with an ALPN identifier for HTTP/2 can be c
onsidered sufficient
protection against cross-protocol attacks. ALPN provides a positive i ndication that a protection against cross-protocol attacks. ALPN provides a positive i ndication that a
server is willing to proceed with HTTP/2, which prevents attacks on ot her TLS-based server is willing to proceed with HTTP/2, which prevents attacks on ot her TLS-based
protocols. protocols.</t>
</t> <t>The encryption in TLS makes it difficult for attackers to control the
<t> data that could be
The encryption in TLS makes it difficult for attackers to control the used in a cross-protocol attack on a cleartext protocol.</t>
data that could be <t>The cleartext version of HTTP/2 has minimal protection against cross-
used in a cross-protocol attack on a cleartext protocol. protocol attacks.
</t>
<t>
The cleartext version of HTTP/2 has minimal protection against cross-p
rotocol attacks.
The <xref target="preface">connection preface</xref> contains a string that is The <xref target="preface">connection preface</xref> contains a string that is
designed to confuse HTTP/1.1 servers, but no special protection is off ered for other designed to confuse HTTP/1.1 servers, but no special protection is off ered for other
protocols. protocols.</t>
</t>
</section> </section>
<section> <section>
<name>Intermediary Encapsulation Attacks</name> <name>Intermediary Encapsulation Attacks</name>
<t> <t>HPACK permits encoding of field names and values that might be treate
HPACK permits encoding of field names and values that might be treated d as delimiters in
as delimiters in other HTTP versions. An intermediary that translates an HTTP/2 reques
other HTTP versions. An intermediary that translates an HTTP/2 reques t or response <bcp14>MUST</bcp14>
t or response MUST
validate fields according to the rules in <xref target="HttpHeaders"/> before validate fields according to the rules in <xref target="HttpHeaders"/> before
translating a message to another HTTP version. Translating a field th at includes invalid translating a message to another HTTP version. Translating a field th at includes invalid
delimiters could be used to cause recipients to incorrectly interpret a message, which delimiters could be used to cause recipients to incorrectly interpret a message, which
could be exploited by an attacker. could be exploited by an attacker.</t>
</t> <t><xref target="HttpHeaders"/> does not include specific rules for vali
<t> dation of
<xref target="HttpHeaders"/> does not include specific rules for valid
ation of
pseudo-header fields. If the values of these fields are used, additio nal validation is pseudo-header fields. If the values of these fields are used, additio nal validation is
necessary. This is particularly important where <tt>:scheme</tt>, <tt> necessary. This is particularly important where "<tt>:scheme</tt>", "<
:authority</tt>, and tt>:authority</tt>", and
<tt>:path</tt> are combined to form a single URI string (<xref "<tt>:path</tt>" are combined to form a single URI string <xref target
target="RFC3986"/>). Similar problems might occur when that URI or jus ="RFC3986"/>. Similar problems might occur when that URI or just "<tt>:path</tt>
t <tt>:path</tt> are " is
combined with <tt>:method</tt> to construct a request line (as in <xre combined with "<tt>:method</tt>" to construct a request line (as in <x
f target="HTTP11" ref target="RFC9112" section="3"/>). Simple concatenation is not secure unless t
section="3"/>). Simple concatenation is not secure unless the input va he input values are fully
lues are fully validated.</t>
validated. <t>An intermediary can reject fields that contain invalid field names or
</t> values for other
<t> reasons -- in particular, those fields that do not conform to the HTTP
An intermediary can reject fields that contain invalid field names or ABNF grammar from <xref target="RFC9110" section="5"/>. Intermediaries that do
values for other not perform any validation of fields
reasons, in particular those that do not conform to the HTTP ABNF gram
mar from <xref target="HTTP" section="5"/>. Intermediaries that do not perform a
ny validation of fields
other than the minimum required by <xref target="HttpHeaders"/> could forward messages other than the minimum required by <xref target="HttpHeaders"/> could forward messages
that contain invalid field names or values. that contain invalid field names or values.</t>
</t> <t>An intermediary that receives any fields that require removal before
<t> forwarding
An intermediary that receives any field that requires removal before f (see <xref target="RFC9110" section="7.6.1"/>) <bcp14>MUST</bcp14> rem
orwarding ove or replace those header fields when
(see <xref target="HTTP" section="7.6.1"/>) MUST remove or replace tho
se header fields when
forwarding messages. Additionally, intermediaries should take care whe n forwarding messages forwarding messages. Additionally, intermediaries should take care whe n forwarding messages
containing Content-Length fields to ensure that the message is <xref t containing <tt>Content-Length</tt> fields to ensure that the message i
arget="malformed">well-formed</xref>. s <xref target="malformed">well-formed</xref>.
This ensures that if the message is translated into HTTP/1.1 at any po This ensures that if the message is translated into HTTP/1.1 at any po
int the framing will be correct. int, the framing will be correct.</t>
</t>
</section> </section>
<section> <section>
<name>Cacheability of Pushed Responses</name> <name>Cacheability of Pushed Responses</name>
<t> <t>Pushed responses do not have an explicit request from the client; the
Pushed responses do not have an explicit request from the client; the request
request is provided by the server in the <xref target="PUSH_PROMISE" format="n
is provided by the server in the <xref target="PUSH_PROMISE" format="n one">PUSH_PROMISE</xref> frame.</t>
one">PUSH_PROMISE</xref> frame. <t>Caching responses that are pushed is possible based on the guidance p
</t> rovided by the origin
<t>
Caching responses that are pushed is possible based on the guidance pr
ovided by the origin
server in the Cache-Control header field. However, this can cause iss ues if a single server in the Cache-Control header field. However, this can cause iss ues if a single
server hosts more than one tenant. For example, a server might offer multiple users each server hosts more than one tenant. For example, a server might offer multiple users each
a small portion of its URI space. a small portion of its URI space.</t>
</t> <t>Where multiple tenants share space on the same server, that server <b
<t> cp14>MUST</bcp14> ensure that
Where multiple tenants share space on the same server, that server MUS
T ensure that
tenants are not able to push representations of resources that they do not have authority tenants are not able to push representations of resources that they do not have authority
over. Failure to enforce this would allow a tenant to provide a repre sentation that would over. Failure to enforce this would allow a tenant to provide a repre sentation that would
be served out of cache, overriding the actual representation that the authoritative tenant be served out of cache, overriding the actual representation that the authoritative tenant
provides. provides.</t>
</t> <t>Pushed responses for which an origin server is not authoritative (see
<t> <xref target="authority"/>) <bcp14>MUST NOT</bcp14> be used or cached.
Pushed responses for which an origin server is not authoritative (see </t>
<xref target="authority"/>) MUST NOT be used or cached.
</t>
</section> </section>
<section anchor="dos"> <section anchor="dos">
<name>Denial-of-Service Considerations</name> <name>Denial-of-Service Considerations</name>
<t> <t>An HTTP/2 connection can demand a greater commitment of resources to
An HTTP/2 connection can demand a greater commitment of resources to o operate than an
perate than an HTTP/1.1 connection. Both field section compression and flow control
HTTP/1.1 connection. The use of field section compression and flow co depend on a
ntrol depend on a commitment of a greater amount of state. Settings for these
commitment of resources for storing a greater amount of state. Settin features ensure that memory commitments for these features are strictl
gs for these y bounded.</t>
features ensure that memory commitments for these features are strictl <t>The number of <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE<
y bounded. /xref> frames is not
</t> constrained in the same fashion. A client that accepts server push <b
<t> cp14>SHOULD</bcp14> limit the
The number of <xref target="PUSH_PROMISE" format="none">PUSH_PROMISE</
xref> frames is not
constrained in the same fashion. A client that accepts server push SH
OULD limit the
number of streams it allows to be in the "reserved (remote)" state. A n excessive number number of streams it allows to be in the "reserved (remote)" state. A n excessive number
of server push streams can be treated as a <xref target="StreamErrorHa ndler">stream of server push streams can be treated as a <xref target="StreamErrorHa ndler">stream
error</xref> of type <xref target="ENHANCE_YOUR_CALM" format="none">EN error</xref> of type <xref target="ENHANCE_YOUR_CALM" format="none">EN
HANCE_YOUR_CALM</xref>. HANCE_YOUR_CALM</xref>.</t>
</t> <t>A number of HTTP/2 implementations were found to be vulnerable to den
<t> ial of service <xref target="NFLX-2019-002"/>. Below is a list of known ways th
A number of HTTP/2 implementations were found to be vulnerable to deni at implementations might be
al of service <xref target="NFLX-2019-002"/>. The following lists known ways th subject to denial-of-service attacks:</t>
at implementations might be
subject to denial of service attack:
</t>
<ul> <ul>
<li> <li>
<t> <t>Inefficient tracking of outstanding outbound frames can lead to o
Inefficient tracking of outstanding outbound frames can lead to ov verload if an adversary can
erload if an adversary can
cause large numbers of frames to be enqueued for sending. A peer could use one of cause large numbers of frames to be enqueued for sending. A peer could use one of
several techniques to cause large numbers of frames to be generate several techniques to cause large numbers of frames to be generate
d: d:</t>
</t>
<ul> <ul>
<li> <li>Providing tiny increments to flow control in <xref target="WIN
Providing tiny increments to flow control in <xref target="WINDO DOW_UPDATE" format="none">WINDOW_UPDATE</xref> frames can cause a sender to gene
W_UPDATE" format="none">WINDOW_UPDATE</xref> frames can cause a sender to genera rate a large
te a large number of <xref target="DATA" format="none">DATA</xref> frames.<
number of <xref target="DATA" format="none">DATA</xref> frames. /li>
</li> <li>An endpoint is required to respond to a <xref target="PING" fo
<li> rmat="none">PING</xref> frame.</li>
An endpoint is required to respond to a <xref target="PING" form <li>Each <xref target="SETTINGS" format="none">SETTINGS</xref> fra
at="none">PING</xref> frame. me requires
</li> acknowledgment.</li>
<li> <li>An invalid request (or server push) can cause a peer to send <
Each <xref target="SETTINGS" format="none">SETTINGS</xref> frame xref target="RST_STREAM" format="none">RST_STREAM</xref> frames in response.</li
requires >
acknowledgment.
</li>
<li>
An invalid request (or server push) can cause a peer to send <xr
ef target="RST_STREAM" format="none">RST_STREAM</xref> frames in response.
</li>
</ul> </ul>
</li> </li>
<li> <li>An attacker can provide large amounts of flow-control credit at th
An attacker can provide large amounts of flow control credit at the e HTTP/2 layer but
HTTP/2 layer, but
withhold credit at the TCP layer, preventing frames from being sent. An endpoint that withhold credit at the TCP layer, preventing frames from being sent. An endpoint that
constructs and remembers frames for sending without considering TCP limits might be constructs and remembers frames for sending without considering TCP limits might be
subject to resource exhaustion. subject to resource exhaustion.</li>
</li> <li>Large numbers of small or empty frames can be abused to cause a pe
<li> er to expend time
Large numbers of small or empty frames can be abused to cause a peer
to expend time
processing frame headers. Caution is required here as some uses of small frames are processing frame headers. Caution is required here as some uses of small frames are
entirely legitimate, such as the sending of an empty <xref target="D entirely legitimate, such as the sending of an empty <xref target="D
ATA" ATA" format="none">DATA</xref> or <xref target="CONTINUATION" format="none">CONT
format="none">DATA</xref> or <xref target="CONTINUATION" INUATION</xref> frame at the end of a stream.</li>
format="none">CONTINUATION</xref> frame at the end of a stream. <li>The <xref target="SETTINGS" format="none">SETTINGS</xref> frame mi
</li> ght also be abused to
<li>
The <xref target="SETTINGS" format="none">SETTINGS</xref> frame migh
t also be abused to
cause a peer to expend additional processing time. This might be do ne by pointlessly cause a peer to expend additional processing time. This might be do ne by pointlessly
changing settings, sending multiple undefined settings, or changing the changing settings, sending multiple undefined settings, or changing the
same setting multiple times in the same frame. same setting multiple times in the same frame.</li>
</li> <li>Handling reprioritization with <xref target="PRIORITY" format="non
<li> e">PRIORITY</xref>
Handling reprioritization with <xref target="PRIORITY" format="none" frames can require significant processing time and can lead to overl
>PRIORITY</xref> oad if many <xref target="PRIORITY" format="none">PRIORITY</xref> frames are sen
frames can require significant processing time and can lead to overl t.</li>
oad if many <xref target="PRIORITY" format="none">PRIORITY</xref> frames are sen <li>Field section compression also provides opportunities for an attac
t. ker to waste
</li> processing resources; see <xref target="RFC7541" section="7"/> for m
<li> ore details on
Field section compression also offers some opportunities to waste pr potential abuses.</li>
ocessing resources; see <li>Limits in <xref target="SETTINGS" format="none">SETTINGS</xref> ca
<xref target="COMPRESSION" section="7"/> for more details on potenti nnot be reduced
al abuses.
</li>
<li>
Limits in <xref target="SETTINGS" format="none">SETTINGS</xref> cann
ot be reduced
instantaneously, which leaves an endpoint exposed to behavior from a peer that could instantaneously, which leaves an endpoint exposed to behavior from a peer that could
exceed the new limits. In particular, immediately after establishing a connection, exceed the new limits. In particular, immediately after establishing a connection,
limits set by a server are not known to clients and could be exceede d without being an limits set by a server are not known to clients and could be exceede d without being an
obvious protocol violation. obvious protocol violation.</li>
</li>
</ul> </ul>
<t> <t>Most of the features that might be exploited for denial of service --
Most of the features that might be exploited for denial of service -- such as <xref target="SETTINGS" format="none">SETTINGS</xref> changes, small fr
i.e., <xref target="SETTINGS" format="none">SETTINGS</xref> changes, small frame ames, field section
s, field section
compression -- have legitimate uses. These features become a burden o nly when they are compression -- have legitimate uses. These features become a burden o nly when they are
used unnecessarily or to excess. used unnecessarily or to excess.</t>
</t> <t>An endpoint that doesn't monitor use of these features exposes itself
<t> to a risk of
An endpoint that doesn't monitor use of these features exposes itself denial of service. Implementations <bcp14>SHOULD</bcp14> track the us
to a risk of e of these features and set
denial of service. Implementations SHOULD track the use of these feat limits on their use. An endpoint <bcp14>MAY</bcp14> treat activity th
ures and set at is suspicious as a <xref target="ConnectionErrorHandler">connection error</xr
limits on their use. An endpoint MAY treat activity that is suspiciou ef> of type <xref target="ENHANCE_YOUR_CALM" format="none">ENHANCE_YOUR_CALM</xr
s as a <xref target="ConnectionErrorHandler">connection error</xref> of type <xr ef>.</t>
ef target="ENHANCE_YOUR_CALM" format="none">ENHANCE_YOUR_CALM</xref>.
</t>
<section anchor="MaxFieldBlock"> <section anchor="MaxFieldBlock">
<name>Limits on Field Block Size</name> <name>Limits on Field Block Size</name>
<t> <t>A large <xref target="FieldBlock">field block</xref> can cause an i
A large <xref target="FieldBlock">field block</xref> can cause an im mplementation to
plementation to
commit a large amount of state. Field lines that are critical for r outing can appear commit a large amount of state. Field lines that are critical for r outing can appear
toward the end of a field block, which prevents streaming of fields to their toward the end of a field block, which prevents streaming of fields to their
ultimate destination. This ordering and other reasons, such as ensu ring cache ultimate destination. This ordering and other reasons, such as ensu ring cache
correctness, mean that an endpoint might need to buffer the entire f ield block. Since correctness, mean that an endpoint might need to buffer the entire f ield block. Since
there is no hard limit to the size of a field block, some endpoints could be forced to there is no hard limit to the size of a field block, some endpoints could be forced to
commit a large amount of available memory for field blocks. commit a large amount of available memory for field blocks.</t>
</t> <t>An endpoint can use the <xref target="SETTINGS_MAX_HEADER_LIST_SIZE
<t> " format="none">SETTINGS_MAX_HEADER_LIST_SIZE</xref> to advise peers of
An endpoint can use the <xref target="SETTINGS_MAX_HEADER_LIST_SIZE"
format="none">SETTINGS_MAX_HEADER_LIST_SIZE</xref> to advise peers of
limits that might apply on the size of uncompressed field blocks. T his setting is only advisory, so limits that might apply on the size of uncompressed field blocks. T his setting is only advisory, so
endpoints MAY choose to send field blocks that exceed this limit and risk the endpoints <bcp14>MAY</bcp14> choose to send field blocks that exceed this limit and risk the
request or response being treated as malformed. This setting is spe cific to a request or response being treated as malformed. This setting is spe cific to a
connection, so any request or response could encounter a hop with a lower, unknown connection, so any request or response could encounter a hop with a lower, unknown
limit. An intermediary can attempt to avoid this problem by passing on values presented limit. An intermediary can attempt to avoid this problem by passing on values presented
by different peers, but they are not obliged to do so. by different peers, but they are not obliged to do so.</t>
</t> <t>A server that receives a larger field block than it is willing to h
<t> andle can send an
A server that receives a larger field block than it is willing to ha
ndle can send an
HTTP 431 (Request Header Fields Too Large) status code <xref target= "RFC6585"/>. A HTTP 431 (Request Header Fields Too Large) status code <xref target= "RFC6585"/>. A
client can discard responses that it cannot process. The field bloc client can discard responses that it cannot process. The field bloc
k MUST be processed k <bcp14>MUST</bcp14> be processed
to ensure a consistent connection state, unless the connection is cl to ensure a consistent connection state, unless the connection is cl
osed. osed.</t>
</t>
</section> </section>
<section anchor="connectDos"> <section anchor="connectDos">
<name>CONNECT Issues</name> <name>CONNECT Issues</name>
<t> <t>The CONNECT method can be used to create disproportionate load on a
The CONNECT method can be used to create disproportionate load on a proxy, since stream
proxy, since stream
creation is relatively inexpensive when compared to the creation and maintenance of a creation is relatively inexpensive when compared to the creation and maintenance of a
TCP connection. A proxy might also maintain some resources for a TC P connection beyond TCP connection. A proxy might also maintain some resources for a TC P connection beyond
the closing of the stream that carries the CONNECT request, since th e outgoing TCP the closing of the stream that carries the CONNECT request, since th e outgoing TCP
connection remains in the TIME_WAIT state. Therefore, a proxy canno t rely on connection remains in the TIME_WAIT state. Therefore, a proxy canno t rely on
<xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTING S_MAX_CONCURRENT_STREAMS</xref> alone to limit the resources consumed by <xref target="SETTINGS_MAX_CONCURRENT_STREAMS" format="none">SETTING S_MAX_CONCURRENT_STREAMS</xref> alone to limit the resources consumed by
CONNECT requests. CONNECT requests.</t>
</t>
</section> </section>
</section> </section>
<section> <section>
<name>Use of Compression</name> <name>Use of Compression</name>
<t> <t>Compression can allow an attacker to recover secret data when it is c
Compression can allow an attacker to recover secret data when it is co ompressed in the same
mpressed in the same
context as data under attacker control. HTTP/2 enables compression of field lines context as data under attacker control. HTTP/2 enables compression of field lines
(<xref target="FieldBlock"/>); the following concerns also apply to th e use of HTTP (<xref target="FieldBlock"/>); the following concerns also apply to th e use of HTTP
compressed content-codings (<xref target="HTTP" section="8.4.1"/>). compressed content-codings (<xref target="RFC9110" section="8.4.1"/>).
</t> </t>
<t> <t>There are demonstrable attacks on compression that exploit the charac
There are demonstrable attacks on compression that exploit the charact teristics of the Web
eristics of the web
(e.g., <xref target="BREACH"/>). The attacker induces multiple reques ts containing (e.g., <xref target="BREACH"/>). The attacker induces multiple reques ts containing
varying plaintext, observing the length of the resulting ciphertext in each, which varying plaintext, observing the length of the resulting ciphertext in each, which
reveals a shorter length when a guess about the secret is correct. reveals a shorter length when a guess about the secret is correct.</t>
</t> <t>Implementations communicating on a secure channel <bcp14>MUST NOT</bc
<t> p14> compress content that includes
Implementations communicating on a secure channel MUST NOT compress co
ntent that includes
both confidential and attacker-controlled data unless separate compres sion dictionaries both confidential and attacker-controlled data unless separate compres sion dictionaries
are used for each source of data. Compression MUST NOT be used if the source of data are used for each source of data. Compression <bcp14>MUST NOT</bcp14> be used if the source of data
cannot be reliably determined. Generic stream compression, such as th at provided by TLS, cannot be reliably determined. Generic stream compression, such as th at provided by TLS,
MUST NOT be used with HTTP/2 (see <xref target="TLSUsage"/>). <bcp14>MUST NOT</bcp14> be used with HTTP/2 (see <xref target="TLSUsag
</t> e"/>).</t>
<t> <t>Further considerations regarding the compression of header fields are
Further considerations regarding the compression of header fields are described in <xref target="RFC7541"/>.</t>
described in <xref target="COMPRESSION"/>.
</t>
</section> </section>
<section anchor="padding"> <section anchor="padding">
<name>Use of Padding</name> <name>Use of Padding</name>
<t> <t>Padding within HTTP/2 is not intended as a replacement for general pu
Padding within HTTP/2 is not intended as a replacement for general pur rpose padding, such
pose padding, such as that provided by <xref target="RFC8446">TLS</xref>. Redundant padd
as that provided by <xref target="TLS13">TLS</xref>. Redundant paddin ing could even be
g could even be
counterproductive. Correct application can depend on having specific knowledge of the counterproductive. Correct application can depend on having specific knowledge of the
data that is being padded. data that is being padded.</t>
</t> <t>To mitigate attacks that rely on compression, disabling or limiting c
<t> ompression might be
To mitigate attacks that rely on compression, disabling or limiting co preferable to padding as a countermeasure.</t>
mpression might be <t>Padding can be used to obscure the exact size of frame content and is
preferable to padding as a countermeasure. provided to
</t> mitigate specific attacks within HTTP -- for example, attacks where co
<t> mpressed content
Padding can be used to obscure the exact size of frame content and is includes both attacker-controlled plaintext and secret data (e.g., <xr
provided to ef target="BREACH"/>).</t>
mitigate specific attacks within HTTP, for example, attacks where comp <t>Use of padding can result in less protection than might seem immediat
ressed content ely obvious. At
includes both attacker-controlled plaintext and secret data (e.g., <xr
ef target="BREACH"/>).
</t>
<t>
Use of padding can result in less protection than might seem immediate
ly obvious. At
best, padding only makes it more difficult for an attacker to infer le ngth information by best, padding only makes it more difficult for an attacker to infer le ngth information by
increasing the number of frames an attacker has to observe. Incorrect ly implemented increasing the number of frames an attacker has to observe. Incorrect ly implemented
padding schemes can be easily defeated. In particular, randomized pad ding with a padding schemes can be easily defeated. In particular, randomized pad ding with a
predictable distribution provides very little protection; similarly, p adding frame payloads to a predictable distribution provides very little protection; similarly, p adding frame payloads to a
fixed size exposes information as frame payload sizes cross the fixed- sized boundary, which could fixed size exposes information as frame payload sizes cross the fixed- sized boundary, which could
be possible if an attacker can control plaintext. be possible if an attacker can control plaintext.</t>
</t> <t>Intermediaries <bcp14>SHOULD</bcp14> retain padding for <xref target=
<t> "DATA" format="none">DATA</xref> frames but <bcp14>MAY</bcp14> drop padding
Intermediaries SHOULD retain padding for <xref target="DATA" format="n
one">DATA</xref> frames, but MAY drop padding
for <xref target="HEADERS" format="none">HEADERS</xref> and <xref targ et="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames. A valid reason for an for <xref target="HEADERS" format="none">HEADERS</xref> and <xref targ et="PUSH_PROMISE" format="none">PUSH_PROMISE</xref> frames. A valid reason for an
intermediary to change the amount of padding of frames is to improve t he protections that intermediary to change the amount of padding of frames is to improve t he protections that
padding provides. padding provides.</t>
</t>
</section> </section>
<section> <section>
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t> <t>Several characteristics of HTTP/2 provide an observer an opportunity
Several characteristics of HTTP/2 provide an observer an opportunity t to correlate actions
o correlate actions of a single client or server over time. These include the values of s
of a single client or server over time. These include the value of se ettings, the manner
ttings, the manner
in which flow-control windows are managed, the way priorities are allo cated to streams, in which flow-control windows are managed, the way priorities are allo cated to streams,
the timing of reactions to stimulus, and the handling of any features that are controlled by the timing of reactions to stimulus, and the handling of any features that are controlled by
settings. settings.</t>
</t> <t>As far as these create observable differences in behavior, they could
<t> be used as a basis
As far as these create observable differences in behavior, they could for fingerprinting a specific client, as defined in <xref target="RFC6
be used as a basis 973" section="3.2"/>.</t>
for fingerprinting a specific client, as defined in <xref target="PRIV <t>HTTP/2's preference for using a single TCP connection allows correlat
ACY" section="3.2"/>. ion of a user's
</t>
<t>
HTTP/2's preference for using a single TCP connection allows correlati
on of a user's
activity on a site. Reusing connections for different origins allows tracking activity on a site. Reusing connections for different origins allows tracking
across those origins. across those origins.</t>
</t> <t>Because the PING and SETTINGS frames solicit immediate responses, the
<t> y can be used by an
Because the PING and SETTINGS frames solicit immediate responses, they
can be used by an
endpoint to measure latency to their peer. This might have privacy im plications in endpoint to measure latency to their peer. This might have privacy im plications in
certain scenarios. certain scenarios.</t>
</t>
</section> </section>
<section> <section>
<name>Remote Timing Attacks</name> <name>Remote Timing Attacks</name>
<t> <t>Remote timing attacks extract secrets from servers by observing varia
Remote timing attacks extract secrets from servers by observing variat tions in the time
ions in the time
that servers take when processing requests that use secrets. HTTP/2 en ables concurrent that servers take when processing requests that use secrets. HTTP/2 en ables concurrent
request creation and processing, which can give attackers better contr ol over when request request creation and processing, which can give attackers better contr ol over when request
processing commences. Multiple HTTP/2 requests can be included in the same IP packet or processing commences. Multiple HTTP/2 requests can be included in the same IP packet or
TLS record. HTTP/2 can therefore make remote timing attacks more effi cient by eliminating TLS record. HTTP/2 can therefore make remote timing attacks more effi cient by eliminating
variability in request delivery, leaving only request order and the de livery of responses variability in request delivery, leaving only request order and the de livery of responses
as sources of timing variability. as sources of timing variability.</t>
</t> <t>Ensuring that processing time is not dependent on the value of a secr
<t> et is the best
Ensuring that processing time is not dependent on the value of secrets defense against any form of timing attack.</t>
is the best defense
against any form of timing attack.
</t>
</section> </section>
</section> </section>
<section anchor="iana"> <section anchor="iana">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t> <t>This revision of HTTP/2 marks the <tt>HTTP2-Settings</tt> header field
This revision of the document marks the <tt>HTTP2-Settings</tt> header f and the
ield and the <tt>h2c</tt> upgrade token, both defined in <xref target="RFC7540"/>, as
<tt>h2c</tt> Upgrade token, both defined in <xref target="RFC7540"/>, as obsolete.</t>
obsolete. <t><xref target="RFC7540" section="11"/> registered the <tt>h2</tt> and <t
</t> t>h2c</tt> ALPN
<t>
<xref target="RFC7540" section="11"/> registered the <tt>h2</tt> and <tt
>h2c</tt> ALPN
identifiers along with the <tt>PRI</tt> HTTP method. RFC 7540 also esta blished a registry identifiers along with the <tt>PRI</tt> HTTP method. RFC 7540 also esta blished a registry
for frame types, settings, and error codes. These registrations and reg istries apply to for frame types, settings, and error codes. These registrations and reg istries apply to
HTTP/2, but are not redefined in this document. HTTP/2, but are not redefined in this document.</t>
</t> <t>IANA has updated references to RFC 7540 in the
<t> following registries to refer to this document: "TLS
IANA is requested to update references to RFC 7540 in the following regi Application-Layer Protocol Negotiation (ALPN) Protocol IDs",
stries to refer to "HTTP/2 Frame Type", "HTTP/2 Settings", "HTTP/2 Error Code",
this document: Application-Layer Protocol Negotiation (ALPN) Protocol ID and "HTTP Method Registry". The registration of the
s, HTTP/2 Frame <tt>PRI</tt> method has been updated to refer to <xref target="preface"/
Type, HTTP/2 Settings, HTTP/2 Error Code, and HTTP Method Registry. The >; all other section numbers have not
registration of the changed.</t>
<tt>PRI</tt> method needs to be updated to refer to <xref target="prefac <t>IANA has changed the policy on those portions of the "HTTP/2
e"/>; all other Frame Type" and "HTTP/2 Settings" registries that were
section numbers have not changed. reserved for Experimental Use in RFC 7540. These portions of
</t> the registries shall operate on the same policy as the
<t> remainder of each registry.</t>
IANA is requested to change the policy on those portions of the "HTTP/2
Frame Type" and
"HTTP/2 Settings" registries that were reserved for Experimental Use in
RFC 7540. These
portions of the registry shall operate on the same policy as the remaind
er of each registry.
</t>
<section anchor="HTTP2-Settings"> <section anchor="HTTP2-Settings">
<name>HTTP2-Settings Header Field Registration</name> <name>HTTP2-Settings Header Field Registration</name>
<t> <t>This section marks the <tt>HTTP2-Settings</tt> header field registere
This section marks the <tt>HTTP2-Settings</tt> header field registered d by <xref target="RFC7540" section="11.5"/> in the "Hypertext Transfer Protocol
by <xref (HTTP) Field Name
target="RFC7540" section="11.5"/> in the Hypertext Transfer Protocol ( Registry" as obsolete. This capability has been removed: see <xref ta
HTTP) Field Name rget="versioning"/>.
Registry as obsolete. This capability has been removed: see <xref tar The registration is updated to include the details as required by <xre
get="versioning"/>. f target="RFC9110" section="18.4"/>:</t>
The registration is updated to include the details as required by <xre
f target="HTTP"
section="18.4"/>:
</t>
<dl newline="false" spacing="normal"> <dl newline="false" spacing="normal">
<dt>Field Name:</dt> <dt>Field Name:</dt>
<dd>HTTP2-Settings</dd> <dd>HTTP2-Settings</dd>
<dt>Status:</dt> <dt>Status:</dt>
<dd>Standard</dd> <dd>obsoleted</dd>
<dt>Ref.:</dt> <dt>Reference:</dt>
<dd> <dd><xref target="RFC7540" section="3.2.1"/></dd>
<xref target="RFC7540" section="3.2.1"/>
</dd>
<dt>Comments:</dt> <dt>Comments:</dt>
<dd>Obsolete; see <xref target="HTTP2-Settings"/> of this document</dd > <dd>Obsolete; see <xref target="HTTP2-Settings"/> of this document.</d d>
</dl> </dl>
</section> </section>
<section anchor="iana-h2c"> <section anchor="iana-h2c">
<name>The h2c Upgrade Token</name> <name>The h2c Upgrade Token</name>
<t> <t>This section records the <tt>h2c</tt> upgrade token registered by <xr
This section records the <tt>h2c</tt> upgrade token registered by <xre ef target="RFC7540" section="11.8"/> in the "Hypertext Transfer Protocol (HTTP)
f target="RFC7540" Upgrade Token Registry" as
section="11.8"/> in the Hypertext Transfer Protocol (HTTP) Upgrade Tok
en Registry as
obsolete. This capability has been removed: see <xref target="version ing"/>. The obsolete. This capability has been removed: see <xref target="version ing"/>. The
registration is updated as follows: registration is updated as follows:</t>
</t>
<dl> <dl>
<dt>Value:</dt><dd>h2c</dd> <dt>Value:</dt>
<dt>Description:</dt><dd>Hypertext Transfer Protocol version 2 (HTTP/2 <dd>h2c</dd>
)</dd> <dt>Description:</dt>
<dt>Expected Version Tokens:</dt><dd>None</dd> <dd>(OBSOLETE) Hypertext Transfer Protocol version 2 (HTTP/2)</dd>
<dt>Reference:</dt><dd><xref target="versioning"/> of this document</d <dt>Expected Version Tokens:</dt>
d> <dd>None</dd>
<dt>Reference:</dt>
<dd><xref target="versioning"/> of this document</dd>
</dl> </dl>
</section> </section>
</section> </section>
</middle> </middle>
<back> <back>
<displayreference target="RFC0793" to="TCP"/>
<displayreference target="RFC5246" to="TLS12"/>
<displayreference target="RFC5289" to="TLS-ECDHE"/>
<displayreference target="RFC6066" to="TLS-EXT"/>
<displayreference target="RFC6265" to="COOKIE"/>
<displayreference target="RFC6973" to="PRIVACY"/>
<displayreference target="RFC7301" to="TLS-ALPN"/>
<displayreference target="RFC7525" to="TLSBCP"/>
<displayreference target="RFC7541" to="COMPRESSION"/>
<displayreference target="RFC7838" to="ALT-SVC"/>
<displayreference target="RFC8446" to="TLS13"/>
<displayreference target="RFC8499" to="DNS-TERMS"/>
<displayreference target="RFC9000" to="QUIC"/>
<displayreference target="RFC9110" to="HTTP"/>
<displayreference target="RFC9111" to="CACHING"/>
<displayreference target="RFC9112" to="HTTP/1.1"/>
<displayreference target="RFC9218" to="HTTP-PRIORITY"/>
<references> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="COMPRESSION"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.0793.xml"/>
<title>HPACK: Header Compression for HTTP/2</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="RFC" value="7541"/> FC.2119.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7541"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="R." surname="Peon" fullname="Roberto Peon"/> FC.3986.xml"/>
<author initials="H." surname="Ruellan" fullname="Herve Ruellan"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date month="May" year="2015"/> FC.5246.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.5289.xml"/>
<reference anchor="TCP"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6066.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.6265.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7301.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7525.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.7541.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8174.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8422.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8446.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.8470.xml"/>
<xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
FC.9000.xml"/>
<!-- draft-ietf-httpbis-semantics (RFC 9110) -->
<reference anchor="RFC9110" target="https://www.rfc-editor.org/info/rfc9
110">
<front> <front>
<title abbrev="Transmission Control Protocol"> <title>HTTP Semantics</title>
Transmission Control Protocol <author initials="R" surname="Fielding" fullname="Roy Fielding" role
</title> ="editor">
<seriesInfo name="STD" value="7"/> <organization/>
<seriesInfo name="RFC" value="793"/>
<seriesInfo name="DOI" value="10.17487/RFC793"/>
<author initials="J." surname="Postel" fullname="Jon Postel">
<organization>University of Southern California (USC)/Information
Sciences
Institute</organization>
</author> </author>
<date year="1981" month="September"/> <author initials="M" surname="Nottingham" fullname="Mark Nottingham"
</front> role="editor">
</reference> <organization/>
<reference anchor="TLSBCP">
<front>
<title>Recommendations for Secure Use of Transport Layer Security (T
LS) and Datagram Transport Layer Security (DTLS)</title>
<seriesInfo name="BCP" value="195"/>
<seriesInfo name="RFC" value="7525"/>
<seriesInfo name="DOI" value="10.17487/RFC7525"/>
<author initials="Y." surname="Sheffer" fullname="Yaron Sheffer"/>
<author initials="R." surname="Holz" fullname="Ralph Holz"/>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-An
dre"/>
<date month="May" year="2015"/>
</front>
</reference>
<reference anchor="RFC2119">
<front>
<title>
Key words for use in RFCs to Indicate Requirement Levels
</title>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
<author initials="S." surname="Bradner" fullname="Scott Bradner">
<organization>Harvard University</organization>
<address>
<email>sob@harvard.edu</email>
</address>
</author> </author>
<date month="March" year="1997"/> <author initials="J" surname="Reschke" fullname="Julian Reschke" rol
</front> e="editor">
</reference>
<reference anchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author fullname="B. Leiba" initials="B." surname="Leiba">
<organization/> <organization/>
</author> </author>
<date month="May" year="2017"/> <date year="2022" month="June"/>
</front> </front>
<seriesInfo name="BCP" value="14"/> <seriesInfo name="STD" value="97"/>
<seriesInfo name="RFC" value="8174"/> <seriesInfo name="RFC" value="9110"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/> <seriesInfo name="DOI" value="10.17487/RFC9110"/>
</reference> </reference>
<reference anchor="RFC3986"> <!-- draft-ietf-httpbis-cache (RFC 9111) -->
<front> <reference anchor="RFC9111" target="https://www.rfc-editor.org/info/rfc9
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI) 111">
: Generic
Syntax</title>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Le
e"/>
<author initials="R." surname="Fielding" fullname="Roy T. Fielding"/
>
<author initials="L." surname="Masinter" fullname="Larry Masinter"/>
<date year="2005" month="January"/>
</front>
</reference>
<reference anchor="TLS12">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.2</titl
e>
<seriesInfo name="RFC" value="5246"/>
<seriesInfo name="DOI" value="10.17487/RFC5246"/>
<author initials="T." surname="Dierks" fullname="Tim Dierks"/>
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"/>
<date year="2008" month="August"/>
</front>
</reference>
<reference anchor="TLS13">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</titl
e>
<seriesInfo name="RFC" value="8446"/>
<seriesInfo name="DOI" value="10.17487/RFC8446"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla"/>
<date year="2018" month="August"/>
</front>
</reference>
<reference anchor="RFC8470">
<front>
<title>Using Early Data in HTTP</title>
<seriesInfo name="RFC" value="8470"/>
<seriesInfo name="DOI" value="10.17487/RFC8470"/>
<author initials="M." surname="Thomson" fullname="M. Thomson"/>
<author initials="M." surname="Nottingham" fullname="M. Nottingham"/
>
<author initials="W." surname="Tarreau" fullname="W. Tarreau"/>
<date year="2018" month="September"/>
</front>
</reference>
<reference anchor="TLS-EXT">
<front>
<title>
Transport Layer Security (TLS) Extensions: Extension Definitions
</title>
<seriesInfo name="RFC" value="6066"/>
<seriesInfo name="DOI" value="10.17487/RFC6066"/>
<author initials="D." surname="Eastlake 3rd" fullname="D. Eastlake 3
rd"/>
<date year="2011" month="January"/>
</front>
</reference>
<reference anchor="TLS-ALPN">
<front>
<title>Transport Layer Security (TLS) Application-Layer Protocol Neg
otiation Extension</title>
<seriesInfo name="RFC" value="7301"/>
<seriesInfo name="DOI" value="10.17487/RFC7301"/>
<author initials="S." surname="Friedl" fullname="Stephan Friedl"/>
<author initials="A." surname="Popov" fullname="Andrei Popov"/>
<author initials="A." surname="Langley" fullname="Adam Langley"/>
<author initials="E." surname="Stephan" fullname="Emile Stephan"/>
<date month="July" year="2014"/>
</front>
</reference>
<reference anchor="TLS-ECDHE">
<front>
<title>
TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois
Counter Mode (GCM)
</title>
<seriesInfo name="RFC" value="5289"/>
<seriesInfo name="DOI" value="10.17487/RFC5289"/>
<author initials="E." surname="Rescorla" fullname="E. Rescorla"/>
<date year="2008" month="August"/>
</front>
</reference>
<reference anchor="RFC8422" target="https://www.rfc-editor.org/info/rfc
8422">
<front>
<title>Elliptic Curve Cryptography (ECC) Cipher Suites for Transport
Layer Security (TLS) Versions 1.2 and Earlier</title>
<seriesInfo name="RFC" value="8422"/>
<seriesInfo name="DOI" value="10.17487/RFC8422"/>
<author initials="Y." surname="Nir" fullname="Y. Nir"/>
<author initials="S." surname="Josefsson" fullname="S. Josefsson"/>
<author initials="M." surname="Pegourie-Gonnard" fullname="M. Pegour
ie-Gonnard"/>
<date year="2018" month="August" />
</front>
</reference>
<reference anchor="COOKIE">
<front>
<title>HTTP State Management Mechanism</title>
<seriesInfo name="RFC" value="6265"/>
<seriesInfo name="DOI" value="10.17487/RFC6265"/>
<author initials="A." surname="Barth" fullname="A. Barth"/>
<date year="2011" month="April"/>
</front>
</reference>
<reference anchor="HTTP">
<front>
<title>HTTP Semantics</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-semantic
s-18"/>
<author fullname="Roy T. Fielding" initials="R." surname="Fielding"
role="editor"/>
<author fullname="Mark Nottingham" initials="M." surname="Nottingham
" role="editor"/>
<author fullname="Julian Reschke" initials="J." surname="Reschke" ro
le="editor"/>
<date year="2021" month="August" day="18"/>
</front>
</reference>
<reference anchor="CACHE">
<front> <front>
<title>HTTP Caching</title> <title>HTTP Caching</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-cache-18 <author initials="R" surname="Fielding" fullname="Roy Fielding" role
"/> ="editor">
<author fullname="Roy T. Fielding" initials="R." surname="Fielding"
role="editor"/>
<author fullname="Mark Nottingham" initials="M." surname="Nottingham
" role="editor"/>
<author fullname="Julian Reschke" initials="J." surname="Reschke" ro
le="editor"/>
<date year="2021" month="August" day="18"/>
</front>
</reference>
<reference anchor="QUIC" target="https://www.rfc-editor.org/info/rfc9000
">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
<author initials="J." surname="Iyengar" fullname="J. Iyengar" role="
editor">
<organization/> <organization/>
</author> </author>
<author initials="M." surname="Thomson" fullname="M. Thomson" role=" editor"> <author initials="M" surname="Nottingham" fullname="Mark Nottingham" role="editor">
<organization/> <organization/>
</author> </author>
<date year="2021" month="May"/> <author initials="J" surname="Reschke" fullname="Julian Reschke" rol
e="editor">
<organization/>
</author>
<date year="2022" month="June"/>
</front> </front>
<seriesInfo name="RFC" value="9000"/> <seriesInfo name="STD" value="98"/>
<seriesInfo name="DOI" value="10.17487/RFC9000"/> <seriesInfo name="RFC" value="9111"/>
<seriesInfo name="DOI" value="10.17487/RFC9111"/>
</reference> </reference>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="RFC7540"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.1122.xml"/>
<title>Hypertext Transfer Protocol Version 2 (HTTP/2)</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="RFC" value="7540"/> FC.3749.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC7540"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="M." surname="Belshe" fullname="M. Belshe"/> FC.6125.xml"/>
<author initials="R." surname="Peon" fullname="R. Peon"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="M." surname="Thomson" fullname="M. Thomson" role=" FC.6585.xml"/>
editor"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<date year="2015" month="May"/> FC.6973.xml"/>
</front> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</reference> FC.7323.xml"/>
<reference anchor="RFC8740"> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<front> FC.7540.xml"/>
<title>Using TLS 1.3 with HTTP/2</title> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<seriesInfo name="RFC" value="8740"/> FC.7838.xml"/>
<seriesInfo name="DOI" value="10.17487/RFC8740"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<author initials="D." surname="Benjamin" fullname="D. Benjamin"/> FC.8441.xml"/>
<date year="2020" month="February"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
</front> FC.8499.xml"/>
</reference> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.R
<reference anchor="HTTP11"> FC.8740.xml"/>
<!-- draft-ietf-httpbis-messaging (RFC 9112) -->
<reference anchor="RFC9112" target="https://www.rfc-editor.org/info/rfc9
112">
<front> <front>
<title>HTTP/1.1</title> <title>HTTP/1.1</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-messagin <author initials="R" surname="Fielding" fullname="Roy Fielding" role
g-18"/> ="editor">
<author fullname="Roy T. Fielding" initials="R." surname="Fielding" <organization/>
role="editor"/> </author>
<author fullname="Mark Nottingham" initials="M." surname="Nottingham <author initials="M" surname="Nottingham" fullname="Mark Nottingham"
" role="editor"/> role="editor">
<author fullname="Julian Reschke" initials="J." surname="Reschke" ro <organization/>
le="editor"/> </author>
<date year="2021" month="August" day="18"/> <author initials="J" surname="Reschke" fullname="Julian Reschke" rol
</front> e="editor">
</reference> <organization/>
<reference anchor="RFC8441"> </author>
<front> <date month="June" year="2022"/>
<title>Bootstrapping WebSockets with HTTP/2</title>
<seriesInfo name="RFC" value="8441"/>
<seriesInfo name="DOI" value="10.17487/RFC8441"/>
<author initials="P." surname="McManus" fullname="P. McManus"/>
<date year="2018" month="September" />
</front>
</reference>
<reference anchor="RFC1122">
<front>
<title>Requirements for Internet Hosts - Communication Layers</title
>
<seriesInfo name="RFC" value="1122"/>
<seriesInfo name="DOI" value="10.17487/RFC1122"/>
<author initials="R." surname="Braden" fullname="Robert T. Braden" r
ole="editor"/>
<date year="1989" month="October"/>
</front>
</reference>
<reference anchor="RFC7323">
<front>
<title>TCP Extensions for High Performance</title>
<seriesInfo name="RFC" value="7323"/>
<seriesInfo name="DOI" value="10.17487/RFC7323"/>
<author initials="D." surname="Borman" fullname="Dave Borman"/>
<author initials="B." surname="Braden" fullname="Bob Braden"/>
<author initials="V." surname="Jacobson" fullname="Van Jacobson"/>
<author initials="R." surname="Scheffenegger" fullname="Richard Sche
ffenegger" role="editor"/>
<date year="2014" month="September"/>
</front>
</reference>
<reference anchor="RFC6125" target="https://www.rfc-editor.org/info/rfc
6125">
<front>
<title>Representation and Verification of Domain-Based Application S
ervice Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Cer
tificates in the Context of Transport Layer Security (TLS)</title>
<seriesInfo name="RFC" value="6125"/>
<seriesInfo name="DOI" value="10.17487/RFC6125"/>
<author initials="P." surname="Saint-Andre" fullname="P. Saint-Andre
"/>
<author initials="J." surname="Hodges" fullname="J. Hodges"/>
<date year="2011" month="March" />
</front>
</reference>
<reference anchor="RFC3749">
<front>
<title>Transport Layer Security Protocol Compression Methods</title>
<seriesInfo name="RFC" value="3749"/>
<seriesInfo name="DOI" value="10.17487/RFC3749"/>
<author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck"/
>
<date year="2004" month="May"/>
</front>
</reference>
<reference anchor="RFC6585">
<front>
<title>Additional HTTP Status Codes</title>
<seriesInfo name="RFC" value="6585"/>
<seriesInfo name="DOI" value="10.17487/RFC6585"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham
"/>
<author initials="R." surname="Fielding" fullname="Roy Fielding"/>
<date year="2012" month="April"/>
</front>
</reference>
<reference anchor="PRIVACY">
<front>
<title>Privacy Considerations for Internet Protocols</title>
<seriesInfo name="RFC" value="6973"/>
<seriesInfo name="DOI" value="10.17487/RFC6973"/>
<author initials="A." surname="Cooper" fullname="A. Cooper"/>
<author initials="H." surname="Tschofenig" fullname="H. Tschofenig"/
>
<author initials="B." surname="Aboba" fullname="B. Aboba"/>
<author initials="J." surname="Peterson" fullname="J. Peterson"/>
<author initials="J." surname="Morris" fullname="J. Morris"/>
<author initials="M." surname="Hansen" fullname="M. Hansen"/>
<author initials="R." surname="Smith" fullname="R. Smith"/>
<date year="2013" month="July"/>
</front> </front>
<seriesInfo name="STD" value="99"/>
<seriesInfo name="RFC" value="9112"/>
<seriesInfo name="DOI" value="10.17487/RFC9112"/>
</reference> </reference>
<reference anchor="TALKING" target="https://www.adambarth.com/papers/201 1/huang-chen-barth-rescorla-jackson.pdf"> <reference anchor="TALKING" target="https://www.adambarth.com/papers/201 1/huang-chen-barth-rescorla-jackson.pdf">
<front> <front>
<title> <title>Talking to Yourself for Fun and Profit</title>
Talking to Yourself for Fun and Profit
</title>
<author initials="L." surname="Huang"/> <author initials="L." surname="Huang"/>
<author initials="E." surname="Chen"/> <author initials="E." surname="Chen"/>
<author initials="A." surname="Barth"/> <author initials="A." surname="Barth"/>
<author initials="E." surname="Rescorla"/> <author initials="E." surname="Rescorla"/>
<author initials="C." surname="Jackson"/> <author initials="C." surname="Jackson"/>
<date year="2011"/> <date year="2011"/>
</front> </front>
</reference> </reference>
<reference anchor="BREACH" target="https://breachattack.com/resources/BR EACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf"> <reference anchor="BREACH" target="https://breachattack.com/resources/BR EACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf">
<front> <front>
<title> <title>BREACH: Reviving the CRIME Attack</title>
BREACH: Reviving the CRIME Attack
</title>
<author initials="Y." surname="Gluck"/> <author initials="Y." surname="Gluck"/>
<author initials="N." surname="Harris"/> <author initials="N." surname="Harris"/>
<author initials="A." surname="Prado"/> <author initials="A." surname="Prado"/>
<date year="2013" month="July" day="12"/> <date year="2013" month="July" day="12"/>
</front> </front>
</reference> </reference>
<reference anchor="ALT-SVC">
<front>
<title>
HTTP Alternative Services
</title>
<seriesInfo name="RFC" value="7838"/>
<seriesInfo name="DOI" value="10.17487/RFC7838"/>
<author initials="M." surname="Nottingham" fullname="Mark Nottingham
">
<organization>Akamai</organization>
</author>
<author initials="P." surname="McManus" fullname="Patrick McManus">
<organization>Mozilla</organization>
</author>
<author initials="J." surname="Reschke" fullname="Julian Reschke">
<organization>greenbytes</organization>
</author>
<date year="2016" month="April"/>
</front>
</reference>
<reference anchor="DNS-TERMS">
<front>
<title>DNS Terminology</title>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
<author initials="P." surname="Hoffman" fullname="P. Hoffman"/>
<author initials="A." surname="Sullivan" fullname="A. Sullivan"/>
<author initials="K." surname="Fujiwara" fullname="K. Fujiwara"/>
<date year="2019" month="January"/>
</front>
</reference>
<reference anchor="NFLX-2019-002" target="https://github.com/Netflix/sec urity-bulletins/blob/master/advisories/third-party/2019-002.md"> <reference anchor="NFLX-2019-002" target="https://github.com/Netflix/sec urity-bulletins/blob/master/advisories/third-party/2019-002.md">
<front> <front>
<title>HTTP/2 Denial of Service Advisory</title> <title>HTTP/2 Denial of Service Advisory</title>
<author> <author>
<organization>Netflix</organization> <organization>Netflix</organization>
</author> </author>
<date year="2019" month="August" day="13"/> <date year="2019" month="August" day="13"/>
</front> </front>
</reference> </reference>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/draft-ietf-ht
tpbis-priority/xml"/> <!-- draft-ietf-httpbis-priority (RFC 9218) -->
<reference anchor="RFC9218" target="https://www.rfc-editor.org/info/rfc9
218">
<front>
<title>Extensible Prioritization Scheme for HTTP</title>
<author initials="K" surname="Oku" asciiFullname="Kazuho Oku" fullna
me="奥 一穂"/>
<author initials="L" surname="Pardue" fullname="Lucas Pardue"/>
<date year="2022" month="June"/>
</front>
<seriesInfo name="RFC" value="9218"/>
<seriesInfo name="DOI" value="10.17487/RFC9218"/>
</reference>
</references> </references>
</references> </references>
<section anchor="BadCipherSuites"> <section anchor="BadCipherSuites">
<name>Prohibited TLS 1.2 Cipher Suites</name> <name>Prohibited TLS 1.2 Cipher Suites</name>
<t> <t>An HTTP/2 implementation <bcp14>MAY</bcp14> treat the negotiation of an
An HTTP/2 implementation MAY treat the negotiation of any of the followi y of the following cipher suites
ng cipher suites
with TLS 1.2 as a <xref target="ConnectionErrorHandler">connection error </xref> of type with TLS 1.2 as a <xref target="ConnectionErrorHandler">connection error </xref> of type
<xref target="INADEQUATE_SECURITY" format="none">INADEQUATE_SECURITY</xr <xref target="INADEQUATE_SECURITY" format="none">INADEQUATE_SECURITY</xr
ef>: ef>:</t>
</t>
<ul spacing="compact"> <ul spacing="compact">
<li>TLS_NULL_WITH_NULL_NULL</li> <li>TLS_NULL_WITH_NULL_NULL</li>
<li>TLS_RSA_WITH_NULL_MD5</li> <li>TLS_RSA_WITH_NULL_MD5</li>
<li>TLS_RSA_WITH_NULL_SHA</li> <li>TLS_RSA_WITH_NULL_SHA</li>
<li>TLS_RSA_EXPORT_WITH_RC4_40_MD5</li> <li>TLS_RSA_EXPORT_WITH_RC4_40_MD5</li>
<li>TLS_RSA_WITH_RC4_128_MD5</li> <li>TLS_RSA_WITH_RC4_128_MD5</li>
<li>TLS_RSA_WITH_RC4_128_SHA</li> <li>TLS_RSA_WITH_RC4_128_SHA</li>
<li>TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5</li> <li>TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5</li>
<li>TLS_RSA_WITH_IDEA_CBC_SHA</li> <li>TLS_RSA_WITH_IDEA_CBC_SHA</li>
<li>TLS_RSA_EXPORT_WITH_DES40_CBC_SHA</li> <li>TLS_RSA_EXPORT_WITH_DES40_CBC_SHA</li>
skipping to change at line 4945 skipping to change at line 3422
<li>TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384</li> <li>TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384</li>
<li>TLS_RSA_WITH_AES_128_CCM</li> <li>TLS_RSA_WITH_AES_128_CCM</li>
<li>TLS_RSA_WITH_AES_256_CCM</li> <li>TLS_RSA_WITH_AES_256_CCM</li>
<li>TLS_RSA_WITH_AES_128_CCM_8</li> <li>TLS_RSA_WITH_AES_128_CCM_8</li>
<li>TLS_RSA_WITH_AES_256_CCM_8</li> <li>TLS_RSA_WITH_AES_256_CCM_8</li>
<li>TLS_PSK_WITH_AES_128_CCM</li> <li>TLS_PSK_WITH_AES_128_CCM</li>
<li>TLS_PSK_WITH_AES_256_CCM</li> <li>TLS_PSK_WITH_AES_256_CCM</li>
<li>TLS_PSK_WITH_AES_128_CCM_8</li> <li>TLS_PSK_WITH_AES_128_CCM_8</li>
<li>TLS_PSK_WITH_AES_256_CCM_8</li> <li>TLS_PSK_WITH_AES_256_CCM_8</li>
</ul> </ul>
<aside><t>Note: This list was assembled from the set of registered TLS cip <aside>
her suites when <t>Note: This list was assembled from the set of registered TLS cipher s
uites when
<xref target="RFC7540"/> was developed. This list includes those cipher s uites that do not <xref target="RFC7540"/> was developed. This list includes those cipher s uites that do not
offer an ephemeral key exchange and those that are based on the TLS null, stream, or block offer an ephemeral key exchange and those that are based on the TLS null, stream, or block
cipher type (as defined in <xref target="TLS12" section="6.2.3"/>). Addit cipher type (as defined in <xref target="RFC5246" section="6.2.3"/>). Add
ional cipher suites itional cipher suites
with these properties could be defined; these would not be explicitly proh with these properties could be defined; these would not be explicitly proh
ibited.</t></aside> ibited.</t>
<t> </aside>
For more details, see <xref target="tls12ciphers"/> <t>For more details, see <xref target="tls12ciphers"/>.</t>
</t>
</section> </section>
<section anchor="revision-updates"> <section anchor="revision-updates">
<name>Changes from RFC 7540</name> <name>Changes from RFC 7540</name>
<t> <t>This revision includes the following substantive changes:</t>
This revision includes the following substantive changes:
</t>
<ul spacing="normal"> <ul spacing="normal">
<li> <li>Use of TLS 1.3 was defined based on <xref target="RFC8740"/>, which
Use of TLS 1.3 was defined based on RFC 8740, which this document obso this document obsoletes.</li>
letes. <li>The priority scheme defined in RFC 7540 is deprecated. Definitions
</li> for the format of the
<li>
The priority scheme defined in RFC 7540 is deprecated. Definitions fo
r the format of the
<xref target="PRIORITY" format="none">PRIORITY</xref> frame and the pr iority fields in the <xref target="PRIORITY" format="none">PRIORITY</xref> frame and the pr iority fields in the
<xref target="HEADERS" format="none">HEADERS</xref> frame have been re tained, plus the <xref target="HEADERS" format="none">HEADERS</xref> frame have been re tained, plus the
rules governing when <xref target="PRIORITY" format="none">PRIORITY</x ref> frames can be rules governing when <xref target="PRIORITY" format="none">PRIORITY</x ref> frames can be
sent and received, but the semantics of these fields are only describe d in RFC 7540. The sent and received, but the semantics of these fields are only describe d in RFC 7540. The
priority signaling scheme from RFC 7540 was not successful. Using the priority signaling scheme from RFC 7540 was not successful. Using the
simpler <xref target="I-D.ietf-httpbis-priority">successor signaling</xref> is simpler signaling
recommended. in <xref target="RFC9218"/> is recommended.</li>
</li> <li>The HTTP/1.1 Upgrade mechanism is deprecated and no longer specified
<li> in this document. It
The HTTP/1.1 Upgrade mechanism is deprecated and no longer specified i
n this document. It
was never widely deployed, with plaintext HTTP/2 users choosing to use the prior-knowledge was never widely deployed, with plaintext HTTP/2 users choosing to use the prior-knowledge
implementation instead. implementation instead.</li>
</li> <li>Validation for field names and values has been narrowed. The valida
<li> tion that is mandatory
Validation for field names and values has been narrowed. The validati for intermediaries is precisely defined, and error reporting for reque
on that is mandatory sts has been amended
for intermediaries is precisely defined and error reporting for reques to encourage sending 400-series status codes.</li>
ts has been amended <li>The ranges of codepoints for settings and frame types that were rese
to encourage sending 400-series status codes. rved for Experimental
</li> Use are now available for general use.</li>
<li> <li>Connection-specific header fields -- which are prohibited -- are mor
The ranges of codepoints for settings and frame types that were reserv e precisely and
ed for "Experimental comprehensively identified.</li>
Use" are now available for general use. <li><tt>Host</tt> and "<tt>:authority</tt>" are no longer permitted to d
</li> isagree.</li>
<li> <li>Rules for sending Dynamic Table Size Update instructions after chang
Connection-specific header fields - which are prohibited - are more pr es in settings have
ecisely and been clarified in <xref target="dynamic-table"/>.</li>
comprehensively identified.
</li>
<li>
<tt>Host</tt> and <tt>:authority</tt> are no longer permitted to disag
ree.
</li>
<li>
Rules for sending Dynamic Table Size Update instructions after changes
in settings have
been clarified in <xref target="dynamic-table"/>.
</li>
</ul> </ul>
<t> <t>Editorial changes are also included. In particular, changes to terminol
Editorial changes are also included. In particular, changes to terminolo ogy and document
gy and document structure are in response to updates to <xref target="RFC9110">core HTTP
structure are in response to updates to <xref target="HTTP">core HTTP
semantics</xref>. Those documents now include some concepts that were fi rst defined in RFC semantics</xref>. Those documents now include some concepts that were fi rst defined in RFC
7540, such as the 421 status code or connection coalescing. 7540, such as the 421 status code or connection coalescing.</t>
</t>
</section>
<section numbered="false">
<name>Contributors</name>
<t>
The previous version of this document was authored by Mike Belshe and Ro
berto Peon.
</t>
</section> </section>
<section numbered="false"> <section numbered="false">
<name>Acknowledgments</name> <name>Acknowledgments</name>
<t> <t>Credit for non-trivial input to this document is owed to a large number
Credit for non-trivial input to this document is owed to a large number of people who have
of people who have contributed to the HTTP Working Group over the years. <xref target="RFC
contributed to the HTTP working group over the years. <xref target="RFC 7540"/> contains a
7540"/> contains a
more extensive list of people that deserve acknowledgment for their cont ributions.</t> more extensive list of people that deserve acknowledgment for their cont ributions.</t>
</section> </section>
<section numbered="false">
<name>Contributors</name>
<t><contact fullname="Mike Belshe"/> and <contact fullname="Roberto Peon"/
> authored the text that this document is based on.</t>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 627 change blocks. 
4201 lines changed or deleted 2726 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/