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