5022 lines
252 KiB
XML
5022 lines
252 KiB
XML
<?xml version="1.0"?>
|
|
<?xml-stylesheet type="text/xsl" href="lib/rfc2629.xslt"?>
|
|
<?rfc toc="yes" ?>
|
|
<?rfc symrefs="yes" ?>
|
|
<?rfc sortrefs="yes" ?>
|
|
<?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" ?>
|
|
|
|
<rfc ipr="trust200902"
|
|
category="std"
|
|
docName="draft-ietf-httpbis-http2-latest"
|
|
x:maturity-level="proposed"
|
|
xmlns:x="http://purl.org/net/xml2rfc/ext">
|
|
<x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&body=<{ref}>:"/>
|
|
<front>
|
|
<title abbrev="HTTP/2">Hypertext Transfer Protocol version 2</title>
|
|
|
|
<author initials="M." surname="Belshe" fullname="Mike Belshe">
|
|
<organization>Twist</organization>
|
|
<address>
|
|
<email>mbelshe@chromium.org</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author initials="R." surname="Peon" fullname="Roberto Peon">
|
|
<organization>Google, Inc</organization>
|
|
<address>
|
|
<email>fenix@google.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
|
|
<organization>Mozilla</organization>
|
|
<address>
|
|
<postal>
|
|
<street>331 E Evelyn Street</street>
|
|
<city>Mountain View</city>
|
|
<region>CA</region>
|
|
<code>94041</code>
|
|
<country>US</country>
|
|
</postal>
|
|
<email>martin.thomson@gmail.com</email>
|
|
</address>
|
|
</author>
|
|
|
|
<date year="2014" />
|
|
<area>Applications</area>
|
|
<workgroup>HTTPbis</workgroup>
|
|
<keyword>HTTP</keyword>
|
|
<keyword>SPDY</keyword>
|
|
<keyword>Web</keyword>
|
|
|
|
<abstract>
|
|
<t>
|
|
This specification describes an optimized expression of the semantics of the Hypertext
|
|
Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a
|
|
reduced perception of latency by introducing header field compression and allowing multiple
|
|
concurrent messages on the same connection. It also introduces unsolicited push of
|
|
representations from servers to clients.
|
|
</t>
|
|
<t>
|
|
This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.
|
|
HTTP's existing semantics remain unchanged.
|
|
</t>
|
|
</abstract>
|
|
|
|
<note title="Editorial Note (To be removed by RFC Editor)">
|
|
<t>
|
|
Discussion of this draft takes place on the HTTPBIS working group mailing list
|
|
(ietf-http-wg@w3.org), which is archived at <eref
|
|
target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
|
|
</t>
|
|
<t>
|
|
Working Group information can be found at <eref
|
|
target="https://tools.ietf.org/wg/httpbis/"/>; that specific to HTTP/2 are at <eref
|
|
target="https://http2.github.io/"/>.
|
|
</t>
|
|
<t>
|
|
The changes in this draft are summarized in <xref
|
|
target="change.log"/>.
|
|
</t>
|
|
</note>
|
|
|
|
</front>
|
|
|
|
<middle>
|
|
<section anchor="intro" title="Introduction">
|
|
|
|
<t>
|
|
The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the
|
|
HTTP/1.1 message format (<xref target="RFC7230" x:fmt="," x:rel="#http.message"/>) has
|
|
several characteristics that have a negative overall effect on application performance
|
|
today.
|
|
</t>
|
|
<t>
|
|
In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given
|
|
TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed
|
|
request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.1
|
|
clients that need to make many requests typically use multiple connections to a server in
|
|
order to achieve concurrency and thereby reduce latency.
|
|
</t>
|
|
<t>
|
|
Furthermore, HTTP header fields are often repetitive and verbose, causing unnecessary
|
|
network traffic, as well as causing the initial <xref target="TCP">TCP</xref> congestion
|
|
window to quickly fill. This can result in excessive latency when multiple requests are
|
|
made on a new TCP connection.
|
|
</t>
|
|
<t>
|
|
HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an
|
|
underlying connection. Specifically, it allows interleaving of request and response
|
|
messages on the same connection and uses an efficient coding for HTTP header fields. It
|
|
also allows prioritization of requests, letting more important requests complete more
|
|
quickly, further improving performance.
|
|
</t>
|
|
<t>
|
|
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 other flows, and
|
|
longer-lived connections, which in turn leads to better utilization of available network
|
|
capacity.
|
|
</t>
|
|
<t>
|
|
Finally, HTTP/2 also enables more efficient processing of messages through use of binary
|
|
message framing.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="Overview" title="HTTP/2 Protocol Overview">
|
|
<t>
|
|
HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 supports all of the core
|
|
features of HTTP/1.1, but aims to be more efficient in several ways.
|
|
</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, <x:ref>HEADERS</x:ref> and
|
|
<x:ref>DATA</x:ref> frames form the basis of <xref target="HttpSequence">HTTP requests and
|
|
responses</xref>; other frame types like <x:ref>SETTINGS</x:ref>,
|
|
<x:ref>WINDOW_UPDATE</x:ref>, and <x:ref>PUSH_PROMISE</x:ref> are used in support of other
|
|
HTTP/2 features.
|
|
</t>
|
|
<t>
|
|
Multiplexing of requests is achieved by having each HTTP request-response exchange
|
|
associated with its own <xref target="StreamsLayer">stream</xref>. Streams are largely
|
|
independent of each other, so a blocked or stalled request or response does not prevent
|
|
progress on other streams.
|
|
</t>
|
|
<t>
|
|
Flow control and prioritization ensure that it is possible to efficiently use multiplexed
|
|
streams. <xref target="FlowControl">Flow control</xref> helps to ensure that only data that
|
|
can be used by a receiver is transmitted. <xref
|
|
target="StreamPriority">Prioritization</xref> ensures that limited resources can be directed
|
|
to the most important streams first.
|
|
</t>
|
|
<t>
|
|
HTTP/2 adds a new interaction mode, whereby a server can <xref target="PushResources">push
|
|
responses to a client</xref>. Server push allows a server to speculatively send a client
|
|
data that the server anticipates the client will need, trading off some network usage
|
|
against a potential latency gain. The server does this by synthesizing a request, which it
|
|
sends as a <x:ref>PUSH_PROMISE</x:ref> frame. The server is then able to send a response to
|
|
the synthetic request on a separate stream.
|
|
</t>
|
|
<t>
|
|
Frames that contain HTTP header fields are <xref target="HeaderBlock">compressed</xref>.
|
|
HTTP requests can be highly redundant, so compression can reduce the size of requests and
|
|
responses significantly.
|
|
</t>
|
|
|
|
<section title="Document Organization">
|
|
<t>
|
|
The HTTP/2 specification is split into four parts:
|
|
<list style="symbols">
|
|
<t>
|
|
<xref target="starting">Starting HTTP/2</xref> covers how an HTTP/2 connection is
|
|
initiated.
|
|
</t>
|
|
<t>
|
|
The <xref target="FramingLayer">framing</xref> and <xref
|
|
target="StreamsLayer">streams</xref> layers describe the way HTTP/2 frames are
|
|
structured and formed into multiplexed streams.
|
|
</t>
|
|
<t>
|
|
<xref target="FrameTypes">Frame</xref> and <xref target="ErrorCodes">error</xref>
|
|
definitions include details of the frame and error types used in HTTP/2.
|
|
</t>
|
|
<t>
|
|
<xref target="HTTPLayer">HTTP mappings</xref> and <xref target="HttpExtra">additional
|
|
requirements</xref> describe how HTTP semantics are expressed using frames and
|
|
streams.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
While some of the frame and stream layer concepts are isolated from HTTP, this
|
|
specification does not define a completely generic framing layer. The framing and streams
|
|
layers are tailored to the needs of the HTTP protocol and server push.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Conventions and Terminology">
|
|
<t>
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
|
|
NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
|
|
described in <xref target="RFC2119">RFC 2119</xref>.
|
|
</t>
|
|
<t>
|
|
All numeric values are in network byte order. Values are unsigned unless otherwise
|
|
indicated. Literal values are provided in decimal or hexadecimal as appropriate.
|
|
Hexadecimal literals are prefixed with <spanx style="verb">0x</spanx> to distinguish them
|
|
from decimal literals.
|
|
</t>
|
|
<t>
|
|
The following terms are used:
|
|
<list style="hanging">
|
|
<t hangText="client:">
|
|
The endpoint initiating the HTTP/2 connection.
|
|
</t>
|
|
<t hangText="connection:">
|
|
A transport-layer connection between two endpoints.
|
|
</t>
|
|
<t hangText="connection error:">
|
|
An error that affects the entire HTTP/2 connection.
|
|
</t>
|
|
<t hangText="endpoint:">
|
|
Either the client or server of the connection.
|
|
</t>
|
|
<t hangText="frame:">
|
|
The smallest unit of communication within an HTTP/2 connection, consisting of a header
|
|
and a variable-length sequence of octets structured according to the frame type.
|
|
</t>
|
|
<t hangText="peer:">
|
|
An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint
|
|
that is remote to the primary subject of discussion.
|
|
</t>
|
|
<t hangText="receiver:">
|
|
An endpoint that is receiving frames.
|
|
</t>
|
|
<t hangText="sender:">
|
|
An endpoint that is transmitting frames.
|
|
</t>
|
|
<t hangText="server:">
|
|
The endpoint which did not initiate the HTTP/2 connection.
|
|
</t>
|
|
<t hangText="stream:">
|
|
A bi-directional flow of frames across a virtual channel within the HTTP/2 connection.
|
|
</t>
|
|
<t hangText="stream error:">
|
|
An error on the individual HTTP/2 stream.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are defined
|
|
in <xref target="RFC7230" x:fmt="of" x:rel="#intermediaries"/>.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="starting" title="Starting HTTP/2">
|
|
<t>
|
|
An HTTP/2 connection is an application layer protocol running on top of a TCP connection
|
|
(<xref target="TCP"/>). The client is the TCP connection initiator.
|
|
</t>
|
|
<t>
|
|
HTTP/2 uses the same "http" and "https" URI schemes used by HTTP/1.1. HTTP/2 shares the same
|
|
default port numbers: 80 for "http" URIs and 443 for "https" URIs. As a result,
|
|
implementations processing requests for target resource URIs like <spanx
|
|
style="verb">http://example.org/foo</spanx> or <spanx
|
|
style="verb">https://example.com/bar</spanx> are required to first discover whether the
|
|
upstream server (the immediate peer to which the client wishes to establish a connection)
|
|
supports HTTP/2.
|
|
</t>
|
|
|
|
<t>
|
|
The means by which support for HTTP/2 is determined is different for "http" and "https"
|
|
URIs. Discovery for "http" URIs is described in <xref target="discover-http"/>. Discovery
|
|
for "https" URIs is described in <xref target="discover-https"/>.
|
|
</t>
|
|
|
|
<section anchor="versioning" title="HTTP/2 Version Identification">
|
|
<t>
|
|
The protocol defined in this document has two identifiers.
|
|
<list style="symbols">
|
|
<x:lt>
|
|
<t>
|
|
The string "h2" identifies the protocol where HTTP/2 uses <xref
|
|
target="TLS12">TLS</xref>. This identifier is used in the <xref
|
|
target="TLS-ALPN">TLS application layer protocol negotiation extension (ALPN)</xref>
|
|
field and any place that HTTP/2 over TLS is identified.
|
|
</t>
|
|
<t>
|
|
The "h2" string is serialized into an ALPN protocol identifier as the two octet
|
|
sequence: 0x68, 0x32.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt>
|
|
<t>
|
|
The string "h2c" identifies the protocol where HTTP/2 is run over cleartext TCP.
|
|
This identifier is used in the HTTP/1.1 Upgrade header field and any place that
|
|
HTTP/2 over TCP is identified.
|
|
</t>
|
|
</x:lt>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Negotiating "h2" or "h2c" implies the use of the transport, security, framing and message
|
|
semantics described in this document.
|
|
</t>
|
|
<t>
|
|
<cref>RFC Editor's Note: please remove the remainder of this section prior to the
|
|
publication of a final version of this document.</cref>
|
|
</t>
|
|
<t>
|
|
Only implementations of the final, published RFC can identify themselves as "h2" or "h2c".
|
|
Until such an RFC exists, implementations MUST NOT identify themselves using these
|
|
strings.
|
|
</t>
|
|
<t>
|
|
Examples and text throughout the rest of this document use "h2" as a matter of
|
|
editorial convenience only. Implementations of draft versions MUST NOT identify using
|
|
this string.
|
|
</t>
|
|
<t>
|
|
Implementations of draft versions of the protocol MUST add the string "-" and the
|
|
corresponding draft number to the identifier. For example, draft-ietf-httpbis-http2-11
|
|
over TLS is identified using the string "h2-11".
|
|
</t>
|
|
<t>
|
|
Non-compatible experiments that are based on these draft versions MUST append the string
|
|
"-" and an experiment name to the identifier. For example, an experimental implementation
|
|
of packet mood-based encoding based on draft-ietf-httpbis-http2-09 might identify itself
|
|
as "h2-09-emo". Note that any label MUST conform to the "token" syntax defined in
|
|
<xref target="RFC7230" x:fmt="of" x:rel="#field.components"/>. Experimenters are
|
|
encouraged to coordinate their experiments on the ietf-http-wg@w3.org mailing list.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="discover-http" title="Starting HTTP/2 for "http" URIs">
|
|
<t>
|
|
A client that makes a request for an "http" URI without prior knowledge about support for
|
|
HTTP/2 uses the HTTP Upgrade mechanism (<xref target="RFC7230" x:fmt="of"
|
|
x:rel="#header.upgrade"/>). The client makes an HTTP/1.1 request that includes an Upgrade
|
|
header field identifying HTTP/2 with the "h2c" token. The HTTP/1.1 request MUST include
|
|
exactly one <xref target="Http2SettingsHeader">HTTP2-Settings</xref> header field.
|
|
</t>
|
|
<figure>
|
|
<preamble>For example:</preamble>
|
|
<artwork type="message/http; msgtype="request"" x:indent-with=" "><![CDATA[
|
|
GET / HTTP/1.1
|
|
Host: server.example.com
|
|
Connection: Upgrade, HTTP2-Settings
|
|
Upgrade: h2c
|
|
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
|
|
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
Requests that contain an entity body MUST be sent in their entirety before the client can
|
|
send HTTP/2 frames. This means that a large request entity can block the use of the
|
|
connection until it is completely sent.
|
|
</t>
|
|
<t>
|
|
If concurrency of an initial request with subsequent requests is important, an OPTIONS
|
|
request can be used to perform the upgrade to HTTP/2, at the cost of an additional
|
|
round-trip.
|
|
</t>
|
|
<t>
|
|
A server that does not support HTTP/2 can respond to the request as though the Upgrade
|
|
header field were absent:
|
|
</t>
|
|
<figure>
|
|
<artwork type="message/http; msgtype="response"" x:indent-with=" ">
|
|
HTTP/1.1 200 OK
|
|
Content-Length: 243
|
|
Content-Type: text/html
|
|
|
|
...
|
|
</artwork>
|
|
</figure>
|
|
<t>
|
|
A server MUST ignore a "h2" token in an Upgrade header field. Presence of a token with
|
|
"h2" implies HTTP/2 over TLS, which is instead negotiated as described in <xref
|
|
target="discover-https"/>.
|
|
</t>
|
|
<t>
|
|
A server that supports HTTP/2 can accept the upgrade with a 101 (Switching Protocols)
|
|
response. After the empty line that terminates the 101 response, the server can begin
|
|
sending HTTP/2 frames. These frames MUST include a response to the request that initiated
|
|
the Upgrade.
|
|
</t>
|
|
|
|
<figure>
|
|
<preamble>
|
|
For example:
|
|
</preamble>
|
|
<artwork type="message/http; msgtype="response"" x:indent-with=" ">
|
|
HTTP/1.1 101 Switching Protocols
|
|
Connection: Upgrade
|
|
Upgrade: h2c
|
|
|
|
[ HTTP/2 connection ...
|
|
</artwork>
|
|
</figure>
|
|
<t>
|
|
The first HTTP/2 frame sent by the server is a <x:ref>SETTINGS</x:ref> frame (<xref
|
|
target="SETTINGS"/>) as the server connection preface (<xref
|
|
target="ConnectionHeader"/>). Upon receiving the 101 response, the client sends a <xref
|
|
target="ConnectionHeader">connection preface</xref>, which includes a
|
|
<x:ref>SETTINGS</x:ref> frame.
|
|
</t>
|
|
<t>
|
|
The HTTP/1.1 request that is sent prior to upgrade is assigned stream identifier 1 and is
|
|
assigned <xref target="pri-default">default priority values</xref>. Stream 1 is
|
|
implicitly half closed from the client toward the server, since the request is completed
|
|
as an HTTP/1.1 request. After commencing the HTTP/2 connection, stream 1 is used for the
|
|
response.
|
|
</t>
|
|
|
|
<section anchor="Http2SettingsHeader" title="HTTP2-Settings Header Field">
|
|
<t>
|
|
A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one <spanx
|
|
style="verb">HTTP2-Settings</spanx> header field. The <spanx
|
|
style="verb">HTTP2-Settings</spanx> header field is a connection-specific header field
|
|
that includes parameters that govern the HTTP/2 connection, provided in anticipation of
|
|
the server accepting the request to upgrade.
|
|
</t>
|
|
<figure>
|
|
<artwork type="abnf" x:indent-with=" "><![CDATA[
|
|
HTTP2-Settings = token68
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present,
|
|
or if more than one is present. A server MUST NOT send this header field.
|
|
</t>
|
|
|
|
<t>
|
|
The content of the <spanx style="verb">HTTP2-Settings</spanx> header field is the
|
|
payload of a <x:ref>SETTINGS</x:ref> frame (<xref target="SETTINGS"/>), encoded as a
|
|
base64url string (that is, the URL- and filename-safe Base64 encoding described in <xref
|
|
target="RFC4648" x:fmt="of" x:sec="5"/>, with any trailing '=' characters omitted). The
|
|
<xref target="RFC5234">ABNF</xref> production for <spanx style="verb">token68</spanx> is
|
|
defined in <xref target="RFC7235" x:fmt="of" x:rel="#challenge.and.response"/>.
|
|
</t>
|
|
<t>
|
|
Since the upgrade is only intended to apply to the immediate connection, a client
|
|
sending <spanx style="verb">HTTP2-Settings</spanx> MUST also send <spanx
|
|
style="verb">HTTP2-Settings</spanx> as a connection option in the <spanx
|
|
style="verb">Connection</spanx> header field to prevent it from being forwarded
|
|
downstream.
|
|
</t>
|
|
<t>
|
|
A server decodes and interprets these values as it would any other
|
|
<x:ref>SETTINGS</x:ref> frame. <xref target="SettingsSync">Acknowledgement of the
|
|
SETTINGS parameters</xref> is not necessary, since a 101 response serves as implicit
|
|
acknowledgment. Providing these values in the Upgrade request gives a client an
|
|
opportunity to provide parameters prior to receiving any frames from the server.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="discover-https" title="Starting HTTP/2 for "https" URIs">
|
|
<t>
|
|
A client that makes a request to an "https" URI uses <xref target="TLS12">TLS</xref>
|
|
with the <xref target="TLS-ALPN">application layer protocol negotiation extension</xref>.
|
|
</t>
|
|
<t>
|
|
HTTP/2 over TLS uses the "h2" application token. The "h2c" token MUST NOT be sent by a
|
|
client or selected by a server.
|
|
</t>
|
|
<t>
|
|
Once TLS negotiation is complete, both the client and the server send a <xref
|
|
target="ConnectionHeader">connection preface</xref>.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="known-http" title="Starting HTTP/2 with Prior Knowledge">
|
|
<t>
|
|
A client can learn that a particular server supports HTTP/2 by other means. For example,
|
|
<xref target="ALT-SVC"/> describes a mechanism for advertising this capability.
|
|
</t>
|
|
<t>
|
|
A client MAY immediately send HTTP/2 frames to a server that is known to support HTTP/2,
|
|
after the <xref target="ConnectionHeader">connection preface</xref>; a server can
|
|
identify such a connection by the presence of the connection preface. This only affects
|
|
the establishment of HTTP/2 connections over cleartext TCP; implementations that support
|
|
HTTP/2 over TLS MUST use <xref target="TLS-ALPN">protocol negotiation in TLS</xref>.
|
|
</t>
|
|
<t>
|
|
Without additional information, prior support for HTTP/2 is not a strong signal that a
|
|
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
|
|
clustered servers, or for network conditions to change.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="ConnectionHeader" title="HTTP/2 Connection Preface">
|
|
<t>
|
|
Upon establishment of a TCP connection and determination that HTTP/2 will be used by both
|
|
peers, each endpoint MUST send a connection preface as a final confirmation and to
|
|
establish the initial SETTINGS parameters for the HTTP/2 connection. The client and
|
|
server each send a different connection preface.
|
|
</t>
|
|
<t>
|
|
The client connection preface starts with a sequence of 24 octets, which in hex notation
|
|
are:
|
|
</t>
|
|
<figure>
|
|
<artwork type="inline" x:indent-with=" "><![CDATA[
|
|
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
(the string <spanx style="verb">PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n</spanx>). This sequence
|
|
is followed by a <x:ref>SETTINGS</x:ref> frame (<xref target="SETTINGS"/>). The
|
|
<x:ref>SETTINGS</x:ref> frame MAY be empty. The client sends the client connection
|
|
preface immediately upon receipt of a 101 Switching Protocols response (indicating a
|
|
successful upgrade), or as the first application data octets of a TLS connection. If
|
|
starting an HTTP/2 connection with prior knowledge of server support for the protocol, the
|
|
client connection preface is sent upon connection establishment.
|
|
</t>
|
|
<t>
|
|
<list>
|
|
<t>
|
|
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 further frames. Note
|
|
that this does not address the concerns raised in <xref target="TALKING"/>.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
The server connection preface consists of a potentially empty <x:ref>SETTINGS</x:ref>
|
|
frame (<xref target="SETTINGS"/>) that MUST be the first frame the server sends in the
|
|
HTTP/2 connection.
|
|
</t>
|
|
<t>
|
|
The <x:ref>SETTINGS</x:ref> frames received from a peer as part of the connection preface
|
|
MUST be acknowledged (see <xref target="SettingsSync"/>) after sending the connection
|
|
preface.
|
|
</t>
|
|
<t>
|
|
To avoid unnecessary latency, clients are permitted to send additional frames to the
|
|
server immediately after sending the client connection preface, without waiting to receive
|
|
the server connection preface. It is important to note, however, that the server
|
|
connection preface <x:ref>SETTINGS</x:ref> frame might include parameters that necessarily
|
|
alter how a client is expected to communicate with the server. Upon receiving the
|
|
<x:ref>SETTINGS</x:ref> frame, the client is expected to honor any parameters established.
|
|
In some configurations, it is possible for the server to transmit <x:ref>SETTINGS</x:ref>
|
|
before the client sends additional frames, providing an opportunity to avoid this issue.
|
|
</t>
|
|
<t>
|
|
Clients and servers MUST treat an invalid connection preface as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>. A <x:ref>GOAWAY</x:ref> frame (<xref target="GOAWAY"/>)
|
|
MAY be omitted in this case, since an invalid preface indicates that the peer is not using
|
|
HTTP/2.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="FramingLayer" title="HTTP Frames">
|
|
<t>
|
|
Once the HTTP/2 connection is established, endpoints can begin exchanging frames.
|
|
</t>
|
|
|
|
<section anchor="FrameHeader" title="Frame Format">
|
|
<t>
|
|
All frames begin with a fixed 9-octet header followed by a variable-length payload.
|
|
</t>
|
|
<figure title="Frame Layout">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Length (24) |
|
|
+---------------+---------------+---------------+
|
|
| Type (8) | Flags (8) |
|
|
+-+-+-----------+---------------+-------------------------------+
|
|
|R| Stream Identifier (31) |
|
|
+=+=============================================================+
|
|
| Frame Payload (0...) ...
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
The fields of the frame header are defined as:
|
|
<list style="hanging">
|
|
<x:lt hangText="Length:">
|
|
<t>
|
|
The length of the frame payload expressed as an unsigned 24-bit integer. Values
|
|
greater than 2<x:sup>14</x:sup> (16,384) MUST NOT be sent unless the receiver has
|
|
set a larger value for <x:ref>SETTINGS_MAX_FRAME_SIZE</x:ref>.
|
|
</t>
|
|
<t>
|
|
The 9 octets of the frame header are not included in this value.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="Type:">
|
|
<t>
|
|
The 8-bit type of the frame. The frame type determines the format and semantics of
|
|
the frame. Implementations MUST ignore and discard any frame that has a type that
|
|
is unknown.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="Flags:">
|
|
<t>
|
|
An 8-bit field reserved for frame-type specific boolean flags.
|
|
</t>
|
|
<t>
|
|
Flags are assigned semantics specific to the indicated frame type. Flags that have
|
|
no defined semantics for a particular frame type MUST be ignored, and MUST be left
|
|
unset (0) when sending.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="R:">
|
|
<t>
|
|
A reserved 1-bit field. The semantics of this bit are undefined and the bit MUST
|
|
remain unset (0) when sending and MUST be ignored when receiving.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="Stream Identifier:">
|
|
<t>
|
|
A 31-bit stream identifier (see <xref target="StreamIdentifiers"/>). The value 0 is
|
|
reserved for frames that are associated with the connection as a whole as opposed to
|
|
an individual stream.
|
|
</t>
|
|
</x:lt>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
The structure and content of the frame payload is dependent entirely on the frame type.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="FrameSize" title="Frame Size">
|
|
<t>
|
|
The size of a frame payload is limited by the maximum size that a receiver advertises in
|
|
the <x:ref>SETTINGS_MAX_FRAME_SIZE</x:ref> setting. This setting can have any value
|
|
between 2<x:sup>14</x:sup> (16,384) and 2<x:sup>24</x:sup>-1 (16,777,215) octets,
|
|
inclusive.
|
|
</t>
|
|
<t>
|
|
All implementations MUST be capable of receiving and minimally processing frames up to
|
|
2<x:sup>14</x:sup> octets in length, plus the 9 octet <xref target="FrameHeader">frame
|
|
header</xref>. The size of the frame header is not included when describing frame sizes.
|
|
<list style="hanging">
|
|
<t hangText="Note:">
|
|
Certain frame types, such as <xref target="PING">PING</xref>, impose additional limits
|
|
on the amount of payload data allowed.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
If a frame size exceeds any defined limit, or is too small to contain mandatory frame
|
|
data, the endpoint MUST send a <x:ref>FRAME_SIZE_ERROR</x:ref> error. A frame size error
|
|
in a frame that could alter the state of the entire connection MUST be treated as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref>; this includes any frame carrying
|
|
a <xref target="HeaderBlock">header block</xref> (that is, <x:ref>HEADERS</x:ref>,
|
|
<x:ref>PUSH_PROMISE</x:ref>, and <x:ref>CONTINUATION</x:ref>), <x:ref>SETTINGS</x:ref>,
|
|
and any <x:ref>WINDOW_UPDATE</x:ref> frame with a stream identifier of 0.
|
|
</t>
|
|
<t>
|
|
Endpoints are not obligated to use all available space in a frame. Responsiveness can be
|
|
improved by using frames that are smaller than the permitted maximum size. Sending large
|
|
frames can result in delays in sending time-sensitive frames (such
|
|
<x:ref>RST_STREAM</x:ref>, <x:ref>WINDOW_UPDATE</x:ref>, or <x:ref>PRIORITY</x:ref>)
|
|
which if blocked by the transmission of a large frame, could affect performance.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="HeaderBlock" title="Header Compression and Decompression">
|
|
<t>
|
|
Just as in HTTP/1, a header field in HTTP/2 is a name with one or more associated values.
|
|
They are used within HTTP request and response messages as well as server push operations
|
|
(see <xref target="PushResources" />).
|
|
</t>
|
|
<t>
|
|
Header lists are collections of zero or more header fields. When transmitted over a
|
|
connection, a header list is serialized into a header block using <xref
|
|
target="COMPRESSION">HTTP Header Compression</xref>. The serialized header block is then
|
|
divided into one or more octet sequences, called header block fragments, and transmitted
|
|
within the payload of <xref target="HEADERS">HEADERS</xref>, <xref
|
|
target="PUSH_PROMISE">PUSH_PROMISE</xref> or <xref
|
|
target="CONTINUATION">CONTINUATION</xref> frames.
|
|
</t>
|
|
<t>
|
|
The <xref target="COOKIE">Cookie header field</xref> is treated specially by the HTTP
|
|
mapping (see <xref target="CompressCookie"/>).
|
|
</t>
|
|
<t>
|
|
A receiving endpoint reassembles the header block by concatenating its fragments, then
|
|
decompresses the block to reconstruct the header list.
|
|
</t>
|
|
<t>
|
|
A complete header block consists of either:
|
|
<list style="symbols">
|
|
<t>
|
|
a single <x:ref>HEADERS</x:ref> or <x:ref>PUSH_PROMISE</x:ref> frame,
|
|
with the END_HEADERS flag set, or
|
|
</t>
|
|
<t>
|
|
a <x:ref>HEADERS</x:ref> or <x:ref>PUSH_PROMISE</x:ref> frame with the END_HEADERS
|
|
flag cleared and one or more <x:ref>CONTINUATION</x:ref> frames,
|
|
where the last <x:ref>CONTINUATION</x:ref> frame has the END_HEADERS flag set.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Header compression is stateful. One compression context and one decompression context is
|
|
used for the entire connection. Each header block is processed as a discrete unit.
|
|
Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved
|
|
frames of any other type or from any other stream. The last frame in a sequence of
|
|
<x:ref>HEADERS</x:ref> or <x:ref>CONTINUATION</x:ref> frames MUST have the END_HEADERS
|
|
flag set. The last frame in a sequence of <x:ref>PUSH_PROMISE</x:ref> or
|
|
<x:ref>CONTINUATION</x:ref> frames MUST have the END_HEADERS flag set. This allows a
|
|
header block to be logically equivalent to a single frame.
|
|
</t>
|
|
<t>
|
|
Header block fragments can only be sent as the payload of <x:ref>HEADERS</x:ref>,
|
|
<x:ref>PUSH_PROMISE</x:ref> or <x:ref>CONTINUATION</x:ref> frames, because these frames
|
|
carry data that can modify the compression context maintained by a receiver. An endpoint
|
|
receiving <x:ref>HEADERS</x:ref>, <x:ref>PUSH_PROMISE</x:ref> or
|
|
<x:ref>CONTINUATION</x:ref> frames MUST reassemble header blocks and perform decompression
|
|
even if the frames are to be discarded. A receiver MUST terminate the connection with a
|
|
<xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>COMPRESSION_ERROR</x:ref> if it does not decompress a header block.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="StreamsLayer" title="Streams and Multiplexing">
|
|
<t>
|
|
A "stream" is an independent, bi-directional sequence of frames exchanged between the client
|
|
and server within an HTTP/2 connection. Streams have several important characteristics:
|
|
<list style="symbols">
|
|
<t>
|
|
A single HTTP/2 connection can contain multiple concurrently open streams, with either
|
|
endpoint interleaving frames from multiple streams.
|
|
</t>
|
|
<t>
|
|
Streams can be established and used unilaterally or shared by either the client or
|
|
server.
|
|
</t>
|
|
<t>
|
|
Streams can be closed by either endpoint.
|
|
</t>
|
|
<t>
|
|
The order in which frames are sent on a stream is significant. Recipients process frames
|
|
in the order they are received. In particular, the order of <x:ref>HEADERS</x:ref>,
|
|
and <x:ref>DATA</x:ref> frames is semantically significant.
|
|
</t>
|
|
<t>
|
|
Streams are identified by an integer. Stream identifiers are assigned to streams by the
|
|
endpoint initiating the stream.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
|
|
<section anchor="StreamStates" title="Stream States">
|
|
<t>
|
|
The lifecycle of a stream is shown in <xref target="StreamStatesFigure"/>.
|
|
</t>
|
|
|
|
<figure anchor="StreamStatesFigure" title="Stream States">
|
|
<artwork type="drawing">
|
|
<![CDATA[
|
|
+--------+
|
|
PP | | PP
|
|
,--------| idle |--------.
|
|
/ | | \
|
|
v +--------+ v
|
|
+----------+ | +----------+
|
|
| | | H | |
|
|
,---| reserved | | | reserved |---.
|
|
| | (local) | v | (remote) | |
|
|
| +----------+ +--------+ +----------+ |
|
|
| | ES | | ES | |
|
|
| | H ,-------| open |-------. | H |
|
|
| | / | | \ | |
|
|
| v v +--------+ v v |
|
|
| +----------+ | +----------+ |
|
|
| | half | | | half | |
|
|
| | closed | | R | closed | |
|
|
| | (remote) | | | (local) | |
|
|
| +----------+ | +----------+ |
|
|
| | v | |
|
|
| | ES / R +--------+ ES / R | |
|
|
| `----------->| |<-----------' |
|
|
| R | closed | R |
|
|
`-------------------->| |<--------------------'
|
|
+--------+
|
|
|
|
H: HEADERS frame (with implied CONTINUATIONs)
|
|
PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
|
|
ES: END_STREAM flag
|
|
R: RST_STREAM frame
|
|
]]>
|
|
</artwork>
|
|
</figure>
|
|
|
|
<t>
|
|
Note that this diagram shows stream state transitions and the frames and flags that affect
|
|
those transitions only. In this regard, <x:ref>CONTINUATION</x:ref> frames do not result
|
|
in state transitions; they are effectively part of the <x:ref>HEADERS</x:ref> or
|
|
<x:ref>PUSH_PROMISE</x:ref> that they follow. For this purpose, the END_STREAM flag is
|
|
processed as a separate event to the frame that bears it; a <x:ref>HEADERS</x:ref> frame
|
|
with the END_STREAM flag set can cause two state transitions.
|
|
</t>
|
|
<t>
|
|
Both endpoints have a subjective view of the state of a stream that could be different
|
|
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
|
|
states are limited to the "closed" state after sending <x:ref>RST_STREAM</x:ref>, where
|
|
frames might be received for some time after closing.
|
|
</t>
|
|
<t>
|
|
Streams have the following states:
|
|
<list style="hanging">
|
|
|
|
<x:lt hangText="idle:">
|
|
<t>
|
|
<vspace blankLines="0"/>
|
|
All streams start in the "idle" state. In this state, no frames have been
|
|
exchanged.
|
|
</t>
|
|
<t>
|
|
The following transitions are valid from this state:
|
|
<list style="symbols">
|
|
<t>
|
|
Sending or receiving a <x:ref>HEADERS</x:ref> frame causes the stream to become
|
|
"open". The stream identifier is selected as described in <xref
|
|
target="StreamIdentifiers"/>. The same <x:ref>HEADERS</x:ref> frame can also
|
|
cause a stream to immediately become "half closed".
|
|
</t>
|
|
<t>
|
|
Sending a <x:ref>PUSH_PROMISE</x:ref> frame marks the associated stream for
|
|
later use. The stream state for the reserved stream transitions to "reserved
|
|
(local)".
|
|
</t>
|
|
<t>
|
|
Receiving a <x:ref>PUSH_PROMISE</x:ref> frame marks the associated stream as
|
|
reserved by the remote peer. The state of the stream becomes "reserved
|
|
(remote)".
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Receiving any frames other than <x:ref>HEADERS</x:ref> or
|
|
<x:ref>PUSH_PROMISE</x:ref> on a stream in this state MUST be treated as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
|
|
<x:lt hangText="reserved (local):">
|
|
<t>
|
|
<vspace blankLines="0"/>
|
|
A stream in the "reserved (local)" state is one that has been promised by sending a
|
|
<x:ref>PUSH_PROMISE</x:ref> frame. A <x:ref>PUSH_PROMISE</x:ref> frame reserves an
|
|
idle stream by associating the stream with an open stream that was initiated by the
|
|
remote peer (see <xref target="PushResources"/>).
|
|
</t>
|
|
<t>
|
|
In this state, only the following transitions are possible:
|
|
<list style="symbols">
|
|
<t>
|
|
The endpoint can send a <x:ref>HEADERS</x:ref> frame. This causes the stream to
|
|
open in a "half closed (remote)" state.
|
|
</t>
|
|
<t>
|
|
Either endpoint can send a <x:ref>RST_STREAM</x:ref> frame to cause the stream
|
|
to become "closed". This releases the stream reservation.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
An endpoint MUST NOT send any type of frame other than <x:ref>HEADERS</x:ref> or
|
|
<x:ref>RST_STREAM</x:ref> in this state.
|
|
</t>
|
|
<t>
|
|
A <x:ref>PRIORITY</x:ref> frame MAY be received in this state. Receiving any type
|
|
of frame other than <x:ref>RST_STREAM</x:ref> or <x:ref>PRIORITY</x:ref> on a stream
|
|
in this state MUST be treated as a <xref target="ConnectionErrorHandler">connection
|
|
error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
|
|
<x:lt hangText="reserved (remote):">
|
|
<t>
|
|
<vspace blankLines="0"/>
|
|
A stream in the "reserved (remote)" state has been reserved by a remote peer.
|
|
</t>
|
|
<t>
|
|
In this state, only the following transitions are possible:
|
|
<list style="symbols">
|
|
<t>
|
|
Receiving a <x:ref>HEADERS</x:ref> frame causes the stream to transition to
|
|
"half closed (local)".
|
|
</t>
|
|
<t>
|
|
Either endpoint can send a <x:ref>RST_STREAM</x:ref> frame to cause the stream
|
|
to become "closed". This releases the stream reservation.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
An endpoint MAY send a <x:ref>PRIORITY</x:ref> frame in this state to reprioritize
|
|
the reserved stream. An endpoint MUST NOT send any type of frame other than
|
|
<x:ref>RST_STREAM</x:ref>, <x:ref>WINDOW_UPDATE</x:ref>, or <x:ref>PRIORITY</x:ref>
|
|
in this state.
|
|
</t>
|
|
<t>
|
|
Receiving any type of frame other than <x:ref>HEADERS</x:ref> or
|
|
<x:ref>RST_STREAM</x:ref> on a stream in this state MUST be treated as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
|
|
<x:lt hangText="open:">
|
|
<t>
|
|
<vspace blankLines="0"/>
|
|
A stream in the "open" state may be used by both peers to send frames of any type.
|
|
In this state, sending peers observe advertised <xref target="FlowControl">stream
|
|
level flow control limits</xref>.
|
|
</t>
|
|
<t>
|
|
From this state either endpoint can send a frame with an END_STREAM flag set, which
|
|
causes the stream to transition into one of the "half closed" states: an endpoint
|
|
sending an END_STREAM flag causes the stream state to become "half closed (local)";
|
|
an endpoint receiving an END_STREAM flag causes the stream state to become "half
|
|
closed (remote)".
|
|
</t>
|
|
<t>
|
|
Either endpoint can send a <x:ref>RST_STREAM</x:ref> frame from this state, causing
|
|
it to transition immediately to "closed".
|
|
</t>
|
|
</x:lt>
|
|
|
|
<x:lt hangText="half closed (local):">
|
|
<t>
|
|
<vspace blankLines="0"/>
|
|
A stream that is in the "half closed (local)" state cannot be used for sending
|
|
frames. Only <x:ref>WINDOW_UPDATE</x:ref>, <x:ref>PRIORITY</x:ref> and
|
|
<x:ref>RST_STREAM</x:ref> frames can be sent in this state.
|
|
</t>
|
|
<t>
|
|
A stream transitions from this state to "closed" when a frame that contains an
|
|
END_STREAM flag is received, or when either peer sends a <x:ref>RST_STREAM</x:ref>
|
|
frame.
|
|
</t>
|
|
<t>
|
|
A receiver can ignore <x:ref>WINDOW_UPDATE</x:ref> frames in this state, which might
|
|
arrive for a short period after a frame bearing the END_STREAM flag is sent.
|
|
</t>
|
|
<t>
|
|
<x:ref>PRIORITY</x:ref> frames received in this state are used to reprioritize
|
|
streams that depend on the current stream.
|
|
</t>
|
|
</x:lt>
|
|
|
|
<x:lt hangText="half closed (remote):">
|
|
<t>
|
|
<vspace blankLines="0"/>
|
|
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 maintain a receiver
|
|
flow control window if it performs flow control.
|
|
</t>
|
|
<t>
|
|
If an endpoint receives additional frames for a stream that is in this state, other
|
|
than <x:ref>WINDOW_UPDATE</x:ref>, <x:ref>PRIORITY</x:ref> or
|
|
<x:ref>RST_STREAM</x:ref>, it MUST respond with a <xref
|
|
target="StreamErrorHandler">stream error</xref> of type
|
|
<x:ref>STREAM_CLOSED</x:ref>.
|
|
</t>
|
|
<t>
|
|
A stream that is "half closed (remote)" can be used by the endpoint to send frames
|
|
of any type. In this state, the endpoint continues to observe advertised <xref
|
|
target="FlowControl">stream level flow control limits</xref>.
|
|
</t>
|
|
<t>
|
|
A stream can transition from this state to "closed" by sending a frame that contains
|
|
an END_STREAM flag, or when either peer sends a <x:ref>RST_STREAM</x:ref> frame.
|
|
</t>
|
|
</x:lt>
|
|
|
|
<x:lt hangText="closed:">
|
|
<t>
|
|
<vspace blankLines="0"/>
|
|
The "closed" state is the terminal state.
|
|
</t>
|
|
<t>
|
|
An endpoint MUST NOT send frames other than <x:ref>PRIORITY</x:ref> on a closed
|
|
stream. An endpoint that receives any frame other than <x:ref>PRIORITY</x:ref>
|
|
after receiving a <x:ref>RST_STREAM</x:ref> MUST treat that as a <xref
|
|
target="StreamErrorHandler">stream error</xref> of type
|
|
<x:ref>STREAM_CLOSED</x:ref>. Similarly, an endpoint that receives any frames after
|
|
receiving a frame with the END_STREAM flag set MUST treat that as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>STREAM_CLOSED</x:ref>, unless the frame is permitted as described below.
|
|
</t>
|
|
<t>
|
|
<x:ref>WINDOW_UPDATE</x:ref> or <x:ref>RST_STREAM</x:ref> frames can be received in
|
|
this state for a short period after a <x:ref>DATA</x:ref> or <x:ref>HEADERS</x:ref>
|
|
frame containing an END_STREAM flag is sent. Until the remote peer receives and
|
|
processes <x:ref>RST_STREAM</x:ref> or the frame bearing the END_STREAM flag, it
|
|
might send frames of these types. Endpoints MUST ignore
|
|
<x:ref>WINDOW_UPDATE</x:ref> or <x:ref>RST_STREAM</x:ref> frames received in this
|
|
state, though endpoints MAY choose to treat frames that arrive a significant time
|
|
after sending END_STREAM as a <xref target="ConnectionErrorHandler">connection
|
|
error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
<x:ref>PRIORITY</x:ref> frames can be sent on closed streams to prioritize streams
|
|
that are dependent on the closed stream. Endpoints SHOULD process
|
|
<x:ref>PRIORITY</x:ref> frame, though they can be ignored if the stream has been
|
|
removed from the dependency tree (see <xref target="priority-gc"/>).
|
|
</t>
|
|
<t>
|
|
If this state is reached as a result of sending a <x:ref>RST_STREAM</x:ref> frame,
|
|
the peer that receives the <x:ref>RST_STREAM</x:ref> might have already sent - or
|
|
enqueued for sending - frames on the stream that cannot be withdrawn. An endpoint
|
|
MUST ignore frames that it receives on closed streams after it has sent a
|
|
<x:ref>RST_STREAM</x:ref> frame. An endpoint MAY choose to limit the period over
|
|
which it ignores frames and treat frames that arrive after this time as being in
|
|
error.
|
|
</t>
|
|
<t>
|
|
Flow controlled frames (i.e., <x:ref>DATA</x:ref>) received after sending
|
|
<x:ref>RST_STREAM</x:ref> are counted toward the connection flow control window.
|
|
Even though these frames might be ignored, because they are sent before the sender
|
|
receives the <x:ref>RST_STREAM</x:ref>, the sender will consider the frames to count
|
|
against the flow control window.
|
|
</t>
|
|
<t>
|
|
An endpoint might receive a <x:ref>PUSH_PROMISE</x:ref> frame after it sends
|
|
<x:ref>RST_STREAM</x:ref>. <x:ref>PUSH_PROMISE</x:ref> causes a stream to become
|
|
"reserved" even if the associated stream has been reset. Therefore, a
|
|
<x:ref>RST_STREAM</x:ref> is needed to close an unwanted promised stream.
|
|
</t>
|
|
</x:lt>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
In the absence of more specific guidance elsewhere in this document, implementations
|
|
SHOULD treat the receipt of a frame that is not expressly permitted in the description of
|
|
a state as a <xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>. Frame of unknown types are ignored.
|
|
</t>
|
|
<t>
|
|
An example of the state transitions for an HTTP request/response exchange can be found in
|
|
<xref target="HttpSequence"/>. An example of the state transitions for server push can be
|
|
found in <xref target="PushRequests"/> and <xref target="PushResponses"/>.
|
|
</t>
|
|
|
|
<section anchor="StreamIdentifiers" title="Stream Identifiers">
|
|
<t>
|
|
Streams are identified with an unsigned 31-bit integer. Streams initiated by a client
|
|
MUST use odd-numbered stream identifiers; those initiated by the server MUST use
|
|
even-numbered stream identifiers. A stream identifier of zero (0x0) is used for
|
|
connection control messages; the stream identifier zero cannot be used to establish a
|
|
new stream.
|
|
</t>
|
|
<t>
|
|
HTTP/1.1 requests that are upgraded to HTTP/2 (see <xref target="discover-http"/>) are
|
|
responded to with a stream identifier of one (0x1). After the upgrade
|
|
completes, stream 0x1 is "half closed (local)" to the client. Therefore, stream 0x1
|
|
cannot be selected as a new stream identifier by a client that upgrades from HTTP/1.1.
|
|
</t>
|
|
<t>
|
|
The identifier of a newly established stream MUST be numerically greater than all
|
|
streams that the initiating endpoint has opened or reserved. This governs streams that
|
|
are opened using a <x:ref>HEADERS</x:ref> frame and streams that are reserved using
|
|
<x:ref>PUSH_PROMISE</x:ref>. An endpoint that receives an unexpected stream identifier
|
|
MUST respond with a <xref target="ConnectionErrorHandler">connection error</xref> of
|
|
type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
The first use of a new stream identifier implicitly closes all streams in the "idle"
|
|
state that might have been initiated by that peer with a lower-valued stream identifier.
|
|
For example, if a client sends a <x:ref>HEADERS</x:ref> frame on stream 7 without ever
|
|
sending a frame on stream 5, then stream 5 transitions to the "closed" state when the
|
|
first frame for stream 7 is sent or received.
|
|
</t>
|
|
<t>
|
|
Stream identifiers cannot be reused. Long-lived connections can result in an endpoint
|
|
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
|
|
server that is unable to establish a new stream identifier can send a
|
|
<x:ref>GOAWAY</x:ref> frame so that the client is forced to open a new connection for
|
|
new streams.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Stream Concurrency">
|
|
<t>
|
|
A peer can limit the number of concurrently active streams using the
|
|
<x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> parameter (see <xref
|
|
target="SettingValues"/>) within a <x:ref>SETTINGS</x:ref> frame. The maximum concurrent
|
|
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 concurrent streams the
|
|
server can initiate, and servers specify the maximum number of concurrent streams the
|
|
client can initiate.
|
|
</t>
|
|
<t>
|
|
Streams that are in the "open" state, or either of the "half closed" states count toward
|
|
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
|
|
<x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> setting. Streams in either of the
|
|
"reserved" states do not count toward the stream limit.
|
|
</t>
|
|
<t>
|
|
Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a
|
|
<x:ref>HEADERS</x:ref> frame that causes their advertised concurrent stream limit to be
|
|
exceeded MUST treat this as a <xref target="StreamErrorHandler">stream error</xref>. An
|
|
endpoint that wishes to reduce the value of
|
|
<x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> to a value that is below the current
|
|
number of open streams can either close streams that exceed the new value or allow
|
|
streams to complete.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="FlowControl" title="Flow Control">
|
|
<t>
|
|
Using streams for multiplexing introduces contention over use of the TCP connection,
|
|
resulting in blocked streams. A flow control scheme ensures that streams on the same
|
|
connection do not destructively interfere with each other. Flow control is used for both
|
|
individual streams and for the connection as a whole.
|
|
</t>
|
|
<t>
|
|
HTTP/2 provides for flow control through use of the <xref
|
|
target="WINDOW_UPDATE">WINDOW_UPDATE frame</xref>.
|
|
</t>
|
|
|
|
<section anchor="fc-principles" title="Flow Control Principles">
|
|
<t>
|
|
HTTP/2 stream flow control aims to allow a variety of flow control algorithms to be
|
|
used without requiring protocol changes. Flow control in HTTP/2 has the following
|
|
characteristics:
|
|
<list style="numbers">
|
|
<t>
|
|
Flow control is specific to a connection; i.e., it is "hop-by-hop", not
|
|
"end-to-end".
|
|
</t>
|
|
<t>
|
|
Flow control is based on window update frames. Receivers advertise how many octets
|
|
they are prepared to receive on a stream and for the entire connection. This is a
|
|
credit-based scheme.
|
|
</t>
|
|
<t>
|
|
Flow control is directional with overall control provided by the receiver. A
|
|
receiver MAY choose to set any window size that it desires for each stream and for
|
|
the entire connection. A sender MUST respect flow control limits imposed by a
|
|
receiver. Clients, servers and intermediaries all independently advertise their
|
|
flow control window as a receiver and abide by the flow control limits set by
|
|
their peer when sending.
|
|
</t>
|
|
<t>
|
|
The initial value for the flow control window is 65,535 octets for both new streams
|
|
and the overall connection.
|
|
</t>
|
|
<t>
|
|
The frame type determines whether flow control applies to a frame. Of the frames
|
|
specified in this document, only <x:ref>DATA</x:ref> frames are subject to flow
|
|
control; all other frame types do not consume space in the advertised flow control
|
|
window. This ensures that important control frames are not blocked by flow control.
|
|
</t>
|
|
<t>
|
|
Flow control cannot be disabled.
|
|
</t>
|
|
<t>
|
|
HTTP/2 defines only the format and semantics of the <x:ref>WINDOW_UPDATE</x:ref>
|
|
frame (<xref target="WINDOW_UPDATE"/>). This document does not stipulate how a
|
|
receiver decides when to send this frame or the value that it sends, nor does it
|
|
specify how a sender chooses to send packets. Implementations are able to select
|
|
any algorithm that suits their needs.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Implementations are also responsible for managing how requests and responses are sent
|
|
based on priority; 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 flow control algorithm.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="DisableFlowControl" title="Appropriate Use of Flow Control">
|
|
<t>
|
|
Flow control is defined to protect endpoints that are operating under resource
|
|
constraints. For example, a proxy needs to share memory between many connections, and
|
|
also might have a slow upstream connection and a fast downstream one. Flow control
|
|
addresses cases where the receiver is unable process data on one stream, yet wants to
|
|
continue to process other streams in the same connection.
|
|
</t>
|
|
<t>
|
|
Deployments that do not require this capability can advertise a flow control window of
|
|
the maximum size, incrementing the available space when new data is received. This
|
|
effectively disables flow control for that receiver. Conversely, a sender is always
|
|
subject to the flow control window advertised by the receiver.
|
|
</t>
|
|
<t>
|
|
Deployments with constrained resources (for example, memory) can employ flow control 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 enabled without
|
|
knowledge of the bandwidth-delay product (see <xref target="RFC1323"/>).
|
|
</t>
|
|
<t>
|
|
Even with full awareness of the current bandwidth-delay product, implementation of flow
|
|
control can be difficult. When using flow control, the receiver MUST read from the TCP
|
|
receive buffer in a timely fashion. Failure to do so could lead to a deadlock when
|
|
critical frames, such as <x:ref>WINDOW_UPDATE</x:ref>, are not read and acted upon.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="StreamPriority" title="Stream priority">
|
|
<t>
|
|
A client can assign a priority for a new stream by including prioritization information in
|
|
the <xref target="HEADERS">HEADERS frame</xref> that opens the stream. For an existing
|
|
stream, the <xref target="PRIORITY">PRIORITY frame</xref> can be used to change the
|
|
priority.
|
|
</t>
|
|
<t>
|
|
The purpose of prioritization is to allow an endpoint to express how it would prefer its
|
|
peer allocate resources when managing concurrent streams. Most importantly, priority can
|
|
be used to select streams for transmitting frames when there is limited capacity for
|
|
sending.
|
|
</t>
|
|
<t>
|
|
Streams can be prioritized by marking them as dependent on the completion of other streams
|
|
(<xref target="pri-depend"/>). Each dependency is assigned a relative weight, a number
|
|
that is used to determine the relative proportion of available resources that are assigned
|
|
to streams dependent on the same stream.
|
|
</t>
|
|
<!--
|
|
Note that stream dependencies have not yet been validated in practice. The theory
|
|
might be fairly sound, but there are no implementations currently sending these. If it
|
|
turns out that they are not useful, or actively harmful, implementations will be requested
|
|
to avoid creating stream dependencies.
|
|
-->
|
|
<t>
|
|
Explicitly setting the priority for a stream is input to a prioritization process. It
|
|
does not guarantee any particular processing or transmission order for the stream relative
|
|
to any other stream. An endpoint cannot force a peer to process concurrent streams in a
|
|
particular order using priority. Expressing priority is therefore only ever a suggestion.
|
|
</t>
|
|
<t>
|
|
Providing prioritization information is optional, so default values are used if no
|
|
explicit indicator is provided (<xref target="pri-default"/>).
|
|
</t>
|
|
|
|
<section title="Stream Dependencies" anchor="pri-depend">
|
|
<t>
|
|
Each stream can be given an explicit dependency on another stream. Including a
|
|
dependency expresses a preference to allocate resources to the identified stream rather
|
|
than to the dependent stream.
|
|
</t>
|
|
<t>
|
|
A stream that is not dependent on any other stream is given a stream dependency of 0x0.
|
|
In other words, the non-existent stream 0 forms the root of the tree.
|
|
</t>
|
|
<t>
|
|
A stream that depends on another stream is a dependent stream. The stream upon which a
|
|
stream is dependent is a parent stream. A dependency on a stream that is not currently
|
|
in the tree - such as a stream in the "idle" state - results in that stream being given
|
|
a <xref target="pri-default">default priority</xref>.
|
|
</t>
|
|
<t>
|
|
When assigning a dependency on another stream, the stream is added as a new dependency
|
|
of the parent stream. Dependent streams that share the same parent are not ordered with
|
|
respect to each other. For example, if streams B and C are dependent on stream A, and
|
|
if stream D is created with a dependency on stream A, this results in a dependency order
|
|
of A followed by B, C, and D in any order.
|
|
</t>
|
|
<figure title="Example of Default Dependency Creation">
|
|
<artwork type="inline"><![CDATA[
|
|
A A
|
|
/ \ ==> /|\
|
|
B C B D C
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
An exclusive flag allows for the insertion of a new level of dependencies. The
|
|
exclusive flag causes the stream to become the sole dependency of its parent stream,
|
|
causing other dependencies to become dependent on the exclusive stream. In the
|
|
previous example, if stream D is created with an exclusive dependency on stream A, this
|
|
results in D becoming the dependency parent of B and C.
|
|
</t>
|
|
<figure title="Example of Exclusive Dependency Creation">
|
|
<artwork type="inline"><![CDATA[
|
|
A
|
|
A |
|
|
/ \ ==> D
|
|
B C / \
|
|
B C
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
Inside the dependency tree, a dependent stream SHOULD only be allocated resources if all
|
|
of the streams that it depends on (the chain of parent streams up to 0x0) are either
|
|
closed, or it is not possible to make progress on them.
|
|
</t>
|
|
<t>
|
|
A stream cannot depend on itself. An endpoint MUST treat this as a <xref
|
|
target="StreamErrorHandler">stream error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Dependency Weighting">
|
|
<t>
|
|
All dependent streams are allocated an integer weight between 1 and 256 (inclusive).
|
|
</t>
|
|
<t>
|
|
Streams with the same parent SHOULD be allocated resources proportionally based on their
|
|
weight. Thus, if stream B depends on stream A with weight 4, and C depends on stream A
|
|
with weight 12, and if no progress can be made on A, stream B ideally receives one third
|
|
of the resources allocated to stream C.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="reprioritize" title="Reprioritization">
|
|
<t>
|
|
Stream priorities are changed using the <x:ref>PRIORITY</x:ref> frame. Setting a
|
|
dependency causes a stream to become dependent on the identified parent stream.
|
|
</t>
|
|
<t>
|
|
Dependent streams move with their parent stream if the parent is reprioritized. Setting
|
|
a dependency with the exclusive flag for a reprioritized stream moves all the
|
|
dependencies of the new parent stream to become dependent on the reprioritized stream.
|
|
</t>
|
|
<t>
|
|
If a stream is made dependent on one of its own dependencies, the formerly dependent
|
|
stream is first moved to be dependent on the reprioritized stream's previous parent.
|
|
The moved dependency retains its weight.
|
|
</t>
|
|
<figure title="Example of Dependency Reordering">
|
|
<preamble>
|
|
For example, consider an original dependency tree where B and C depend on A, D and E
|
|
depend on C, and F depends on D. If A is made dependent on D, then D takes the place
|
|
of A. All other dependency relationships stay the same, except for F, which becomes
|
|
dependent on A if the reprioritization is exclusive.
|
|
</preamble>
|
|
<artwork type="inline"><![CDATA[
|
|
? ? ? ?
|
|
| / \ | |
|
|
A D A D D
|
|
/ \ / / \ / \ |
|
|
B C ==> F B C ==> F A OR A
|
|
/ \ | / \ /|\
|
|
D E E B C B C F
|
|
| | |
|
|
F E E
|
|
(intermediate) (non-exclusive) (exclusive)
|
|
]]></artwork>
|
|
</figure>
|
|
</section>
|
|
|
|
<section anchor="priority-gc" title="Prioritization State Management">
|
|
<t>
|
|
When a stream is removed from the dependency tree, its dependencies can be moved to
|
|
become dependent on the parent of the closed stream. The weights of new dependencies
|
|
are recalculated by distributing the weight of the dependency of the closed stream
|
|
proportionally based on the weights of its dependencies.
|
|
</t>
|
|
<t>
|
|
Streams that are removed from the dependency tree cause some prioritization information
|
|
to be lost. Resources are shared between streams with the same parent stream, which
|
|
means that if a stream in that set closes or becomes blocked, any spare capacity
|
|
allocated to a stream is distributed to the immediate neighbors of the stream. However,
|
|
if the common dependency is removed from the tree, those streams share resources with
|
|
streams at the next highest level.
|
|
</t>
|
|
<t>
|
|
For example, assume streams A and B share a parent, and streams C and D both depend on
|
|
stream A. Prior to the removal of stream A, if streams A and D are unable to proceed,
|
|
then stream C receives all the resources dedicated to stream A. If stream A is removed
|
|
from the tree, the weight of stream A is divided between streams C and D. If stream D
|
|
is still unable to proceed, this results in stream C receiving a reduced proportion of
|
|
resources. For equal starting weights, C receives one third, rather than one half, of
|
|
available resources.
|
|
</t>
|
|
<t>
|
|
It is possible for a stream to become closed while prioritization information that
|
|
creates a dependency on that stream is in transit. If a stream identified in a
|
|
dependency has no associated priority information, then the dependent stream is instead
|
|
assigned a <xref target="pri-default">default priority</xref>. This potentially creates
|
|
suboptimal prioritization, since the stream could be given a priority that is different
|
|
to what is intended.
|
|
</t>
|
|
<t>
|
|
To avoid these problems, an endpoint SHOULD retain stream prioritization state for a
|
|
period after streams become closed. The longer state is retained, the lower the chance
|
|
that streams are assigned incorrect or default priority values.
|
|
</t>
|
|
<t>
|
|
This could create a large state burden for an endpoint, so this state MAY be limited.
|
|
An endpoint MAY apply a fixed upper limit on the number of closed streams for which
|
|
prioritization state is tracked to limit state exposure. The amount of additional state
|
|
an endpoint maintains could be dependent on load; under high load, prioritization state
|
|
can be discarded to limit resource commitments. In extreme cases, an endpoint could
|
|
even discard prioritization state for active or reserved streams. If a fixed limit is
|
|
applied, endpoints SHOULD maintain state for at least as many streams as allowed by
|
|
their setting for <x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref>.
|
|
</t>
|
|
<t>
|
|
An endpoint receiving a <x:ref>PRIORITY</x:ref> frame that changes the priority of a
|
|
closed stream SHOULD alter the dependencies of the streams that depend on it, if it has
|
|
retained enough state to do so.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Default Priorities" anchor="pri-default">
|
|
<t>
|
|
Providing priority information is optional. Streams are assigned a non-exclusive
|
|
dependency on stream 0x0 by default. <xref target="PushResources">Pushed streams</xref>
|
|
initially depend on their associated stream. In both cases, streams are assigned a
|
|
default weight of 16.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section title="Error Handling">
|
|
<t>
|
|
HTTP/2 framing permits two classes of error:
|
|
<list style="symbols">
|
|
<t>
|
|
An error condition that renders the entire connection unusable is a connection error.
|
|
</t>
|
|
<t>
|
|
An error in an individual stream is a stream error.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
A list of error codes is included in <xref target="ErrorCodes"/>.
|
|
</t>
|
|
|
|
<section anchor="ConnectionErrorHandler" title="Connection Error Handling">
|
|
<t>
|
|
A connection error is any error which prevents further processing of the framing layer,
|
|
or which corrupts any connection state.
|
|
</t>
|
|
<t>
|
|
An endpoint that encounters a connection error SHOULD first send a <x:ref>GOAWAY</x:ref>
|
|
frame (<xref target="GOAWAY"/>) with the stream identifier of the last stream that it
|
|
successfully received from its peer. The <x:ref>GOAWAY</x:ref> frame includes an error
|
|
code that indicates why the connection is terminating. After sending the
|
|
<x:ref>GOAWAY</x:ref> frame, the endpoint MUST close the TCP connection.
|
|
</t>
|
|
<t>
|
|
It is possible that the <x:ref>GOAWAY</x:ref> will not be reliably received by the
|
|
receiving endpoint (see <xref target="RFC7230" x:fmt=","
|
|
x:rel="#persistent.tear-down"/>). In the event of a connection error,
|
|
<x:ref>GOAWAY</x:ref> only provides a best effort attempt to communicate with the peer
|
|
about why the connection is being terminated.
|
|
</t>
|
|
<t>
|
|
An endpoint can end a connection at any time. In particular, an endpoint MAY choose to
|
|
treat a stream error as a connection error. Endpoints SHOULD send a
|
|
<x:ref>GOAWAY</x:ref> frame when ending a connection, providing that circumstances
|
|
permit it.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="StreamErrorHandler" title="Stream Error Handling">
|
|
<t>
|
|
A stream error is an error related to a specific stream that does not affect processing
|
|
of other streams.
|
|
</t>
|
|
<t>
|
|
An endpoint that detects a stream error sends a <x:ref>RST_STREAM</x:ref> frame (<xref
|
|
target="RST_STREAM"/>) that contains the stream identifier of the stream where the error
|
|
occurred. The <x:ref>RST_STREAM</x:ref> frame includes an error code that indicates the
|
|
type of error.
|
|
</t>
|
|
<t>
|
|
A <x:ref>RST_STREAM</x:ref> is the last frame that an endpoint can send on a stream.
|
|
The peer that sends the <x:ref>RST_STREAM</x:ref> frame MUST be prepared to receive any
|
|
frames that were sent or enqueued for sending by the remote peer. These frames can be
|
|
ignored, except where they modify connection state (such as the state maintained for
|
|
<xref target="HeaderBlock">header compression</xref>, or flow control).
|
|
</t>
|
|
<t>
|
|
Normally, an endpoint SHOULD NOT send more than one <x:ref>RST_STREAM</x:ref> frame for
|
|
any stream. However, an endpoint MAY send additional <x:ref>RST_STREAM</x:ref> frames if
|
|
it receives frames on a closed stream after more than a round-trip time. This behavior
|
|
is permitted to deal with misbehaving implementations.
|
|
</t>
|
|
<t>
|
|
An endpoint MUST NOT send a <x:ref>RST_STREAM</x:ref> in response to an
|
|
<x:ref>RST_STREAM</x:ref> frame, to avoid looping.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Connection Termination">
|
|
<t>
|
|
If the TCP connection is closed or reset while streams remain in open or half closed
|
|
states, then the endpoint MUST assume that those streams were abnormally interrupted and
|
|
could be incomplete.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="extensibility" title="Extending HTTP/2">
|
|
<t>
|
|
HTTP/2 permits extension of the protocol. Protocol extensions can be used to provide
|
|
additional services or alter any aspect of the protocol, within the limitations described
|
|
in this section. Extensions are effective only within the scope of a single HTTP/2
|
|
connection.
|
|
</t>
|
|
<t>
|
|
Extensions are permitted to use new <xref target="FrameHeader">frame types</xref>, new
|
|
<xref target="SettingValues">settings</xref>, or new <xref target="ErrorCodes">error
|
|
codes</xref>. Registries are established for managing these extension points: <xref
|
|
target="iana-frames">frame types</xref>, <xref target="iana-settings">settings</xref> and
|
|
<xref target="iana-errors">error codes</xref>.
|
|
</t>
|
|
<t>
|
|
Implementations MUST ignore unknown or unsupported values in all extensible protocol
|
|
elements. Implementations MUST discard frames that have unknown or unsupported types.
|
|
This means that any of these extension points can be safely used by extensions without
|
|
prior arrangement or negotiation. However, extension frames that appear in the middle of
|
|
a <xref target="HeaderBlock">header block</xref> are not permitted; these MUST be treated
|
|
as a <xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
However, extensions that could change the semantics of existing protocol components MUST
|
|
be negotiated before being used. For example, an extension that changes the layout of the
|
|
<x:ref>HEADERS</x:ref> frame cannot be used until the peer has given a positive signal
|
|
that this is acceptable. In this case, it could also be necessary to coordinate when the
|
|
revised layout comes into effect. Note that treating any frame other than
|
|
<x:ref>DATA</x:ref> frames as flow controlled is such a change in semantics, and can only
|
|
be done through negotiation.
|
|
</t>
|
|
<t>
|
|
This document doesn't mandate a specific method for negotiating the use of an extension,
|
|
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
|
|
the extension can be used. If a setting is used for extension negotiation, the initial
|
|
value MUST be defined so that the extension is initially disabled.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="FrameTypes" title="Frame Definitions">
|
|
<t>
|
|
This specification defines a number of frame types, each identified by a unique 8-bit type
|
|
code. Each frame type serves a distinct purpose either in the establishment and management
|
|
of the connection as a whole, or of individual streams.
|
|
</t>
|
|
<t>
|
|
The transmission of specific frame types can alter the state of a connection. If endpoints
|
|
fail to maintain a synchronized view of the connection state, successful communication
|
|
within the connection will no longer be possible. Therefore, it is important that endpoints
|
|
have a shared comprehension of how the state is affected by the use any given frame.
|
|
</t>
|
|
|
|
<section anchor="DATA" title="DATA">
|
|
<t>
|
|
DATA frames (type=0x0) convey arbitrary, variable-length sequences of octets associated
|
|
with a stream. One or more DATA frames are used, for instance, to carry HTTP request or
|
|
response payloads.
|
|
</t>
|
|
<t>
|
|
DATA frames MAY also contain arbitrary padding. Padding can be added to DATA frames to
|
|
obscure the size of messages.
|
|
</t>
|
|
<figure title="DATA Frame Payload">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|Pad Length? (8)|
|
|
+---------------+-----------------------------------------------+
|
|
| Data (*) ...
|
|
+---------------------------------------------------------------+
|
|
| Padding (*) ...
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
The DATA frame contains the following fields:
|
|
<list style="hanging">
|
|
<t hangText="Pad Length:">
|
|
An 8-bit field containing the length of the frame padding in units of octets. This
|
|
field is optional and is only present if the PADDED flag is set.
|
|
</t>
|
|
<t hangText="Data:">
|
|
Application data. The amount of data is the remainder of the frame payload after
|
|
subtracting the length of the other fields that are present.
|
|
</t>
|
|
<t hangText="Padding:">
|
|
Padding octets that contain no application semantic value. Padding octets MUST be set
|
|
to zero when sending and ignored when receiving.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
The DATA frame defines the following flags:
|
|
<list style="hanging">
|
|
<t hangText="END_STREAM (0x1):">
|
|
Bit 1 being set indicates that this frame is the last that the endpoint will send for
|
|
the identified stream. Setting this flag causes the stream to enter one of <xref
|
|
target="StreamStates">the "half closed" states or the "closed" state</xref>.
|
|
</t>
|
|
<t hangText="PADDED (0x8):">
|
|
Bit 4 being set indicates that the Pad Length field and any padding that it describes
|
|
is present.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
DATA frames MUST be associated with a stream. If a DATA frame is received whose stream
|
|
identifier field is 0x0, the recipient MUST respond with a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
DATA frames are subject to flow control and can only be sent when a stream is in the
|
|
"open" or "half closed (remote)" states. The entire DATA frame payload is included in flow
|
|
control, including 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 recipient MUST respond
|
|
with a <xref target="StreamErrorHandler">stream error</xref> of type
|
|
<x:ref>STREAM_CLOSED</x:ref>.
|
|
</t>
|
|
<t>
|
|
The total number of padding octets is determined by the value of the Pad Length field. If
|
|
the length of the padding is greater than the length of the frame payload, the recipient
|
|
MUST treat this as a <xref target="ConnectionErrorHandler">connection error</xref> of
|
|
type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
<list style="hanging">
|
|
<t hangText="Note:">
|
|
A frame can be increased in size by one octet by including a Pad Length field with a
|
|
value of zero.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Padding is a security feature; see <xref target="padding"/>.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="HEADERS" title="HEADERS">
|
|
<t>
|
|
The HEADERS frame (type=0x1) is used to <xref target="StreamStates">open a stream</xref>,
|
|
and additionally carries a header block fragment. HEADERS frames can be sent on a stream
|
|
in the "open" or "half closed (remote)" states.
|
|
</t>
|
|
<figure title="HEADERS Frame Payload">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|Pad Length? (8)|
|
|
+-+-------------+-----------------------------------------------+
|
|
|E| Stream Dependency? (31) |
|
|
+-+-------------+-----------------------------------------------+
|
|
| Weight? (8) |
|
|
+-+-------------+-----------------------------------------------+
|
|
| Header Block Fragment (*) ...
|
|
+---------------------------------------------------------------+
|
|
| Padding (*) ...
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
The HEADERS frame payload has the following fields:
|
|
<list style="hanging">
|
|
<t hangText="Pad Length:">
|
|
An 8-bit field containing the length of the frame padding in units of octets. This
|
|
field is only present if the PADDED flag is set.
|
|
</t>
|
|
<t hangText="E:">
|
|
A single bit flag indicates that the stream dependency is exclusive, see <xref
|
|
target="StreamPriority"/>. This field is only present if the PRIORITY flag is set.
|
|
</t>
|
|
<t hangText="Stream Dependency:">
|
|
A 31-bit stream identifier for the stream that this stream depends on, see <xref
|
|
target="StreamPriority"/>. This field is only present if the PRIORITY flag is set.
|
|
</t>
|
|
<t hangText="Weight:">
|
|
An 8-bit weight for the stream, see <xref target="StreamPriority"/>. Add one to the
|
|
value to obtain a weight between 1 and 256. This field is only present if the
|
|
PRIORITY flag is set.
|
|
</t>
|
|
<t hangText="Header Block Fragment:">
|
|
A <xref target="HeaderBlock">header block fragment</xref>.
|
|
</t>
|
|
<t hangText="Padding:">
|
|
Padding octets that contain no application semantic value. Padding octets MUST be set
|
|
to zero when sending and ignored when receiving.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
The HEADERS frame defines the following flags:
|
|
<list style="hanging">
|
|
<x:lt hangText="END_STREAM (0x1):">
|
|
<t>
|
|
Bit 1 being set indicates that the <xref target="HeaderBlock">header block</xref> is
|
|
the last that the endpoint will send for the identified stream. Setting this flag
|
|
causes the stream to enter one of <xref target="StreamStates">"half closed"
|
|
states</xref>.
|
|
</t>
|
|
<t>
|
|
A HEADERS frame carries the END_STREAM flag that signals the end of a stream.
|
|
However, a HEADERS frame with the END_STREAM flag set can be followed by
|
|
<x:ref>CONTINUATION</x:ref> frames on the same stream. Logically, the
|
|
<x:ref>CONTINUATION</x:ref> frames are part of the HEADERS frame.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="END_HEADERS (0x4):">
|
|
<t>
|
|
Bit 3 being set indicates that this frame contains an entire <xref
|
|
target="HeaderBlock">header block</xref> and is not followed by any
|
|
<x:ref>CONTINUATION</x:ref> frames.
|
|
</t>
|
|
<t>
|
|
A HEADERS frame without the END_HEADERS flag set MUST be followed by a
|
|
<x:ref>CONTINUATION</x:ref> frame for the same stream. A receiver MUST treat the
|
|
receipt of any other type of frame or a frame on a different stream as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="PADDED (0x8):">
|
|
<t>
|
|
Bit 4 being set indicates that the Pad Length field and any padding that it
|
|
describes is present.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="PRIORITY (0x20):">
|
|
<t>
|
|
Bit 6 being set indicates that the Exclusive Flag (E), Stream Dependency, and Weight
|
|
fields are present; see <xref target="StreamPriority"/>.
|
|
</t>
|
|
</x:lt>
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
The payload of a HEADERS frame contains a <xref target="HeaderBlock">header block
|
|
fragment</xref>. A header block that does not fit within a HEADERS frame is continued in
|
|
a <xref target="CONTINUATION">CONTINUATION frame</xref>.
|
|
</t>
|
|
|
|
<t>
|
|
HEADERS frames MUST be associated with a stream. If a HEADERS frame is received whose
|
|
stream identifier field is 0x0, the recipient MUST respond with a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
|
|
<t>
|
|
The HEADERS frame changes the connection state as described in <xref
|
|
target="HeaderBlock"/>.
|
|
</t>
|
|
|
|
<t>
|
|
The HEADERS frame includes optional padding. Padding fields and flags are identical to
|
|
those defined for <xref target="DATA">DATA frames</xref>.
|
|
</t>
|
|
<t>
|
|
Prioritization information in a HEADERS frame is logically equivalent to a separate
|
|
<x:ref>PRIORITY</x:ref> frame, but inclusion in HEADERS avoids the potential for churn in
|
|
stream prioritization when new streams are created. Priorization fields in HEADERS frames
|
|
subsequent to the first on a stream <xref target="reprioritize">reprioritize the
|
|
stream</xref>.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="PRIORITY" title="PRIORITY">
|
|
<t>
|
|
The PRIORITY frame (type=0x2) specifies the <xref target="StreamPriority">sender-advised
|
|
priority of a stream</xref>. It can be sent at any time for an existing stream, including
|
|
closed streams. This enables reprioritization of existing streams.
|
|
</t>
|
|
<figure title="PRIORITY Frame Payload">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|E| Stream Dependency (31) |
|
|
+-+-------------+-----------------------------------------------+
|
|
| Weight (8) |
|
|
+-+-------------+
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
The payload of a PRIORITY frame contains the following fields:
|
|
<list style="hanging">
|
|
<t hangText="E:">
|
|
A single bit flag indicates that the stream dependency is exclusive, see <xref
|
|
target="StreamPriority"/>.
|
|
</t>
|
|
<t hangText="Stream Dependency:">
|
|
A 31-bit stream identifier for the stream that this stream depends on, see <xref
|
|
target="StreamPriority"/>.
|
|
</t>
|
|
<t hangText="Weight:">
|
|
An 8-bit weight for the identified stream dependency, see <xref
|
|
target="StreamPriority"/>. Add one to the value to obtain a weight between 1 and 256.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
The PRIORITY frame does not define any flags.
|
|
</t>
|
|
|
|
<t>
|
|
The PRIORITY frame is associated with an existing stream. If a PRIORITY frame is received
|
|
with a stream identifier of 0x0, the recipient MUST respond with a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
The PRIORITY frame can be sent on a stream in any of the "reserved (remote)", "open",
|
|
"half closed (local)", "half closed (remote)", or "closed" states, though it cannot be
|
|
sent between consecutive frames that comprise a single <xref target="HeaderBlock">header
|
|
block</xref>. Note that this frame could arrive after processing or frame sending has
|
|
completed, which would cause it to have no effect on the current stream. For a stream
|
|
that is in the "half closed (remote)" or "closed" - state, this frame can only affect
|
|
processing of the current stream and not frame transmission.
|
|
</t>
|
|
<t>
|
|
The PRIORITY frame is the only frame that can be sent for a stream in the "closed" state.
|
|
This allows for the reprioritization of a group of dependent streams by altering the
|
|
priority of a parent stream, which might be closed. However, a PRIORITY frame sent on a
|
|
closed stream risks being ignored due to the peer having discarded priority state
|
|
information for that stream.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="RST_STREAM" title="RST_STREAM">
|
|
<t>
|
|
The RST_STREAM frame (type=0x3) allows for abnormal termination of a stream. When sent by
|
|
the initiator of a stream, it indicates that they wish to cancel the stream or that an
|
|
error condition has occurred. When sent by the receiver of a stream, it indicates that
|
|
either the receiver is rejecting the stream, requesting that the stream be cancelled, or
|
|
that an error condition has occurred.
|
|
</t>
|
|
<figure title="RST_STREAM Frame Payload">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Error Code (32) |
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
|
|
<t>
|
|
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.
|
|
</t>
|
|
|
|
<t>
|
|
The RST_STREAM frame does not define any flags.
|
|
</t>
|
|
|
|
<t>
|
|
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, with the exception of <x:ref>PRIORITY</x:ref>. However,
|
|
after sending the RST_STREAM, the sending endpoint MUST be prepared to receive and process
|
|
additional frames sent on the stream that might have been sent by the peer prior to the
|
|
arrival of the RST_STREAM.
|
|
</t>
|
|
|
|
<t>
|
|
RST_STREAM frames MUST be associated with a stream. If a RST_STREAM frame is received
|
|
with a stream identifier of 0x0, the recipient MUST treat this as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
|
|
<t>
|
|
RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. If a RST_STREAM
|
|
frame identifying an idle stream is received, the recipient MUST treat this as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="SETTINGS" title="SETTINGS">
|
|
<t>
|
|
The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints
|
|
communicate, such as preferences and constraints on peer behavior. The SETTINGS frame is
|
|
also used to acknowledge the receipt of those parameters. Individually, a SETTINGS
|
|
parameter can also be referred to as a "setting".
|
|
</t>
|
|
<t>
|
|
SETTINGS parameters are not negotiated; they describe characteristics of the sending peer,
|
|
which are used by the receiving peer. Different values for the same parameter can be
|
|
advertised by each peer. For example, a client might set a high initial flow control
|
|
window, whereas a server might set a lower value to conserve resources.
|
|
</t>
|
|
|
|
<t>
|
|
A SETTINGS frame MUST be sent by both endpoints at the start of a connection, and MAY be
|
|
sent at any other time by either endpoint over the lifetime of the connection.
|
|
Implementations MUST support all of the parameters defined by this specification.
|
|
</t>
|
|
|
|
<t>
|
|
Each parameter in a SETTINGS frame replaces any existing value for that parameter.
|
|
Parameters are processed in the order in which they appear, and a receiver of a SETTINGS
|
|
frame does not need to maintain any state other than the current value of its
|
|
parameters. Therefore, the value of a SETTINGS parameter is the last value that is seen by
|
|
a receiver.
|
|
</t>
|
|
<t>
|
|
SETTINGS parameters are acknowledged by the receiving peer. To enable this, the SETTINGS
|
|
frame defines the following flag:
|
|
<list style="hanging">
|
|
<t hangText="ACK (0x1):">
|
|
Bit 1 being set indicates that this frame acknowledges receipt and application of the
|
|
peer's SETTINGS frame. When this bit is set, the payload of the SETTINGS frame MUST
|
|
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="ConnectionErrorHandler">connection
|
|
error</xref> of type <x:ref>FRAME_SIZE_ERROR</x:ref>. For more info, see <xref
|
|
target="SettingsSync">Settings Synchronization</xref>.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
SETTINGS frames always apply to a connection, never a single stream. The stream
|
|
identifier for a SETTINGS frame MUST be zero (0x0). If an endpoint receives a SETTINGS
|
|
frame whose stream identifier field is anything other than 0x0, the endpoint MUST respond
|
|
with a <xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
The SETTINGS frame affects connection state. A badly formed or incomplete SETTINGS frame
|
|
MUST be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
|
|
<section title="SETTINGS Format" anchor="SettingFormat">
|
|
<t>
|
|
The payload of a SETTINGS frame consists of zero or more parameters, each consisting of
|
|
an unsigned 16-bit setting identifier and an unsigned 32-bit value.
|
|
</t>
|
|
|
|
<figure title="Setting Format">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Identifier (16) |
|
|
+-------------------------------+-------------------------------+
|
|
| Value (32) |
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
</section>
|
|
|
|
<section anchor="SettingValues" title="Defined SETTINGS Parameters">
|
|
<t>
|
|
The following parameters are defined:
|
|
<list style="hanging">
|
|
<x:lt hangText="SETTINGS_HEADER_TABLE_SIZE (0x1):"
|
|
anchor="SETTINGS_HEADER_TABLE_SIZE">
|
|
<t>
|
|
Allows the sender to inform the remote endpoint of the maximum size of the header
|
|
compression table used to decode header blocks, in octets. The encoder can select
|
|
any size equal to or less than this value by using signaling specific to the
|
|
header compression format inside a header block. The initial value is 4,096
|
|
octets.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="SETTINGS_ENABLE_PUSH (0x2):"
|
|
anchor="SETTINGS_ENABLE_PUSH">
|
|
<t>
|
|
This setting can be use to disable <xref target="PushResources">server
|
|
push</xref>. An endpoint MUST NOT send a <x:ref>PUSH_PROMISE</x:ref> frame if it
|
|
receives this parameter set to a value of 0. An endpoint that has both set this
|
|
parameter to 0 and had it acknowledged MUST treat the receipt of a
|
|
<x:ref>PUSH_PROMISE</x:ref> frame as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
The initial value is 1, which indicates that server push is permitted. Any value
|
|
other than 0 or 1 MUST be treated as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="SETTINGS_MAX_CONCURRENT_STREAMS (0x3):"
|
|
anchor="SETTINGS_MAX_CONCURRENT_STREAMS">
|
|
<t>
|
|
Indicates the maximum number of concurrent streams that the sender will allow.
|
|
This limit is directional: it applies to the number of streams that the sender
|
|
permits the receiver to create. Initially there is no limit to this value. It is
|
|
recommended that this value be no smaller than 100, so as to not unnecessarily
|
|
limit parallelism.
|
|
</t>
|
|
<t>
|
|
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 streams, however this
|
|
can also happen for any limit that is exhausted with active streams. Servers
|
|
SHOULD only set a zero value for short durations; if a server does not wish to
|
|
accept requests, closing the connection could be preferable.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="SETTINGS_INITIAL_WINDOW_SIZE (0x4):"
|
|
anchor="SETTINGS_INITIAL_WINDOW_SIZE">
|
|
<t>
|
|
Indicates the sender's initial window size (in octets) for stream level flow
|
|
control. The initial value is 2<x:sup>16</x:sup>-1 (65,535) octets.
|
|
</t>
|
|
<t>
|
|
This setting affects the window size of all streams, including existing streams,
|
|
see <xref target="InitialWindowSize"/>.
|
|
</t>
|
|
<t>
|
|
Values above the maximum flow control window size of 2<x:sup>31</x:sup>-1 MUST
|
|
be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of
|
|
type <x:ref>FLOW_CONTROL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="SETTINGS_MAX_FRAME_SIZE (0x5):"
|
|
anchor="SETTINGS_MAX_FRAME_SIZE">
|
|
<t>
|
|
Indicates the size of the largest frame payload that the sender is willing to
|
|
receive, in octets.
|
|
</t>
|
|
<t>
|
|
The initial value is 2<x:sup>14</x:sup> (16,384) octets. The value advertised by
|
|
an endpoint MUST be between this initial value and the maximum allowed frame size
|
|
(2<x:sup>24</x:sup>-1 or 16,777,215 octets), inclusive. Values outside this range
|
|
MUST be treated as a <xref target="ConnectionErrorHandler">connection error</xref>
|
|
of type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="SETTINGS_MAX_HEADER_LIST_SIZE (0x6):"
|
|
anchor="SETTINGS_MAX_HEADER_LIST_SIZE">
|
|
<t>
|
|
This advisory setting informs a peer of the maximum size of header list that the
|
|
sender is prepared to accept, in octets. The value is based on the uncompressed
|
|
size of header fields, including the length of the name and value in octets plus
|
|
an overhead of 32 octets for each header field.
|
|
</t>
|
|
<t>
|
|
For any given request, a lower limit than what is advertised MAY be enforced. The
|
|
initial value of this setting is unlimited.
|
|
</t>
|
|
</x:lt>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier
|
|
MUST ignore that setting.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="SettingsSync" title="Settings Synchronization">
|
|
<t>
|
|
Most values in SETTINGS benefit from or require an understanding of when the peer has
|
|
received and applied the changed parameter values. In order to provide
|
|
such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag
|
|
is not set MUST apply the updated parameters as soon as possible upon receipt.
|
|
</t>
|
|
<t>
|
|
The values in the SETTINGS frame MUST be processed in the order they appear, with no
|
|
other frame processing between values. Unsupported parameters MUST be ignored. Once
|
|
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
|
|
of the altered parameters can rely on the setting having been applied.
|
|
</t>
|
|
<t>
|
|
If the sender of a SETTINGS frame does not receive an acknowledgement within a
|
|
reasonable amount of time, it MAY issue a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>SETTINGS_TIMEOUT</x:ref>.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="PUSH_PROMISE" title="PUSH_PROMISE">
|
|
<t>
|
|
The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint in advance of
|
|
streams the sender intends to initiate. The PUSH_PROMISE frame includes the unsigned
|
|
31-bit identifier of the stream the endpoint plans to create along with a set of headers
|
|
that provide additional context for the stream. <xref target="PushResources"/> contains a
|
|
thorough description of the use of PUSH_PROMISE frames.
|
|
</t>
|
|
|
|
<figure title="PUSH_PROMISE Payload Format">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|Pad Length? (8)|
|
|
+-+-------------+-----------------------------------------------+
|
|
|R| Promised Stream ID (31) |
|
|
+-+-----------------------------+-------------------------------+
|
|
| Header Block Fragment (*) ...
|
|
+---------------------------------------------------------------+
|
|
| Padding (*) ...
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
The PUSH_PROMISE frame payload has the following fields:
|
|
<list style="hanging">
|
|
<t hangText="Pad Length:">
|
|
An 8-bit field containing the length of the frame padding in units of octets. This
|
|
field is only present if the PADDED flag is set.
|
|
</t>
|
|
<t hangText="R:">
|
|
A single reserved bit.
|
|
</t>
|
|
<t hangText="Promised Stream ID:">
|
|
An unsigned 31-bit integer that identifies the stream that is reserved by the
|
|
PUSH_PROMISE. The promised stream identifier MUST be a valid choice for the next
|
|
stream sent by the sender (see <xref target="StreamIdentifiers">new stream
|
|
identifier</xref>).
|
|
</t>
|
|
<t hangText="Header Block Fragment:">
|
|
A <xref target="HeaderBlock">header block fragment</xref> containing request header
|
|
fields.
|
|
</t>
|
|
<t hangText="Padding:">
|
|
Padding octets.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
The PUSH_PROMISE frame defines the following flags:
|
|
<list style="hanging">
|
|
<x:lt hangText="END_HEADERS (0x4):">
|
|
<t>
|
|
Bit 3 being set indicates that this frame contains an entire <xref
|
|
target="HeaderBlock">header block</xref> and is not followed by any
|
|
<x:ref>CONTINUATION</x:ref> frames.
|
|
</t>
|
|
<t>
|
|
A PUSH_PROMISE frame without the END_HEADERS flag set MUST be followed by a
|
|
CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any
|
|
other type of frame or a frame on a different stream as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt hangText="PADDED (0x8):">
|
|
<t>
|
|
Bit 4 being set indicates that the Pad Length field and any padding that it
|
|
describes is present.
|
|
</t>
|
|
</x:lt>
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
PUSH_PROMISE frames MUST be associated with an existing, peer-initiated stream. The stream
|
|
identifier of a PUSH_PROMISE frame indicates the stream it is associated with. If the
|
|
stream identifier field specifies the value 0x0, a recipient MUST respond with a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
|
|
<t>
|
|
Promised streams are not required to be used in the order they are promised. The
|
|
PUSH_PROMISE only reserves stream identifiers for later use.
|
|
</t>
|
|
|
|
<t>
|
|
PUSH_PROMISE MUST NOT be sent if the <x:ref>SETTINGS_ENABLE_PUSH</x:ref> setting of the
|
|
peer endpoint is set to 0. An endpoint that has set this setting and has received
|
|
acknowledgement MUST treat the receipt of a PUSH_PROMISE frame as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
Recipients of PUSH_PROMISE frames can choose to reject promised streams by returning a
|
|
<x:ref>RST_STREAM</x:ref> referencing the promised stream identifier back to the sender of
|
|
the PUSH_PROMISE.
|
|
</t>
|
|
|
|
<t>
|
|
A PUSH_PROMISE frame modifies the connection state in two ways. The inclusion of a <xref
|
|
target="HeaderBlock">header block</xref> potentially modifies the state maintained for
|
|
header compression. PUSH_PROMISE also reserves a stream for later use, causing the
|
|
promised stream to enter the "reserved" state. A sender MUST NOT send a PUSH_PROMISE on a
|
|
stream unless that stream is either "open" or "half closed (remote)"; the sender MUST
|
|
ensure that the promised stream is a valid choice for a <xref
|
|
target="StreamIdentifiers">new stream identifier</xref> (that is, the promised stream MUST
|
|
be in the "idle" state).
|
|
</t>
|
|
<t>
|
|
Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame causes the stream
|
|
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
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>. However, an endpoint that has sent
|
|
<x:ref>RST_STREAM</x:ref> on the associated stream MUST handle PUSH_PROMISE frames that
|
|
might have been created before the <x:ref>RST_STREAM</x:ref> frame is received and
|
|
processed.
|
|
</t>
|
|
<t>
|
|
A receiver MUST treat the receipt of a PUSH_PROMISE that promises an <xref
|
|
target="StreamIdentifiers">illegal stream identifier</xref> (that is, an identifier for a
|
|
stream that is not currently in the "idle" state) as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
|
|
<t>
|
|
The PUSH_PROMISE frame includes optional padding. Padding fields and flags are identical
|
|
to those defined for <xref target="DATA">DATA frames</xref>.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="PING" title="PING">
|
|
<t>
|
|
The PING frame (type=0x6) is a mechanism for measuring a minimal round trip time from the
|
|
sender, as well as determining whether an idle connection is still functional. PING
|
|
frames can be sent from any endpoint.
|
|
</t>
|
|
<figure title="PING Payload Format">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| |
|
|
| Opaque Data (64) |
|
|
| |
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
|
|
<t>
|
|
In addition to the frame header, PING frames MUST contain 8 octets of data in the payload.
|
|
A sender can include any value it chooses and use those bytes in any fashion.
|
|
</t>
|
|
<t>
|
|
Receivers of a PING frame that does not include an ACK flag MUST send a PING frame with
|
|
the ACK flag set in response, with an identical payload. PING responses SHOULD be given
|
|
higher priority than any other frame.
|
|
</t>
|
|
|
|
<t>
|
|
The PING frame defines the following flags:
|
|
<list style="hanging">
|
|
<t hangText="ACK (0x1):">
|
|
Bit 1 being set indicates that this PING frame is a PING response. An endpoint MUST
|
|
set this flag in PING responses. An endpoint MUST NOT respond to PING frames
|
|
containing this flag.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
PING frames are not associated with any individual stream. If a PING frame is received
|
|
with a stream identifier field value other than 0x0, the recipient MUST respond with a
|
|
<xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
Receipt of a PING frame with a length field value other than 8 MUST be treated as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>FRAME_SIZE_ERROR</x:ref>.
|
|
</t>
|
|
|
|
</section>
|
|
|
|
<section anchor="GOAWAY" title="GOAWAY">
|
|
<t>
|
|
The GOAWAY frame (type=0x7) informs the remote peer to stop creating streams on this
|
|
connection. GOAWAY can be sent by either the client or the server. Once sent, the sender
|
|
will ignore frames sent on any new streams with identifiers higher than the included last
|
|
stream identifier. Receivers of a GOAWAY frame MUST NOT open additional streams on the
|
|
connection, although a new connection can be established for new streams.
|
|
</t>
|
|
<t>
|
|
The purpose of this frame is to allow an endpoint to gracefully stop accepting new
|
|
streams, while still finishing processing of previously established streams. This enables
|
|
administrative actions, like server maintainance.
|
|
</t>
|
|
<t>
|
|
There is an inherent race condition between an endpoint starting new streams and the
|
|
remote sending a GOAWAY frame. To deal with this case, the GOAWAY contains the stream
|
|
identifier of the last peer-initiated stream which was or might be processed on the
|
|
sending endpoint in this connection. For instance, if the server sends a GOAWAY frame,
|
|
the identified stream is the highest numbered stream initiated by the client.
|
|
</t>
|
|
<t>
|
|
If the receiver of the GOAWAY has sent data on streams with a higher stream identifier
|
|
than what is indicated in the GOAWAY frame, those streams are not or will not be
|
|
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 retried later on a new
|
|
connection.
|
|
</t>
|
|
<t>
|
|
Endpoints SHOULD always send a GOAWAY frame before closing a connection so that the remote
|
|
can know whether a stream has been partially processed or not. For example, if an HTTP
|
|
client sends a POST at the same time that a server closes a connection, the client 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.
|
|
</t>
|
|
<t>
|
|
An endpoint might choose to close a connection without sending GOAWAY for misbehaving
|
|
peers.
|
|
</t>
|
|
|
|
<figure title="GOAWAY Payload Format">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|R| Last-Stream-ID (31) |
|
|
+-+-------------------------------------------------------------+
|
|
| Error Code (32) |
|
|
+---------------------------------------------------------------+
|
|
| Additional Debug Data (*) |
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
The GOAWAY frame does not define any flags.
|
|
</t>
|
|
<t>
|
|
The GOAWAY frame applies to the connection, not a specific stream. An endpoint MUST treat
|
|
a <x:ref>GOAWAY</x:ref> frame with a stream identifier other than 0x0 as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
The last stream identifier in the GOAWAY frame contains the highest numbered stream
|
|
identifier for which the sender of the GOAWAY frame might have taken some action on, or
|
|
might yet take action on. All streams up to and including the identified stream might
|
|
have been processed in some way. The last stream identifier can be set to 0 if no streams
|
|
were processed.
|
|
<list style="hanging">
|
|
<t hangText="Note:">
|
|
In this context, "processed" means that some data from the stream was passed to some
|
|
higher layer of software that might have taken some action as a result.
|
|
</t>
|
|
</list>
|
|
If a connection terminates without a GOAWAY frame, the last stream identifier is
|
|
effectively the highest possible stream identifier.
|
|
</t>
|
|
<t>
|
|
On streams with lower or equal numbered identifiers that were not closed completely prior
|
|
to the connection being closed, re-attempting requests, transactions, or any protocol
|
|
activity is not possible, with the exception of idempotent actions like HTTP GET, PUT, or
|
|
DELETE. Any protocol activity that uses higher numbered streams can be safely retried
|
|
using a new connection.
|
|
</t>
|
|
<t>
|
|
Activity on streams numbered lower or equal to the last stream identifier might still
|
|
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
|
|
all in-progress streams complete.
|
|
</t>
|
|
<t>
|
|
An endpoint MAY send multiple GOAWAY frames if circumstances change. For instance, an
|
|
endpoint that sends GOAWAY with <x:ref>NO_ERROR</x:ref> during graceful shutdown could
|
|
subsequently encounter an condition that requires immediate termination of the connection.
|
|
The last stream identifier from the last GOAWAY frame received indicates which streams
|
|
could have been acted upon. Endpoints MUST NOT increase the value they send in the last
|
|
stream identifier, since the peers might already have retried unprocessed requests on
|
|
another connection.
|
|
</t>
|
|
<t>
|
|
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 intermediaries that might
|
|
not be serving clients using HTTP/2. A server that is attempting to gracefully shut down
|
|
a connection SHOULD send an initial GOAWAY frame with the last stream identifier set to
|
|
2<x:sup>31</x:sup>-1 and a <x:ref>NO_ERROR</x:ref> code. This signals to the client that
|
|
a shutdown is imminent and that no further requests can be initiated. After waiting at
|
|
least one round trip time, the server can send another GOAWAY frame with an updated last
|
|
stream identifier. This ensures that a connection can be cleanly shut down without losing
|
|
requests.
|
|
</t>
|
|
|
|
<t>
|
|
After sending a GOAWAY frame, the sender can discard frames for streams with identifiers
|
|
higher than the identified last stream. However, any frames that alter connection state
|
|
cannot be completely ignored. For instance, <x:ref>HEADERS</x:ref>,
|
|
<x:ref>PUSH_PROMISE</x:ref> and <x:ref>CONTINUATION</x:ref> frames MUST be minimally
|
|
processed to ensure the state maintained for header compression is consistent (see <xref
|
|
target="HeaderBlock"/>); similarly DATA frames MUST be counted toward the connection flow
|
|
control window. Failure to process these frames can cause flow control or header
|
|
compression state to become unsynchronized.
|
|
</t>
|
|
|
|
<t>
|
|
The GOAWAY frame also contains a 32-bit <xref target="ErrorCodes">error code</xref> that
|
|
contains the reason for closing the connection.
|
|
</t>
|
|
<t>
|
|
Endpoints MAY append opaque data to the payload of any GOAWAY frame. Additional 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
|
|
persistently stored debug data MUST have adequate safeguards to prevent unauthorized
|
|
access.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="WINDOW_UPDATE" title="WINDOW_UPDATE">
|
|
<t>
|
|
The WINDOW_UPDATE frame (type=0x8) is used to implement flow control; see <xref
|
|
target="FlowControl"/> for an overview.
|
|
</t>
|
|
<t>
|
|
Flow control operates at two levels: on each individual stream and on the entire
|
|
connection.
|
|
</t>
|
|
<t>
|
|
Both types of flow control are hop-by-hop; that is, only between the two endpoints.
|
|
Intermediaries do not forward WINDOW_UPDATE frames between dependent connections.
|
|
However, throttling of data transfer by any receiver can indirectly cause the propagation
|
|
of flow control information toward the original sender.
|
|
</t>
|
|
<t>
|
|
Flow control only applies to frames that are identified as being subject to flow control.
|
|
Of the frame types defined in this document, this includes only <x:ref>DATA</x:ref> frames.
|
|
Frames that are exempt from flow control MUST be accepted and processed, unless the
|
|
receiver is unable to assign resources to handling the frame. A receiver MAY respond with
|
|
a <xref target="StreamErrorHandler">stream error</xref> or <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>FLOW_CONTROL_ERROR</x:ref> if it is unable to accept a frame.
|
|
</t>
|
|
<figure title="WINDOW_UPDATE Payload Format">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
|R| Window Size Increment (31) |
|
|
+-+-------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
The 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 addition to the existing
|
|
flow control window. The legal range for the increment to the flow control window is 1 to
|
|
2<x:sup>31</x:sup>-1 (0x7fffffff) octets.
|
|
</t>
|
|
<t>
|
|
The WINDOW_UPDATE frame does not define any flags.
|
|
</t>
|
|
<t>
|
|
The WINDOW_UPDATE frame can be specific to a stream or to the entire connection. In the
|
|
former case, the frame's stream identifier indicates the affected stream; in the latter,
|
|
the value "0" indicates that the entire connection is the subject of the frame.
|
|
</t>
|
|
<t>
|
|
A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an flow control window
|
|
increment of 0 as a <xref target="StreamErrorHandler">stream error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>; errors on the connection flow control window MUST be
|
|
treated as a <xref target="ConnectionErrorHandler">connection error</xref>.
|
|
</t>
|
|
<t>
|
|
WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the END_STREAM flag.
|
|
This means that a receiver could receive a WINDOW_UPDATE frame on a "half closed (remote)"
|
|
or "closed" stream. A receiver MUST NOT treat this as an error, see <xref
|
|
target="StreamStates"/>.
|
|
</t>
|
|
<t>
|
|
A receiver that receives a flow controlled frame MUST always account for 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
|
|
frame is in error. Since the sender counts the frame toward the flow control window, if
|
|
the receiver does not, the flow control window at sender and receiver can become
|
|
different.
|
|
</t>
|
|
|
|
<section title="The Flow Control Window">
|
|
<t>
|
|
Flow control in HTTP/2 is implemented using a window kept by each sender on every
|
|
stream. The flow control window is a simple integer value that indicates how many octets
|
|
of data the sender is permitted to transmit; as such, its size is a measure of the
|
|
buffering capacity of the receiver.
|
|
</t>
|
|
<t>
|
|
Two flow control windows are applicable: the stream flow control window and the
|
|
connection flow control window. The sender MUST NOT send a flow controlled frame with a
|
|
length that exceeds the space available in either of the flow control windows advertised
|
|
by the receiver. Frames with zero length with the END_STREAM flag set (that is, an
|
|
empty <x:ref>DATA</x:ref> frame) MAY be sent if there is no available space in either
|
|
flow control window.
|
|
</t>
|
|
<t>
|
|
For flow control calculations, the 9 octet frame header is not counted.
|
|
</t>
|
|
<t>
|
|
After sending a flow controlled frame, the sender reduces the space 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 data and frees up
|
|
space in flow control windows. Separate WINDOW_UPDATE frames are sent for the stream
|
|
and connection level flow control windows.
|
|
</t>
|
|
<t>
|
|
A sender that receives a WINDOW_UPDATE frame updates the corresponding window by the
|
|
amount specified in the frame.
|
|
</t>
|
|
<t>
|
|
A sender MUST NOT allow a flow control window to exceed 2<x:sup>31</x:sup>-1 octets.
|
|
If a sender receives a WINDOW_UPDATE that causes a flow control window to exceed this
|
|
maximum it MUST terminate either the stream or the connection, as appropriate. For
|
|
streams, the sender sends a <x:ref>RST_STREAM</x:ref> with the error code of
|
|
<x:ref>FLOW_CONTROL_ERROR</x:ref> code; for the connection, a <x:ref>GOAWAY</x:ref>
|
|
frame with a <x:ref>FLOW_CONTROL_ERROR</x:ref> code.
|
|
</t>
|
|
<t>
|
|
Flow controlled frames from the sender and WINDOW_UPDATE frames from the receiver are
|
|
completely asynchronous with respect to each other. This property allows a receiver to
|
|
aggressively update the window size kept by the sender to prevent streams from stalling.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="InitialWindowSize" title="Initial Flow Control Window Size">
|
|
<t>
|
|
When an HTTP/2 connection is first established, new streams are created with an initial
|
|
flow control window size of 65,535 octets. The connection flow control window is 65,535
|
|
octets. Both endpoints can adjust the initial window size for new streams by including
|
|
a value for <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref> in the <x:ref>SETTINGS</x:ref>
|
|
frame that forms part of the connection preface. The connection flow control window can
|
|
only be changed using WINDOW_UPDATE frames.
|
|
</t>
|
|
<t>
|
|
Prior to receiving a <x:ref>SETTINGS</x:ref> frame that sets a value for
|
|
<x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref>, an endpoint can only use the default
|
|
initial window size when sending flow controlled frames. Similarly, the connection flow
|
|
control window is set to the default initial window size until a WINDOW_UPDATE frame is
|
|
received.
|
|
</t>
|
|
<t>
|
|
A <x:ref>SETTINGS</x:ref> frame can alter the initial flow control window size for all
|
|
current streams. When the value of <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref> changes,
|
|
a receiver MUST adjust the size of all stream flow control windows that it maintains by
|
|
the difference between the new value and the old value.
|
|
</t>
|
|
<t>
|
|
A change to <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref> can cause the available space in
|
|
a flow control window to become negative. A sender MUST track the negative flow control
|
|
window, and MUST NOT send new flow controlled frames until it receives WINDOW_UPDATE
|
|
frames that cause the flow control window to become positive.
|
|
</t>
|
|
<t>
|
|
For example, if the client sends 60KB immediately on connection establishment, and the
|
|
server sets the initial window size to be 16KB, the client will recalculate the
|
|
available flow control window to be -44KB on receipt of the <x:ref>SETTINGS</x:ref>
|
|
frame. The client retains a negative flow control window until WINDOW_UPDATE frames
|
|
restore the window to being positive, after which the client can resume sending.
|
|
</t>
|
|
<t>
|
|
A <x:ref>SETTINGS</x:ref> frame cannot alter the connection flow control window.
|
|
</t>
|
|
<t>
|
|
An endpoint MUST treat a change to <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref> that
|
|
causes any flow control window to exceed the maximum size as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>FLOW_CONTROL_ERROR</x:ref>.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Reducing the Stream Window Size">
|
|
<t>
|
|
A receiver that wishes to use a smaller flow control window than the current size can
|
|
send a new <x:ref>SETTINGS</x:ref> frame. However, the receiver MUST be prepared to
|
|
receive data that exceeds this window size, since the sender might send data that
|
|
exceeds the lower limit prior to processing the <x:ref>SETTINGS</x:ref> frame.
|
|
</t>
|
|
<t>
|
|
After sending a SETTINGS frame that reduces the initial flow control window size, a
|
|
receiver has two options for handling streams that exceed flow control limits:
|
|
<list style="numbers">
|
|
<t>
|
|
The receiver can immediately send <x:ref>RST_STREAM</x:ref> with
|
|
<x:ref>FLOW_CONTROL_ERROR</x:ref> error code for the affected streams.
|
|
</t>
|
|
<t>
|
|
The receiver can accept the streams and tolerate the resulting head of line
|
|
blocking, sending WINDOW_UPDATE frames as it consumes data.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="CONTINUATION" title="CONTINUATION">
|
|
<t>
|
|
The CONTINUATION frame (type=0x9) is used to continue a sequence of <xref
|
|
target="HeaderBlock">header block fragments</xref>. Any number of CONTINUATION frames can
|
|
be sent on an existing stream, as long as the preceding frame is on the same stream and is
|
|
a <x:ref>HEADERS</x:ref>, <x:ref>PUSH_PROMISE</x:ref> or CONTINUATION frame without the
|
|
END_HEADERS flag set.
|
|
</t>
|
|
|
|
<figure title="CONTINUATION Frame Payload">
|
|
<artwork type="inline"><![CDATA[
|
|
0 1 2 3
|
|
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
|
| Header Block Fragment (*) ...
|
|
+---------------------------------------------------------------+
|
|
]]></artwork>
|
|
</figure>
|
|
<t>
|
|
The CONTINUATION frame payload contains a <xref target="HeaderBlock">header block
|
|
fragment</xref>.
|
|
</t>
|
|
|
|
<t>
|
|
The CONTINUATION frame defines the following flag:
|
|
<list style="hanging">
|
|
<x:lt hangText="END_HEADERS (0x4):">
|
|
<t>
|
|
Bit 3 being set indicates that this frame ends a <xref target="HeaderBlock">header
|
|
block</xref>.
|
|
</t>
|
|
<t>
|
|
If the END_HEADERS bit is not set, this frame MUST be followed by another
|
|
CONTINUATION frame. A receiver MUST treat the receipt of any other type of frame or
|
|
a frame on a different stream as a <xref target="ConnectionErrorHandler">connection
|
|
error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</x:lt>
|
|
</list>
|
|
</t>
|
|
|
|
<t>
|
|
The CONTINUATION frame changes the connection state as defined in <xref
|
|
target="HeaderBlock" />.
|
|
</t>
|
|
|
|
<t>
|
|
CONTINUATION frames MUST be associated with a stream. If a CONTINUATION frame is received
|
|
whose stream identifier field is 0x0, the recipient MUST respond with a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type PROTOCOL_ERROR.
|
|
</t>
|
|
|
|
<t>
|
|
A CONTINUATION frame MUST be preceded by a <x:ref>HEADERS</x:ref>,
|
|
<x:ref>PUSH_PROMISE</x:ref> or CONTINUATION frame without the END_HEADERS flag set. A
|
|
recipient that observes violation of this rule MUST respond with a <xref
|
|
target="ConnectionErrorHandler"> connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="ErrorCodes" title="Error Codes">
|
|
<t>
|
|
Error codes are 32-bit fields that are used in <x:ref>RST_STREAM</x:ref> and
|
|
<x:ref>GOAWAY</x:ref> frames to convey the reasons for the stream or connection error.
|
|
</t>
|
|
|
|
<t>
|
|
Error codes share a common code space. Some error codes apply only to either streams or the
|
|
entire connection and have no defined semantics in the other context.
|
|
</t>
|
|
|
|
<t>
|
|
The following error codes are defined:
|
|
<list style="hanging">
|
|
<t hangText="NO_ERROR (0x0):" anchor="NO_ERROR">
|
|
The associated condition is not as a result of an error. For example, a
|
|
<x:ref>GOAWAY</x:ref> might include this code to indicate graceful shutdown of a
|
|
connection.
|
|
</t>
|
|
<t hangText="PROTOCOL_ERROR (0x1):" anchor="PROTOCOL_ERROR">
|
|
The endpoint detected an unspecific protocol error. This error is for use when a more
|
|
specific error code is not available.
|
|
</t>
|
|
<t hangText="INTERNAL_ERROR (0x2):" anchor="INTERNAL_ERROR">
|
|
The endpoint encountered an unexpected internal error.
|
|
</t>
|
|
<t hangText="FLOW_CONTROL_ERROR (0x3):" anchor="FLOW_CONTROL_ERROR">
|
|
The endpoint detected that its peer violated the flow control protocol.
|
|
</t>
|
|
<t hangText="SETTINGS_TIMEOUT (0x4):" anchor="SETTINGS_TIMEOUT">
|
|
The endpoint sent a <x:ref>SETTINGS</x:ref> frame, but did not receive a response in a
|
|
timely manner. See <xref target="SettingsSync">Settings Synchronization</xref>.
|
|
</t>
|
|
<t hangText="STREAM_CLOSED (0x5):" anchor="STREAM_CLOSED">
|
|
The endpoint received a frame after a stream was half closed.
|
|
</t>
|
|
<t hangText="FRAME_SIZE_ERROR (0x6):" anchor="FRAME_SIZE_ERROR">
|
|
The endpoint received a frame with an invalid size.
|
|
</t>
|
|
<t hangText="REFUSED_STREAM (0x7):" anchor="REFUSED_STREAM">
|
|
The endpoint refuses the stream prior to performing any application processing, see
|
|
<xref target="Reliability"/> for details.
|
|
</t>
|
|
<t hangText="CANCEL (0x8):" anchor="CANCEL">
|
|
Used by the endpoint to indicate that the stream is no longer needed.
|
|
</t>
|
|
<t hangText="COMPRESSION_ERROR (0x9):" anchor="COMPRESSION_ERROR">
|
|
The endpoint is unable to maintain the header compression context for the connection.
|
|
</t>
|
|
<t hangText="CONNECT_ERROR (0xa):" anchor="CONNECT_ERROR">
|
|
The connection established in response to a <xref target="CONNECT">CONNECT
|
|
request</xref> was reset or abnormally closed.
|
|
</t>
|
|
<t hangText="ENHANCE_YOUR_CALM (0xb):" anchor="ENHANCE_YOUR_CALM">
|
|
The endpoint detected that its peer is exhibiting a behavior that might be generating
|
|
excessive load.
|
|
</t>
|
|
<t hangText="INADEQUATE_SECURITY (0xc):" anchor="INADEQUATE_SECURITY">
|
|
The underlying transport has properties that do not meet minimum security
|
|
requirements (see <xref target="TLSUsage"/>).
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Unknown or unsupported error codes MUST NOT trigger any special behavior. These MAY be
|
|
treated by an implementation as being equivalent to <x:ref>INTERNAL_ERROR</x:ref>.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="HTTPLayer" title="HTTP Message Exchanges">
|
|
<t>
|
|
HTTP/2 is intended to be as compatible as possible with current uses of HTTP. This means
|
|
that, from the application perspective, the features of the protocol are largely
|
|
unchanged. To achieve this, all request and response semantics are preserved, although the
|
|
syntax of conveying those semantics has changed.
|
|
</t>
|
|
<t>
|
|
Thus, the specification and requirements of HTTP/1.1 Semantics and Content <xref
|
|
target="RFC7231"/>, Conditional Requests <xref target="RFC7232"/>, Range Requests <xref
|
|
target="RFC7233"/>, Caching <xref target="RFC7234"/> and Authentication <xref
|
|
target="RFC7235"/> are applicable to HTTP/2. Selected portions of HTTP/1.1 Message Syntax
|
|
and Routing <xref target="RFC7230"/>, such as the HTTP and HTTPS URI schemes, are also
|
|
applicable in HTTP/2, but the expression of those semantics for this protocol are defined
|
|
in the sections below.
|
|
</t>
|
|
|
|
<section anchor="HttpSequence" title="HTTP Request/Response Exchange">
|
|
<t>
|
|
A client sends an HTTP request on a new stream, using a previously unused <xref
|
|
target="StreamIdentifiers">stream identifier</xref>. A server sends an HTTP response on
|
|
the same stream as the request.
|
|
</t>
|
|
<t>
|
|
An HTTP message (request or response) consists of:
|
|
<list style="numbers">
|
|
<t>
|
|
for a response only, zero or more <x:ref>HEADERS</x:ref> frames (each followed by zero
|
|
or more <x:ref>CONTINUATION</x:ref> frames) containing the message headers of
|
|
informational (1xx) HTTP responses (see <xref target="RFC7230" x:fmt=","
|
|
x:rel="#header.fields"/> and <xref target="RFC7231" x:fmt="," x:rel="#status.1xx"/>),
|
|
and
|
|
</t>
|
|
<t>
|
|
one <x:ref>HEADERS</x:ref> frame (followed by zero or more <x:ref>CONTINUATION</x:ref>
|
|
frames) containing the message headers (see <xref target="RFC7230" x:fmt=","
|
|
x:rel="#header.fields"/>), and
|
|
</t>
|
|
<t>
|
|
zero or more <x:ref>DATA</x:ref> frames containing the message payload (see <xref
|
|
target="RFC7230" x:fmt="," x:rel="#message.body"/>), and
|
|
</t>
|
|
<t>
|
|
optionally, one <x:ref>HEADERS</x:ref> frame, followed by zero or more
|
|
<x:ref>CONTINUATION</x:ref> frames containing the trailer-part, if present (see <xref
|
|
target="RFC7230" x:fmt="," x:rel="#chunked.trailer.part"/>).
|
|
</t>
|
|
</list>
|
|
The last frame in the sequence bears an END_STREAM flag, noting that a
|
|
<x:ref>HEADERS</x:ref> frame bearing the END_STREAM flag can be followed by
|
|
<x:ref>CONTINUATION</x:ref> frames that carry any remaining portions of the header block.
|
|
</t>
|
|
<t>
|
|
Other frames (from any stream) MUST NOT occur between either <x:ref>HEADERS</x:ref> frame
|
|
and any <x:ref>CONTINUATION</x:ref> frames that might follow.
|
|
</t>
|
|
|
|
<t>
|
|
Trailing header fields are carried in a header block that also terminates the stream.
|
|
That is, a sequence starting with a <x:ref>HEADERS</x:ref> frame, followed by zero or more
|
|
<x:ref>CONTINUATION</x:ref> frames, where the <x:ref>HEADERS</x:ref> frame bears an
|
|
END_STREAM flag. Header blocks after the first that do not terminate the stream are not
|
|
part of an HTTP request or response.
|
|
</t>
|
|
<t>
|
|
A <x:ref>HEADERS</x:ref> frame (and associated <x:ref>CONTINUATION</x:ref> frames) can
|
|
only appear at the start or end of a stream. An endpoint that receives a
|
|
<x:ref>HEADERS</x:ref> frame without the END_STREAM flag set after receiving a final
|
|
(non-informational) status code MUST treat the corresponding request or response as <xref
|
|
target="malformed">malformed</xref>.
|
|
</t>
|
|
|
|
<t>
|
|
An HTTP request/response exchange fully consumes a single stream. A request starts with
|
|
the <x:ref>HEADERS</x:ref> frame that puts the stream into an "open" state. The request
|
|
ends with a frame bearing END_STREAM, which causes the stream to become "half closed
|
|
(local)" for the client and "half closed (remote)" for the server. A response starts with
|
|
a <x:ref>HEADERS</x:ref> frame and ends with a frame bearing END_STREAM, which places the
|
|
stream in the "closed" state.
|
|
<!-- Yes, the response might be completed before the request does, but that's not a detail
|
|
we need to expand upon. It's complicated enough explaining this as it is. -->
|
|
</t>
|
|
|
|
<section anchor="informational-responses" title="Upgrading From HTTP/2">
|
|
<t>
|
|
HTTP/2 removes support for the 101 (Switching Protocols) informational status code
|
|
(<xref target="RFC7231" x:fmt="," x:rel="#status.101"/>).
|
|
</t>
|
|
<t>
|
|
The semantics of 101 (Switching Protocols) aren't applicable to a multiplexed protocol.
|
|
Alternative protocols are able to use the same mechanisms that HTTP/2 uses to negotiate
|
|
their use (see <xref target="starting"/>).
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="HttpHeaders" title="HTTP Header Fields">
|
|
<t>
|
|
HTTP header fields carry information as a series of key-value pairs. For a listing of
|
|
registered HTTP headers, see the Message Header Field Registry maintained at <eref
|
|
target="https://www.iana.org/assignments/message-headers"/>.
|
|
</t>
|
|
|
|
<section anchor="PseudoHeaderFields" title="Pseudo-Header Fields">
|
|
<t>
|
|
While HTTP/1.x used the message start-line (see <xref target="RFC7230" x:fmt=","
|
|
x:rel="#start.line"/>) to convey the target URI and method of the request, and the
|
|
status code for the response, HTTP/2 uses special pseudo-header fields beginning with
|
|
':' character (ASCII 0x3a) for this purpose.
|
|
</t>
|
|
<t>
|
|
Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT generate
|
|
pseudo-header fields other than those defined in this document.
|
|
</t>
|
|
<t>
|
|
Pseudo-header fields are only valid in the context in which they are defined.
|
|
Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header
|
|
fields defined for responses MUST NOT appear in requests. Pseudo-header fields MUST
|
|
NOT appear in trailers. Endpoints MUST treat a request or response that contains
|
|
undefined or invalid pseudo-header fields as <xref
|
|
target="malformed">malformed</xref>.
|
|
</t>
|
|
<t>
|
|
Just as in HTTP/1.x, header field names are strings of ASCII characters that are
|
|
compared in a case-insensitive fashion. However, header field names MUST be converted
|
|
to lowercase prior to their encoding in HTTP/2. A request or response containing
|
|
uppercase header field names MUST be treated as <xref
|
|
target="malformed">malformed</xref>.
|
|
</t>
|
|
<t>
|
|
All pseudo-header fields MUST appear in the header block before regular header fields.
|
|
Any request or response that contains a pseudo-header field that appears in a header
|
|
block after a regular header field MUST be treated as <xref
|
|
target="malformed">malformed</xref>.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Connection-Specific Header Fields">
|
|
<t>
|
|
HTTP/2 does not use the <spanx style="verb">Connection</spanx> header field to
|
|
indicate connection-specific header fields; in this protocol, connection-specific
|
|
metadata is conveyed by other means. An endpoint MUST NOT generate a HTTP/2 message
|
|
containing connection-specific header fields; any message containing
|
|
connection-specific header fields MUST be treated as <xref
|
|
target="malformed">malformed</xref>.
|
|
</t>
|
|
<t>
|
|
This means that an intermediary transforming an HTTP/1.x message to HTTP/2 will need
|
|
to remove any header fields nominated by the Connection header field, along with the
|
|
Connection header field itself. Such intermediaries SHOULD also remove other
|
|
connection-specific header fields, such as Keep-Alive, Proxy-Connection,
|
|
Transfer-Encoding and Upgrade, even if they are not nominated by Connection.
|
|
</t>
|
|
<t>
|
|
One exception to this is the TE header field, which MAY be present in an HTTP/2
|
|
request, but when it is MUST NOT contain any value other than "trailers".
|
|
</t>
|
|
<t>
|
|
<list style="hanging">
|
|
<t hangText="Note:">
|
|
HTTP/2 purposefully does not support upgrade to another protocol. The handshake
|
|
methods described in <xref target="starting"/> are believed sufficient to
|
|
negotiate the use of alternative protocols.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="HttpRequest" title="Request Pseudo-Header Fields">
|
|
<t>
|
|
The following pseudo-header fields are defined for HTTP/2 requests:
|
|
<list style="symbols">
|
|
<x:lt>
|
|
<t>
|
|
The <spanx style="verb">:method</spanx> pseudo-header field includes the HTTP
|
|
method (<xref target="RFC7231" x:fmt="," x:rel="#methods"/>).
|
|
</t>
|
|
</x:lt>
|
|
<x:lt>
|
|
<t>
|
|
The <spanx style="verb">:scheme</spanx> pseudo-header field includes the scheme
|
|
portion of the target URI (<xref target="RFC3986" x:fmt="," x:sec="3.1"/>).
|
|
</t>
|
|
<t>
|
|
<spanx style="verb">:scheme</spanx> is not restricted to <spanx
|
|
style="verb">http</spanx> and <spanx style="verb">https</spanx> schemed URIs. A
|
|
proxy or gateway can translate requests for non-HTTP schemes, enabling the use
|
|
of HTTP to interact with non-HTTP services.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt>
|
|
<t>
|
|
The <spanx style="verb">:authority</spanx> pseudo-header field includes the
|
|
authority portion of the target URI (<xref target="RFC3986" x:fmt=","
|
|
x:sec="3.2"/>). The authority MUST NOT include the deprecated <spanx
|
|
style="verb">userinfo</spanx> subcomponent for <spanx style="verb">http</spanx>
|
|
or <spanx style="verb">https</spanx> schemed URIs.
|
|
</t>
|
|
<t>
|
|
To ensure that the HTTP/1.1 request line can be reproduced accurately, this
|
|
pseudo-header field MUST be omitted when translating from an HTTP/1.1 request
|
|
that has a request target in origin or asterisk form (see <xref
|
|
target="RFC7230" x:fmt="," x:rel="#request-target"/>). Clients that generate
|
|
HTTP/2 requests directly SHOULD use the <spanx>:authority</spanx> pseudo-header
|
|
field instead of the <spanx style="verb">Host</spanx> header field. An
|
|
intermediary that converts an HTTP/2 request to HTTP/1.1 MUST create a <spanx
|
|
style="verb">Host</spanx> header field if one is not present in a request by
|
|
copying the value of the <spanx style="verb">:authority</spanx> pseudo-header
|
|
field.
|
|
</t>
|
|
</x:lt>
|
|
<x:lt>
|
|
<t>
|
|
The <spanx style="verb">:path</spanx> pseudo-header field includes the path and
|
|
query parts of the target URI (the <spanx style="verb">path-absolute</spanx>
|
|
production from <xref target="RFC3986"/> and optionally a '?' character
|
|
followed by the <spanx style="verb">query</spanx> production, see <xref
|
|
target="RFC3986" x:fmt="," x:sec="3.3"/> and <xref target="RFC3986" x:fmt=","
|
|
x:sec="3.4"/>). A request in asterisk form includes the value '*' for the
|
|
<spanx style="verb">:path</spanx> pseudo-header field.
|
|
</t>
|
|
<t>
|
|
This pseudo-header field MUST NOT be empty for <spanx style="verb">http</spanx>
|
|
or <spanx style="verb">https</spanx> URIs; <spanx style="verb">http</spanx> or
|
|
<spanx style="verb">https</spanx> URIs that do not contain a path component
|
|
MUST include a value of '/'. The exception to this rule is an OPTIONS request
|
|
for an <spanx style="verb">http</spanx> or <spanx style="verb">https</spanx>
|
|
URI that does not include a path component; these MUST include a <spanx
|
|
style="verb">:path</spanx> pseudo-header field with a value of '*' (see <xref
|
|
target="RFC7230" x:fmt="," x:rel="#asterisk-form"/>).
|
|
</t>
|
|
</x:lt>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
All HTTP/2 requests MUST include exactly one valid value for the <spanx
|
|
style="verb">:method</spanx>, <spanx style="verb">:scheme</spanx>, and <spanx
|
|
style="verb">:path</spanx> pseudo-header fields, unless it is a <xref
|
|
target="CONNECT">CONNECT request</xref>. An HTTP request that omits mandatory
|
|
pseudo-header fields is <xref target="malformed">malformed</xref>.
|
|
</t>
|
|
<t>
|
|
HTTP/2 does not define a way to carry the version identifier that is included in the
|
|
HTTP/1.1 request line.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="HttpResponse" title="Response Pseudo-Header Fields">
|
|
<t>
|
|
For HTTP/2 responses, a single <spanx style="verb">:status</spanx> pseudo-header
|
|
field is defined that carries the HTTP status code field (see <xref target="RFC7231"
|
|
x:fmt="," x:rel="#status.codes"/>). This pseudo-header field MUST be included in all
|
|
responses, otherwise the response is <xref target="malformed">malformed</xref>.
|
|
</t>
|
|
<t>
|
|
HTTP/2 does not define a way to carry the version or reason phrase that is included in
|
|
an HTTP/1.1 status line.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="CompressCookie" title="Compressing the Cookie Header Field">
|
|
<t>
|
|
The <xref target="COOKIE">Cookie header field</xref> can carry a significant amount of
|
|
redundant data.
|
|
</t>
|
|
<t>
|
|
The Cookie header field uses a semi-colon (";") to delimit cookie-pairs (or "crumbs").
|
|
This header field doesn't follow the list construction rules in HTTP (see <xref
|
|
target="RFC7230" x:fmt="," x:rel="#field.order"/>), which prevents cookie-pairs from
|
|
being separated into different name-value pairs. This can significantly reduce
|
|
compression efficiency as individual cookie-pairs are updated.
|
|
</t>
|
|
<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 there are multiple
|
|
Cookie header fields after decompression, these MUST be concatenated into a single
|
|
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 connection, or a
|
|
generic HTTP server application.
|
|
</t>
|
|
<figure>
|
|
<preamble>
|
|
Therefore, the following two lists of Cookie header fields are semantically
|
|
equivalent.
|
|
</preamble>
|
|
<artwork type="inline"><![CDATA[
|
|
cookie: a=b; c=d; e=f
|
|
|
|
cookie: a=b
|
|
cookie: c=d
|
|
cookie: e=f
|
|
]]></artwork>
|
|
</figure>
|
|
</section>
|
|
|
|
<section anchor="malformed" title="Malformed Requests and Responses">
|
|
<t>
|
|
A malformed request or response is one that is an otherwise valid sequence of HTTP/2
|
|
frames, but is otherwise invalid due to the presence of extraneous frames, prohibited
|
|
header fields, the absence of mandatory header fields, or the inclusion of uppercase
|
|
header field names.
|
|
</t>
|
|
<t>
|
|
A request or response that includes an entity body can include a <spanx
|
|
style="verb">content-length</spanx> header field. A request or response is also
|
|
malformed if the value of a <spanx style="verb">content-length</spanx> header field
|
|
does not equal the sum of the <x:ref>DATA</x:ref> frame payload lengths that form the
|
|
body. A response that is defined to have no payload, as described in <xref
|
|
target="RFC7230" x:fmt="," x:rel="#header.content-length"/>, can have a non-zero
|
|
<spanx style="verb">content-length</spanx> header field, even though no content is
|
|
included in <x:ref>DATA</x:ref> frames.
|
|
</t>
|
|
<t>
|
|
Intermediaries that process HTTP requests or responses (i.e., any intermediary not
|
|
acting as a tunnel) MUST NOT forward a malformed request or response. Malformed
|
|
requests or responses that are detected MUST be treated as a <xref
|
|
target="StreamErrorHandler">stream error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
For malformed requests, a server MAY send an HTTP response prior to closing or
|
|
resetting the stream. Clients MUST NOT accept a malformed response. Note that these
|
|
requirements are intended to protect against several types of common attacks against
|
|
HTTP; they are deliberately strict, because being permissive can expose
|
|
implementations to these vulnerabilities.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section title="Examples">
|
|
<t>
|
|
This section shows HTTP/1.1 requests and responses, with illustrations of equivalent
|
|
HTTP/2 requests and responses.
|
|
</t>
|
|
<t>
|
|
An HTTP GET request includes request header fields and no body and is therefore
|
|
transmitted as a single <x:ref>HEADERS</x:ref> frame, followed by zero or more
|
|
<x:ref>CONTINUATION</x:ref> frames containing the serialized block of request header
|
|
fields. The <x:ref>HEADERS</x:ref> frame in the following has both the END_HEADERS and
|
|
END_STREAM flags set; no <x:ref>CONTINUATION</x:ref> frames are sent:
|
|
</t>
|
|
|
|
<figure>
|
|
<artwork type="inline"><![CDATA[
|
|
GET /resource HTTP/1.1 HEADERS
|
|
Host: example.org ==> + END_STREAM
|
|
Accept: image/jpeg + END_HEADERS
|
|
:method = GET
|
|
:scheme = https
|
|
:path = /resource
|
|
host = example.org
|
|
accept = image/jpeg
|
|
]]></artwork>
|
|
</figure>
|
|
|
|
<t>
|
|
Similarly, a response that includes only response header fields is transmitted as a
|
|
<x:ref>HEADERS</x:ref> frame (again, followed by zero or more
|
|
<x:ref>CONTINUATION</x:ref> frames) containing the serialized block of response header
|
|
fields.
|
|
</t>
|
|
|
|
<figure>
|
|
<artwork type="inline"><![CDATA[
|
|
HTTP/1.1 304 Not Modified HEADERS
|
|
ETag: "xyzzy" ==> + END_STREAM
|
|
Expires: Thu, 23 Jan ... + END_HEADERS
|
|
:status = 304
|
|
etag = "xyzzy"
|
|
expires = Thu, 23 Jan ...
|
|
]]></artwork>
|
|
</figure>
|
|
|
|
<t>
|
|
An HTTP POST request that includes request header fields and payload data is transmitted
|
|
as one <x:ref>HEADERS</x:ref> frame, followed by zero or more
|
|
<x:ref>CONTINUATION</x:ref> frames containing the request header fields, followed by one
|
|
or more <x:ref>DATA</x:ref> frames, with the last <x:ref>CONTINUATION</x:ref> (or
|
|
<x:ref>HEADERS</x:ref>) frame having the END_HEADERS flag set and the final
|
|
<x:ref>DATA</x:ref> frame having the END_STREAM flag set:
|
|
</t>
|
|
|
|
<figure>
|
|
<artwork type="inline"><![CDATA[
|
|
POST /resource HTTP/1.1 HEADERS
|
|
Host: example.org ==> - END_STREAM
|
|
Content-Type: image/jpeg - END_HEADERS
|
|
Content-Length: 123 :method = POST
|
|
:path = /resource
|
|
{binary data} :scheme = https
|
|
|
|
CONTINUATION
|
|
+ END_HEADERS
|
|
content-type = image/jpeg
|
|
host = example.org
|
|
content-length = 123
|
|
|
|
DATA
|
|
+ END_STREAM
|
|
{binary data}
|
|
]]></artwork>
|
|
<postamble>
|
|
Note that data contributing to any given header field could be spread between header
|
|
block fragments. The allocation of header fields to frames in this example is
|
|
illustrative only.
|
|
</postamble>
|
|
</figure>
|
|
|
|
<t>
|
|
A response that includes header fields and payload data is transmitted as a
|
|
<x:ref>HEADERS</x:ref> frame, followed by zero or more <x:ref>CONTINUATION</x:ref>
|
|
frames, followed by one or more <x:ref>DATA</x:ref> frames, with the last
|
|
<x:ref>DATA</x:ref> frame in the sequence having the END_STREAM flag set:
|
|
</t>
|
|
|
|
<figure>
|
|
<artwork type="inline"><![CDATA[
|
|
HTTP/1.1 200 OK HEADERS
|
|
Content-Type: image/jpeg ==> - END_STREAM
|
|
Content-Length: 123 + END_HEADERS
|
|
:status = 200
|
|
{binary data} content-type = image/jpeg
|
|
content-length = 123
|
|
|
|
DATA
|
|
+ END_STREAM
|
|
{binary data}
|
|
]]></artwork>
|
|
</figure>
|
|
|
|
<t>
|
|
Trailing header fields are sent as a header block after both the request or response
|
|
header block and all the <x:ref>DATA</x:ref> frames have been sent. The
|
|
<x:ref>HEADERS</x:ref> frame starting the trailers header block has the END_STREAM flag
|
|
set.
|
|
</t>
|
|
|
|
<figure>
|
|
<artwork type="inline"><![CDATA[
|
|
HTTP/1.1 200 OK HEADERS
|
|
Content-Type: image/jpeg ==> - END_STREAM
|
|
Transfer-Encoding: chunked + END_HEADERS
|
|
Trailer: Foo :status = 200
|
|
content-length = 123
|
|
123 content-type = image/jpeg
|
|
{binary data} trailer = Foo
|
|
0
|
|
Foo: bar DATA
|
|
- END_STREAM
|
|
{binary data}
|
|
|
|
HEADERS
|
|
+ END_STREAM
|
|
+ END_HEADERS
|
|
foo = bar
|
|
]]></artwork>
|
|
</figure>
|
|
|
|
|
|
<figure>
|
|
<preamble>
|
|
An informational response using a 1xx status code other than 101 is transmitted as a
|
|
<x:ref>HEADERS</x:ref> frame, followed by zero or more <x:ref>CONTINUATION</x:ref>
|
|
frames:
|
|
</preamble>
|
|
<artwork type="inline"><![CDATA[
|
|
HTTP/1.1 103 BAR HEADERS
|
|
Extension-Field: bar ==> - END_STREAM
|
|
+ END_HEADERS
|
|
:status = 103
|
|
extension-field = bar
|
|
]]></artwork>
|
|
</figure>
|
|
</section>
|
|
|
|
<section anchor="Reliability" title="Request Reliability Mechanisms in HTTP/2">
|
|
<t>
|
|
In HTTP/1.1, an HTTP client is unable to retry a non-idempotent request when an error
|
|
occurs, because there is no means to determine the nature of the error. It is possible
|
|
that some server processing occurred prior to the error, which could result in
|
|
undesirable effects if the request were reattempted.
|
|
</t>
|
|
<t>
|
|
HTTP/2 provides two mechanisms for providing a guarantee to a client that a request has
|
|
not been processed:
|
|
<list style="symbols">
|
|
<t>
|
|
The <x:ref>GOAWAY</x:ref> frame indicates the highest stream number that might have
|
|
been processed. Requests on streams with higher numbers are therefore guaranteed to
|
|
be safe to retry.
|
|
</t>
|
|
<t>
|
|
The <x:ref>REFUSED_STREAM</x:ref> error code can be included in a
|
|
<x:ref>RST_STREAM</x:ref> 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
|
|
be safely retried.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
Requests that have not been processed have not failed; clients MAY automatically retry
|
|
them, even those with non-idempotent methods.
|
|
</t>
|
|
<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 application layer for any
|
|
stream, then <x:ref>REFUSED_STREAM</x:ref> MUST NOT be used for that stream, and a
|
|
<x:ref>GOAWAY</x:ref> frame MUST include a stream identifier that is greater than or
|
|
equal to the given stream identifier.
|
|
</t>
|
|
<t>
|
|
In addition to these mechanisms, the <x:ref>PING</x:ref> frame provides a way for a
|
|
client to easily test a connection. Connections that remain idle can become broken as
|
|
some middleboxes (for instance, network address translators, or load balancers) silently
|
|
discard connection bindings. The <x:ref>PING</x:ref> frame allows a client to safely
|
|
test whether a connection is still active without sending a request.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="PushResources" title="Server Push">
|
|
<t>
|
|
HTTP/2 allows a server to pre-emptively send (or "push") responses (along with
|
|
corresponding "promised" requests) to a client in association with a previous
|
|
client-initiated request. This can be useful when the server knows the client will need
|
|
to have those responses available in order to fully process the response to the original
|
|
request.
|
|
</t>
|
|
|
|
<t>
|
|
Pushing additional message exchanges in this fashion is optional, and is negotiated
|
|
between individual endpoints. The <x:ref>SETTINGS_ENABLE_PUSH</x:ref> setting can be set
|
|
to 0 to indicate that server push is disabled.
|
|
</t>
|
|
<t>
|
|
Promised requests MUST be cacheable (see <xref target="RFC7231" x:fmt=","
|
|
x:rel="#cacheable.methods"/>), MUST be safe (see <xref target="RFC7231" x:fmt=","
|
|
x:rel="#safe.methods"/>) and MUST NOT include a request body. Clients that receive a
|
|
promised request that is not cacheable, unsafe or that includes a request body MUST
|
|
reset the stream with a <xref target="StreamErrorHandler">stream error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
<t>
|
|
Pushed responses that are cacheable (see <xref target="RFC7234" x:fmt=","
|
|
x:rel="#response.cacheability"/>) can be stored by the client, if it implements a HTTP
|
|
cache. Pushed responses are considered successfully validated on the origin server (e.g.,
|
|
if the "no-cache" cache response directive <xref target="RFC7234" x:fmt=","
|
|
x:rel="#cache-response-directive"/> is present) while the stream identified by the
|
|
promised stream ID is still open.
|
|
</t>
|
|
<t>
|
|
Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache. They MAY
|
|
be made available to the application separately.
|
|
</t>
|
|
<t>
|
|
An intermediary can receive pushes from the server and choose not to forward them on to
|
|
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 additional pushes to the
|
|
client, without any action taken by the server.
|
|
</t>
|
|
<t>
|
|
A client cannot push. Thus, servers MUST treat the receipt of a
|
|
<x:ref>PUSH_PROMISE</x:ref> frame as a <xref target="ConnectionErrorHandler">connection
|
|
error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>. Clients MUST reject any attempt to
|
|
change the <x:ref>SETTINGS_ENABLE_PUSH</x:ref> setting to a value other than 0 by treating
|
|
the message as a <xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
|
|
<section anchor="PushRequests" title="Push Requests">
|
|
<t>
|
|
Server push is semantically equivalent to a server responding to a request; however, in
|
|
this case that request is also sent by the server, as a <x:ref>PUSH_PROMISE</x:ref>
|
|
frame.
|
|
</t>
|
|
<t>
|
|
The <x:ref>PUSH_PROMISE</x:ref> frame includes a header block that contains a complete
|
|
set of request header fields that the server attributes to the request. It is not
|
|
possible to push a response to a request that includes a request body.
|
|
</t>
|
|
|
|
<t>
|
|
Pushed responses are always associated with an explicit request from the client. The
|
|
<x:ref>PUSH_PROMISE</x:ref> frames sent by the server are sent on that explicit
|
|
request's stream. The <x:ref>PUSH_PROMISE</x:ref> frame also includes a promised stream
|
|
identifier, chosen from the stream identifiers available to the server (see <xref
|
|
target="StreamIdentifiers"/>).
|
|
</t>
|
|
|
|
<t>
|
|
The header fields in <x:ref>PUSH_PROMISE</x:ref> and any subsequent
|
|
<x:ref>CONTINUATION</x:ref> frames MUST be a valid and complete set of <xref
|
|
target="HttpRequest">request header fields</xref>. The server MUST include a method in
|
|
the <spanx style="verb">:method</spanx> header field that is safe and cacheable. If a
|
|
client receives a <x:ref>PUSH_PROMISE</x:ref> that does not include a complete and valid
|
|
set of header fields, or the <spanx style="verb">:method</spanx> header field identifies
|
|
a method that is not safe, it MUST respond with a <xref
|
|
target="StreamErrorHandler">stream error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
|
|
</t>
|
|
|
|
<t>
|
|
The server SHOULD send <x:ref>PUSH_PROMISE</x:ref> (<xref target="PUSH_PROMISE"/>)
|
|
frames prior to sending any frames that reference the promised responses. This avoids a
|
|
race where clients issue requests prior to receiving any <x:ref>PUSH_PROMISE</x:ref>
|
|
frames.
|
|
</t>
|
|
<t>
|
|
For example, if the server receives a request for a document containing embedded links
|
|
to multiple image files, and the server chooses to push those additional images to the
|
|
client, sending push promises before the <x:ref>DATA</x:ref> frames that contain the
|
|
image links ensures that the client is able to see the promises before discovering
|
|
embedded links. Similarly, if the server pushes responses referenced by the header block
|
|
(for instance, in Link header fields), sending the push promises before sending the
|
|
header block ensures that clients do not request them.
|
|
</t>
|
|
|
|
<t>
|
|
<x:ref>PUSH_PROMISE</x:ref> frames MUST NOT be sent by the client.
|
|
</t>
|
|
<t>
|
|
<x:ref>PUSH_PROMISE</x:ref> frames can be sent by the server in response to any
|
|
client-initiated stream, but the stream MUST be in either the "open" or "half closed
|
|
(remote)" state with respect to the server. <x:ref>PUSH_PROMISE</x:ref> frames are
|
|
interspersed with the frames that comprise a response, though they cannot be
|
|
interspersed with <x:ref>HEADERS</x:ref> and <x:ref>CONTINUATION</x:ref> frames that
|
|
comprise a single header block.
|
|
</t>
|
|
<t>
|
|
Sending a <x:ref>PUSH_PROMISE</x:ref> frame creates a new stream and puts the stream
|
|
into the “reserved (local)” state for the server and the “reserved (remote)” state for
|
|
the client.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="PushResponses" title="Push Responses">
|
|
<t>
|
|
After sending the <x:ref>PUSH_PROMISE</x:ref> frame, the server can begin delivering the
|
|
pushed response as a <xref target="HttpResponse">response</xref> on a server-initiated
|
|
stream that uses the promised stream identifier. The server uses this stream to
|
|
transmit an HTTP response, using the same sequence of frames as defined in <xref
|
|
target="HttpSequence"/>. This stream becomes <xref target="StreamStates">"half closed"
|
|
to the client</xref> after the initial <x:ref>HEADERS</x:ref> frame is sent.
|
|
</t>
|
|
|
|
<t>
|
|
Once a client receives a <x:ref>PUSH_PROMISE</x:ref> frame and chooses to accept the
|
|
pushed response, the client SHOULD NOT issue any requests for the promised response
|
|
until after the promised stream has closed.
|
|
</t>
|
|
|
|
<t>
|
|
If the client determines, for any reason, that it does not wish to receive the pushed
|
|
response from the server, or if the server takes too long to begin sending the promised
|
|
response, the client can send an <x:ref>RST_STREAM</x:ref> frame, using either the
|
|
<x:ref>CANCEL</x:ref> or <x:ref>REFUSED_STREAM</x:ref> codes, and referencing the pushed
|
|
stream's identifier.
|
|
</t>
|
|
<t>
|
|
A client can use the <x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> setting to limit the
|
|
number of responses that can be concurrently pushed by a server. Advertising a
|
|
<x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> value of zero disables server push by
|
|
preventing the server from creating the necessary streams. This does not prohibit a
|
|
server from sending <x:ref>PUSH_PROMISE</x:ref> frames; clients need to reset any
|
|
promised streams that are not wanted.
|
|
</t>
|
|
|
|
<t>
|
|
Clients receiving a pushed response MUST validate that either the server is
|
|
authoritative (see <xref target="authority"/>), or the proxy that provided the pushed
|
|
response is configured for the corresponding request. For example, a server that offers
|
|
a certificate for only the <spanx style="verb">example.com</spanx> DNS-ID or Common Name
|
|
is not permitted to push a response for <spanx
|
|
style="verb">https://www.example.org/doc</spanx>.
|
|
</t>
|
|
<t>
|
|
The response for a <x:ref>PUSH_PROMISE</x:ref> stream begins with a
|
|
<x:ref>HEADERS</x:ref> frame, which immediately puts the stream into the “half closed
|
|
(remote)” state for the server and “half closed (local)” state for the client, and ends
|
|
with a frame bearing END_STREAM, which places the stream in the "closed" state.
|
|
<list style="hanging">
|
|
<t hangText="Note:">
|
|
The client never sends a frame with the END_STREAM flag for a server push.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section anchor="CONNECT" title="The CONNECT Method">
|
|
<t>
|
|
In HTTP/1.x, the pseudo-method CONNECT (<xref target="RFC7231" x:fmt=","
|
|
x:rel="#CONNECT"/>) is 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
|
|
server for the purposes of interacting with <spanx style="verb">https</spanx> resources.
|
|
</t>
|
|
<t>
|
|
In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to
|
|
a remote host, for similar purposes. The HTTP header field mapping works as defined in
|
|
<xref target="HttpRequest">Request Header Fields</xref>, with a few
|
|
differences. Specifically:
|
|
<list style="symbols">
|
|
<t>
|
|
The <spanx style="verb">:method</spanx> header field is set to <spanx
|
|
style="verb">CONNECT</spanx>.
|
|
</t>
|
|
<t>
|
|
The <spanx style="verb">:scheme</spanx> and <spanx style="verb">:path</spanx> header
|
|
fields MUST be omitted.
|
|
</t>
|
|
<t>
|
|
The <spanx style="verb">:authority</spanx> header field contains the host and port to
|
|
connect to (equivalent to the authority-form of the request-target of CONNECT
|
|
requests, see <xref target="RFC7230" x:fmt="," x:rel="#request-target"/>).
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
A proxy that supports CONNECT establishes a <xref target="TCP">TCP connection</xref> to
|
|
the server identified in the <spanx style="verb">:authority</spanx> header field. Once
|
|
this connection is successfully established, the proxy sends a <x:ref>HEADERS</x:ref>
|
|
frame containing a 2xx series status code to the client, as defined in <xref
|
|
target="RFC7231" x:fmt="," x:rel="#CONNECT"/>.
|
|
</t>
|
|
<t>
|
|
After the initial <x:ref>HEADERS</x:ref> frame sent by each peer, all subsequent
|
|
<x:ref>DATA</x:ref> frames correspond to data sent on the TCP connection. The payload of
|
|
any <x:ref>DATA</x:ref> frames sent by the client is transmitted by the proxy to the TCP
|
|
server; data received from the TCP server is assembled into <x:ref>DATA</x:ref> frames by
|
|
the proxy. Frame types other than <x:ref>DATA</x:ref> or stream management frames
|
|
(<x:ref>RST_STREAM</x:ref>, <x:ref>WINDOW_UPDATE</x:ref>, and <x:ref>PRIORITY</x:ref>)
|
|
MUST NOT be sent on a connected stream, and MUST be treated 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
|
|
<x:ref>DATA</x:ref> frame is treated as being equivalent to the TCP FIN bit. A client is
|
|
expected to send a <x:ref>DATA</x:ref> frame with the END_STREAM flag set after receiving
|
|
a frame bearing the END_STREAM flag. A proxy that receives a <x:ref>DATA</x:ref> frame
|
|
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 sends a
|
|
<x:ref>DATA</x:ref> frame with the END_STREAM flag set. Note that the final TCP segment
|
|
or <x:ref>DATA</x:ref> frame could be empty.
|
|
</t>
|
|
<t>
|
|
A TCP connection error is signaled with <x:ref>RST_STREAM</x:ref>. A proxy treats any
|
|
error in the TCP connection, which includes receiving a TCP segment with the RST bit set,
|
|
as a <xref target="StreamErrorHandler">stream error</xref> of type
|
|
<x:ref>CONNECT_ERROR</x:ref>. Correspondingly, a proxy MUST send a TCP segment with the
|
|
RST bit set if it detects an error with the stream or the HTTP/2 connection.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="HttpExtra" title="Additional HTTP Requirements/Considerations">
|
|
<t>
|
|
This section outlines attributes of the HTTP protocol that improve interoperability, reduce
|
|
exposure to known security vulnerabilities, or reduce the potential for implementation
|
|
variation.
|
|
</t>
|
|
|
|
<section title="Connection Management">
|
|
<t>
|
|
HTTP/2 connections are persistent. For best performance, it is expected clients will not
|
|
close connections until it is determined that no further communication with a server is
|
|
necessary (for example, when a user navigates away from a particular web page), or until
|
|
the server closes the connection.
|
|
</t>
|
|
<t>
|
|
Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair,
|
|
where host is derived from a URI, a selected <xref target="ALT-SVC">alternative
|
|
service</xref>, or a configured proxy.
|
|
</t>
|
|
<t>
|
|
A client can create additional connections as replacements, either to replace connections
|
|
that are near to exhausting the available <xref target="StreamIdentifiers">stream
|
|
identifier space</xref>, to refresh the keying material for a TLS connection, or to
|
|
replace connections that have encountered <xref
|
|
target="ConnectionErrorHandler">errors</xref>.
|
|
</t>
|
|
<t>
|
|
A client MAY open multiple connections to the same IP address and TCP port using different
|
|
<xref target="TLS-EXT">Server Name Indication</xref> values or to provide different TLS
|
|
client certificates, but SHOULD avoid creating multiple connections with the same
|
|
configuration.
|
|
</t>
|
|
<t>
|
|
Servers are encouraged to maintain open connections for as long as possible, but are
|
|
permitted to terminate idle connections if necessary. When either endpoint chooses to
|
|
close the transport-layer TCP connection, the terminating endpoint SHOULD first send a
|
|
<x:ref>GOAWAY</x:ref> (<xref target="GOAWAY"/>) frame so that both endpoints can reliably
|
|
determine whether previously sent frames have been processed and gracefully complete or
|
|
terminate any necessary remaining tasks.
|
|
</t>
|
|
|
|
<section anchor="reuse" title="Connection Reuse">
|
|
<t>
|
|
Connections that are made to an origin servers, either directly or through a tunnel
|
|
created using the <xref target="CONNECT">CONNECT method</xref> MAY be reused for
|
|
requests with multiple different URI authority components. A connection can be reused
|
|
as long as the origin server is <xref target="authority">authoritative</xref>. For
|
|
<spanx style="verb">http</spanx> resources, this depends on the host having resolved to
|
|
the same IP address.
|
|
</t>
|
|
<t>
|
|
For <spanx style="verb">https</spanx> resources, connection reuse additionally depends
|
|
on having a certificate that is valid for the host in the URI. An origin server might
|
|
offer a certificate with multiple <spanx style="verb">subjectAltName</spanx> attributes,
|
|
or names with wildcards, one of which is valid for the authority in the URI. For
|
|
example, a certificate with a <spanx style="verb">subjectAltName</spanx> of <spanx
|
|
style="verb">*.example.com</spanx> might permit the use of the same connection for
|
|
requests to URIs starting with <spanx style="verb">https://a.example.com/</spanx> and
|
|
<spanx style="verb">https://b.example.com/</spanx>.
|
|
</t>
|
|
<t>
|
|
In some deployments, reusing a connection for multiple origins can result in requests
|
|
being directed to the wrong origin server. For example, TLS termination might be
|
|
performed by a middlebox that uses the TLS <xref target="TLS-EXT">Server Name Indication
|
|
(SNI)</xref> extension to select an origin server. This means that it is possible
|
|
for clients to send confidential information to servers that might not be the intended
|
|
target for the request, even though the server is otherwise authoritative.
|
|
</t>
|
|
<t>
|
|
A server that does not wish clients to reuse connections can indicate that it is not
|
|
authoritative for a request by sending a 421 (Misdirected Request) status code in response
|
|
to the request (see <xref target="MisdirectedRequest"/>).
|
|
</t>
|
|
<t>
|
|
A client that is configured to use a proxy over HTTP/2 directs requests to that proxy
|
|
through a single connection. That is, all requests sent via a proxy reuse the
|
|
connection to the proxy.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="MisdirectedRequest" title="The 421 (Misdirected Request) Status Code">
|
|
<t>
|
|
The 421 (Misdirected Request) status code indicates that the request was directed at a
|
|
server that is not able to produce a response. This can be sent by a server that is not
|
|
configured to produce responses for the combination of scheme and authority that are
|
|
included in the request URI.
|
|
</t>
|
|
<t>
|
|
Clients receiving a 421 (Misdirected Request) response from a server MAY retry the
|
|
request - whether the request method is idempotent or not - over a different connection.
|
|
This is possible if a connection is reused (<xref target="reuse"/>) or if an alternative
|
|
service is selected (<xref target="ALT-SVC"/>).
|
|
</t>
|
|
<t>
|
|
This status code MUST NOT be generated by proxies.
|
|
</t>
|
|
<t>
|
|
A 421 response is cacheable by default; i.e., unless otherwise indicated by the method
|
|
definition or explicit cache controls (see <xref target="RFC7234"
|
|
x:rel="#heuristic.freshness" x:fmt="of"/>).
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section title="Use of TLS Features" anchor="TLSUsage">
|
|
<t>
|
|
Implementations of HTTP/2 MUST support <xref target="TLS12">TLS 1.2</xref> for HTTP/2 over
|
|
TLS. The general TLS usage guidance in <xref target="TLSBCP"/> SHOULD be followed, with
|
|
some additional restrictions that are specific to HTTP/2.
|
|
</t>
|
|
|
|
<t>
|
|
An implementation of HTTP/2 over TLS MUST use TLS 1.2 or higher with the restrictions on
|
|
feature set and cipher suite described in this section. Due to implementation
|
|
limitations, it might not be possible to fail TLS negotiation. An endpoint MUST
|
|
immediately terminate an HTTP/2 connection that does not meet these minimum requirements
|
|
with a <xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>INADEQUATE_SECURITY</x:ref>.
|
|
</t>
|
|
|
|
<section anchor="TLSFeatures" title="TLS Features">
|
|
<t>
|
|
The TLS implementation MUST support the <xref target="TLS-EXT">Server Name Indication
|
|
(SNI)</xref> extension to TLS. HTTP/2 clients MUST indicate the target domain name when
|
|
negotiating TLS.
|
|
</t>
|
|
<t>
|
|
The TLS implementation MUST disable compression. TLS compression 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 likely to be more appropriate for use for
|
|
performance, security or other reasons.
|
|
</t>
|
|
<t>
|
|
The TLS implementation MUST disable renegotiation. An endpoint MUST treat a TLS
|
|
renegotiation as a <xref target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>PROTOCOL_ERROR</x:ref>. Note that disabling renegotiation can result in
|
|
long-lived connections becoming unusable due to limits on the number of messages the
|
|
underlying cipher suite can encipher.
|
|
</t>
|
|
<t>
|
|
A client MAY use renegotiation to provide confidentiality protection for client
|
|
credentials offered in the handshake, but any renegotiation MUST occur prior to sending
|
|
the connection preface. A server SHOULD request a client certificate if it sees a
|
|
renegotiation request immediately after establishing a connection.
|
|
</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
|
|
use case. <!-- <cref> We are tracking this in a non-blocking fashion in issue #496 and
|
|
with a new draft. -->
|
|
</t>
|
|
</section>
|
|
|
|
<section title="TLS Cipher Suites">
|
|
<t>
|
|
The set of TLS cipher suites that are permitted in HTTP/2 is restricted. HTTP/2 MUST
|
|
only be used with cipher suites that have ephemeral key exchange, such as the <xref
|
|
target="TLS12">ephemeral Diffie-Hellman (DHE)</xref> or the <xref
|
|
target="RFC4492">elliptic curve variant (ECDHE)</xref>. Ephemeral key exchange MUST
|
|
have a minimum size of 2048 bits for DHE or security level of 128 bits for ECDHE.
|
|
Clients MUST accept DHE sizes of up to 4096 bits. HTTP MUST NOT be used with cipher
|
|
suites that use stream or block ciphers. Authenticated Encryption with Additional Data
|
|
(AEAD) modes, such as the <xref target="RFC5288">Galois Counter Model (GCM) mode for
|
|
AES</xref> are acceptable.
|
|
</t>
|
|
<t>
|
|
The effect of these restrictions is that TLS 1.2 implementations could have
|
|
non-intersecting sets of available cipher suites, since these prevent the use of the
|
|
cipher suite that TLS 1.2 makes mandatory. To avoid this problem, implementations of
|
|
HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 <xref
|
|
target="TLS-ECDHE"/> with P256 <xref target="FIPS186"/>.
|
|
</t>
|
|
<t>
|
|
Clients MAY advertise support of cipher suites that are prohibited by the above
|
|
restrictions in order to allow for connection to servers that do not support HTTP/2.
|
|
This enables a fallback to protocols without these constraints without the additional
|
|
latency imposed by using a separate connection for fallback.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="security" title="Security Considerations">
|
|
<section title="Server Authority" anchor="authority">
|
|
<t>
|
|
HTTP/2 relies on the HTTP/1.1 definition of authority for determining whether a server is
|
|
authoritative in providing a given response, see <xref target="RFC7230" x:fmt=","
|
|
x:rel="#establishing.authority"/>. This relies on local name resolution for the "http"
|
|
URI scheme, and the authenticated server identity for the "https" scheme (see <xref
|
|
target="RFC2818" x:fmt="," x:sec="3"/>).
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Cross-Protocol Attacks">
|
|
<t>
|
|
In a cross-protocol attack, an attacker causes a client to initiate a transaction in one
|
|
protocol toward a server that understands a different protocol. An attacker might be able
|
|
to cause the transaction to appear as valid transaction in the second protocol. In
|
|
combination with the capabilities of the web context, this can be used to interact with
|
|
poorly protected servers in private networks.
|
|
</t>
|
|
<t>
|
|
Completing a TLS handshake with an ALPN identifier for HTTP/2 can be considered sufficient
|
|
protection against cross protocol attacks. ALPN provides a positive indication that a
|
|
server is willing to proceed with HTTP/2, which prevents attacks on other TLS-based
|
|
protocols.
|
|
</t>
|
|
<t>
|
|
The encryption in TLS makes it difficult for attackers to control the data which could be
|
|
used in a cross-protocol attack on a cleartext protocol.
|
|
</t>
|
|
<t>
|
|
The cleartext version of HTTP/2 has minimal protection against cross-protocol attacks.
|
|
The <xref target="ConnectionHeader">connection preface</xref> contains a string that is
|
|
designed to confuse HTTP/1.1 servers, but no special protection is offered for other
|
|
protocols. A server that is willing to ignore parts of an HTTP/1.1 request containing an
|
|
Upgrade header field in addition to the client connection preface could be exposed to a
|
|
cross-protocol attack.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Intermediary Encapsulation Attacks">
|
|
<t>
|
|
HTTP/2 header field names and values are encoded as sequences of octets with a length
|
|
prefix. This enables HTTP/2 to carry any string of octets as the name or value of a
|
|
header field. An intermediary that translates HTTP/2 requests or responses into HTTP/1.1
|
|
directly could permit the creation of corrupted HTTP/1.1 messages. An attacker might
|
|
exploit this behavior to cause the intermediary to create HTTP/1.1 messages with illegal
|
|
header fields, extra header fields, or even new messages that are entirely falsified.
|
|
</t>
|
|
<t>
|
|
Header field names or values that contain characters not permitted by HTTP/1.1, including
|
|
carriage return (ASCII 0xd) or line feed (ASCII 0xa) MUST NOT be translated verbatim by an
|
|
intermediary, as stipulated in <xref target="RFC7230" x:rel="#field.parsing" x:fmt=","/>.
|
|
</t>
|
|
<t>
|
|
Translation from HTTP/1.x to HTTP/2 does not produce the same opportunity to an attacker.
|
|
Intermediaries that perform translation to HTTP/2 MUST remove any instances of the <spanx
|
|
style="verb">obs-fold</spanx> production from header field values.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Cacheability of Pushed Responses">
|
|
<t>
|
|
Pushed responses do not have an explicit request from the client; the request
|
|
is provided by the server in the <x:ref>PUSH_PROMISE</x:ref> frame.
|
|
</t>
|
|
<t>
|
|
Caching responses that are pushed is possible based on the guidance provided by the origin
|
|
server in the Cache-Control header field. However, this can cause issues if a single
|
|
server hosts more than one tenant. For example, a server might offer multiple users each
|
|
a small portion of its URI space.
|
|
</t>
|
|
<t>
|
|
Where multiple tenants share space on the same server, that server MUST ensure that
|
|
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 representation that would
|
|
be served out of cache, overriding the actual representation that the authoritative tenant
|
|
provides.
|
|
</t>
|
|
<t>
|
|
Pushed responses for which an origin server is not authoritative (see
|
|
<xref target="authority"/>) are never cached or used.
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="dos" title="Denial of Service Considerations">
|
|
<t>
|
|
An HTTP/2 connection can demand a greater commitment of resources to operate than a
|
|
HTTP/1.1 connection. The use of header compression and flow control depend on a
|
|
commitment of resources for storing a greater amount of state. Settings for these
|
|
features ensure that memory commitments for these features are strictly bounded.
|
|
</t>
|
|
<t>
|
|
The number of <x:ref>PUSH_PROMISE</x:ref> frames is not constrained in the same fashion.
|
|
A client that accepts server push SHOULD limit the number of streams it allows to be in
|
|
the "reserved (remote)" state. Excessive number of server push streams can be treated as
|
|
a <xref target="StreamErrorHandler">stream error</xref> of type
|
|
<x:ref>ENHANCE_YOUR_CALM</x:ref>.
|
|
</t>
|
|
<t>
|
|
Processing capacity cannot be guarded as effectively as state capacity.
|
|
</t>
|
|
<t>
|
|
The <x:ref>SETTINGS</x:ref> frame can be abused to cause a peer to expend additional
|
|
processing time. This might be done by pointlessly changing SETTINGS parameters, setting
|
|
multiple undefined parameters, or changing the same setting multiple times in the same
|
|
frame. <x:ref>WINDOW_UPDATE</x:ref> or <x:ref>PRIORITY</x:ref> frames can be abused to
|
|
cause an unnecessary waste of resources.
|
|
</t>
|
|
<t>
|
|
Large numbers of small or empty frames can be abused to cause a peer to expend time
|
|
processing frame headers. Note however that some uses are entirely legitimate, such as
|
|
the sending of an empty <x:ref>DATA</x:ref> frame to end a stream.
|
|
</t>
|
|
<t>
|
|
Header compression also offers some opportunities to waste processing resources; see <xref
|
|
target="COMPRESSION" x:fmt="of" x:rel="#Security"/> for more details on potential abuses.
|
|
</t>
|
|
<t>
|
|
Limits in <x:ref>SETTINGS</x:ref> parameters cannot be reduced instantaneously, which
|
|
leaves an endpoint exposed to behavior from a peer that could exceed the new limits. In
|
|
particular, immediately after establishing a connection, limits set by a server are not
|
|
known to clients and could be exceeded without being an obvious protocol violation.
|
|
</t>
|
|
<t>
|
|
All these features - i.e., <x:ref>SETTINGS</x:ref> changes, small frames, header
|
|
compression - have legitimate uses. These features become a burden only when they are
|
|
used unnecessarily or to excess.
|
|
</t>
|
|
<t>
|
|
An endpoint that doesn't monitor this behavior exposes itself to a risk of denial of
|
|
service attack. Implementations SHOULD track the use of these features and set limits on
|
|
their use. An endpoint MAY treat activity that is suspicious as a <xref
|
|
target="ConnectionErrorHandler">connection error</xref> of type
|
|
<x:ref>ENHANCE_YOUR_CALM</x:ref>.
|
|
</t>
|
|
|
|
<section anchor="MaxHeaderBlock" title="Limits on Header Block Size">
|
|
<t>
|
|
A large <xref target="HeaderBlock">header block</xref> can cause an implementation to
|
|
commit a large amount of state. Header fields that are critical for routing can appear
|
|
toward the end of a header block, which prevents streaming of header fields to their
|
|
ultimate destination. For this an other reasons, such as ensuring cache correctness,
|
|
means that an endpoint might need to buffer the entire header block. Since there is no
|
|
hard limit to the size of a header block, some endpoints could be forced commit a large
|
|
amount of available memory for header fields.
|
|
</t>
|
|
<t>
|
|
An endpoint can use the <x:ref>SETTINGS_MAX_HEADER_LIST_SIZE</x:ref> to advise peers of
|
|
limits that might apply on the size of header blocks. This setting is only advisory, so
|
|
endpoints MAY choose to send header blocks that exceed this limit and risk having the
|
|
request or response being treated as malformed. This setting specific to a 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 by
|
|
different peers, but they are not obligated to do so.
|
|
</t>
|
|
<t>
|
|
A server that receives a larger header block than it is willing to handle can send an
|
|
HTTP 431 (Request Header Fields Too Large) status code <xref target="RFC6585"/>. A
|
|
client can discard responses that it cannot process. The header block MUST be processed
|
|
to ensure a consistent connection state, unless the connection is closed.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section title="Use of Compression">
|
|
<t>
|
|
HTTP/2 enables greater use of compression for both header fields (<xref
|
|
target="HeaderBlock"/>) and entity bodies. Compression can allow an attacker to recover
|
|
secret data when it is compressed in the same context as data under attacker control.
|
|
</t>
|
|
<t>
|
|
There are demonstrable attacks on compression that exploit the characteristics of the web
|
|
(e.g., <xref target="BREACH"/>). The attacker induces multiple requests containing
|
|
varying plaintext, observing the length of the resulting ciphertext in each, which
|
|
reveals a shorter length when a guess about the secret is correct.
|
|
</t>
|
|
<t>
|
|
Implementations communicating on a secure channel MUST NOT compress content that includes
|
|
both confidential and attacker-controlled data unless separate compression dictionaries
|
|
are used for each source of data. Compression MUST NOT be used if the source of data
|
|
cannot be reliably determined. Generic stream compression, such as that provided by TLS
|
|
MUST NOT be used with HTTP/2 (<xref target="TLSFeatures"/>).
|
|
</t>
|
|
<t>
|
|
Further considerations regarding the compression of header fields are described in <xref
|
|
target="COMPRESSION"/>.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Use of Padding" anchor="padding">
|
|
<t>
|
|
Padding within HTTP/2 is not intended as a replacement for general purpose padding, such
|
|
as might be provided by <xref target="TLS12">TLS</xref>. Redundant padding could even be
|
|
counterproductive. Correct application can depend on having specific knowledge of the
|
|
data that is being padded.
|
|
</t>
|
|
<t>
|
|
To mitigate attacks that rely on compression, disabling or limiting compression might be
|
|
preferable to padding as a countermeasure.
|
|
</t>
|
|
<t>
|
|
Padding can be used to obscure the exact size of frame content, and is provided to
|
|
mitigate specific attacks within HTTP. For example, attacks where compressed content
|
|
includes both attacker-controlled plaintext and secret data (see for example, <xref
|
|
target="BREACH"/>).
|
|
</t>
|
|
<t>
|
|
Use of padding can result in less protection than might seem immediately obvious. At
|
|
best, padding only makes it more difficult for an attacker to infer length information by
|
|
increasing the number of frames an attacker has to observe. Incorrectly implemented
|
|
padding schemes can be easily defeated. In particular, randomized padding with a
|
|
predictable distribution provides very little protection; similarly, padding payloads to a
|
|
fixed size exposes information as payload sizes cross the fixed size boundary, which could
|
|
be possible if an attacker can control plaintext.
|
|
</t>
|
|
<t>
|
|
Intermediaries SHOULD retain padding for <x:ref>DATA</x:ref> frames, but MAY drop padding
|
|
for <x:ref>HEADERS</x:ref> and <x:ref>PUSH_PROMISE</x:ref> frames. A valid reason for an
|
|
intermediary to change the amount of padding of frames is to improve the protections that
|
|
padding provides.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Privacy Considerations">
|
|
<t>
|
|
Several characteristics of HTTP/2 provide an observer an opportunity to correlate actions
|
|
of a single client or server over time. This includes the value of settings, the manner
|
|
in which flow control windows are managed, the way priorities are allocated to streams,
|
|
timing of reactions to stimulus, and handling of any optional features.
|
|
</t>
|
|
<t>
|
|
As far as this creates observable differences in behavior, they could be used as a basis
|
|
for fingerprinting a specific client, as defined in <xref target="HTML5" x:fmt="of"
|
|
x:sec="1.8" x:rel="introduction.html#fingerprint"/>.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
<section anchor="iana" title="IANA Considerations">
|
|
<t>
|
|
A string for identifying HTTP/2 is entered into the "Application Layer Protocol Negotiation
|
|
(ALPN) Protocol IDs" registry established in <xref target="TLS-ALPN"/>.
|
|
</t>
|
|
<t>
|
|
This document establishes a registry for frame types, settings, and error codes. These new
|
|
registries are entered into a new "Hypertext Transfer Protocol (HTTP) 2 Parameters" section.
|
|
</t>
|
|
<t>
|
|
This document registers the <spanx style="verb">HTTP2-Settings</spanx> header field for
|
|
use in HTTP; and the 421 (Misdirected Request) status code.
|
|
</t>
|
|
<t>
|
|
This document registers the <spanx style="verb">PRI</spanx> method for use in HTTP, to avoid
|
|
collisions with the <xref target="ConnectionHeader">connection preface</xref>.
|
|
</t>
|
|
|
|
<section anchor="iana-alpn" title="Registration of HTTP/2 Identification Strings">
|
|
<t>
|
|
This document creates two registrations for the identification of HTTP/2 in the
|
|
"Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in <xref
|
|
target="TLS-ALPN"/>.
|
|
</t>
|
|
<t>
|
|
The "h2" string identifies HTTP/2 when used over TLS:
|
|
<list style="hanging">
|
|
<t hangText="Protocol:">HTTP/2 over TLS</t>
|
|
<t hangText="Identification Sequence:">0x68 0x32 ("h2")</t>
|
|
<t hangText="Specification:">This document</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
The "h2c" string identifies HTTP/2 when used over cleartext TCP:
|
|
<list style="hanging">
|
|
<t hangText="Protocol:">HTTP/2 over TCP</t>
|
|
<t hangText="Identification Sequence:">0x68 0x32 0x63 ("h2c")</t>
|
|
<t hangText="Specification:">This document</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
|
|
<section anchor="iana-frames" title="Frame Type Registry">
|
|
<t>
|
|
This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame
|
|
Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under
|
|
either of the <xref target="RFC5226">"IETF Review" or "IESG Approval" policies</xref> for
|
|
values between 0x00 and 0xef, with values between 0xf0 and 0xff being reserved for
|
|
experimental use.
|
|
</t>
|
|
<t>
|
|
New entries in this registry require the following information:
|
|
<list style="hanging">
|
|
<t hangText="Frame Type:">
|
|
A name or label for the frame type.
|
|
</t>
|
|
<t hangText="Code:">
|
|
The 8-bit code assigned to the frame type.
|
|
</t>
|
|
<t hangText="Specification:">
|
|
A reference to a specification that includes a description of the frame layout,
|
|
it's semantics and flags that the frame type uses, including any parts of the frame
|
|
that are conditionally present based on the value of flags.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
The entries in the following table are registered by this document.
|
|
</t>
|
|
<texttable align="left" suppress-title="true">
|
|
<ttcol>Frame Type</ttcol>
|
|
<ttcol>Code</ttcol>
|
|
<ttcol>Section</ttcol>
|
|
<c>DATA</c><c>0x0</c><c><xref target="DATA"/></c>
|
|
<c>HEADERS</c><c>0x1</c><c><xref target="HEADERS"/></c>
|
|
<c>PRIORITY</c><c>0x2</c><c><xref target="PRIORITY"/></c>
|
|
<c>RST_STREAM</c><c>0x3</c><c><xref target="RST_STREAM"/></c>
|
|
<c>SETTINGS</c><c>0x4</c><c><xref target="SETTINGS"/></c>
|
|
<c>PUSH_PROMISE</c><c>0x5</c><c><xref target="PUSH_PROMISE"/></c>
|
|
<c>PING</c><c>0x6</c><c><xref target="PING"/></c>
|
|
<c>GOAWAY</c><c>0x7</c><c><xref target="GOAWAY"/></c>
|
|
<c>WINDOW_UPDATE</c><c>0x8</c><c><xref target="WINDOW_UPDATE"/></c>
|
|
<c>CONTINUATION</c><c>0x9</c><c><xref target="CONTINUATION"/></c>
|
|
</texttable>
|
|
</section>
|
|
|
|
<section anchor="iana-settings" title="Settings Registry">
|
|
<t>
|
|
This document establishes a registry for HTTP/2 settings. The "HTTP/2 Settings" registry
|
|
manages a 16-bit space. The "HTTP/2 Settings" registry operates under the <xref
|
|
target="RFC5226">"Expert Review" policy</xref> for values in the range from 0x0000 to
|
|
0xefff, with values between and 0xf000 and 0xffff being reserved for experimental use.
|
|
</t>
|
|
<t>
|
|
New registrations are advised to provide the following information:
|
|
<list style="hanging">
|
|
<t hangText="Name:">
|
|
A symbolic name for the setting. Specifying a setting name is optional.
|
|
</t>
|
|
<t hangText="Code:">
|
|
The 16-bit code assigned to the setting.
|
|
</t>
|
|
<t hangText="Initial Value:">
|
|
An initial value for the setting.
|
|
</t>
|
|
<t hangText="Specification:">
|
|
An optional reference to a specification that describes the use of the setting.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
An initial set of setting registrations can be found in <xref target="SettingValues"/>.
|
|
</t>
|
|
<texttable align="left" suppress-title="true">
|
|
<ttcol>Name</ttcol>
|
|
<ttcol>Code</ttcol>
|
|
<ttcol>Initial Value</ttcol>
|
|
<ttcol>Specification</ttcol>
|
|
<c>HEADER_TABLE_SIZE</c>
|
|
<c>0x1</c><c>4096</c><c><xref target="SettingValues"/></c>
|
|
<c>ENABLE_PUSH</c>
|
|
<c>0x2</c><c>1</c><c><xref target="SettingValues"/></c>
|
|
<c>MAX_CONCURRENT_STREAMS</c>
|
|
<c>0x3</c><c>(infinite)</c><c><xref target="SettingValues"/></c>
|
|
<c>INITIAL_WINDOW_SIZE</c>
|
|
<c>0x4</c><c>65535</c><c><xref target="SettingValues"/></c>
|
|
<c>MAX_FRAME_SIZE</c>
|
|
<c>0x5</c><c>16384</c><c><xref target="SettingValues"/></c>
|
|
<c>MAX_HEADER_LIST_SIZE</c>
|
|
<c>0x6</c><c>(infinite)</c><c><xref target="SettingValues"/></c>
|
|
</texttable>
|
|
|
|
</section>
|
|
|
|
<section anchor="iana-errors" title="Error Code Registry">
|
|
<t>
|
|
This document establishes a registry for HTTP/2 error codes. The "HTTP/2 Error Code"
|
|
registry manages a 32-bit space. The "HTTP/2 Error Code" registry operates under the
|
|
<xref target="RFC5226">"Expert Review" policy</xref>.
|
|
</t>
|
|
<t>
|
|
Registrations for error codes are required to include a description of the error code. An
|
|
expert reviewer is advised to examine new registrations for possible duplication with
|
|
existing error codes. Use of existing registrations is to be encouraged, but not
|
|
mandated.
|
|
</t>
|
|
<t>
|
|
New registrations are advised to provide the following information:
|
|
<list style="hanging">
|
|
<t hangText="Name:">
|
|
A name for the error code. Specifying an error code name is optional.
|
|
</t>
|
|
<t hangText="Code:">
|
|
The 32-bit error code value.
|
|
</t>
|
|
<t hangText="Description:">
|
|
A brief description of the error code semantics, longer if no detailed specification
|
|
is provided.
|
|
</t>
|
|
<t hangText="Specification:">
|
|
An optional reference for a specification that defines the error code.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
<t>
|
|
The entries in the following table are registered by this document.
|
|
</t>
|
|
<texttable align="left" suppress-title="true">
|
|
<ttcol>Name</ttcol>
|
|
<ttcol>Code</ttcol>
|
|
<ttcol>Description</ttcol>
|
|
<ttcol>Specification</ttcol>
|
|
<c>NO_ERROR</c><c>0x0</c>
|
|
<c>Graceful shutdown</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>PROTOCOL_ERROR</c><c>0x1</c>
|
|
<c>Protocol error detected</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>INTERNAL_ERROR</c><c>0x2</c>
|
|
<c>Implementation fault</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>FLOW_CONTROL_ERROR</c><c>0x3</c>
|
|
<c>Flow control limits exceeded</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>SETTINGS_TIMEOUT</c><c>0x4</c>
|
|
<c>Settings not acknowledged</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>STREAM_CLOSED</c><c>0x5</c>
|
|
<c>Frame received for closed stream</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>FRAME_SIZE_ERROR</c><c>0x6</c>
|
|
<c>Frame size incorrect</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>REFUSED_STREAM</c><c>0x7</c>
|
|
<c>Stream not processed</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>CANCEL</c><c>0x8</c>
|
|
<c>Stream cancelled</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>COMPRESSION_ERROR</c><c>0x9</c>
|
|
<c>Compression state not updated</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>CONNECT_ERROR</c><c>0xa</c>
|
|
<c>TCP connection error for CONNECT method</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>ENHANCE_YOUR_CALM</c><c>0xb</c>
|
|
<c>Processing capacity exceeded</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
<c>INADEQUATE_SECURITY</c><c>0xc</c>
|
|
<c>Negotiated TLS parameters not acceptable</c>
|
|
<c><xref target="ErrorCodes"/></c>
|
|
</texttable>
|
|
|
|
</section>
|
|
|
|
<section title="HTTP2-Settings Header Field Registration">
|
|
<t>
|
|
This section registers the <spanx style="verb">HTTP2-Settings</spanx> header field in the
|
|
<xref target="BCP90">Permanent Message Header Field Registry</xref>.
|
|
<list style="hanging">
|
|
<t hangText="Header field name:">
|
|
HTTP2-Settings
|
|
</t>
|
|
<t hangText="Applicable protocol:">
|
|
http
|
|
</t>
|
|
<t hangText="Status:">
|
|
standard
|
|
</t>
|
|
<t hangText="Author/Change controller:">
|
|
IETF
|
|
</t>
|
|
<t hangText="Specification document(s):">
|
|
<xref target="Http2SettingsHeader"/> of this document
|
|
</t>
|
|
<t hangText="Related information:">
|
|
This header field is only used by an HTTP/2 client for Upgrade-based negotiation.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
|
|
<section title="PRI Method Registration">
|
|
<t>
|
|
This section registers the <spanx style="verb">PRI</spanx> method in the HTTP Method
|
|
Registry (<xref target="RFC7231" x:fmt="," x:rel="#method.registry"/>).
|
|
<list style="hanging">
|
|
<t hangText="Method Name:">
|
|
PRI
|
|
</t>
|
|
<t hangText="Safe">
|
|
No
|
|
</t>
|
|
<t hangText="Idempotent">
|
|
No
|
|
</t>
|
|
<t hangText="Specification document(s)">
|
|
<xref target="ConnectionHeader"/> of this document
|
|
</t>
|
|
<t hangText="Related information:">
|
|
This method is never used by an actual client. This method will appear to be used
|
|
when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2 connection
|
|
preface.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
|
|
<section title="The 421 (Misdirected Request) HTTP Status Code"
|
|
anchor="iana-MisdirectedRequest">
|
|
<t>
|
|
This document registers the 421 (Misdirected Request) HTTP Status code in the Hypertext
|
|
Transfer Protocol (HTTP) Status Code Registry (<xref target="RFC7231" x:fmt=","
|
|
x:rel="#status.code.registry"/>).
|
|
</t>
|
|
<t>
|
|
<list style="hanging">
|
|
<t hangText="Status Code:">
|
|
421
|
|
</t>
|
|
<t hangText="Short Description:">
|
|
Misdirected Request
|
|
</t>
|
|
<t hangText="Specification:">
|
|
<xref target="MisdirectedRequest"/> of this document
|
|
</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
|
|
</section>
|
|
|
|
<section title="Acknowledgements">
|
|
<t>
|
|
This document includes substantial input from the following individuals:
|
|
<list style="symbols">
|
|
<t>
|
|
Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin
|
|
Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin
|
|
Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton (SPDY
|
|
contributors).
|
|
</t>
|
|
<t>
|
|
Gabriel Montenegro and Willy Tarreau (Upgrade mechanism).
|
|
</t>
|
|
<t>
|
|
William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto
|
|
Peon, Rob Trace (Flow control).
|
|
</t>
|
|
<t>
|
|
Mike Bishop (Extensibility).
|
|
</t>
|
|
<t>
|
|
Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike Bishop, Herve Ruellan
|
|
(Substantial editorial contributions).
|
|
</t>
|
|
<t>
|
|
Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp.
|
|
</t>
|
|
<t>
|
|
Alexey Melnikov was an editor of this document during 2013.
|
|
</t>
|
|
<t>
|
|
A substantial proportion of Martin's contribution was supported by Microsoft during his
|
|
employment there.
|
|
</t>
|
|
</list>
|
|
</t>
|
|
</section>
|
|
</middle>
|
|
|
|
<back>
|
|
<references title="Normative References">
|
|
<reference anchor="COMPRESSION">
|
|
<front>
|
|
<title>HPACK - Header Compression for HTTP/2</title>
|
|
<author initials="H." surname="Ruellan" fullname="Herve Ruellan"/>
|
|
<author initials="R." surname="Peon" fullname="Roberto Peon"/>
|
|
<date month="July" year="2014" />
|
|
</front>
|
|
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-header-compression-09" />
|
|
<x:source href="refs/draft-ietf-httpbis-header-compression-09.xml"/>
|
|
</reference>
|
|
|
|
<reference anchor="TCP">
|
|
<front>
|
|
<title abbrev="Transmission Control Protocol">
|
|
Transmission Control Protocol
|
|
</title>
|
|
<author initials="J." surname="Postel" fullname="Jon Postel">
|
|
<organization>University of Southern California (USC)/Information Sciences
|
|
Institute</organization>
|
|
</author>
|
|
<date year="1981" month="September" />
|
|
</front>
|
|
<seriesInfo name="STD" value="7" />
|
|
<seriesInfo name="RFC" value="793" />
|
|
</reference>
|
|
|
|
<reference anchor="RFC2119">
|
|
<front>
|
|
<title>
|
|
Key words for use in RFCs to Indicate Requirement Levels
|
|
</title>
|
|
<author initials="S." surname="Bradner" fullname="Scott Bradner">
|
|
<organization>Harvard University</organization>
|
|
<address><email>sob@harvard.edu</email></address>
|
|
</author>
|
|
<date month="March" year="1997"/>
|
|
</front>
|
|
<seriesInfo name="BCP" value="14"/>
|
|
<seriesInfo name="RFC" value="2119"/>
|
|
</reference>
|
|
|
|
<reference anchor="RFC2818">
|
|
<front>
|
|
<title>
|
|
HTTP Over TLS
|
|
</title>
|
|
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"/>
|
|
<date month="May" year="2000"/>
|
|
</front>
|
|
<seriesInfo name="RFC" value="2818"/>
|
|
</reference>
|
|
|
|
<reference anchor="RFC3986">
|
|
<front>
|
|
<title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic
|
|
Syntax</title>
|
|
<author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"></author>
|
|
<author initials="R." surname="Fielding" fullname="Roy T. Fielding"></author>
|
|
<author initials="L." surname="Masinter" fullname="Larry Masinter"></author>
|
|
<date year="2005" month="January" />
|
|
</front>
|
|
<seriesInfo name="STD" value="66" />
|
|
<seriesInfo name="RFC" value="3986" />
|
|
</reference>
|
|
|
|
<reference anchor="RFC4648">
|
|
<front>
|
|
<title>The Base16, Base32, and Base64 Data Encodings</title>
|
|
<author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
|
|
<date year="2006" month="October"/>
|
|
</front>
|
|
<seriesInfo value="4648" name="RFC"/>
|
|
</reference>
|
|
|
|
<reference anchor="RFC5226">
|
|
<front>
|
|
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
|
|
<author initials="T." surname="Narten" fullname="T. Narten"/>
|
|
<author initials="H." surname="Alvestrand" fullname="H. Alvestrand"/>
|
|
<date year="2008" month="May" />
|
|
</front>
|
|
<seriesInfo name="BCP" value="26" />
|
|
<seriesInfo name="RFC" value="5226" />
|
|
</reference>
|
|
|
|
<reference anchor="RFC5234">
|
|
<front>
|
|
<title>Augmented BNF for Syntax Specifications: ABNF</title>
|
|
<author initials="D." surname="Crocker" fullname="D. Crocker"/>
|
|
<author initials="P." surname="Overell" fullname="P. Overell"/>
|
|
<date year="2008" month="January" />
|
|
</front>
|
|
<seriesInfo name="STD" value="68" />
|
|
<seriesInfo name="RFC" value="5234" />
|
|
</reference>
|
|
|
|
<reference anchor="TLS12">
|
|
<front>
|
|
<title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
|
|
<author initials="T." surname="Dierks" fullname="Tim Dierks"/>
|
|
<author initials="E." surname="Rescorla" fullname="Eric Rescorla"/>
|
|
<date year="2008" month="August" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="5246" />
|
|
</reference>
|
|
|
|
<reference anchor="TLS-EXT">
|
|
<front>
|
|
<title>
|
|
Transport Layer Security (TLS) Extensions: Extension Definitions
|
|
</title>
|
|
<author initials="D." surname="Eastlake" fullname="D. Eastlake"/>
|
|
<date year="2011" month="January"/>
|
|
</front>
|
|
<seriesInfo name="RFC" value="6066"/>
|
|
</reference>
|
|
|
|
<reference anchor="TLS-ALPN">
|
|
<front>
|
|
<title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
|
|
<author initials="S." surname="Friedl" fullname="Stephan Friedl"></author>
|
|
<author initials="A." surname="Popov" fullname="Andrei Popov"></author>
|
|
<author initials="A." surname="Langley" fullname="Adam Langley"></author>
|
|
<author initials="E." surname="Stephan" fullname="Emile Stephan"></author>
|
|
<date month="July" year="2014" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="7301" />
|
|
</reference>
|
|
|
|
<reference anchor="TLS-ECDHE">
|
|
<front>
|
|
<title>
|
|
TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois
|
|
Counter Mode (GCM)
|
|
</title>
|
|
<author initials="E." surname="Rescorla" fullname="E. Rescorla"/>
|
|
<date year="2008" month="August" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="5289" />
|
|
</reference>
|
|
|
|
<reference anchor="FIPS186">
|
|
<front>
|
|
<title>
|
|
Digital Signature Standard (DSS)
|
|
</title>
|
|
<author><organization>NIST</organization></author>
|
|
<date year="2013" month="July" />
|
|
</front>
|
|
<seriesInfo name="FIPS" value="PUB 186-4" />
|
|
</reference>
|
|
|
|
<reference anchor="RFC7230">
|
|
<front>
|
|
<title>
|
|
Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
|
|
<author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
|
|
<organization abbrev="Adobe">Adobe Systems Incorporated</organization>
|
|
<address><email>fielding@gbiv.com</email></address>
|
|
</author>
|
|
<author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
|
|
<organization abbrev="greenbytes">greenbytes GmbH</organization>
|
|
<address><email>julian.reschke@greenbytes.de</email></address>
|
|
</author>
|
|
<date month="June" year="2014" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="7230" />
|
|
<x:source href="refs/rfc7230.xml"
|
|
basename="https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230"/>
|
|
</reference>
|
|
<reference anchor="RFC7231">
|
|
<front>
|
|
<title>
|
|
Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
|
|
<author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
|
|
<organization abbrev="Adobe">Adobe Systems Incorporated</organization>
|
|
<address><email>fielding@gbiv.com</email></address>
|
|
</author>
|
|
<author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
|
|
<organization abbrev="greenbytes">greenbytes GmbH</organization>
|
|
<address><email>julian.reschke@greenbytes.de</email></address>
|
|
</author>
|
|
<date month="June" year="2014" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="7231" />
|
|
<x:source href="refs/rfc7231.xml"
|
|
basename="https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231"/>
|
|
</reference>
|
|
<reference anchor="RFC7232">
|
|
<front>
|
|
<title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
|
|
<author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
|
|
<organization abbrev="Adobe">Adobe Systems Incorporated</organization>
|
|
<address><email>fielding@gbiv.com</email></address>
|
|
</author>
|
|
<author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
|
|
<organization abbrev="greenbytes">greenbytes GmbH</organization>
|
|
<address><email>julian.reschke@greenbytes.de</email></address>
|
|
</author>
|
|
<date month="June" year="2014" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="7232" />
|
|
</reference>
|
|
<reference anchor="RFC7233">
|
|
<front>
|
|
<title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
|
|
<author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
|
|
<organization abbrev="Adobe">Adobe Systems Incorporated</organization>
|
|
<address><email>fielding@gbiv.com</email></address>
|
|
</author>
|
|
<author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
|
|
<organization abbrev="W3C">World Wide Web Consortium</organization>
|
|
<address><email>ylafon@w3.org</email></address>
|
|
</author>
|
|
<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
|
|
<organization abbrev="greenbytes">greenbytes GmbH</organization>
|
|
<address><email>julian.reschke@greenbytes.de</email></address>
|
|
</author>
|
|
<date month="June" year="2014" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="7233" />
|
|
</reference>
|
|
<reference anchor="RFC7234">
|
|
<front>
|
|
<title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
|
|
<author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
|
|
<organization abbrev="Adobe">Adobe Systems Incorporated</organization>
|
|
<address><email>fielding@gbiv.com</email></address>
|
|
</author>
|
|
<author fullname="Mark Nottingham" initials="M." role="editor" surname="Nottingham">
|
|
<organization>Akamai</organization>
|
|
<address><email>mnot@mnot.net</email></address>
|
|
</author>
|
|
<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
|
|
<organization abbrev="greenbytes">greenbytes GmbH</organization>
|
|
<address><email>julian.reschke@greenbytes.de</email></address>
|
|
</author>
|
|
<date month="June" year="2014" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="7234"/>
|
|
<x:source href="refs/rfc7234.xml"
|
|
basename="https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7234"/>
|
|
</reference>
|
|
<reference anchor="RFC7235">
|
|
<front>
|
|
<title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
|
|
<author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
|
|
<organization abbrev="Adobe">Adobe Systems Incorporated</organization>
|
|
<address><email>fielding@gbiv.com</email></address>
|
|
</author>
|
|
<author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
|
|
<organization abbrev="greenbytes">greenbytes GmbH</organization>
|
|
<address><email>julian.reschke@greenbytes.de</email></address>
|
|
</author>
|
|
<date month="June" year="2014" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="7235"/>
|
|
<x:source href="refs/rfc7235.xml"
|
|
basename="https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7235"/>
|
|
</reference>
|
|
|
|
<reference anchor="COOKIE">
|
|
<front>
|
|
<title>HTTP State Management Mechanism</title>
|
|
<author initials="A." surname="Barth" fullname="A. Barth"/>
|
|
<date year="2011" month="April" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="6265" />
|
|
</reference>
|
|
</references>
|
|
|
|
<references title="Informative References">
|
|
<reference anchor="RFC1323">
|
|
<front>
|
|
<title>
|
|
TCP Extensions for High Performance
|
|
</title>
|
|
<author initials="V." surname="Jacobson" fullname="Van Jacobson"></author>
|
|
<author initials="B." surname="Braden" fullname="Bob Braden"></author>
|
|
<author initials="D." surname="Borman" fullname="Dave Borman"></author>
|
|
<date year="1992" month="May" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="1323" />
|
|
</reference>
|
|
|
|
<reference anchor="RFC3749">
|
|
<front>
|
|
<title>Transport Layer Security Protocol Compression Methods</title>
|
|
<author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck"/>
|
|
<date year="2004" month="May" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="3749" />
|
|
</reference>
|
|
|
|
<reference anchor="RFC6585">
|
|
<front>
|
|
<title>Additional HTTP Status Codes</title>
|
|
<author initials="M." surname="Nottingham" fullname="Mark Nottingham"/>
|
|
<author initials="R." surname="Fielding" fullname="Roy Fielding"/>
|
|
<date year="2012" month="April" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="6585" />
|
|
</reference>
|
|
|
|
<reference anchor="RFC4492">
|
|
<front>
|
|
<title>
|
|
Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
|
|
</title>
|
|
<author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wilson"/>
|
|
<author initials="N." surname="Bolyard" fullname="N. Bolyard"/>
|
|
<author initials="V." surname="Gupta" fullname="V. Gupta"/>
|
|
<author initials="C." surname="Hawk" fullname="C. Hawk"/>
|
|
<author initials="B." surname="Moeller" fullname="B. Moeller"/>
|
|
<date year="2006" month="May" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="4492" />
|
|
</reference>
|
|
|
|
<reference anchor="RFC5288">
|
|
<front>
|
|
<title>
|
|
AES Galois Counter Mode (GCM) Cipher Suites for TLS
|
|
</title>
|
|
<author initials="J." surname="Salowey" fullname="J. Salowey"/>
|
|
<author initials="A." surname="Choudhury" fullname="A. Choudhury"/>
|
|
<author initials="D." surname="McGrew" fullname="D. McGrew"/>
|
|
<date year="2008" month="August" />
|
|
</front>
|
|
<seriesInfo name="RFC" value="5288" />
|
|
</reference>
|
|
|
|
<reference anchor='HTML5'
|
|
target='http://www.w3.org/TR/2014/CR-html5-20140731/'>
|
|
<front>
|
|
<title>HTML5</title>
|
|
<author fullname='Robin Berjon' surname='Berjon' initials='R.'/>
|
|
<author fullname='Steve Faulkner' surname='Faulkner' initials='S.'/>
|
|
<author fullname='Travis Leithead' surname='Leithead' initials='T.'/>
|
|
<author fullname='Erika Doyle Navara' surname='Doyle Navara' initials='E.'/>
|
|
<author fullname='Edward O'Connor' surname='O'Connor' initials='E.'/>
|
|
<author fullname='Silvia Pfeiffer' surname='Pfeiffer' initials='S.'/>
|
|
<date year='2014' month='July' day='31'/>
|
|
</front>
|
|
<seriesInfo name='W3C Candidate Recommendation' value='CR-html5-20140731'/>
|
|
<annotation>
|
|
Latest version available at
|
|
<eref target='http://www.w3.org/TR/html5/'/>.
|
|
</annotation>
|
|
</reference>
|
|
|
|
<reference anchor="TALKING" target="http://w2spconf.com/2011/papers/websocket.pdf">
|
|
<front>
|
|
<title>
|
|
Talking to Yourself for Fun and Profit
|
|
</title>
|
|
<author initials="L-S." surname="Huang"/>
|
|
<author initials="E." surname="Chen"/>
|
|
<author initials="A." surname="Barth"/>
|
|
<author initials="E." surname="Rescorla"/>
|
|
<author initials="C." surname="Jackson"/>
|
|
<date year="2011" />
|
|
</front>
|
|
</reference>
|
|
|
|
<reference anchor="BREACH"
|
|
target="http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf">
|
|
<front>
|
|
<title>
|
|
BREACH: Reviving the CRIME Attack
|
|
</title>
|
|
<author initials="Y." surname="Gluck"/>
|
|
<author initials="N." surname="Harris"/>
|
|
<author initials="A." surname="Prado"/>
|
|
<date year="2013" month="July" day="12"/>
|
|
</front>
|
|
</reference>
|
|
|
|
<reference anchor="BCP90">
|
|
<front>
|
|
<title>Registration Procedures for Message Header Fields</title>
|
|
<author initials="G." surname="Klyne" fullname="G. Klyne">
|
|
<organization>Nine by Nine</organization>
|
|
<address><email>GK-IETF@ninebynine.org</email></address>
|
|
</author>
|
|
<author initials="M." surname="Nottingham" fullname="M. Nottingham">
|
|
<organization>BEA Systems</organization>
|
|
<address><email>mnot@pobox.com</email></address>
|
|
</author>
|
|
<author initials="J." surname="Mogul" fullname="J. Mogul">
|
|
<organization>HP Labs</organization>
|
|
<address><email>JeffMogul@acm.org</email></address>
|
|
</author>
|
|
<date year="2004" month="September" />
|
|
</front>
|
|
<seriesInfo name="BCP" value="90" />
|
|
<seriesInfo name="RFC" value="3864" />
|
|
</reference>
|
|
|
|
<reference anchor="TLSBCP">
|
|
<front>
|
|
<title>Recommendations for Secure Use of TLS and DTLS</title>
|
|
<author initials="Y" surname="Sheffer" fullname="Yaron Sheffer">
|
|
<organization />
|
|
</author>
|
|
<author initials="R" surname="Holz" fullname="Ralph Holz">
|
|
<organization />
|
|
</author>
|
|
<author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
|
|
<organization />
|
|
</author>
|
|
<date month="June" day="23" year="2014" />
|
|
</front>
|
|
<seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls-bcp-01" />
|
|
</reference>
|
|
|
|
<reference anchor="ALT-SVC">
|
|
<front>
|
|
<title>
|
|
HTTP Alternative Services
|
|
</title>
|
|
<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="2014" month="April"/>
|
|
</front>
|
|
<seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-alt-svc-02"/>
|
|
<x:source href="refs/draft-ietf-httpbis-alt-svc-02.xml"/>
|
|
</reference>
|
|
</references>
|
|
|
|
<section title="Change Log" anchor="change.log">
|
|
<t>
|
|
This section is to be removed by RFC Editor before publication.
|
|
</t>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-14" anchor="changes.since.draft-ietf-httpbis-http2-14">
|
|
<t>
|
|
Renamed Not Authoritative status code to Misdirected Request.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-13" anchor="changes.since.draft-ietf-httpbis-http2-13">
|
|
<t>
|
|
Pseudo-header fields are now required to appear strictly before regular ones.
|
|
</t>
|
|
<t>
|
|
Restored 1xx series status codes, except 101.
|
|
</t>
|
|
<t>
|
|
Changed frame length field 24-bits. Expanded frame header to 9 octets. Added a setting
|
|
to limit the damage.
|
|
</t>
|
|
<t>
|
|
Added a setting to advise peers of header set size limits.
|
|
</t>
|
|
<t>
|
|
Removed segments.
|
|
</t>
|
|
<t>
|
|
Made non-semantic-bearing <x:ref>HEADERS</x:ref> frames illegal in the HTTP mapping.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-12" anchor="changes.since.draft-ietf-httpbis-http2-12">
|
|
<t>
|
|
Restored extensibility options.
|
|
</t>
|
|
<t>
|
|
Restricting TLS cipher suites to AEAD only.
|
|
</t>
|
|
<t>
|
|
Removing Content-Encoding requirements.
|
|
</t>
|
|
<t>
|
|
Permitting the use of <x:ref>PRIORITY</x:ref> after stream close.
|
|
</t>
|
|
<t>
|
|
Removed ALTSVC frame.
|
|
</t>
|
|
<t>
|
|
Removed BLOCKED frame.
|
|
</t>
|
|
<t>
|
|
Reducing the maximum padding size to 256 octets; removing padding from
|
|
<x:ref>CONTINUATION</x:ref> frames.
|
|
</t>
|
|
<t>
|
|
Removed per-frame GZIP compression.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-11" anchor="changes.since.draft-ietf-httpbis-http2-11">
|
|
<t>
|
|
Added BLOCKED frame (at risk).
|
|
</t>
|
|
<t>
|
|
Simplified priority scheme.
|
|
</t>
|
|
<t>
|
|
Added <x:ref>DATA</x:ref> per-frame GZIP compression.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-10" anchor="changes.since.draft-ietf-httpbis-http2-10">
|
|
<t>
|
|
Changed "connection header" to "connection preface" to avoid confusion.
|
|
</t>
|
|
<t>
|
|
Added dependency-based stream prioritization.
|
|
</t>
|
|
<t>
|
|
Added "h2c" identifier to distinguish between cleartext and secured HTTP/2.
|
|
</t>
|
|
<t>
|
|
Adding missing padding to <x:ref>PUSH_PROMISE</x:ref>.
|
|
</t>
|
|
<t>
|
|
Integrate ALTSVC frame and supporting text.
|
|
</t>
|
|
<t>
|
|
Dropping requirement on "deflate" Content-Encoding.
|
|
</t>
|
|
<t>
|
|
Improving security considerations around use of compression.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-09" anchor="changes.since.draft-ietf-httpbis-http2-09">
|
|
<t>
|
|
Adding padding for data frames.
|
|
</t>
|
|
<t>
|
|
Renumbering frame types, error codes, and settings.
|
|
</t>
|
|
<t>
|
|
Adding INADEQUATE_SECURITY error code.
|
|
</t>
|
|
<t>
|
|
Updating TLS usage requirements to 1.2; forbidding TLS compression.
|
|
</t>
|
|
<t>
|
|
Removing extensibility for frames and settings.
|
|
</t>
|
|
<t>
|
|
Changing setting identifier size.
|
|
</t>
|
|
<t>
|
|
Removing the ability to disable flow control.
|
|
</t>
|
|
<t>
|
|
Changing the protocol identification token to "h2".
|
|
</t>
|
|
<t>
|
|
Changing the use of :authority to make it optional and to allow userinfo in non-HTTP
|
|
cases.
|
|
</t>
|
|
<t>
|
|
Allowing split on 0x0 for Cookie.
|
|
</t>
|
|
<t>
|
|
Reserved PRI method in HTTP/1.1 to avoid possible future collisions.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-08" anchor="changes.since.draft-ietf-httpbis-http2-08">
|
|
<t>
|
|
Added cookie crumbling for more efficient header compression.
|
|
</t>
|
|
<t>
|
|
Added header field ordering with the value-concatenation mechanism.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-07" anchor="changes.since.draft-ietf-httpbis-http2-07">
|
|
<t>
|
|
Marked draft for implementation.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-06" anchor="changes.since.draft-ietf-httpbis-http2-06">
|
|
<t>
|
|
Adding definition for CONNECT method.
|
|
</t>
|
|
<t>
|
|
Constraining the use of push to safe, cacheable methods with no request body.
|
|
</t>
|
|
<t>
|
|
Changing from :host to :authority to remove any potential confusion.
|
|
</t>
|
|
<t>
|
|
Adding setting for header compression table size.
|
|
</t>
|
|
<t>
|
|
Adding settings acknowledgement.
|
|
</t>
|
|
<t>
|
|
Removing unnecessary and potentially problematic flags from CONTINUATION.
|
|
</t>
|
|
<t>
|
|
Added denial of service considerations.
|
|
</t>
|
|
</section>
|
|
<section title="Since draft-ietf-httpbis-http2-05" anchor="changes.since.draft-ietf-httpbis-http2-05">
|
|
<t>
|
|
Marking the draft ready for implementation.
|
|
</t>
|
|
<t>
|
|
Renumbering END_PUSH_PROMISE flag.
|
|
</t>
|
|
<t>
|
|
Editorial clarifications and changes.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-04" anchor="changes.since.draft-ietf-httpbis-http2-04">
|
|
<t>
|
|
Added CONTINUATION frame for HEADERS and PUSH_PROMISE.
|
|
</t>
|
|
<t>
|
|
PUSH_PROMISE is no longer implicitly prohibited if SETTINGS_MAX_CONCURRENT_STREAMS is
|
|
zero.
|
|
</t>
|
|
<t>
|
|
Push expanded to allow all safe methods without a request body.
|
|
</t>
|
|
<t>
|
|
Clarified the use of HTTP header fields in requests and responses. Prohibited HTTP/1.1
|
|
hop-by-hop header fields.
|
|
</t>
|
|
<t>
|
|
Requiring that intermediaries not forward requests with missing or illegal routing
|
|
:-headers.
|
|
</t>
|
|
<t>
|
|
Clarified requirements around handling different frames after stream close, stream reset
|
|
and <x:ref>GOAWAY</x:ref>.
|
|
</t>
|
|
<t>
|
|
Added more specific prohibitions for sending of different frame types in various stream
|
|
states.
|
|
</t>
|
|
<t>
|
|
Making the last received setting value the effective value.
|
|
</t>
|
|
<t>
|
|
Clarified requirements on TLS version, extension and ciphers.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-03" anchor="changes.since.draft-ietf-httpbis-http2-03">
|
|
<t>
|
|
Committed major restructuring atrocities.
|
|
</t>
|
|
<t>
|
|
Added reference to first header compression draft.
|
|
</t>
|
|
<t>
|
|
Added more formal description of frame lifecycle.
|
|
</t>
|
|
<t>
|
|
Moved END_STREAM (renamed from FINAL) back to <x:ref>HEADERS</x:ref>/<x:ref>DATA</x:ref>.
|
|
</t>
|
|
<t>
|
|
Removed HEADERS+PRIORITY, added optional priority to <x:ref>HEADERS</x:ref> frame.
|
|
</t>
|
|
<t>
|
|
Added <x:ref>PRIORITY</x:ref> frame.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-02" anchor="changes.since.draft-ietf-httpbis-http2-02">
|
|
<t>
|
|
Added continuations to frames carrying header blocks.
|
|
</t>
|
|
<t>
|
|
Replaced use of "session" with "connection" to avoid confusion with other HTTP stateful
|
|
concepts, like cookies.
|
|
</t>
|
|
<t>
|
|
Removed "message".
|
|
</t>
|
|
<t>
|
|
Switched to TLS ALPN from NPN.
|
|
</t>
|
|
<t>
|
|
Editorial changes.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-01" anchor="changes.since.draft-ietf-httpbis-http2-01">
|
|
<t>
|
|
Added IANA considerations section for frame types, error codes and settings.
|
|
</t>
|
|
<t>
|
|
Removed data frame compression.
|
|
</t>
|
|
<t>
|
|
Added <x:ref>PUSH_PROMISE</x:ref>.
|
|
</t>
|
|
<t>
|
|
Added globally applicable flags to framing.
|
|
</t>
|
|
<t>
|
|
Removed zlib-based header compression mechanism.
|
|
</t>
|
|
<t>
|
|
Updated references.
|
|
</t>
|
|
<t>
|
|
Clarified stream identifier reuse.
|
|
</t>
|
|
<t>
|
|
Removed CREDENTIALS frame and associated mechanisms.
|
|
</t>
|
|
<t>
|
|
Added advice against naive implementation of flow control.
|
|
</t>
|
|
<t>
|
|
Added session header section.
|
|
</t>
|
|
<t>
|
|
Restructured frame header. Removed distinction between data and control frames.
|
|
</t>
|
|
<t>
|
|
Altered flow control properties to include session-level limits.
|
|
</t>
|
|
<t>
|
|
Added note on cacheability of pushed resources and multiple tenant servers.
|
|
</t>
|
|
<t>
|
|
Changed protocol label form based on discussions.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-ietf-httpbis-http2-00" anchor="changes.since.draft-ietf-httpbis-http2-00">
|
|
<t>
|
|
Changed title throughout.
|
|
</t>
|
|
<t>
|
|
Removed section on Incompatibilities with SPDY draft#2.
|
|
</t>
|
|
<t>
|
|
Changed <x:ref>INTERNAL_ERROR</x:ref> on <x:ref>GOAWAY</x:ref> to have a value of 2 <eref
|
|
target="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU"/>.
|
|
</t>
|
|
<t>
|
|
Replaced abstract and introduction.
|
|
</t>
|
|
<t>
|
|
Added section on starting HTTP/2.0, including upgrade mechanism.
|
|
</t>
|
|
<t>
|
|
Removed unused references.
|
|
</t>
|
|
<t>
|
|
Added <xref target="fc-principles">flow control principles</xref> based on <eref
|
|
target="https://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01"/>.
|
|
</t>
|
|
</section>
|
|
|
|
<section title="Since draft-mbelshe-httpbis-spdy-00" anchor="changes.since.draft-mbelshe-httpbis-spdy-00">
|
|
<t>
|
|
Adopted as base for draft-ietf-httpbis-http2.
|
|
</t>
|
|
<t>
|
|
Updated authors/editors list.
|
|
</t>
|
|
<t>
|
|
Added status note.
|
|
</t>
|
|
</section>
|
|
</section>
|
|
|
|
</back>
|
|
</rfc>
|
|
<!--
|
|
vim:et:tw=100:sw=2:
|
|
-->
|