2 <?xml-stylesheet type="text/xsl" href="lib/rfc2629.xslt"?>
5 <?rfc sortrefs="yes" ?>
7 <?rfc subcompact="no" ?>
8 <?rfc linkmailto="no" ?>
10 <?rfc comments="yes" ?>
12 <?rfc rfcedstyle="yes"?>
13 <?rfc-ext allow-markup-in-artwork="yes" ?>
14 <?rfc-ext include-index="no" ?>
16 <rfc ipr="trust200902"
18 docName="draft-ietf-httpbis-http2-latest"
19 x:maturity-level="proposed"
20 xmlns:x="http://purl.org/net/xml2rfc/ext">
21 <x:feedback template="mailto:ietf-http-wg@w3.org?subject={docname},%20%22{section}%22&body=<{ref}>:"/>
23 <title abbrev="HTTP/2">Hypertext Transfer Protocol version 2</title>
25 <author initials="M." surname="Belshe" fullname="Mike Belshe">
26 <organization>Twist</organization>
28 <email>mbelshe@chromium.org</email>
32 <author initials="R." surname="Peon" fullname="Roberto Peon">
33 <organization>Google, Inc</organization>
35 <email>fenix@google.com</email>
39 <author initials="M." surname="Thomson" fullname="Martin Thomson" role="editor">
40 <organization>Mozilla</organization>
43 <street>331 E Evelyn Street</street>
44 <city>Mountain View</city>
49 <email>martin.thomson@gmail.com</email>
54 <area>Applications</area>
55 <workgroup>HTTPbis</workgroup>
56 <keyword>HTTP</keyword>
57 <keyword>SPDY</keyword>
58 <keyword>Web</keyword>
62 This specification describes an optimized expression of the semantics of the Hypertext
63 Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a
64 reduced perception of latency by introducing header field compression and allowing multiple
65 concurrent messages on the same connection. It also introduces unsolicited push of
66 representations from servers to clients.
69 This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax.
70 HTTP's existing semantics remain unchanged.
74 <note title="Editorial Note (To be removed by RFC Editor)">
76 Discussion of this draft takes place on the HTTPBIS working group mailing list
77 (ietf-http-wg@w3.org), which is archived at <eref
78 target="https://lists.w3.org/Archives/Public/ietf-http-wg/"/>.
81 Working Group information can be found at <eref
82 target="https://tools.ietf.org/wg/httpbis/"/>; that specific to HTTP/2 are at <eref
83 target="https://http2.github.io/"/>.
86 The changes in this draft are summarized in <xref
87 target="change.log"/>.
94 <section anchor="intro" title="Introduction">
97 The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, the
98 HTTP/1.1 message format (<xref target="RFC7230" x:fmt="," x:rel="#http.message"/>) has
99 several characteristics that have a negative overall effect on application performance
103 In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given
104 TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed
105 request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.1
106 clients that need to make many requests typically use multiple connections to a server in
107 order to achieve concurrency and thereby reduce latency.
110 Furthermore, HTTP header fields are often repetitive and verbose, causing unnecessary
111 network traffic, as well as causing the initial <xref target="TCP">TCP</xref> congestion
112 window to quickly fill. This can result in excessive latency when multiple requests are
113 made on a new TCP connection.
116 HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an
117 underlying connection. Specifically, it allows interleaving of request and response
118 messages on the same connection and uses an efficient coding for HTTP header fields. It
119 also allows prioritization of requests, letting more important requests complete more
120 quickly, further improving performance.
123 The resulting protocol is more friendly to the network, because fewer TCP connections can
124 be used in comparison to HTTP/1.x. This means less competition with other flows, and
125 longer-lived connections, which in turn leads to better utilization of available network
129 Finally, HTTP/2 also enables more efficient processing of messages through use of binary
134 <section anchor="Overview" title="HTTP/2 Protocol Overview">
136 HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 supports all of the core
137 features of HTTP/1.1, but aims to be more efficient in several ways.
140 The basic protocol unit in HTTP/2 is a <xref target="FrameHeader">frame</xref>. Each frame
141 type serves a different purpose. For example, <x:ref>HEADERS</x:ref> and
142 <x:ref>DATA</x:ref> frames form the basis of <xref target="HttpSequence">HTTP requests and
143 responses</xref>; other frame types like <x:ref>SETTINGS</x:ref>,
144 <x:ref>WINDOW_UPDATE</x:ref>, and <x:ref>PUSH_PROMISE</x:ref> are used in support of other
148 Multiplexing of requests is achieved by having each HTTP request-response exchange
149 associated with its own <xref target="StreamsLayer">stream</xref>. Streams are largely
150 independent of each other, so a blocked or stalled request or response does not prevent
151 progress on other streams.
154 Flow control and prioritization ensure that it is possible to efficiently use multiplexed
155 streams. <xref target="FlowControl">Flow control</xref> helps to ensure that only data that
156 can be used by a receiver is transmitted. <xref
157 target="StreamPriority">Prioritization</xref> ensures that limited resources can be directed
158 to the most important streams first.
161 HTTP/2 adds a new interaction mode, whereby a server can <xref target="PushResources">push
162 responses to a client</xref>. Server push allows a server to speculatively send a client
163 data that the server anticipates the client will need, trading off some network usage
164 against a potential latency gain. The server does this by synthesizing a request, which it
165 sends as a <x:ref>PUSH_PROMISE</x:ref> frame. The server is then able to send a response to
166 the synthetic request on a separate stream.
169 Frames that contain HTTP header fields are <xref target="HeaderBlock">compressed</xref>.
170 HTTP requests can be highly redundant, so compression can reduce the size of requests and
171 responses significantly.
174 <section title="Document Organization">
176 The HTTP/2 specification is split into four parts:
177 <list style="symbols">
179 <xref target="starting">Starting HTTP/2</xref> covers how an HTTP/2 connection is
183 The <xref target="FramingLayer">framing</xref> and <xref
184 target="StreamsLayer">streams</xref> layers describe the way HTTP/2 frames are
185 structured and formed into multiplexed streams.
188 <xref target="FrameTypes">Frame</xref> and <xref target="ErrorCodes">error</xref>
189 definitions include details of the frame and error types used in HTTP/2.
192 <xref target="HTTPLayer">HTTP mappings</xref> and <xref target="HttpExtra">additional
193 requirements</xref> describe how HTTP semantics are expressed using frames and
199 While some of the frame and stream layer concepts are isolated from HTTP, this
200 specification does not define a completely generic framing layer. The framing and streams
201 layers are tailored to the needs of the HTTP protocol and server push.
205 <section title="Conventions and Terminology">
207 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD
208 NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as
209 described in <xref target="RFC2119">RFC 2119</xref>.
212 All numeric values are in network byte order. Values are unsigned unless otherwise
213 indicated. Literal values are provided in decimal or hexadecimal as appropriate.
214 Hexadecimal literals are prefixed with <spanx style="verb">0x</spanx> to distinguish them
215 from decimal literals.
218 The following terms are used:
219 <list style="hanging">
220 <t hangText="client:">
221 The endpoint initiating the HTTP/2 connection.
223 <t hangText="connection:">
224 A transport-layer connection between two endpoints.
226 <t hangText="connection error:">
227 An error that affects the entire HTTP/2 connection.
229 <t hangText="endpoint:">
230 Either the client or server of the connection.
232 <t hangText="frame:">
233 The smallest unit of communication within an HTTP/2 connection, consisting of a header
234 and a variable-length sequence of octets structured according to the frame type.
237 An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint
238 that is remote to the primary subject of discussion.
240 <t hangText="receiver:">
241 An endpoint that is receiving frames.
243 <t hangText="sender:">
244 An endpoint that is transmitting frames.
246 <t hangText="server:">
247 The endpoint which did not initiate the HTTP/2 connection.
249 <t hangText="stream:">
250 A bi-directional flow of frames across a virtual channel within the HTTP/2 connection.
252 <t hangText="stream error:">
253 An error on the individual HTTP/2 stream.
258 Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" are defined
259 in <xref target="RFC7230" x:fmt="of" x:rel="#intermediaries"/>.
264 <section anchor="starting" title="Starting HTTP/2">
266 An HTTP/2 connection is an application layer protocol running on top of a TCP connection
267 (<xref target="TCP"/>). The client is the TCP connection initiator.
270 HTTP/2 uses the same "http" and "https" URI schemes used by HTTP/1.1. HTTP/2 shares the same
271 default port numbers: 80 for "http" URIs and 443 for "https" URIs. As a result,
272 implementations processing requests for target resource URIs like <spanx
273 style="verb">http://example.org/foo</spanx> or <spanx
274 style="verb">https://example.com/bar</spanx> are required to first discover whether the
275 upstream server (the immediate peer to which the client wishes to establish a connection)
280 The means by which support for HTTP/2 is determined is different for "http" and "https"
281 URIs. Discovery for "http" URIs is described in <xref target="discover-http"/>. Discovery
282 for "https" URIs is described in <xref target="discover-https"/>.
285 <section anchor="versioning" title="HTTP/2 Version Identification">
287 The protocol defined in this document has two identifiers.
288 <list style="symbols">
291 The string "h2" identifies the protocol where HTTP/2 uses <xref
292 target="TLS12">TLS</xref>. This identifier is used in the <xref
293 target="TLS-ALPN">TLS application layer protocol negotiation extension (ALPN)</xref>
294 field and any place that HTTP/2 over TLS is identified.
297 The "h2" string is serialized into an ALPN protocol identifier as the two octet
298 sequence: 0x68, 0x32.
303 The string "h2c" identifies the protocol where HTTP/2 is run over cleartext TCP.
304 This identifier is used in the HTTP/1.1 Upgrade header field and any place that
305 HTTP/2 over TCP is identified.
311 Negotiating "h2" or "h2c" implies the use of the transport, security, framing and message
312 semantics described in this document.
315 <cref>RFC Editor's Note: please remove the remainder of this section prior to the
316 publication of a final version of this document.</cref>
319 Only implementations of the final, published RFC can identify themselves as "h2" or "h2c".
320 Until such an RFC exists, implementations MUST NOT identify themselves using these
324 Examples and text throughout the rest of this document use "h2" as a matter of
325 editorial convenience only. Implementations of draft versions MUST NOT identify using
329 Implementations of draft versions of the protocol MUST add the string "-" and the
330 corresponding draft number to the identifier. For example, draft-ietf-httpbis-http2-11
331 over TLS is identified using the string "h2-11".
334 Non-compatible experiments that are based on these draft versions MUST append the string
335 "-" and an experiment name to the identifier. For example, an experimental implementation
336 of packet mood-based encoding based on draft-ietf-httpbis-http2-09 might identify itself
337 as "h2-09-emo". Note that any label MUST conform to the "token" syntax defined in
338 <xref target="RFC7230" x:fmt="of" x:rel="#field.components"/>. Experimenters are
339 encouraged to coordinate their experiments on the ietf-http-wg@w3.org mailing list.
343 <section anchor="discover-http" title="Starting HTTP/2 for "http" URIs">
345 A client that makes a request for an "http" URI without prior knowledge about support for
346 HTTP/2 uses the HTTP Upgrade mechanism (<xref target="RFC7230" x:fmt="of"
347 x:rel="#header.upgrade"/>). The client makes an HTTP/1.1 request that includes an Upgrade
348 header field identifying HTTP/2 with the "h2c" token. The HTTP/1.1 request MUST include
349 exactly one <xref target="Http2SettingsHeader">HTTP2-Settings</xref> header field.
352 <preamble>For example:</preamble>
353 <artwork type="message/http; msgtype="request"" x:indent-with=" "><![CDATA[
355 Host: server.example.com
356 Connection: Upgrade, HTTP2-Settings
358 HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
363 Requests that contain an entity body MUST be sent in their entirety before the client can
364 send HTTP/2 frames. This means that a large request entity can block the use of the
365 connection until it is completely sent.
368 If concurrency of an initial request with subsequent requests is important, an OPTIONS
369 request can be used to perform the upgrade to HTTP/2, at the cost of an additional
373 A server that does not support HTTP/2 can respond to the request as though the Upgrade
374 header field were absent:
377 <artwork type="message/http; msgtype="response"" x:indent-with=" ">
380 Content-Type: text/html
386 A server MUST ignore a "h2" token in an Upgrade header field. Presence of a token with
387 "h2" implies HTTP/2 over TLS, which is instead negotiated as described in <xref
388 target="discover-https"/>.
391 A server that supports HTTP/2 can accept the upgrade with a 101 (Switching Protocols)
392 response. After the empty line that terminates the 101 response, the server can begin
393 sending HTTP/2 frames. These frames MUST include a response to the request that initiated
401 <artwork type="message/http; msgtype="response"" x:indent-with=" ">
402 HTTP/1.1 101 Switching Protocols
406 [ HTTP/2 connection ...
410 The first HTTP/2 frame sent by the server is a <x:ref>SETTINGS</x:ref> frame (<xref
411 target="SETTINGS"/>) as the server connection preface (<xref
412 target="ConnectionHeader"/>). Upon receiving the 101 response, the client sends a <xref
413 target="ConnectionHeader">connection preface</xref>, which includes a
414 <x:ref>SETTINGS</x:ref> frame.
417 The HTTP/1.1 request that is sent prior to upgrade is assigned stream identifier 1 and is
418 assigned <xref target="pri-default">default priority values</xref>. Stream 1 is
419 implicitly half closed from the client toward the server, since the request is completed
420 as an HTTP/1.1 request. After commencing the HTTP/2 connection, stream 1 is used for the
424 <section anchor="Http2SettingsHeader" title="HTTP2-Settings Header Field">
426 A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one <spanx
427 style="verb">HTTP2-Settings</spanx> header field. The <spanx
428 style="verb">HTTP2-Settings</spanx> header field is a connection-specific header field
429 that includes parameters that govern the HTTP/2 connection, provided in anticipation of
430 the server accepting the request to upgrade.
433 <artwork type="abnf" x:indent-with=" "><![CDATA[
434 HTTP2-Settings = token68
438 A server MUST NOT upgrade the connection to HTTP/2 if this header field is not present,
439 or if more than one is present. A server MUST NOT send this header field.
443 The content of the <spanx style="verb">HTTP2-Settings</spanx> header field is the
444 payload of a <x:ref>SETTINGS</x:ref> frame (<xref target="SETTINGS"/>), encoded as a
445 base64url string (that is, the URL- and filename-safe Base64 encoding described in <xref
446 target="RFC4648" x:fmt="of" x:sec="5"/>, with any trailing '=' characters omitted). The
447 <xref target="RFC5234">ABNF</xref> production for <spanx style="verb">token68</spanx> is
448 defined in <xref target="RFC7235" x:fmt="of" x:rel="#challenge.and.response"/>.
451 Since the upgrade is only intended to apply to the immediate connection, a client
452 sending <spanx style="verb">HTTP2-Settings</spanx> MUST also send <spanx
453 style="verb">HTTP2-Settings</spanx> as a connection option in the <spanx
454 style="verb">Connection</spanx> header field to prevent it from being forwarded
458 A server decodes and interprets these values as it would any other
459 <x:ref>SETTINGS</x:ref> frame. <xref target="SettingsSync">Acknowledgement of the
460 SETTINGS parameters</xref> is not necessary, since a 101 response serves as implicit
461 acknowledgment. Providing these values in the Upgrade request gives a client an
462 opportunity to provide parameters prior to receiving any frames from the server.
467 <section anchor="discover-https" title="Starting HTTP/2 for "https" URIs">
469 A client that makes a request to an "https" URI uses <xref target="TLS12">TLS</xref>
470 with the <xref target="TLS-ALPN">application layer protocol negotiation extension</xref>.
473 HTTP/2 over TLS uses the "h2" application token. The "h2c" token MUST NOT be sent by a
474 client or selected by a server.
477 Once TLS negotiation is complete, both the client and the server send a <xref
478 target="ConnectionHeader">connection preface</xref>.
482 <section anchor="known-http" title="Starting HTTP/2 with Prior Knowledge">
484 A client can learn that a particular server supports HTTP/2 by other means. For example,
485 <xref target="ALT-SVC"/> describes a mechanism for advertising this capability.
488 A client MAY immediately send HTTP/2 frames to a server that is known to support HTTP/2,
489 after the <xref target="ConnectionHeader">connection preface</xref>; a server can
490 identify such a connection by the presence of the connection preface. This only affects
491 the establishment of HTTP/2 connections over cleartext TCP; implementations that support
492 HTTP/2 over TLS MUST use <xref target="TLS-ALPN">protocol negotiation in TLS</xref>.
495 Without additional information, prior support for HTTP/2 is not a strong signal that a
496 given server will support HTTP/2 for future connections. For example, it is possible for
497 server configurations to change, for configurations to differ between instances in
498 clustered servers, or for network conditions to change.
502 <section anchor="ConnectionHeader" title="HTTP/2 Connection Preface">
504 Upon establishment of a TCP connection and determination that HTTP/2 will be used by both
505 peers, each endpoint MUST send a connection preface as a final confirmation and to
506 establish the initial SETTINGS parameters for the HTTP/2 connection. The client and
507 server each send a different connection preface.
510 The client connection preface starts with a sequence of 24 octets, which in hex notation
514 <artwork type="inline" x:indent-with=" "><![CDATA[
515 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
519 (the string <spanx style="verb">PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n</spanx>). This sequence
520 is followed by a <x:ref>SETTINGS</x:ref> frame (<xref target="SETTINGS"/>). The
521 <x:ref>SETTINGS</x:ref> frame MAY be empty. The client sends the client connection
522 preface immediately upon receipt of a 101 Switching Protocols response (indicating a
523 successful upgrade), or as the first application data octets of a TLS connection. If
524 starting an HTTP/2 connection with prior knowledge of server support for the protocol, the
525 client connection preface is sent upon connection establishment.
530 The client connection preface is selected so that a large proportion of HTTP/1.1 or
531 HTTP/1.0 servers and intermediaries do not attempt to process further frames. Note
532 that this does not address the concerns raised in <xref target="TALKING"/>.
537 The server connection preface consists of a potentially empty <x:ref>SETTINGS</x:ref>
538 frame (<xref target="SETTINGS"/>) that MUST be the first frame the server sends in the
542 The <x:ref>SETTINGS</x:ref> frames received from a peer as part of the connection preface
543 MUST be acknowledged (see <xref target="SettingsSync"/>) after sending the connection
547 To avoid unnecessary latency, clients are permitted to send additional frames to the
548 server immediately after sending the client connection preface, without waiting to receive
549 the server connection preface. It is important to note, however, that the server
550 connection preface <x:ref>SETTINGS</x:ref> frame might include parameters that necessarily
551 alter how a client is expected to communicate with the server. Upon receiving the
552 <x:ref>SETTINGS</x:ref> frame, the client is expected to honor any parameters established.
553 In some configurations, it is possible for the server to transmit <x:ref>SETTINGS</x:ref>
554 before the client sends additional frames, providing an opportunity to avoid this issue.
557 Clients and servers MUST treat an invalid connection preface as a <xref
558 target="ConnectionErrorHandler">connection error</xref> of type
559 <x:ref>PROTOCOL_ERROR</x:ref>. A <x:ref>GOAWAY</x:ref> frame (<xref target="GOAWAY"/>)
560 MAY be omitted in this case, since an invalid preface indicates that the peer is not using
566 <section anchor="FramingLayer" title="HTTP Frames">
568 Once the HTTP/2 connection is established, endpoints can begin exchanging frames.
571 <section anchor="FrameHeader" title="Frame Format">
573 All frames begin with a fixed 9-octet header followed by a variable-length payload.
575 <figure title="Frame Layout">
576 <artwork type="inline"><![CDATA[
578 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
579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
581 +---------------+---------------+---------------+
582 | Type (8) | Flags (8) |
583 +-+-+-----------+---------------+-------------------------------+
584 |R| Stream Identifier (31) |
585 +=+=============================================================+
586 | Frame Payload (0...) ...
587 +---------------------------------------------------------------+
591 The fields of the frame header are defined as:
592 <list style="hanging">
593 <x:lt hangText="Length:">
595 The length of the frame payload expressed as an unsigned 24-bit integer. Values
596 greater than 2<x:sup>14</x:sup> (16,384) MUST NOT be sent unless the receiver has
597 set a larger value for <x:ref>SETTINGS_MAX_FRAME_SIZE</x:ref>.
600 The 9 octets of the frame header are not included in this value.
603 <x:lt hangText="Type:">
605 The 8-bit type of the frame. The frame type determines the format and semantics of
606 the frame. Implementations MUST ignore and discard any frame that has a type that
610 <x:lt hangText="Flags:">
612 An 8-bit field reserved for frame-type specific boolean flags.
615 Flags are assigned semantics specific to the indicated frame type. Flags that have
616 no defined semantics for a particular frame type MUST be ignored, and MUST be left
617 unset (0) when sending.
622 A reserved 1-bit field. The semantics of this bit are undefined and the bit MUST
623 remain unset (0) when sending and MUST be ignored when receiving.
626 <x:lt hangText="Stream Identifier:">
628 A 31-bit stream identifier (see <xref target="StreamIdentifiers"/>). The value 0 is
629 reserved for frames that are associated with the connection as a whole as opposed to
630 an individual stream.
636 The structure and content of the frame payload is dependent entirely on the frame type.
640 <section anchor="FrameSize" title="Frame Size">
642 The size of a frame payload is limited by the maximum size that a receiver advertises in
643 the <x:ref>SETTINGS_MAX_FRAME_SIZE</x:ref> setting. This setting can have any value
644 between 2<x:sup>14</x:sup> (16,384) and 2<x:sup>24</x:sup>-1 (16,777,215) octets,
648 All implementations MUST be capable of receiving and minimally processing frames up to
649 2<x:sup>14</x:sup> octets in length, plus the 9 octet <xref target="FrameHeader">frame
650 header</xref>. The size of the frame header is not included when describing frame sizes.
651 <list style="hanging">
653 Certain frame types, such as <xref target="PING">PING</xref>, impose additional limits
654 on the amount of payload data allowed.
659 If a frame size exceeds any defined limit, or is too small to contain mandatory frame
660 data, the endpoint MUST send a <x:ref>FRAME_SIZE_ERROR</x:ref> error. A frame size error
661 in a frame that could alter the state of the entire connection MUST be treated as a <xref
662 target="ConnectionErrorHandler">connection error</xref>; this includes any frame carrying
663 a <xref target="HeaderBlock">header block</xref> (that is, <x:ref>HEADERS</x:ref>,
664 <x:ref>PUSH_PROMISE</x:ref>, and <x:ref>CONTINUATION</x:ref>), <x:ref>SETTINGS</x:ref>,
665 and any <x:ref>WINDOW_UPDATE</x:ref> frame with a stream identifier of 0.
668 Endpoints are not obligated to use all available space in a frame. Responsiveness can be
669 improved by using frames that are smaller than the permitted maximum size. Sending large
670 frames can result in delays in sending time-sensitive frames (such
671 <x:ref>RST_STREAM</x:ref>, <x:ref>WINDOW_UPDATE</x:ref>, or <x:ref>PRIORITY</x:ref>)
672 which if blocked by the transmission of a large frame, could affect performance.
676 <section anchor="HeaderBlock" title="Header Compression and Decompression">
678 Just as in HTTP/1, a header field in HTTP/2 is a name with one or more associated values.
679 They are used within HTTP request and response messages as well as server push operations
680 (see <xref target="PushResources" />).
683 Header lists are collections of zero or more header fields. When transmitted over a
684 connection, a header list is serialized into a header block using <xref
685 target="COMPRESSION">HTTP Header Compression</xref>. The serialized header block is then
686 divided into one or more octet sequences, called header block fragments, and transmitted
687 within the payload of <xref target="HEADERS">HEADERS</xref>, <xref
688 target="PUSH_PROMISE">PUSH_PROMISE</xref> or <xref
689 target="CONTINUATION">CONTINUATION</xref> frames.
692 The <xref target="COOKIE">Cookie header field</xref> is treated specially by the HTTP
693 mapping (see <xref target="CompressCookie"/>).
696 A receiving endpoint reassembles the header block by concatenating its fragments, then
697 decompresses the block to reconstruct the header list.
700 A complete header block consists of either:
701 <list style="symbols">
703 a single <x:ref>HEADERS</x:ref> or <x:ref>PUSH_PROMISE</x:ref> frame,
704 with the END_HEADERS flag set, or
707 a <x:ref>HEADERS</x:ref> or <x:ref>PUSH_PROMISE</x:ref> frame with the END_HEADERS
708 flag cleared and one or more <x:ref>CONTINUATION</x:ref> frames,
709 where the last <x:ref>CONTINUATION</x:ref> frame has the END_HEADERS flag set.
714 Header compression is stateful. One compression context and one decompression context is
715 used for the entire connection. Each header block is processed as a discrete unit.
716 Header blocks MUST be transmitted as a contiguous sequence of frames, with no interleaved
717 frames of any other type or from any other stream. The last frame in a sequence of
718 <x:ref>HEADERS</x:ref> or <x:ref>CONTINUATION</x:ref> frames MUST have the END_HEADERS
719 flag set. The last frame in a sequence of <x:ref>PUSH_PROMISE</x:ref> or
720 <x:ref>CONTINUATION</x:ref> frames MUST have the END_HEADERS flag set. This allows a
721 header block to be logically equivalent to a single frame.
724 Header block fragments can only be sent as the payload of <x:ref>HEADERS</x:ref>,
725 <x:ref>PUSH_PROMISE</x:ref> or <x:ref>CONTINUATION</x:ref> frames, because these frames
726 carry data that can modify the compression context maintained by a receiver. An endpoint
727 receiving <x:ref>HEADERS</x:ref>, <x:ref>PUSH_PROMISE</x:ref> or
728 <x:ref>CONTINUATION</x:ref> frames MUST reassemble header blocks and perform decompression
729 even if the frames are to be discarded. A receiver MUST terminate the connection with a
730 <xref target="ConnectionErrorHandler">connection error</xref> of type
731 <x:ref>COMPRESSION_ERROR</x:ref> if it does not decompress a header block.
736 <section anchor="StreamsLayer" title="Streams and Multiplexing">
738 A "stream" is an independent, bi-directional sequence of frames exchanged between the client
739 and server within an HTTP/2 connection. Streams have several important characteristics:
740 <list style="symbols">
742 A single HTTP/2 connection can contain multiple concurrently open streams, with either
743 endpoint interleaving frames from multiple streams.
746 Streams can be established and used unilaterally or shared by either the client or
750 Streams can be closed by either endpoint.
753 The order in which frames are sent on a stream is significant. Recipients process frames
754 in the order they are received. In particular, the order of <x:ref>HEADERS</x:ref>,
755 and <x:ref>DATA</x:ref> frames is semantically significant.
758 Streams are identified by an integer. Stream identifiers are assigned to streams by the
759 endpoint initiating the stream.
764 <section anchor="StreamStates" title="Stream States">
766 The lifecycle of a stream is shown in <xref target="StreamStatesFigure"/>.
769 <figure anchor="StreamStatesFigure" title="Stream States">
770 <artwork type="drawing">
774 ,--------| idle |--------.
777 +----------+ | +----------+
779 ,---| reserved | | | reserved |---.
780 | | (local) | v | (remote) | |
781 | +----------+ +--------+ +----------+ |
783 | | H ,-------| open |-------. | H |
785 | v v +--------+ v v |
786 | +----------+ | +----------+ |
787 | | half | | | half | |
788 | | closed | | R | closed | |
789 | | (remote) | | | (local) | |
790 | +----------+ | +----------+ |
792 | | ES / R +--------+ ES / R | |
793 | `----------->| |<-----------' |
795 `-------------------->| |<--------------------'
798 H: HEADERS frame (with implied CONTINUATIONs)
799 PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
807 Note that this diagram shows stream state transitions and the frames and flags that affect
808 those transitions only. In this regard, <x:ref>CONTINUATION</x:ref> frames do not result
809 in state transitions; they are effectively part of the <x:ref>HEADERS</x:ref> or
810 <x:ref>PUSH_PROMISE</x:ref> that they follow. For this purpose, the END_STREAM flag is
811 processed as a separate event to the frame that bears it; a <x:ref>HEADERS</x:ref> frame
812 with the END_STREAM flag set can cause two state transitions.
815 Both endpoints have a subjective view of the state of a stream that could be different
816 when frames are in transit. Endpoints do not coordinate the creation of streams; they are
817 created unilaterally by either endpoint. The negative consequences of a mismatch in
818 states are limited to the "closed" state after sending <x:ref>RST_STREAM</x:ref>, where
819 frames might be received for some time after closing.
822 Streams have the following states:
823 <list style="hanging">
825 <x:lt hangText="idle:">
827 <vspace blankLines="0"/>
828 All streams start in the "idle" state. In this state, no frames have been
832 The following transitions are valid from this state:
833 <list style="symbols">
835 Sending or receiving a <x:ref>HEADERS</x:ref> frame causes the stream to become
836 "open". The stream identifier is selected as described in <xref
837 target="StreamIdentifiers"/>. The same <x:ref>HEADERS</x:ref> frame can also
838 cause a stream to immediately become "half closed".
841 Sending a <x:ref>PUSH_PROMISE</x:ref> frame marks the associated stream for
842 later use. The stream state for the reserved stream transitions to "reserved
846 Receiving a <x:ref>PUSH_PROMISE</x:ref> frame marks the associated stream as
847 reserved by the remote peer. The state of the stream becomes "reserved
853 Receiving any frames other than <x:ref>HEADERS</x:ref> or
854 <x:ref>PUSH_PROMISE</x:ref> on a stream in this state MUST be treated as a <xref
855 target="ConnectionErrorHandler">connection error</xref> of type
856 <x:ref>PROTOCOL_ERROR</x:ref>.
860 <x:lt hangText="reserved (local):">
862 <vspace blankLines="0"/>
863 A stream in the "reserved (local)" state is one that has been promised by sending a
864 <x:ref>PUSH_PROMISE</x:ref> frame. A <x:ref>PUSH_PROMISE</x:ref> frame reserves an
865 idle stream by associating the stream with an open stream that was initiated by the
866 remote peer (see <xref target="PushResources"/>).
869 In this state, only the following transitions are possible:
870 <list style="symbols">
872 The endpoint can send a <x:ref>HEADERS</x:ref> frame. This causes the stream to
873 open in a "half closed (remote)" state.
876 Either endpoint can send a <x:ref>RST_STREAM</x:ref> frame to cause the stream
877 to become "closed". This releases the stream reservation.
882 An endpoint MUST NOT send any type of frame other than <x:ref>HEADERS</x:ref> or
883 <x:ref>RST_STREAM</x:ref> in this state.
886 A <x:ref>PRIORITY</x:ref> frame MAY be received in this state. Receiving any type
887 of frame other than <x:ref>RST_STREAM</x:ref> or <x:ref>PRIORITY</x:ref> on a stream
888 in this state MUST be treated as a <xref target="ConnectionErrorHandler">connection
889 error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
893 <x:lt hangText="reserved (remote):">
895 <vspace blankLines="0"/>
896 A stream in the "reserved (remote)" state has been reserved by a remote peer.
899 In this state, only the following transitions are possible:
900 <list style="symbols">
902 Receiving a <x:ref>HEADERS</x:ref> frame causes the stream to transition to
903 "half closed (local)".
906 Either endpoint can send a <x:ref>RST_STREAM</x:ref> frame to cause the stream
907 to become "closed". This releases the stream reservation.
912 An endpoint MAY send a <x:ref>PRIORITY</x:ref> frame in this state to reprioritize
913 the reserved stream. An endpoint MUST NOT send any type of frame other than
914 <x:ref>RST_STREAM</x:ref>, <x:ref>WINDOW_UPDATE</x:ref>, or <x:ref>PRIORITY</x:ref>
918 Receiving any type of frame other than <x:ref>HEADERS</x:ref> or
919 <x:ref>RST_STREAM</x:ref> on a stream in this state MUST be treated as a <xref
920 target="ConnectionErrorHandler">connection error</xref> of type
921 <x:ref>PROTOCOL_ERROR</x:ref>.
925 <x:lt hangText="open:">
927 <vspace blankLines="0"/>
928 A stream in the "open" state may be used by both peers to send frames of any type.
929 In this state, sending peers observe advertised <xref target="FlowControl">stream
930 level flow control limits</xref>.
933 From this state either endpoint can send a frame with an END_STREAM flag set, which
934 causes the stream to transition into one of the "half closed" states: an endpoint
935 sending an END_STREAM flag causes the stream state to become "half closed (local)";
936 an endpoint receiving an END_STREAM flag causes the stream state to become "half
940 Either endpoint can send a <x:ref>RST_STREAM</x:ref> frame from this state, causing
941 it to transition immediately to "closed".
945 <x:lt hangText="half closed (local):">
947 <vspace blankLines="0"/>
948 A stream that is in the "half closed (local)" state cannot be used for sending
949 frames. Only <x:ref>WINDOW_UPDATE</x:ref>, <x:ref>PRIORITY</x:ref> and
950 <x:ref>RST_STREAM</x:ref> frames can be sent in this state.
953 A stream transitions from this state to "closed" when a frame that contains an
954 END_STREAM flag is received, or when either peer sends a <x:ref>RST_STREAM</x:ref>
958 A receiver can ignore <x:ref>WINDOW_UPDATE</x:ref> frames in this state, which might
959 arrive for a short period after a frame bearing the END_STREAM flag is sent.
962 <x:ref>PRIORITY</x:ref> frames received in this state are used to reprioritize
963 streams that depend on the current stream.
967 <x:lt hangText="half closed (remote):">
969 <vspace blankLines="0"/>
970 A stream that is "half closed (remote)" is no longer being used by the peer to send
971 frames. In this state, an endpoint is no longer obligated to maintain a receiver
972 flow control window if it performs flow control.
975 If an endpoint receives additional frames for a stream that is in this state, other
976 than <x:ref>WINDOW_UPDATE</x:ref>, <x:ref>PRIORITY</x:ref> or
977 <x:ref>RST_STREAM</x:ref>, it MUST respond with a <xref
978 target="StreamErrorHandler">stream error</xref> of type
979 <x:ref>STREAM_CLOSED</x:ref>.
982 A stream that is "half closed (remote)" can be used by the endpoint to send frames
983 of any type. In this state, the endpoint continues to observe advertised <xref
984 target="FlowControl">stream level flow control limits</xref>.
987 A stream can transition from this state to "closed" by sending a frame that contains
988 an END_STREAM flag, or when either peer sends a <x:ref>RST_STREAM</x:ref> frame.
992 <x:lt hangText="closed:">
994 <vspace blankLines="0"/>
995 The "closed" state is the terminal state.
998 An endpoint MUST NOT send frames other than <x:ref>PRIORITY</x:ref> on a closed
999 stream. An endpoint that receives any frame other than <x:ref>PRIORITY</x:ref>
1000 after receiving a <x:ref>RST_STREAM</x:ref> MUST treat that as a <xref
1001 target="StreamErrorHandler">stream error</xref> of type
1002 <x:ref>STREAM_CLOSED</x:ref>. Similarly, an endpoint that receives any frames after
1003 receiving a frame with the END_STREAM flag set MUST treat that as a <xref
1004 target="ConnectionErrorHandler">connection error</xref> of type
1005 <x:ref>STREAM_CLOSED</x:ref>, unless the frame is permitted as described below.
1008 <x:ref>WINDOW_UPDATE</x:ref> or <x:ref>RST_STREAM</x:ref> frames can be received in
1009 this state for a short period after a <x:ref>DATA</x:ref> or <x:ref>HEADERS</x:ref>
1010 frame containing an END_STREAM flag is sent. Until the remote peer receives and
1011 processes <x:ref>RST_STREAM</x:ref> or the frame bearing the END_STREAM flag, it
1012 might send frames of these types. Endpoints MUST ignore
1013 <x:ref>WINDOW_UPDATE</x:ref> or <x:ref>RST_STREAM</x:ref> frames received in this
1014 state, though endpoints MAY choose to treat frames that arrive a significant time
1015 after sending END_STREAM as a <xref target="ConnectionErrorHandler">connection
1016 error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
1019 <x:ref>PRIORITY</x:ref> frames can be sent on closed streams to prioritize streams
1020 that are dependent on the closed stream. Endpoints SHOULD process
1021 <x:ref>PRIORITY</x:ref> frame, though they can be ignored if the stream has been
1022 removed from the dependency tree (see <xref target="priority-gc"/>).
1025 If this state is reached as a result of sending a <x:ref>RST_STREAM</x:ref> frame,
1026 the peer that receives the <x:ref>RST_STREAM</x:ref> might have already sent - or
1027 enqueued for sending - frames on the stream that cannot be withdrawn. An endpoint
1028 MUST ignore frames that it receives on closed streams after it has sent a
1029 <x:ref>RST_STREAM</x:ref> frame. An endpoint MAY choose to limit the period over
1030 which it ignores frames and treat frames that arrive after this time as being in
1034 Flow controlled frames (i.e., <x:ref>DATA</x:ref>) received after sending
1035 <x:ref>RST_STREAM</x:ref> are counted toward the connection flow control window.
1036 Even though these frames might be ignored, because they are sent before the sender
1037 receives the <x:ref>RST_STREAM</x:ref>, the sender will consider the frames to count
1038 against the flow control window.
1041 An endpoint might receive a <x:ref>PUSH_PROMISE</x:ref> frame after it sends
1042 <x:ref>RST_STREAM</x:ref>. <x:ref>PUSH_PROMISE</x:ref> causes a stream to become
1043 "reserved" even if the associated stream has been reset. Therefore, a
1044 <x:ref>RST_STREAM</x:ref> is needed to close an unwanted promised stream.
1050 In the absence of more specific guidance elsewhere in this document, implementations
1051 SHOULD treat the receipt of a frame that is not expressly permitted in the description of
1052 a state as a <xref target="ConnectionErrorHandler">connection error</xref> of type
1053 <x:ref>PROTOCOL_ERROR</x:ref>. Frame of unknown types are ignored.
1056 An example of the state transitions for an HTTP request/response exchange can be found in
1057 <xref target="HttpSequence"/>. An example of the state transitions for server push can be
1058 found in <xref target="PushRequests"/> and <xref target="PushResponses"/>.
1061 <section anchor="StreamIdentifiers" title="Stream Identifiers">
1063 Streams are identified with an unsigned 31-bit integer. Streams initiated by a client
1064 MUST use odd-numbered stream identifiers; those initiated by the server MUST use
1065 even-numbered stream identifiers. A stream identifier of zero (0x0) is used for
1066 connection control messages; the stream identifier zero cannot be used to establish a
1070 HTTP/1.1 requests that are upgraded to HTTP/2 (see <xref target="discover-http"/>) are
1071 responded to with a stream identifier of one (0x1). After the upgrade
1072 completes, stream 0x1 is "half closed (local)" to the client. Therefore, stream 0x1
1073 cannot be selected as a new stream identifier by a client that upgrades from HTTP/1.1.
1076 The identifier of a newly established stream MUST be numerically greater than all
1077 streams that the initiating endpoint has opened or reserved. This governs streams that
1078 are opened using a <x:ref>HEADERS</x:ref> frame and streams that are reserved using
1079 <x:ref>PUSH_PROMISE</x:ref>. An endpoint that receives an unexpected stream identifier
1080 MUST respond with a <xref target="ConnectionErrorHandler">connection error</xref> of
1081 type <x:ref>PROTOCOL_ERROR</x:ref>.
1084 The first use of a new stream identifier implicitly closes all streams in the "idle"
1085 state that might have been initiated by that peer with a lower-valued stream identifier.
1086 For example, if a client sends a <x:ref>HEADERS</x:ref> frame on stream 7 without ever
1087 sending a frame on stream 5, then stream 5 transitions to the "closed" state when the
1088 first frame for stream 7 is sent or received.
1091 Stream identifiers cannot be reused. Long-lived connections can result in an endpoint
1092 exhausting the available range of stream identifiers. A client that is unable to
1093 establish a new stream identifier can establish a new connection for new streams. A
1094 server that is unable to establish a new stream identifier can send a
1095 <x:ref>GOAWAY</x:ref> frame so that the client is forced to open a new connection for
1100 <section title="Stream Concurrency">
1102 A peer can limit the number of concurrently active streams using the
1103 <x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> parameter (see <xref
1104 target="SettingValues"/>) within a <x:ref>SETTINGS</x:ref> frame. The maximum concurrent
1105 streams setting is specific to each endpoint and applies only to the peer that receives
1106 the setting. That is, clients specify the maximum number of concurrent streams the
1107 server can initiate, and servers specify the maximum number of concurrent streams the
1108 client can initiate.
1111 Streams that are in the "open" state, or either of the "half closed" states count toward
1112 the maximum number of streams that an endpoint is permitted to open. Streams in any of
1113 these three states count toward the limit advertised in the
1114 <x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> setting. Streams in either of the
1115 "reserved" states do not count toward the stream limit.
1118 Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a
1119 <x:ref>HEADERS</x:ref> frame that causes their advertised concurrent stream limit to be
1120 exceeded MUST treat this as a <xref target="StreamErrorHandler">stream error</xref>. An
1121 endpoint that wishes to reduce the value of
1122 <x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> to a value that is below the current
1123 number of open streams can either close streams that exceed the new value or allow
1124 streams to complete.
1129 <section anchor="FlowControl" title="Flow Control">
1131 Using streams for multiplexing introduces contention over use of the TCP connection,
1132 resulting in blocked streams. A flow control scheme ensures that streams on the same
1133 connection do not destructively interfere with each other. Flow control is used for both
1134 individual streams and for the connection as a whole.
1137 HTTP/2 provides for flow control through use of the <xref
1138 target="WINDOW_UPDATE">WINDOW_UPDATE frame</xref>.
1141 <section anchor="fc-principles" title="Flow Control Principles">
1143 HTTP/2 stream flow control aims to allow a variety of flow control algorithms to be
1144 used without requiring protocol changes. Flow control in HTTP/2 has the following
1146 <list style="numbers">
1148 Flow control is specific to a connection; i.e., it is "hop-by-hop", not
1152 Flow control is based on window update frames. Receivers advertise how many octets
1153 they are prepared to receive on a stream and for the entire connection. This is a
1154 credit-based scheme.
1157 Flow control is directional with overall control provided by the receiver. A
1158 receiver MAY choose to set any window size that it desires for each stream and for
1159 the entire connection. A sender MUST respect flow control limits imposed by a
1160 receiver. Clients, servers and intermediaries all independently advertise their
1161 flow control window as a receiver and abide by the flow control limits set by
1162 their peer when sending.
1165 The initial value for the flow control window is 65,535 octets for both new streams
1166 and the overall connection.
1169 The frame type determines whether flow control applies to a frame. Of the frames
1170 specified in this document, only <x:ref>DATA</x:ref> frames are subject to flow
1171 control; all other frame types do not consume space in the advertised flow control
1172 window. This ensures that important control frames are not blocked by flow control.
1175 Flow control cannot be disabled.
1178 HTTP/2 defines only the format and semantics of the <x:ref>WINDOW_UPDATE</x:ref>
1179 frame (<xref target="WINDOW_UPDATE"/>). This document does not stipulate how a
1180 receiver decides when to send this frame or the value that it sends, nor does it
1181 specify how a sender chooses to send packets. Implementations are able to select
1182 any algorithm that suits their needs.
1187 Implementations are also responsible for managing how requests and responses are sent
1188 based on priority; choosing how to avoid head of line blocking for requests; and
1189 managing the creation of new streams. Algorithm choices for these could interact with
1190 any flow control algorithm.
1194 <section anchor="DisableFlowControl" title="Appropriate Use of Flow Control">
1196 Flow control is defined to protect endpoints that are operating under resource
1197 constraints. For example, a proxy needs to share memory between many connections, and
1198 also might have a slow upstream connection and a fast downstream one. Flow control
1199 addresses cases where the receiver is unable process data on one stream, yet wants to
1200 continue to process other streams in the same connection.
1203 Deployments that do not require this capability can advertise a flow control window of
1204 the maximum size, incrementing the available space when new data is received. This
1205 effectively disables flow control for that receiver. Conversely, a sender is always
1206 subject to the flow control window advertised by the receiver.
1209 Deployments with constrained resources (for example, memory) can employ flow control to
1210 limit the amount of memory a peer can consume. Note, however, that this can lead to
1211 suboptimal use of available network resources if flow control is enabled without
1212 knowledge of the bandwidth-delay product (see <xref target="RFC1323"/>).
1215 Even with full awareness of the current bandwidth-delay product, implementation of flow
1216 control can be difficult. When using flow control, the receiver MUST read from the TCP
1217 receive buffer in a timely fashion. Failure to do so could lead to a deadlock when
1218 critical frames, such as <x:ref>WINDOW_UPDATE</x:ref>, are not read and acted upon.
1223 <section anchor="StreamPriority" title="Stream priority">
1225 A client can assign a priority for a new stream by including prioritization information in
1226 the <xref target="HEADERS">HEADERS frame</xref> that opens the stream. For an existing
1227 stream, the <xref target="PRIORITY">PRIORITY frame</xref> can be used to change the
1231 The purpose of prioritization is to allow an endpoint to express how it would prefer its
1232 peer allocate resources when managing concurrent streams. Most importantly, priority can
1233 be used to select streams for transmitting frames when there is limited capacity for
1237 Streams can be prioritized by marking them as dependent on the completion of other streams
1238 (<xref target="pri-depend"/>). Each dependency is assigned a relative weight, a number
1239 that is used to determine the relative proportion of available resources that are assigned
1240 to streams dependent on the same stream.
1243 Note that stream dependencies have not yet been validated in practice. The theory
1244 might be fairly sound, but there are no implementations currently sending these. If it
1245 turns out that they are not useful, or actively harmful, implementations will be requested
1246 to avoid creating stream dependencies.
1249 Explicitly setting the priority for a stream is input to a prioritization process. It
1250 does not guarantee any particular processing or transmission order for the stream relative
1251 to any other stream. An endpoint cannot force a peer to process concurrent streams in a
1252 particular order using priority. Expressing priority is therefore only ever a suggestion.
1255 Providing prioritization information is optional, so default values are used if no
1256 explicit indicator is provided (<xref target="pri-default"/>).
1259 <section title="Stream Dependencies" anchor="pri-depend">
1261 Each stream can be given an explicit dependency on another stream. Including a
1262 dependency expresses a preference to allocate resources to the identified stream rather
1263 than to the dependent stream.
1266 A stream that is not dependent on any other stream is given a stream dependency of 0x0.
1267 In other words, the non-existent stream 0 forms the root of the tree.
1270 A stream that depends on another stream is a dependent stream. The stream upon which a
1271 stream is dependent is a parent stream. A dependency on a stream that is not currently
1272 in the tree - such as a stream in the "idle" state - results in that stream being given
1273 a <xref target="pri-default">default priority</xref>.
1276 When assigning a dependency on another stream, the stream is added as a new dependency
1277 of the parent stream. Dependent streams that share the same parent are not ordered with
1278 respect to each other. For example, if streams B and C are dependent on stream A, and
1279 if stream D is created with a dependency on stream A, this results in a dependency order
1280 of A followed by B, C, and D in any order.
1282 <figure title="Example of Default Dependency Creation">
1283 <artwork type="inline"><![CDATA[
1290 An exclusive flag allows for the insertion of a new level of dependencies. The
1291 exclusive flag causes the stream to become the sole dependency of its parent stream,
1292 causing other dependencies to become dependent on the exclusive stream. In the
1293 previous example, if stream D is created with an exclusive dependency on stream A, this
1294 results in D becoming the dependency parent of B and C.
1296 <figure title="Example of Exclusive Dependency Creation">
1297 <artwork type="inline"><![CDATA[
1306 Inside the dependency tree, a dependent stream SHOULD only be allocated resources if all
1307 of the streams that it depends on (the chain of parent streams up to 0x0) are either
1308 closed, or it is not possible to make progress on them.
1311 A stream cannot depend on itself. An endpoint MUST treat this as a <xref
1312 target="StreamErrorHandler">stream error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
1316 <section title="Dependency Weighting">
1318 All dependent streams are allocated an integer weight between 1 and 256 (inclusive).
1321 Streams with the same parent SHOULD be allocated resources proportionally based on their
1322 weight. Thus, if stream B depends on stream A with weight 4, and C depends on stream A
1323 with weight 12, and if no progress can be made on A, stream B ideally receives one third
1324 of the resources allocated to stream C.
1328 <section anchor="reprioritize" title="Reprioritization">
1330 Stream priorities are changed using the <x:ref>PRIORITY</x:ref> frame. Setting a
1331 dependency causes a stream to become dependent on the identified parent stream.
1334 Dependent streams move with their parent stream if the parent is reprioritized. Setting
1335 a dependency with the exclusive flag for a reprioritized stream moves all the
1336 dependencies of the new parent stream to become dependent on the reprioritized stream.
1339 If a stream is made dependent on one of its own dependencies, the formerly dependent
1340 stream is first moved to be dependent on the reprioritized stream's previous parent.
1341 The moved dependency retains its weight.
1343 <figure title="Example of Dependency Reordering">
1345 For example, consider an original dependency tree where B and C depend on A, D and E
1346 depend on C, and F depends on D. If A is made dependent on D, then D takes the place
1347 of A. All other dependency relationships stay the same, except for F, which becomes
1348 dependent on A if the reprioritization is exclusive.
1350 <artwork type="inline"><![CDATA[
1355 B C ==> F B C ==> F A OR A
1360 (intermediate) (non-exclusive) (exclusive)
1365 <section anchor="priority-gc" title="Prioritization State Management">
1367 When a stream is removed from the dependency tree, its dependencies can be moved to
1368 become dependent on the parent of the closed stream. The weights of new dependencies
1369 are recalculated by distributing the weight of the dependency of the closed stream
1370 proportionally based on the weights of its dependencies.
1373 Streams that are removed from the dependency tree cause some prioritization information
1374 to be lost. Resources are shared between streams with the same parent stream, which
1375 means that if a stream in that set closes or becomes blocked, any spare capacity
1376 allocated to a stream is distributed to the immediate neighbors of the stream. However,
1377 if the common dependency is removed from the tree, those streams share resources with
1378 streams at the next highest level.
1381 For example, assume streams A and B share a parent, and streams C and D both depend on
1382 stream A. Prior to the removal of stream A, if streams A and D are unable to proceed,
1383 then stream C receives all the resources dedicated to stream A. If stream A is removed
1384 from the tree, the weight of stream A is divided between streams C and D. If stream D
1385 is still unable to proceed, this results in stream C receiving a reduced proportion of
1386 resources. For equal starting weights, C receives one third, rather than one half, of
1387 available resources.
1390 It is possible for a stream to become closed while prioritization information that
1391 creates a dependency on that stream is in transit. If a stream identified in a
1392 dependency has no associated priority information, then the dependent stream is instead
1393 assigned a <xref target="pri-default">default priority</xref>. This potentially creates
1394 suboptimal prioritization, since the stream could be given a priority that is different
1395 to what is intended.
1398 To avoid these problems, an endpoint SHOULD retain stream prioritization state for a
1399 period after streams become closed. The longer state is retained, the lower the chance
1400 that streams are assigned incorrect or default priority values.
1403 This could create a large state burden for an endpoint, so this state MAY be limited.
1404 An endpoint MAY apply a fixed upper limit on the number of closed streams for which
1405 prioritization state is tracked to limit state exposure. The amount of additional state
1406 an endpoint maintains could be dependent on load; under high load, prioritization state
1407 can be discarded to limit resource commitments. In extreme cases, an endpoint could
1408 even discard prioritization state for active or reserved streams. If a fixed limit is
1409 applied, endpoints SHOULD maintain state for at least as many streams as allowed by
1410 their setting for <x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref>.
1413 An endpoint receiving a <x:ref>PRIORITY</x:ref> frame that changes the priority of a
1414 closed stream SHOULD alter the dependencies of the streams that depend on it, if it has
1415 retained enough state to do so.
1419 <section title="Default Priorities" anchor="pri-default">
1421 Providing priority information is optional. Streams are assigned a non-exclusive
1422 dependency on stream 0x0 by default. <xref target="PushResources">Pushed streams</xref>
1423 initially depend on their associated stream. In both cases, streams are assigned a
1424 default weight of 16.
1429 <section title="Error Handling">
1431 HTTP/2 framing permits two classes of error:
1432 <list style="symbols">
1434 An error condition that renders the entire connection unusable is a connection error.
1437 An error in an individual stream is a stream error.
1442 A list of error codes is included in <xref target="ErrorCodes"/>.
1445 <section anchor="ConnectionErrorHandler" title="Connection Error Handling">
1447 A connection error is any error which prevents further processing of the framing layer,
1448 or which corrupts any connection state.
1451 An endpoint that encounters a connection error SHOULD first send a <x:ref>GOAWAY</x:ref>
1452 frame (<xref target="GOAWAY"/>) with the stream identifier of the last stream that it
1453 successfully received from its peer. The <x:ref>GOAWAY</x:ref> frame includes an error
1454 code that indicates why the connection is terminating. After sending the
1455 <x:ref>GOAWAY</x:ref> frame, the endpoint MUST close the TCP connection.
1458 It is possible that the <x:ref>GOAWAY</x:ref> will not be reliably received by the
1459 receiving endpoint (see <xref target="RFC7230" x:fmt=","
1460 x:rel="#persistent.tear-down"/>). In the event of a connection error,
1461 <x:ref>GOAWAY</x:ref> only provides a best effort attempt to communicate with the peer
1462 about why the connection is being terminated.
1465 An endpoint can end a connection at any time. In particular, an endpoint MAY choose to
1466 treat a stream error as a connection error. Endpoints SHOULD send a
1467 <x:ref>GOAWAY</x:ref> frame when ending a connection, providing that circumstances
1472 <section anchor="StreamErrorHandler" title="Stream Error Handling">
1474 A stream error is an error related to a specific stream that does not affect processing
1478 An endpoint that detects a stream error sends a <x:ref>RST_STREAM</x:ref> frame (<xref
1479 target="RST_STREAM"/>) that contains the stream identifier of the stream where the error
1480 occurred. The <x:ref>RST_STREAM</x:ref> frame includes an error code that indicates the
1484 A <x:ref>RST_STREAM</x:ref> is the last frame that an endpoint can send on a stream.
1485 The peer that sends the <x:ref>RST_STREAM</x:ref> frame MUST be prepared to receive any
1486 frames that were sent or enqueued for sending by the remote peer. These frames can be
1487 ignored, except where they modify connection state (such as the state maintained for
1488 <xref target="HeaderBlock">header compression</xref>, or flow control).
1491 Normally, an endpoint SHOULD NOT send more than one <x:ref>RST_STREAM</x:ref> frame for
1492 any stream. However, an endpoint MAY send additional <x:ref>RST_STREAM</x:ref> frames if
1493 it receives frames on a closed stream after more than a round-trip time. This behavior
1494 is permitted to deal with misbehaving implementations.
1497 An endpoint MUST NOT send a <x:ref>RST_STREAM</x:ref> in response to an
1498 <x:ref>RST_STREAM</x:ref> frame, to avoid looping.
1502 <section title="Connection Termination">
1504 If the TCP connection is closed or reset while streams remain in open or half closed
1505 states, then the endpoint MUST assume that those streams were abnormally interrupted and
1506 could be incomplete.
1511 <section anchor="extensibility" title="Extending HTTP/2">
1513 HTTP/2 permits extension of the protocol. Protocol extensions can be used to provide
1514 additional services or alter any aspect of the protocol, within the limitations described
1515 in this section. Extensions are effective only within the scope of a single HTTP/2
1519 Extensions are permitted to use new <xref target="FrameHeader">frame types</xref>, new
1520 <xref target="SettingValues">settings</xref>, or new <xref target="ErrorCodes">error
1521 codes</xref>. Registries are established for managing these extension points: <xref
1522 target="iana-frames">frame types</xref>, <xref target="iana-settings">settings</xref> and
1523 <xref target="iana-errors">error codes</xref>.
1526 Implementations MUST ignore unknown or unsupported values in all extensible protocol
1527 elements. Implementations MUST discard frames that have unknown or unsupported types.
1528 This means that any of these extension points can be safely used by extensions without
1529 prior arrangement or negotiation. However, extension frames that appear in the middle of
1530 a <xref target="HeaderBlock">header block</xref> are not permitted; these MUST be treated
1531 as a <xref target="ConnectionErrorHandler">connection error</xref> of type
1532 <x:ref>PROTOCOL_ERROR</x:ref>.
1535 However, extensions that could change the semantics of existing protocol components MUST
1536 be negotiated before being used. For example, an extension that changes the layout of the
1537 <x:ref>HEADERS</x:ref> frame cannot be used until the peer has given a positive signal
1538 that this is acceptable. In this case, it could also be necessary to coordinate when the
1539 revised layout comes into effect. Note that treating any frame other than
1540 <x:ref>DATA</x:ref> frames as flow controlled is such a change in semantics, and can only
1541 be done through negotiation.
1544 This document doesn't mandate a specific method for negotiating the use of an extension,
1545 but notes that a <xref target="SettingValues">setting</xref> could be used for that
1546 purpose. If both peers set a value that indicates willingness to use the extension, then
1547 the extension can be used. If a setting is used for extension negotiation, the initial
1548 value MUST be defined so that the extension is initially disabled.
1553 <section anchor="FrameTypes" title="Frame Definitions">
1555 This specification defines a number of frame types, each identified by a unique 8-bit type
1556 code. Each frame type serves a distinct purpose either in the establishment and management
1557 of the connection as a whole, or of individual streams.
1560 The transmission of specific frame types can alter the state of a connection. If endpoints
1561 fail to maintain a synchronized view of the connection state, successful communication
1562 within the connection will no longer be possible. Therefore, it is important that endpoints
1563 have a shared comprehension of how the state is affected by the use any given frame.
1566 <section anchor="DATA" title="DATA">
1568 DATA frames (type=0x0) convey arbitrary, variable-length sequences of octets associated
1569 with a stream. One or more DATA frames are used, for instance, to carry HTTP request or
1573 DATA frames MAY also contain arbitrary padding. Padding can be added to DATA frames to
1574 obscure the size of messages.
1576 <figure title="DATA Frame Payload">
1577 <artwork type="inline"><![CDATA[
1579 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
1580 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1582 +---------------+-----------------------------------------------+
1584 +---------------------------------------------------------------+
1586 +---------------------------------------------------------------+
1590 The DATA frame contains the following fields:
1591 <list style="hanging">
1592 <t hangText="Pad Length:">
1593 An 8-bit field containing the length of the frame padding in units of octets. This
1594 field is optional and is only present if the PADDED flag is set.
1596 <t hangText="Data:">
1597 Application data. The amount of data is the remainder of the frame payload after
1598 subtracting the length of the other fields that are present.
1600 <t hangText="Padding:">
1601 Padding octets that contain no application semantic value. Padding octets MUST be set
1602 to zero when sending and ignored when receiving.
1608 The DATA frame defines the following flags:
1609 <list style="hanging">
1610 <t hangText="END_STREAM (0x1):">
1611 Bit 1 being set indicates that this frame is the last that the endpoint will send for
1612 the identified stream. Setting this flag causes the stream to enter one of <xref
1613 target="StreamStates">the "half closed" states or the "closed" state</xref>.
1615 <t hangText="PADDED (0x8):">
1616 Bit 4 being set indicates that the Pad Length field and any padding that it describes
1622 DATA frames MUST be associated with a stream. If a DATA frame is received whose stream
1623 identifier field is 0x0, the recipient MUST respond with a <xref
1624 target="ConnectionErrorHandler">connection error</xref> of type
1625 <x:ref>PROTOCOL_ERROR</x:ref>.
1628 DATA frames are subject to flow control and can only be sent when a stream is in the
1629 "open" or "half closed (remote)" states. The entire DATA frame payload is included in flow
1630 control, including Pad Length and Padding fields if present. If a DATA frame is received
1631 whose stream is not in "open" or "half closed (local)" state, the recipient MUST respond
1632 with a <xref target="StreamErrorHandler">stream error</xref> of type
1633 <x:ref>STREAM_CLOSED</x:ref>.
1636 The total number of padding octets is determined by the value of the Pad Length field. If
1637 the length of the padding is greater than the length of the frame payload, the recipient
1638 MUST treat this as a <xref target="ConnectionErrorHandler">connection error</xref> of
1639 type <x:ref>PROTOCOL_ERROR</x:ref>.
1640 <list style="hanging">
1641 <t hangText="Note:">
1642 A frame can be increased in size by one octet by including a Pad Length field with a
1648 Padding is a security feature; see <xref target="padding"/>.
1652 <section anchor="HEADERS" title="HEADERS">
1654 The HEADERS frame (type=0x1) is used to <xref target="StreamStates">open a stream</xref>,
1655 and additionally carries a header block fragment. HEADERS frames can be sent on a stream
1656 in the "open" or "half closed (remote)" states.
1658 <figure title="HEADERS Frame Payload">
1659 <artwork type="inline"><![CDATA[
1661 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
1662 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1664 +-+-------------+-----------------------------------------------+
1665 |E| Stream Dependency? (31) |
1666 +-+-------------+-----------------------------------------------+
1668 +-+-------------+-----------------------------------------------+
1669 | Header Block Fragment (*) ...
1670 +---------------------------------------------------------------+
1672 +---------------------------------------------------------------+
1676 The HEADERS frame payload has the following fields:
1677 <list style="hanging">
1678 <t hangText="Pad Length:">
1679 An 8-bit field containing the length of the frame padding in units of octets. This
1680 field is only present if the PADDED flag is set.
1683 A single bit flag indicates that the stream dependency is exclusive, see <xref
1684 target="StreamPriority"/>. This field is only present if the PRIORITY flag is set.
1686 <t hangText="Stream Dependency:">
1687 A 31-bit stream identifier for the stream that this stream depends on, see <xref
1688 target="StreamPriority"/>. This field is only present if the PRIORITY flag is set.
1690 <t hangText="Weight:">
1691 An 8-bit weight for the stream, see <xref target="StreamPriority"/>. Add one to the
1692 value to obtain a weight between 1 and 256. This field is only present if the
1693 PRIORITY flag is set.
1695 <t hangText="Header Block Fragment:">
1696 A <xref target="HeaderBlock">header block fragment</xref>.
1698 <t hangText="Padding:">
1699 Padding octets that contain no application semantic value. Padding octets MUST be set
1700 to zero when sending and ignored when receiving.
1706 The HEADERS frame defines the following flags:
1707 <list style="hanging">
1708 <x:lt hangText="END_STREAM (0x1):">
1710 Bit 1 being set indicates that the <xref target="HeaderBlock">header block</xref> is
1711 the last that the endpoint will send for the identified stream. Setting this flag
1712 causes the stream to enter one of <xref target="StreamStates">"half closed"
1716 A HEADERS frame carries the END_STREAM flag that signals the end of a stream.
1717 However, a HEADERS frame with the END_STREAM flag set can be followed by
1718 <x:ref>CONTINUATION</x:ref> frames on the same stream. Logically, the
1719 <x:ref>CONTINUATION</x:ref> frames are part of the HEADERS frame.
1722 <x:lt hangText="END_HEADERS (0x4):">
1724 Bit 3 being set indicates that this frame contains an entire <xref
1725 target="HeaderBlock">header block</xref> and is not followed by any
1726 <x:ref>CONTINUATION</x:ref> frames.
1729 A HEADERS frame without the END_HEADERS flag set MUST be followed by a
1730 <x:ref>CONTINUATION</x:ref> frame for the same stream. A receiver MUST treat the
1731 receipt of any other type of frame or a frame on a different stream as a <xref
1732 target="ConnectionErrorHandler">connection error</xref> of type
1733 <x:ref>PROTOCOL_ERROR</x:ref>.
1736 <x:lt hangText="PADDED (0x8):">
1738 Bit 4 being set indicates that the Pad Length field and any padding that it
1739 describes is present.
1742 <x:lt hangText="PRIORITY (0x20):">
1744 Bit 6 being set indicates that the Exclusive Flag (E), Stream Dependency, and Weight
1745 fields are present; see <xref target="StreamPriority"/>.
1752 The payload of a HEADERS frame contains a <xref target="HeaderBlock">header block
1753 fragment</xref>. A header block that does not fit within a HEADERS frame is continued in
1754 a <xref target="CONTINUATION">CONTINUATION frame</xref>.
1758 HEADERS frames MUST be associated with a stream. If a HEADERS frame is received whose
1759 stream identifier field is 0x0, the recipient MUST respond with a <xref
1760 target="ConnectionErrorHandler">connection error</xref> of type
1761 <x:ref>PROTOCOL_ERROR</x:ref>.
1765 The HEADERS frame changes the connection state as described in <xref
1766 target="HeaderBlock"/>.
1770 The HEADERS frame includes optional padding. Padding fields and flags are identical to
1771 those defined for <xref target="DATA">DATA frames</xref>.
1774 Prioritization information in a HEADERS frame is logically equivalent to a separate
1775 <x:ref>PRIORITY</x:ref> frame, but inclusion in HEADERS avoids the potential for churn in
1776 stream prioritization when new streams are created. Priorization fields in HEADERS frames
1777 subsequent to the first on a stream <xref target="reprioritize">reprioritize the
1782 <section anchor="PRIORITY" title="PRIORITY">
1784 The PRIORITY frame (type=0x2) specifies the <xref target="StreamPriority">sender-advised
1785 priority of a stream</xref>. It can be sent at any time for an existing stream, including
1786 closed streams. This enables reprioritization of existing streams.
1788 <figure title="PRIORITY Frame Payload">
1789 <artwork type="inline"><![CDATA[
1791 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
1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1793 |E| Stream Dependency (31) |
1794 +-+-------------+-----------------------------------------------+
1800 The payload of a PRIORITY frame contains the following fields:
1801 <list style="hanging">
1803 A single bit flag indicates that the stream dependency is exclusive, see <xref
1804 target="StreamPriority"/>.
1806 <t hangText="Stream Dependency:">
1807 A 31-bit stream identifier for the stream that this stream depends on, see <xref
1808 target="StreamPriority"/>.
1810 <t hangText="Weight:">
1811 An 8-bit weight for the identified stream dependency, see <xref
1812 target="StreamPriority"/>. Add one to the value to obtain a weight between 1 and 256.
1818 The PRIORITY frame does not define any flags.
1822 The PRIORITY frame is associated with an existing stream. If a PRIORITY frame is received
1823 with a stream identifier of 0x0, the recipient MUST respond with a <xref
1824 target="ConnectionErrorHandler">connection error</xref> of type
1825 <x:ref>PROTOCOL_ERROR</x:ref>.
1828 The PRIORITY frame can be sent on a stream in any of the "reserved (remote)", "open",
1829 "half closed (local)", "half closed (remote)", or "closed" states, though it cannot be
1830 sent between consecutive frames that comprise a single <xref target="HeaderBlock">header
1831 block</xref>. Note that this frame could arrive after processing or frame sending has
1832 completed, which would cause it to have no effect on the current stream. For a stream
1833 that is in the "half closed (remote)" or "closed" - state, this frame can only affect
1834 processing of the current stream and not frame transmission.
1837 The PRIORITY frame is the only frame that can be sent for a stream in the "closed" state.
1838 This allows for the reprioritization of a group of dependent streams by altering the
1839 priority of a parent stream, which might be closed. However, a PRIORITY frame sent on a
1840 closed stream risks being ignored due to the peer having discarded priority state
1841 information for that stream.
1845 <section anchor="RST_STREAM" title="RST_STREAM">
1847 The RST_STREAM frame (type=0x3) allows for abnormal termination of a stream. When sent by
1848 the initiator of a stream, it indicates that they wish to cancel the stream or that an
1849 error condition has occurred. When sent by the receiver of a stream, it indicates that
1850 either the receiver is rejecting the stream, requesting that the stream be cancelled, or
1851 that an error condition has occurred.
1853 <figure title="RST_STREAM Frame Payload">
1854 <artwork type="inline"><![CDATA[
1856 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
1857 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1859 +---------------------------------------------------------------+
1864 The RST_STREAM frame contains a single unsigned, 32-bit integer identifying the <xref
1865 target="ErrorCodes">error code</xref>. The error code indicates why the stream is being
1870 The RST_STREAM frame does not define any flags.
1874 The RST_STREAM frame fully terminates the referenced stream and causes it to enter the
1875 closed state. After receiving a RST_STREAM on a stream, the receiver MUST NOT send
1876 additional frames for that stream, with the exception of <x:ref>PRIORITY</x:ref>. However,
1877 after sending the RST_STREAM, the sending endpoint MUST be prepared to receive and process
1878 additional frames sent on the stream that might have been sent by the peer prior to the
1879 arrival of the RST_STREAM.
1883 RST_STREAM frames MUST be associated with a stream. If a RST_STREAM frame is received
1884 with a stream identifier of 0x0, the recipient MUST treat this as a <xref
1885 target="ConnectionErrorHandler">connection error</xref> of type
1886 <x:ref>PROTOCOL_ERROR</x:ref>.
1890 RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. If a RST_STREAM
1891 frame identifying an idle stream is received, the recipient MUST treat this as a <xref
1892 target="ConnectionErrorHandler">connection error</xref> of type
1893 <x:ref>PROTOCOL_ERROR</x:ref>.
1898 <section anchor="SETTINGS" title="SETTINGS">
1900 The SETTINGS frame (type=0x4) conveys configuration parameters that affect how endpoints
1901 communicate, such as preferences and constraints on peer behavior. The SETTINGS frame is
1902 also used to acknowledge the receipt of those parameters. Individually, a SETTINGS
1903 parameter can also be referred to as a "setting".
1906 SETTINGS parameters are not negotiated; they describe characteristics of the sending peer,
1907 which are used by the receiving peer. Different values for the same parameter can be
1908 advertised by each peer. For example, a client might set a high initial flow control
1909 window, whereas a server might set a lower value to conserve resources.
1913 A SETTINGS frame MUST be sent by both endpoints at the start of a connection, and MAY be
1914 sent at any other time by either endpoint over the lifetime of the connection.
1915 Implementations MUST support all of the parameters defined by this specification.
1919 Each parameter in a SETTINGS frame replaces any existing value for that parameter.
1920 Parameters are processed in the order in which they appear, and a receiver of a SETTINGS
1921 frame does not need to maintain any state other than the current value of its
1922 parameters. Therefore, the value of a SETTINGS parameter is the last value that is seen by
1926 SETTINGS parameters are acknowledged by the receiving peer. To enable this, the SETTINGS
1927 frame defines the following flag:
1928 <list style="hanging">
1929 <t hangText="ACK (0x1):">
1930 Bit 1 being set indicates that this frame acknowledges receipt and application of the
1931 peer's SETTINGS frame. When this bit is set, the payload of the SETTINGS frame MUST
1932 be empty. Receipt of a SETTINGS frame with the ACK flag set and a length field value
1933 other than 0 MUST be treated as a <xref target="ConnectionErrorHandler">connection
1934 error</xref> of type <x:ref>FRAME_SIZE_ERROR</x:ref>. For more info, see <xref
1935 target="SettingsSync">Settings Synchronization</xref>.
1940 SETTINGS frames always apply to a connection, never a single stream. The stream
1941 identifier for a SETTINGS frame MUST be zero (0x0). If an endpoint receives a SETTINGS
1942 frame whose stream identifier field is anything other than 0x0, the endpoint MUST respond
1943 with a <xref target="ConnectionErrorHandler">connection error</xref> of type
1944 <x:ref>PROTOCOL_ERROR</x:ref>.
1947 The SETTINGS frame affects connection state. A badly formed or incomplete SETTINGS frame
1948 MUST be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of type
1949 <x:ref>PROTOCOL_ERROR</x:ref>.
1952 <section title="SETTINGS Format" anchor="SettingFormat">
1954 The payload of a SETTINGS frame consists of zero or more parameters, each consisting of
1955 an unsigned 16-bit setting identifier and an unsigned 32-bit value.
1958 <figure title="Setting Format">
1959 <artwork type="inline"><![CDATA[
1961 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
1962 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
1964 +-------------------------------+-------------------------------+
1966 +---------------------------------------------------------------+
1971 <section anchor="SettingValues" title="Defined SETTINGS Parameters">
1973 The following parameters are defined:
1974 <list style="hanging">
1975 <x:lt hangText="SETTINGS_HEADER_TABLE_SIZE (0x1):"
1976 anchor="SETTINGS_HEADER_TABLE_SIZE">
1978 Allows the sender to inform the remote endpoint of the maximum size of the header
1979 compression table used to decode header blocks, in octets. The encoder can select
1980 any size equal to or less than this value by using signaling specific to the
1981 header compression format inside a header block. The initial value is 4,096
1985 <x:lt hangText="SETTINGS_ENABLE_PUSH (0x2):"
1986 anchor="SETTINGS_ENABLE_PUSH">
1988 This setting can be use to disable <xref target="PushResources">server
1989 push</xref>. An endpoint MUST NOT send a <x:ref>PUSH_PROMISE</x:ref> frame if it
1990 receives this parameter set to a value of 0. An endpoint that has both set this
1991 parameter to 0 and had it acknowledged MUST treat the receipt of a
1992 <x:ref>PUSH_PROMISE</x:ref> frame as a <xref
1993 target="ConnectionErrorHandler">connection error</xref> of type
1994 <x:ref>PROTOCOL_ERROR</x:ref>.
1997 The initial value is 1, which indicates that server push is permitted. Any value
1998 other than 0 or 1 MUST be treated as a <xref
1999 target="ConnectionErrorHandler">connection error</xref> of type
2000 <x:ref>PROTOCOL_ERROR</x:ref>.
2003 <x:lt hangText="SETTINGS_MAX_CONCURRENT_STREAMS (0x3):"
2004 anchor="SETTINGS_MAX_CONCURRENT_STREAMS">
2006 Indicates the maximum number of concurrent streams that the sender will allow.
2007 This limit is directional: it applies to the number of streams that the sender
2008 permits the receiver to create. Initially there is no limit to this value. It is
2009 recommended that this value be no smaller than 100, so as to not unnecessarily
2013 A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be treated as special
2014 by endpoints. A zero value does prevent the creation of new streams, however this
2015 can also happen for any limit that is exhausted with active streams. Servers
2016 SHOULD only set a zero value for short durations; if a server does not wish to
2017 accept requests, closing the connection could be preferable.
2020 <x:lt hangText="SETTINGS_INITIAL_WINDOW_SIZE (0x4):"
2021 anchor="SETTINGS_INITIAL_WINDOW_SIZE">
2023 Indicates the sender's initial window size (in octets) for stream level flow
2024 control. The initial value is 2<x:sup>16</x:sup>-1 (65,535) octets.
2027 This setting affects the window size of all streams, including existing streams,
2028 see <xref target="InitialWindowSize"/>.
2031 Values above the maximum flow control window size of 2<x:sup>31</x:sup>-1 MUST
2032 be treated as a <xref target="ConnectionErrorHandler">connection error</xref> of
2033 type <x:ref>FLOW_CONTROL_ERROR</x:ref>.
2036 <x:lt hangText="SETTINGS_MAX_FRAME_SIZE (0x5):"
2037 anchor="SETTINGS_MAX_FRAME_SIZE">
2039 Indicates the size of the largest frame payload that the sender is willing to
2043 The initial value is 2<x:sup>14</x:sup> (16,384) octets. The value advertised by
2044 an endpoint MUST be between this initial value and the maximum allowed frame size
2045 (2<x:sup>24</x:sup>-1 or 16,777,215 octets), inclusive. Values outside this range
2046 MUST be treated as a <xref target="ConnectionErrorHandler">connection error</xref>
2047 of type <x:ref>PROTOCOL_ERROR</x:ref>.
2050 <x:lt hangText="SETTINGS_MAX_HEADER_LIST_SIZE (0x6):"
2051 anchor="SETTINGS_MAX_HEADER_LIST_SIZE">
2053 This advisory setting informs a peer of the maximum size of header list that the
2054 sender is prepared to accept, in octets. The value is based on the uncompressed
2055 size of header fields, including the length of the name and value in octets plus
2056 an overhead of 32 octets for each header field.
2059 For any given request, a lower limit than what is advertised MAY be enforced. The
2060 initial value of this setting is unlimited.
2066 An endpoint that receives a SETTINGS frame with any unknown or unsupported identifier
2067 MUST ignore that setting.
2071 <section anchor="SettingsSync" title="Settings Synchronization">
2073 Most values in SETTINGS benefit from or require an understanding of when the peer has
2074 received and applied the changed parameter values. In order to provide
2075 such synchronization timepoints, the recipient of a SETTINGS frame in which the ACK flag
2076 is not set MUST apply the updated parameters as soon as possible upon receipt.
2079 The values in the SETTINGS frame MUST be processed in the order they appear, with no
2080 other frame processing between values. Unsupported parameters MUST be ignored. Once
2081 all values have been processed, the recipient MUST immediately emit a SETTINGS frame
2082 with the ACK flag set. Upon receiving a SETTINGS frame with the ACK flag set, the sender
2083 of the altered parameters can rely on the setting having been applied.
2086 If the sender of a SETTINGS frame does not receive an acknowledgement within a
2087 reasonable amount of time, it MAY issue a <xref
2088 target="ConnectionErrorHandler">connection error</xref> of type
2089 <x:ref>SETTINGS_TIMEOUT</x:ref>.
2094 <section anchor="PUSH_PROMISE" title="PUSH_PROMISE">
2096 The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint in advance of
2097 streams the sender intends to initiate. The PUSH_PROMISE frame includes the unsigned
2098 31-bit identifier of the stream the endpoint plans to create along with a set of headers
2099 that provide additional context for the stream. <xref target="PushResources"/> contains a
2100 thorough description of the use of PUSH_PROMISE frames.
2103 <figure title="PUSH_PROMISE Payload Format">
2104 <artwork type="inline"><![CDATA[
2106 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
2107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2109 +-+-------------+-----------------------------------------------+
2110 |R| Promised Stream ID (31) |
2111 +-+-----------------------------+-------------------------------+
2112 | Header Block Fragment (*) ...
2113 +---------------------------------------------------------------+
2115 +---------------------------------------------------------------+
2119 The PUSH_PROMISE frame payload has the following fields:
2120 <list style="hanging">
2121 <t hangText="Pad Length:">
2122 An 8-bit field containing the length of the frame padding in units of octets. This
2123 field is only present if the PADDED flag is set.
2126 A single reserved bit.
2128 <t hangText="Promised Stream ID:">
2129 An unsigned 31-bit integer that identifies the stream that is reserved by the
2130 PUSH_PROMISE. The promised stream identifier MUST be a valid choice for the next
2131 stream sent by the sender (see <xref target="StreamIdentifiers">new stream
2134 <t hangText="Header Block Fragment:">
2135 A <xref target="HeaderBlock">header block fragment</xref> containing request header
2138 <t hangText="Padding:">
2145 The PUSH_PROMISE frame defines the following flags:
2146 <list style="hanging">
2147 <x:lt hangText="END_HEADERS (0x4):">
2149 Bit 3 being set indicates that this frame contains an entire <xref
2150 target="HeaderBlock">header block</xref> and is not followed by any
2151 <x:ref>CONTINUATION</x:ref> frames.
2154 A PUSH_PROMISE frame without the END_HEADERS flag set MUST be followed by a
2155 CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any
2156 other type of frame or a frame on a different stream as a <xref
2157 target="ConnectionErrorHandler">connection error</xref> of type
2158 <x:ref>PROTOCOL_ERROR</x:ref>.
2161 <x:lt hangText="PADDED (0x8):">
2163 Bit 4 being set indicates that the Pad Length field and any padding that it
2164 describes is present.
2171 PUSH_PROMISE frames MUST be associated with an existing, peer-initiated stream. The stream
2172 identifier of a PUSH_PROMISE frame indicates the stream it is associated with. If the
2173 stream identifier field specifies the value 0x0, a recipient MUST respond with a <xref
2174 target="ConnectionErrorHandler">connection error</xref> of type
2175 <x:ref>PROTOCOL_ERROR</x:ref>.
2179 Promised streams are not required to be used in the order they are promised. The
2180 PUSH_PROMISE only reserves stream identifiers for later use.
2184 PUSH_PROMISE MUST NOT be sent if the <x:ref>SETTINGS_ENABLE_PUSH</x:ref> setting of the
2185 peer endpoint is set to 0. An endpoint that has set this setting and has received
2186 acknowledgement MUST treat the receipt of a PUSH_PROMISE frame as a <xref
2187 target="ConnectionErrorHandler">connection error</xref> of type
2188 <x:ref>PROTOCOL_ERROR</x:ref>.
2191 Recipients of PUSH_PROMISE frames can choose to reject promised streams by returning a
2192 <x:ref>RST_STREAM</x:ref> referencing the promised stream identifier back to the sender of
2197 A PUSH_PROMISE frame modifies the connection state in two ways. The inclusion of a <xref
2198 target="HeaderBlock">header block</xref> potentially modifies the state maintained for
2199 header compression. PUSH_PROMISE also reserves a stream for later use, causing the
2200 promised stream to enter the "reserved" state. A sender MUST NOT send a PUSH_PROMISE on a
2201 stream unless that stream is either "open" or "half closed (remote)"; the sender MUST
2202 ensure that the promised stream is a valid choice for a <xref
2203 target="StreamIdentifiers">new stream identifier</xref> (that is, the promised stream MUST
2204 be in the "idle" state).
2207 Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame causes the stream
2208 state to become indeterminate. A receiver MUST treat the receipt of a PUSH_PROMISE on a
2209 stream that is neither "open" nor "half closed (local)" as a <xref
2210 target="ConnectionErrorHandler">connection error</xref> of type
2211 <x:ref>PROTOCOL_ERROR</x:ref>. However, an endpoint that has sent
2212 <x:ref>RST_STREAM</x:ref> on the associated stream MUST handle PUSH_PROMISE frames that
2213 might have been created before the <x:ref>RST_STREAM</x:ref> frame is received and
2217 A receiver MUST treat the receipt of a PUSH_PROMISE that promises an <xref
2218 target="StreamIdentifiers">illegal stream identifier</xref> (that is, an identifier for a
2219 stream that is not currently in the "idle" state) as a <xref
2220 target="ConnectionErrorHandler">connection error</xref> of type
2221 <x:ref>PROTOCOL_ERROR</x:ref>.
2225 The PUSH_PROMISE frame includes optional padding. Padding fields and flags are identical
2226 to those defined for <xref target="DATA">DATA frames</xref>.
2230 <section anchor="PING" title="PING">
2232 The PING frame (type=0x6) is a mechanism for measuring a minimal round trip time from the
2233 sender, as well as determining whether an idle connection is still functional. PING
2234 frames can be sent from any endpoint.
2236 <figure title="PING Payload Format">
2237 <artwork type="inline"><![CDATA[
2239 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
2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2242 | Opaque Data (64) |
2244 +---------------------------------------------------------------+
2249 In addition to the frame header, PING frames MUST contain 8 octets of data in the payload.
2250 A sender can include any value it chooses and use those bytes in any fashion.
2253 Receivers of a PING frame that does not include an ACK flag MUST send a PING frame with
2254 the ACK flag set in response, with an identical payload. PING responses SHOULD be given
2255 higher priority than any other frame.
2259 The PING frame defines the following flags:
2260 <list style="hanging">
2261 <t hangText="ACK (0x1):">
2262 Bit 1 being set indicates that this PING frame is a PING response. An endpoint MUST
2263 set this flag in PING responses. An endpoint MUST NOT respond to PING frames
2264 containing this flag.
2269 PING frames are not associated with any individual stream. If a PING frame is received
2270 with a stream identifier field value other than 0x0, the recipient MUST respond with a
2271 <xref target="ConnectionErrorHandler">connection error</xref> of type
2272 <x:ref>PROTOCOL_ERROR</x:ref>.
2275 Receipt of a PING frame with a length field value other than 8 MUST be treated as a <xref
2276 target="ConnectionErrorHandler">connection error</xref> of type
2277 <x:ref>FRAME_SIZE_ERROR</x:ref>.
2282 <section anchor="GOAWAY" title="GOAWAY">
2284 The GOAWAY frame (type=0x7) informs the remote peer to stop creating streams on this
2285 connection. GOAWAY can be sent by either the client or the server. Once sent, the sender
2286 will ignore frames sent on any new streams with identifiers higher than the included last
2287 stream identifier. Receivers of a GOAWAY frame MUST NOT open additional streams on the
2288 connection, although a new connection can be established for new streams.
2291 The purpose of this frame is to allow an endpoint to gracefully stop accepting new
2292 streams, while still finishing processing of previously established streams. This enables
2293 administrative actions, like server maintainance.
2296 There is an inherent race condition between an endpoint starting new streams and the
2297 remote sending a GOAWAY frame. To deal with this case, the GOAWAY contains the stream
2298 identifier of the last peer-initiated stream which was or might be processed on the
2299 sending endpoint in this connection. For instance, if the server sends a GOAWAY frame,
2300 the identified stream is the highest numbered stream initiated by the client.
2303 If the receiver of the GOAWAY has sent data on streams with a higher stream identifier
2304 than what is indicated in the GOAWAY frame, those streams are not or will not be
2305 processed. The receiver of the GOAWAY frame can treat the streams as though they had
2306 never been created at all, thereby allowing those streams to be retried later on a new
2310 Endpoints SHOULD always send a GOAWAY frame before closing a connection so that the remote
2311 can know whether a stream has been partially processed or not. For example, if an HTTP
2312 client sends a POST at the same time that a server closes a connection, the client cannot
2313 know if the server started to process that POST request if the server does not send a
2314 GOAWAY frame to indicate what streams it might have acted on.
2317 An endpoint might choose to close a connection without sending GOAWAY for misbehaving
2321 <figure title="GOAWAY Payload Format">
2322 <artwork type="inline"><![CDATA[
2324 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
2325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2326 |R| Last-Stream-ID (31) |
2327 +-+-------------------------------------------------------------+
2329 +---------------------------------------------------------------+
2330 | Additional Debug Data (*) |
2331 +---------------------------------------------------------------+
2335 The GOAWAY frame does not define any flags.
2338 The GOAWAY frame applies to the connection, not a specific stream. An endpoint MUST treat
2339 a <x:ref>GOAWAY</x:ref> frame with a stream identifier other than 0x0 as a <xref
2340 target="ConnectionErrorHandler">connection error</xref> of type
2341 <x:ref>PROTOCOL_ERROR</x:ref>.
2344 The last stream identifier in the GOAWAY frame contains the highest numbered stream
2345 identifier for which the sender of the GOAWAY frame might have taken some action on, or
2346 might yet take action on. All streams up to and including the identified stream might
2347 have been processed in some way. The last stream identifier can be set to 0 if no streams
2349 <list style="hanging">
2350 <t hangText="Note:">
2351 In this context, "processed" means that some data from the stream was passed to some
2352 higher layer of software that might have taken some action as a result.
2355 If a connection terminates without a GOAWAY frame, the last stream identifier is
2356 effectively the highest possible stream identifier.
2359 On streams with lower or equal numbered identifiers that were not closed completely prior
2360 to the connection being closed, re-attempting requests, transactions, or any protocol
2361 activity is not possible, with the exception of idempotent actions like HTTP GET, PUT, or
2362 DELETE. Any protocol activity that uses higher numbered streams can be safely retried
2363 using a new connection.
2366 Activity on streams numbered lower or equal to the last stream identifier might still
2367 complete successfully. The sender of a GOAWAY frame might gracefully shut down a
2368 connection by sending a GOAWAY frame, maintaining the connection in an open state until
2369 all in-progress streams complete.
2372 An endpoint MAY send multiple GOAWAY frames if circumstances change. For instance, an
2373 endpoint that sends GOAWAY with <x:ref>NO_ERROR</x:ref> during graceful shutdown could
2374 subsequently encounter an condition that requires immediate termination of the connection.
2375 The last stream identifier from the last GOAWAY frame received indicates which streams
2376 could have been acted upon. Endpoints MUST NOT increase the value they send in the last
2377 stream identifier, since the peers might already have retried unprocessed requests on
2381 A client that is unable to retry requests loses all requests that are in flight when the
2382 server closes the connection. This is especially true for intermediaries that might
2383 not be serving clients using HTTP/2. A server that is attempting to gracefully shut down
2384 a connection SHOULD send an initial GOAWAY frame with the last stream identifier set to
2385 2<x:sup>31</x:sup>-1 and a <x:ref>NO_ERROR</x:ref> code. This signals to the client that
2386 a shutdown is imminent and that no further requests can be initiated. After waiting at
2387 least one round trip time, the server can send another GOAWAY frame with an updated last
2388 stream identifier. This ensures that a connection can be cleanly shut down without losing
2393 After sending a GOAWAY frame, the sender can discard frames for streams with identifiers
2394 higher than the identified last stream. However, any frames that alter connection state
2395 cannot be completely ignored. For instance, <x:ref>HEADERS</x:ref>,
2396 <x:ref>PUSH_PROMISE</x:ref> and <x:ref>CONTINUATION</x:ref> frames MUST be minimally
2397 processed to ensure the state maintained for header compression is consistent (see <xref
2398 target="HeaderBlock"/>); similarly DATA frames MUST be counted toward the connection flow
2399 control window. Failure to process these frames can cause flow control or header
2400 compression state to become unsynchronized.
2404 The GOAWAY frame also contains a 32-bit <xref target="ErrorCodes">error code</xref> that
2405 contains the reason for closing the connection.
2408 Endpoints MAY append opaque data to the payload of any GOAWAY frame. Additional debug
2409 data is intended for diagnostic purposes only and carries no semantic value. Debug
2410 information could contain security- or privacy-sensitive data. Logged or otherwise
2411 persistently stored debug data MUST have adequate safeguards to prevent unauthorized
2416 <section anchor="WINDOW_UPDATE" title="WINDOW_UPDATE">
2418 The WINDOW_UPDATE frame (type=0x8) is used to implement flow control; see <xref
2419 target="FlowControl"/> for an overview.
2422 Flow control operates at two levels: on each individual stream and on the entire
2426 Both types of flow control are hop-by-hop; that is, only between the two endpoints.
2427 Intermediaries do not forward WINDOW_UPDATE frames between dependent connections.
2428 However, throttling of data transfer by any receiver can indirectly cause the propagation
2429 of flow control information toward the original sender.
2432 Flow control only applies to frames that are identified as being subject to flow control.
2433 Of the frame types defined in this document, this includes only <x:ref>DATA</x:ref> frames.
2434 Frames that are exempt from flow control MUST be accepted and processed, unless the
2435 receiver is unable to assign resources to handling the frame. A receiver MAY respond with
2436 a <xref target="StreamErrorHandler">stream error</xref> or <xref
2437 target="ConnectionErrorHandler">connection error</xref> of type
2438 <x:ref>FLOW_CONTROL_ERROR</x:ref> if it is unable to accept a frame.
2440 <figure title="WINDOW_UPDATE Payload Format">
2441 <artwork type="inline"><![CDATA[
2443 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
2444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2445 |R| Window Size Increment (31) |
2446 +-+-------------------------------------------------------------+
2450 The payload of a WINDOW_UPDATE frame is one reserved bit, plus an unsigned 31-bit integer
2451 indicating the number of octets that the sender can transmit in addition to the existing
2452 flow control window. The legal range for the increment to the flow control window is 1 to
2453 2<x:sup>31</x:sup>-1 (0x7fffffff) octets.
2456 The WINDOW_UPDATE frame does not define any flags.
2459 The WINDOW_UPDATE frame can be specific to a stream or to the entire connection. In the
2460 former case, the frame's stream identifier indicates the affected stream; in the latter,
2461 the value "0" indicates that the entire connection is the subject of the frame.
2464 A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an flow control window
2465 increment of 0 as a <xref target="StreamErrorHandler">stream error</xref> of type
2466 <x:ref>PROTOCOL_ERROR</x:ref>; errors on the connection flow control window MUST be
2467 treated as a <xref target="ConnectionErrorHandler">connection error</xref>.
2470 WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the END_STREAM flag.
2471 This means that a receiver could receive a WINDOW_UPDATE frame on a "half closed (remote)"
2472 or "closed" stream. A receiver MUST NOT treat this as an error, see <xref
2473 target="StreamStates"/>.
2476 A receiver that receives a flow controlled frame MUST always account for its contribution
2477 against the connection flow control window, unless the receiver treats this as a <xref
2478 target="ConnectionErrorHandler">connection error</xref>. This is necessary even if the
2479 frame is in error. Since the sender counts the frame toward the flow control window, if
2480 the receiver does not, the flow control window at sender and receiver can become
2484 <section title="The Flow Control Window">
2486 Flow control in HTTP/2 is implemented using a window kept by each sender on every
2487 stream. The flow control window is a simple integer value that indicates how many octets
2488 of data the sender is permitted to transmit; as such, its size is a measure of the
2489 buffering capacity of the receiver.
2492 Two flow control windows are applicable: the stream flow control window and the
2493 connection flow control window. The sender MUST NOT send a flow controlled frame with a
2494 length that exceeds the space available in either of the flow control windows advertised
2495 by the receiver. Frames with zero length with the END_STREAM flag set (that is, an
2496 empty <x:ref>DATA</x:ref> frame) MAY be sent if there is no available space in either
2497 flow control window.
2500 For flow control calculations, the 9 octet frame header is not counted.
2503 After sending a flow controlled frame, the sender reduces the space available in both
2504 windows by the length of the transmitted frame.
2507 The receiver of a frame sends a WINDOW_UPDATE frame as it consumes data and frees up
2508 space in flow control windows. Separate WINDOW_UPDATE frames are sent for the stream
2509 and connection level flow control windows.
2512 A sender that receives a WINDOW_UPDATE frame updates the corresponding window by the
2513 amount specified in the frame.
2516 A sender MUST NOT allow a flow control window to exceed 2<x:sup>31</x:sup>-1 octets.
2517 If a sender receives a WINDOW_UPDATE that causes a flow control window to exceed this
2518 maximum it MUST terminate either the stream or the connection, as appropriate. For
2519 streams, the sender sends a <x:ref>RST_STREAM</x:ref> with the error code of
2520 <x:ref>FLOW_CONTROL_ERROR</x:ref> code; for the connection, a <x:ref>GOAWAY</x:ref>
2521 frame with a <x:ref>FLOW_CONTROL_ERROR</x:ref> code.
2524 Flow controlled frames from the sender and WINDOW_UPDATE frames from the receiver are
2525 completely asynchronous with respect to each other. This property allows a receiver to
2526 aggressively update the window size kept by the sender to prevent streams from stalling.
2530 <section anchor="InitialWindowSize" title="Initial Flow Control Window Size">
2532 When an HTTP/2 connection is first established, new streams are created with an initial
2533 flow control window size of 65,535 octets. The connection flow control window is 65,535
2534 octets. Both endpoints can adjust the initial window size for new streams by including
2535 a value for <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref> in the <x:ref>SETTINGS</x:ref>
2536 frame that forms part of the connection preface. The connection flow control window can
2537 only be changed using WINDOW_UPDATE frames.
2540 Prior to receiving a <x:ref>SETTINGS</x:ref> frame that sets a value for
2541 <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref>, an endpoint can only use the default
2542 initial window size when sending flow controlled frames. Similarly, the connection flow
2543 control window is set to the default initial window size until a WINDOW_UPDATE frame is
2547 A <x:ref>SETTINGS</x:ref> frame can alter the initial flow control window size for all
2548 current streams. When the value of <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref> changes,
2549 a receiver MUST adjust the size of all stream flow control windows that it maintains by
2550 the difference between the new value and the old value.
2553 A change to <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref> can cause the available space in
2554 a flow control window to become negative. A sender MUST track the negative flow control
2555 window, and MUST NOT send new flow controlled frames until it receives WINDOW_UPDATE
2556 frames that cause the flow control window to become positive.
2559 For example, if the client sends 60KB immediately on connection establishment, and the
2560 server sets the initial window size to be 16KB, the client will recalculate the
2561 available flow control window to be -44KB on receipt of the <x:ref>SETTINGS</x:ref>
2562 frame. The client retains a negative flow control window until WINDOW_UPDATE frames
2563 restore the window to being positive, after which the client can resume sending.
2566 A <x:ref>SETTINGS</x:ref> frame cannot alter the connection flow control window.
2569 An endpoint MUST treat a change to <x:ref>SETTINGS_INITIAL_WINDOW_SIZE</x:ref> that
2570 causes any flow control window to exceed the maximum size as a <xref
2571 target="ConnectionErrorHandler">connection error</xref> of type
2572 <x:ref>FLOW_CONTROL_ERROR</x:ref>.
2576 <section title="Reducing the Stream Window Size">
2578 A receiver that wishes to use a smaller flow control window than the current size can
2579 send a new <x:ref>SETTINGS</x:ref> frame. However, the receiver MUST be prepared to
2580 receive data that exceeds this window size, since the sender might send data that
2581 exceeds the lower limit prior to processing the <x:ref>SETTINGS</x:ref> frame.
2584 After sending a SETTINGS frame that reduces the initial flow control window size, a
2585 receiver has two options for handling streams that exceed flow control limits:
2586 <list style="numbers">
2588 The receiver can immediately send <x:ref>RST_STREAM</x:ref> with
2589 <x:ref>FLOW_CONTROL_ERROR</x:ref> error code for the affected streams.
2592 The receiver can accept the streams and tolerate the resulting head of line
2593 blocking, sending WINDOW_UPDATE frames as it consumes data.
2600 <section anchor="CONTINUATION" title="CONTINUATION">
2602 The CONTINUATION frame (type=0x9) is used to continue a sequence of <xref
2603 target="HeaderBlock">header block fragments</xref>. Any number of CONTINUATION frames can
2604 be sent on an existing stream, as long as the preceding frame is on the same stream and is
2605 a <x:ref>HEADERS</x:ref>, <x:ref>PUSH_PROMISE</x:ref> or CONTINUATION frame without the
2606 END_HEADERS flag set.
2609 <figure title="CONTINUATION Frame Payload">
2610 <artwork type="inline"><![CDATA[
2612 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
2613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
2614 | Header Block Fragment (*) ...
2615 +---------------------------------------------------------------+
2619 The CONTINUATION frame payload contains a <xref target="HeaderBlock">header block
2624 The CONTINUATION frame defines the following flag:
2625 <list style="hanging">
2626 <x:lt hangText="END_HEADERS (0x4):">
2628 Bit 3 being set indicates that this frame ends a <xref target="HeaderBlock">header
2632 If the END_HEADERS bit is not set, this frame MUST be followed by another
2633 CONTINUATION frame. A receiver MUST treat the receipt of any other type of frame or
2634 a frame on a different stream as a <xref target="ConnectionErrorHandler">connection
2635 error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
2642 The CONTINUATION frame changes the connection state as defined in <xref
2643 target="HeaderBlock" />.
2647 CONTINUATION frames MUST be associated with a stream. If a CONTINUATION frame is received
2648 whose stream identifier field is 0x0, the recipient MUST respond with a <xref
2649 target="ConnectionErrorHandler">connection error</xref> of type PROTOCOL_ERROR.
2653 A CONTINUATION frame MUST be preceded by a <x:ref>HEADERS</x:ref>,
2654 <x:ref>PUSH_PROMISE</x:ref> or CONTINUATION frame without the END_HEADERS flag set. A
2655 recipient that observes violation of this rule MUST respond with a <xref
2656 target="ConnectionErrorHandler"> connection error</xref> of type
2657 <x:ref>PROTOCOL_ERROR</x:ref>.
2662 <section anchor="ErrorCodes" title="Error Codes">
2664 Error codes are 32-bit fields that are used in <x:ref>RST_STREAM</x:ref> and
2665 <x:ref>GOAWAY</x:ref> frames to convey the reasons for the stream or connection error.
2669 Error codes share a common code space. Some error codes apply only to either streams or the
2670 entire connection and have no defined semantics in the other context.
2674 The following error codes are defined:
2675 <list style="hanging">
2676 <t hangText="NO_ERROR (0x0):" anchor="NO_ERROR">
2677 The associated condition is not as a result of an error. For example, a
2678 <x:ref>GOAWAY</x:ref> might include this code to indicate graceful shutdown of a
2681 <t hangText="PROTOCOL_ERROR (0x1):" anchor="PROTOCOL_ERROR">
2682 The endpoint detected an unspecific protocol error. This error is for use when a more
2683 specific error code is not available.
2685 <t hangText="INTERNAL_ERROR (0x2):" anchor="INTERNAL_ERROR">
2686 The endpoint encountered an unexpected internal error.
2688 <t hangText="FLOW_CONTROL_ERROR (0x3):" anchor="FLOW_CONTROL_ERROR">
2689 The endpoint detected that its peer violated the flow control protocol.
2691 <t hangText="SETTINGS_TIMEOUT (0x4):" anchor="SETTINGS_TIMEOUT">
2692 The endpoint sent a <x:ref>SETTINGS</x:ref> frame, but did not receive a response in a
2693 timely manner. See <xref target="SettingsSync">Settings Synchronization</xref>.
2695 <t hangText="STREAM_CLOSED (0x5):" anchor="STREAM_CLOSED">
2696 The endpoint received a frame after a stream was half closed.
2698 <t hangText="FRAME_SIZE_ERROR (0x6):" anchor="FRAME_SIZE_ERROR">
2699 The endpoint received a frame with an invalid size.
2701 <t hangText="REFUSED_STREAM (0x7):" anchor="REFUSED_STREAM">
2702 The endpoint refuses the stream prior to performing any application processing, see
2703 <xref target="Reliability"/> for details.
2705 <t hangText="CANCEL (0x8):" anchor="CANCEL">
2706 Used by the endpoint to indicate that the stream is no longer needed.
2708 <t hangText="COMPRESSION_ERROR (0x9):" anchor="COMPRESSION_ERROR">
2709 The endpoint is unable to maintain the header compression context for the connection.
2711 <t hangText="CONNECT_ERROR (0xa):" anchor="CONNECT_ERROR">
2712 The connection established in response to a <xref target="CONNECT">CONNECT
2713 request</xref> was reset or abnormally closed.
2715 <t hangText="ENHANCE_YOUR_CALM (0xb):" anchor="ENHANCE_YOUR_CALM">
2716 The endpoint detected that its peer is exhibiting a behavior that might be generating
2719 <t hangText="INADEQUATE_SECURITY (0xc):" anchor="INADEQUATE_SECURITY">
2720 The underlying transport has properties that do not meet minimum security
2721 requirements (see <xref target="TLSUsage"/>).
2726 Unknown or unsupported error codes MUST NOT trigger any special behavior. These MAY be
2727 treated by an implementation as being equivalent to <x:ref>INTERNAL_ERROR</x:ref>.
2731 <section anchor="HTTPLayer" title="HTTP Message Exchanges">
2733 HTTP/2 is intended to be as compatible as possible with current uses of HTTP. This means
2734 that, from the application perspective, the features of the protocol are largely
2735 unchanged. To achieve this, all request and response semantics are preserved, although the
2736 syntax of conveying those semantics has changed.
2739 Thus, the specification and requirements of HTTP/1.1 Semantics and Content <xref
2740 target="RFC7231"/>, Conditional Requests <xref target="RFC7232"/>, Range Requests <xref
2741 target="RFC7233"/>, Caching <xref target="RFC7234"/> and Authentication <xref
2742 target="RFC7235"/> are applicable to HTTP/2. Selected portions of HTTP/1.1 Message Syntax
2743 and Routing <xref target="RFC7230"/>, such as the HTTP and HTTPS URI schemes, are also
2744 applicable in HTTP/2, but the expression of those semantics for this protocol are defined
2745 in the sections below.
2748 <section anchor="HttpSequence" title="HTTP Request/Response Exchange">
2750 A client sends an HTTP request on a new stream, using a previously unused <xref
2751 target="StreamIdentifiers">stream identifier</xref>. A server sends an HTTP response on
2752 the same stream as the request.
2755 An HTTP message (request or response) consists of:
2756 <list style="numbers">
2758 for a response only, zero or more <x:ref>HEADERS</x:ref> frames (each followed by zero
2759 or more <x:ref>CONTINUATION</x:ref> frames) containing the message headers of
2760 informational (1xx) HTTP responses (see <xref target="RFC7230" x:fmt=","
2761 x:rel="#header.fields"/> and <xref target="RFC7231" x:fmt="," x:rel="#status.1xx"/>),
2765 one <x:ref>HEADERS</x:ref> frame (followed by zero or more <x:ref>CONTINUATION</x:ref>
2766 frames) containing the message headers (see <xref target="RFC7230" x:fmt=","
2767 x:rel="#header.fields"/>), and
2770 zero or more <x:ref>DATA</x:ref> frames containing the message payload (see <xref
2771 target="RFC7230" x:fmt="," x:rel="#message.body"/>), and
2774 optionally, one <x:ref>HEADERS</x:ref> frame, followed by zero or more
2775 <x:ref>CONTINUATION</x:ref> frames containing the trailer-part, if present (see <xref
2776 target="RFC7230" x:fmt="," x:rel="#chunked.trailer.part"/>).
2779 The last frame in the sequence bears an END_STREAM flag, noting that a
2780 <x:ref>HEADERS</x:ref> frame bearing the END_STREAM flag can be followed by
2781 <x:ref>CONTINUATION</x:ref> frames that carry any remaining portions of the header block.
2784 Other frames (from any stream) MUST NOT occur between either <x:ref>HEADERS</x:ref> frame
2785 and any <x:ref>CONTINUATION</x:ref> frames that might follow.
2789 Trailing header fields are carried in a header block that also terminates the stream.
2790 That is, a sequence starting with a <x:ref>HEADERS</x:ref> frame, followed by zero or more
2791 <x:ref>CONTINUATION</x:ref> frames, where the <x:ref>HEADERS</x:ref> frame bears an
2792 END_STREAM flag. Header blocks after the first that do not terminate the stream are not
2793 part of an HTTP request or response.
2796 A <x:ref>HEADERS</x:ref> frame (and associated <x:ref>CONTINUATION</x:ref> frames) can
2797 only appear at the start or end of a stream. An endpoint that receives a
2798 <x:ref>HEADERS</x:ref> frame without the END_STREAM flag set after receiving a final
2799 (non-informational) status code MUST treat the corresponding request or response as <xref
2800 target="malformed">malformed</xref>.
2804 An HTTP request/response exchange fully consumes a single stream. A request starts with
2805 the <x:ref>HEADERS</x:ref> frame that puts the stream into an "open" state. The request
2806 ends with a frame bearing END_STREAM, which causes the stream to become "half closed
2807 (local)" for the client and "half closed (remote)" for the server. A response starts with
2808 a <x:ref>HEADERS</x:ref> frame and ends with a frame bearing END_STREAM, which places the
2809 stream in the "closed" state.
2810 <!-- Yes, the response might be completed before the request does, but that's not a detail
2811 we need to expand upon. It's complicated enough explaining this as it is. -->
2814 <section anchor="informational-responses" title="Upgrading From HTTP/2">
2816 HTTP/2 removes support for the 101 (Switching Protocols) informational status code
2817 (<xref target="RFC7231" x:fmt="," x:rel="#status.101"/>).
2820 The semantics of 101 (Switching Protocols) aren't applicable to a multiplexed protocol.
2821 Alternative protocols are able to use the same mechanisms that HTTP/2 uses to negotiate
2822 their use (see <xref target="starting"/>).
2826 <section anchor="HttpHeaders" title="HTTP Header Fields">
2828 HTTP header fields carry information as a series of key-value pairs. For a listing of
2829 registered HTTP headers, see the Message Header Field Registry maintained at <eref
2830 target="https://www.iana.org/assignments/message-headers"/>.
2833 <section anchor="PseudoHeaderFields" title="Pseudo-Header Fields">
2835 While HTTP/1.x used the message start-line (see <xref target="RFC7230" x:fmt=","
2836 x:rel="#start.line"/>) to convey the target URI and method of the request, and the
2837 status code for the response, HTTP/2 uses special pseudo-header fields beginning with
2838 ':' character (ASCII 0x3a) for this purpose.
2841 Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT generate
2842 pseudo-header fields other than those defined in this document.
2845 Pseudo-header fields are only valid in the context in which they are defined.
2846 Pseudo-header fields defined for requests MUST NOT appear in responses; pseudo-header
2847 fields defined for responses MUST NOT appear in requests. Pseudo-header fields MUST
2848 NOT appear in trailers. Endpoints MUST treat a request or response that contains
2849 undefined or invalid pseudo-header fields as <xref
2850 target="malformed">malformed</xref>.
2853 Just as in HTTP/1.x, header field names are strings of ASCII characters that are
2854 compared in a case-insensitive fashion. However, header field names MUST be converted
2855 to lowercase prior to their encoding in HTTP/2. A request or response containing
2856 uppercase header field names MUST be treated as <xref
2857 target="malformed">malformed</xref>.
2860 All pseudo-header fields MUST appear in the header block before regular header fields.
2861 Any request or response that contains a pseudo-header field that appears in a header
2862 block after a regular header field MUST be treated as <xref
2863 target="malformed">malformed</xref>.
2867 <section title="Connection-Specific Header Fields">
2869 HTTP/2 does not use the <spanx style="verb">Connection</spanx> header field to
2870 indicate connection-specific header fields; in this protocol, connection-specific
2871 metadata is conveyed by other means. An endpoint MUST NOT generate a HTTP/2 message
2872 containing connection-specific header fields; any message containing
2873 connection-specific header fields MUST be treated as <xref
2874 target="malformed">malformed</xref>.
2877 This means that an intermediary transforming an HTTP/1.x message to HTTP/2 will need
2878 to remove any header fields nominated by the Connection header field, along with the
2879 Connection header field itself. Such intermediaries SHOULD also remove other
2880 connection-specific header fields, such as Keep-Alive, Proxy-Connection,
2881 Transfer-Encoding and Upgrade, even if they are not nominated by Connection.
2884 One exception to this is the TE header field, which MAY be present in an HTTP/2
2885 request, but when it is MUST NOT contain any value other than "trailers".
2888 <list style="hanging">
2889 <t hangText="Note:">
2890 HTTP/2 purposefully does not support upgrade to another protocol. The handshake
2891 methods described in <xref target="starting"/> are believed sufficient to
2892 negotiate the use of alternative protocols.
2898 <section anchor="HttpRequest" title="Request Pseudo-Header Fields">
2900 The following pseudo-header fields are defined for HTTP/2 requests:
2901 <list style="symbols">
2904 The <spanx style="verb">:method</spanx> pseudo-header field includes the HTTP
2905 method (<xref target="RFC7231" x:fmt="," x:rel="#methods"/>).
2910 The <spanx style="verb">:scheme</spanx> pseudo-header field includes the scheme
2911 portion of the target URI (<xref target="RFC3986" x:fmt="," x:sec="3.1"/>).
2914 <spanx style="verb">:scheme</spanx> is not restricted to <spanx
2915 style="verb">http</spanx> and <spanx style="verb">https</spanx> schemed URIs. A
2916 proxy or gateway can translate requests for non-HTTP schemes, enabling the use
2917 of HTTP to interact with non-HTTP services.
2922 The <spanx style="verb">:authority</spanx> pseudo-header field includes the
2923 authority portion of the target URI (<xref target="RFC3986" x:fmt=","
2924 x:sec="3.2"/>). The authority MUST NOT include the deprecated <spanx
2925 style="verb">userinfo</spanx> subcomponent for <spanx style="verb">http</spanx>
2926 or <spanx style="verb">https</spanx> schemed URIs.
2929 To ensure that the HTTP/1.1 request line can be reproduced accurately, this
2930 pseudo-header field MUST be omitted when translating from an HTTP/1.1 request
2931 that has a request target in origin or asterisk form (see <xref
2932 target="RFC7230" x:fmt="," x:rel="#request-target"/>). Clients that generate
2933 HTTP/2 requests directly SHOULD use the <spanx>:authority</spanx> pseudo-header
2934 field instead of the <spanx style="verb">Host</spanx> header field. An
2935 intermediary that converts an HTTP/2 request to HTTP/1.1 MUST create a <spanx
2936 style="verb">Host</spanx> header field if one is not present in a request by
2937 copying the value of the <spanx style="verb">:authority</spanx> pseudo-header
2943 The <spanx style="verb">:path</spanx> pseudo-header field includes the path and
2944 query parts of the target URI (the <spanx style="verb">path-absolute</spanx>
2945 production from <xref target="RFC3986"/> and optionally a '?' character
2946 followed by the <spanx style="verb">query</spanx> production, see <xref
2947 target="RFC3986" x:fmt="," x:sec="3.3"/> and <xref target="RFC3986" x:fmt=","
2948 x:sec="3.4"/>). A request in asterisk form includes the value '*' for the
2949 <spanx style="verb">:path</spanx> pseudo-header field.
2952 This pseudo-header field MUST NOT be empty for <spanx style="verb">http</spanx>
2953 or <spanx style="verb">https</spanx> URIs; <spanx style="verb">http</spanx> or
2954 <spanx style="verb">https</spanx> URIs that do not contain a path component
2955 MUST include a value of '/'. The exception to this rule is an OPTIONS request
2956 for an <spanx style="verb">http</spanx> or <spanx style="verb">https</spanx>
2957 URI that does not include a path component; these MUST include a <spanx
2958 style="verb">:path</spanx> pseudo-header field with a value of '*' (see <xref
2959 target="RFC7230" x:fmt="," x:rel="#asterisk-form"/>).
2965 All HTTP/2 requests MUST include exactly one valid value for the <spanx
2966 style="verb">:method</spanx>, <spanx style="verb">:scheme</spanx>, and <spanx
2967 style="verb">:path</spanx> pseudo-header fields, unless it is a <xref
2968 target="CONNECT">CONNECT request</xref>. An HTTP request that omits mandatory
2969 pseudo-header fields is <xref target="malformed">malformed</xref>.
2972 HTTP/2 does not define a way to carry the version identifier that is included in the
2973 HTTP/1.1 request line.
2977 <section anchor="HttpResponse" title="Response Pseudo-Header Fields">
2979 For HTTP/2 responses, a single <spanx style="verb">:status</spanx> pseudo-header
2980 field is defined that carries the HTTP status code field (see <xref target="RFC7231"
2981 x:fmt="," x:rel="#status.codes"/>). This pseudo-header field MUST be included in all
2982 responses, otherwise the response is <xref target="malformed">malformed</xref>.
2985 HTTP/2 does not define a way to carry the version or reason phrase that is included in
2986 an HTTP/1.1 status line.
2990 <section anchor="CompressCookie" title="Compressing the Cookie Header Field">
2992 The <xref target="COOKIE">Cookie header field</xref> can carry a significant amount of
2996 The Cookie header field uses a semi-colon (";") to delimit cookie-pairs (or "crumbs").
2997 This header field doesn't follow the list construction rules in HTTP (see <xref
2998 target="RFC7230" x:fmt="," x:rel="#field.order"/>), which prevents cookie-pairs from
2999 being separated into different name-value pairs. This can significantly reduce
3000 compression efficiency as individual cookie-pairs are updated.
3003 To allow for better compression efficiency, the Cookie header field MAY be split into
3004 separate header fields, each with one or more cookie-pairs. If there are multiple
3005 Cookie header fields after decompression, these MUST be concatenated into a single
3006 octet string using the two octet delimiter of 0x3B, 0x20 (the ASCII string "; ")
3007 before being passed into a non-HTTP/2 context, such as an HTTP/1.1 connection, or a
3008 generic HTTP server application.
3012 Therefore, the following two lists of Cookie header fields are semantically
3015 <artwork type="inline"><![CDATA[
3016 cookie: a=b; c=d; e=f
3025 <section anchor="malformed" title="Malformed Requests and Responses">
3027 A malformed request or response is one that is an otherwise valid sequence of HTTP/2
3028 frames, but is otherwise invalid due to the presence of extraneous frames, prohibited
3029 header fields, the absence of mandatory header fields, or the inclusion of uppercase
3033 A request or response that includes an entity body can include a <spanx
3034 style="verb">content-length</spanx> header field. A request or response is also
3035 malformed if the value of a <spanx style="verb">content-length</spanx> header field
3036 does not equal the sum of the <x:ref>DATA</x:ref> frame payload lengths that form the
3037 body. A response that is defined to have no payload, as described in <xref
3038 target="RFC7230" x:fmt="," x:rel="#header.content-length"/>, can have a non-zero
3039 <spanx style="verb">content-length</spanx> header field, even though no content is
3040 included in <x:ref>DATA</x:ref> frames.
3043 Intermediaries that process HTTP requests or responses (i.e., any intermediary not
3044 acting as a tunnel) MUST NOT forward a malformed request or response. Malformed
3045 requests or responses that are detected MUST be treated as a <xref
3046 target="StreamErrorHandler">stream error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
3049 For malformed requests, a server MAY send an HTTP response prior to closing or
3050 resetting the stream. Clients MUST NOT accept a malformed response. Note that these
3051 requirements are intended to protect against several types of common attacks against
3052 HTTP; they are deliberately strict, because being permissive can expose
3053 implementations to these vulnerabilities.
3058 <section title="Examples">
3060 This section shows HTTP/1.1 requests and responses, with illustrations of equivalent
3061 HTTP/2 requests and responses.
3064 An HTTP GET request includes request header fields and no body and is therefore
3065 transmitted as a single <x:ref>HEADERS</x:ref> frame, followed by zero or more
3066 <x:ref>CONTINUATION</x:ref> frames containing the serialized block of request header
3067 fields. The <x:ref>HEADERS</x:ref> frame in the following has both the END_HEADERS and
3068 END_STREAM flags set; no <x:ref>CONTINUATION</x:ref> frames are sent:
3072 <artwork type="inline"><![CDATA[
3073 GET /resource HTTP/1.1 HEADERS
3074 Host: example.org ==> + END_STREAM
3075 Accept: image/jpeg + END_HEADERS
3085 Similarly, a response that includes only response header fields is transmitted as a
3086 <x:ref>HEADERS</x:ref> frame (again, followed by zero or more
3087 <x:ref>CONTINUATION</x:ref> frames) containing the serialized block of response header
3092 <artwork type="inline"><![CDATA[
3093 HTTP/1.1 304 Not Modified HEADERS
3094 ETag: "xyzzy" ==> + END_STREAM
3095 Expires: Thu, 23 Jan ... + END_HEADERS
3098 expires = Thu, 23 Jan ...
3103 An HTTP POST request that includes request header fields and payload data is transmitted
3104 as one <x:ref>HEADERS</x:ref> frame, followed by zero or more
3105 <x:ref>CONTINUATION</x:ref> frames containing the request header fields, followed by one
3106 or more <x:ref>DATA</x:ref> frames, with the last <x:ref>CONTINUATION</x:ref> (or
3107 <x:ref>HEADERS</x:ref>) frame having the END_HEADERS flag set and the final
3108 <x:ref>DATA</x:ref> frame having the END_STREAM flag set:
3112 <artwork type="inline"><![CDATA[
3113 POST /resource HTTP/1.1 HEADERS
3114 Host: example.org ==> - END_STREAM
3115 Content-Type: image/jpeg - END_HEADERS
3116 Content-Length: 123 :method = POST
3118 {binary data} :scheme = https
3122 content-type = image/jpeg
3124 content-length = 123
3131 Note that data contributing to any given header field could be spread between header
3132 block fragments. The allocation of header fields to frames in this example is
3138 A response that includes header fields and payload data is transmitted as a
3139 <x:ref>HEADERS</x:ref> frame, followed by zero or more <x:ref>CONTINUATION</x:ref>
3140 frames, followed by one or more <x:ref>DATA</x:ref> frames, with the last
3141 <x:ref>DATA</x:ref> frame in the sequence having the END_STREAM flag set:
3145 <artwork type="inline"><![CDATA[
3146 HTTP/1.1 200 OK HEADERS
3147 Content-Type: image/jpeg ==> - END_STREAM
3148 Content-Length: 123 + END_HEADERS
3150 {binary data} content-type = image/jpeg
3151 content-length = 123
3160 Trailing header fields are sent as a header block after both the request or response
3161 header block and all the <x:ref>DATA</x:ref> frames have been sent. The
3162 <x:ref>HEADERS</x:ref> frame starting the trailers header block has the END_STREAM flag
3167 <artwork type="inline"><![CDATA[
3168 HTTP/1.1 200 OK HEADERS
3169 Content-Type: image/jpeg ==> - END_STREAM
3170 Transfer-Encoding: chunked + END_HEADERS
3171 Trailer: Foo :status = 200
3172 content-length = 123
3173 123 content-type = image/jpeg
3174 {binary data} trailer = Foo
3190 An informational response using a 1xx status code other than 101 is transmitted as a
3191 <x:ref>HEADERS</x:ref> frame, followed by zero or more <x:ref>CONTINUATION</x:ref>
3194 <artwork type="inline"><![CDATA[
3195 HTTP/1.1 103 BAR HEADERS
3196 Extension-Field: bar ==> - END_STREAM
3199 extension-field = bar
3204 <section anchor="Reliability" title="Request Reliability Mechanisms in HTTP/2">
3206 In HTTP/1.1, an HTTP client is unable to retry a non-idempotent request when an error
3207 occurs, because there is no means to determine the nature of the error. It is possible
3208 that some server processing occurred prior to the error, which could result in
3209 undesirable effects if the request were reattempted.
3212 HTTP/2 provides two mechanisms for providing a guarantee to a client that a request has
3214 <list style="symbols">
3216 The <x:ref>GOAWAY</x:ref> frame indicates the highest stream number that might have
3217 been processed. Requests on streams with higher numbers are therefore guaranteed to
3221 The <x:ref>REFUSED_STREAM</x:ref> error code can be included in a
3222 <x:ref>RST_STREAM</x:ref> frame to indicate that the stream is being closed prior to
3223 any processing having occurred. Any request that was sent on the reset stream can
3229 Requests that have not been processed have not failed; clients MAY automatically retry
3230 them, even those with non-idempotent methods.
3233 A server MUST NOT indicate that a stream has not been processed unless it can guarantee
3234 that fact. If frames that are on a stream are passed to the application layer for any
3235 stream, then <x:ref>REFUSED_STREAM</x:ref> MUST NOT be used for that stream, and a
3236 <x:ref>GOAWAY</x:ref> frame MUST include a stream identifier that is greater than or
3237 equal to the given stream identifier.
3240 In addition to these mechanisms, the <x:ref>PING</x:ref> frame provides a way for a
3241 client to easily test a connection. Connections that remain idle can become broken as
3242 some middleboxes (for instance, network address translators, or load balancers) silently
3243 discard connection bindings. The <x:ref>PING</x:ref> frame allows a client to safely
3244 test whether a connection is still active without sending a request.
3249 <section anchor="PushResources" title="Server Push">
3251 HTTP/2 allows a server to pre-emptively send (or "push") responses (along with
3252 corresponding "promised" requests) to a client in association with a previous
3253 client-initiated request. This can be useful when the server knows the client will need
3254 to have those responses available in order to fully process the response to the original
3259 Pushing additional message exchanges in this fashion is optional, and is negotiated
3260 between individual endpoints. The <x:ref>SETTINGS_ENABLE_PUSH</x:ref> setting can be set
3261 to 0 to indicate that server push is disabled.
3264 Promised requests MUST be cacheable (see <xref target="RFC7231" x:fmt=","
3265 x:rel="#cacheable.methods"/>), MUST be safe (see <xref target="RFC7231" x:fmt=","
3266 x:rel="#safe.methods"/>) and MUST NOT include a request body. Clients that receive a
3267 promised request that is not cacheable, unsafe or that includes a request body MUST
3268 reset the stream with a <xref target="StreamErrorHandler">stream error</xref> of type
3269 <x:ref>PROTOCOL_ERROR</x:ref>.
3272 Pushed responses that are cacheable (see <xref target="RFC7234" x:fmt=","
3273 x:rel="#response.cacheability"/>) can be stored by the client, if it implements a HTTP
3274 cache. Pushed responses are considered successfully validated on the origin server (e.g.,
3275 if the "no-cache" cache response directive <xref target="RFC7234" x:fmt=","
3276 x:rel="#cache-response-directive"/> is present) while the stream identified by the
3277 promised stream ID is still open.
3280 Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache. They MAY
3281 be made available to the application separately.
3284 An intermediary can receive pushes from the server and choose not to forward them on to
3285 the client. In other words, how to make use of the pushed information is up to that
3286 intermediary. Equally, the intermediary might choose to make additional pushes to the
3287 client, without any action taken by the server.
3290 A client cannot push. Thus, servers MUST treat the receipt of a
3291 <x:ref>PUSH_PROMISE</x:ref> frame as a <xref target="ConnectionErrorHandler">connection
3292 error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>. Clients MUST reject any attempt to
3293 change the <x:ref>SETTINGS_ENABLE_PUSH</x:ref> setting to a value other than 0 by treating
3294 the message as a <xref target="ConnectionErrorHandler">connection error</xref> of type
3295 <x:ref>PROTOCOL_ERROR</x:ref>.
3298 <section anchor="PushRequests" title="Push Requests">
3300 Server push is semantically equivalent to a server responding to a request; however, in
3301 this case that request is also sent by the server, as a <x:ref>PUSH_PROMISE</x:ref>
3305 The <x:ref>PUSH_PROMISE</x:ref> frame includes a header block that contains a complete
3306 set of request header fields that the server attributes to the request. It is not
3307 possible to push a response to a request that includes a request body.
3311 Pushed responses are always associated with an explicit request from the client. The
3312 <x:ref>PUSH_PROMISE</x:ref> frames sent by the server are sent on that explicit
3313 request's stream. The <x:ref>PUSH_PROMISE</x:ref> frame also includes a promised stream
3314 identifier, chosen from the stream identifiers available to the server (see <xref
3315 target="StreamIdentifiers"/>).
3319 The header fields in <x:ref>PUSH_PROMISE</x:ref> and any subsequent
3320 <x:ref>CONTINUATION</x:ref> frames MUST be a valid and complete set of <xref
3321 target="HttpRequest">request header fields</xref>. The server MUST include a method in
3322 the <spanx style="verb">:method</spanx> header field that is safe and cacheable. If a
3323 client receives a <x:ref>PUSH_PROMISE</x:ref> that does not include a complete and valid
3324 set of header fields, or the <spanx style="verb">:method</spanx> header field identifies
3325 a method that is not safe, it MUST respond with a <xref
3326 target="StreamErrorHandler">stream error</xref> of type <x:ref>PROTOCOL_ERROR</x:ref>.
3330 The server SHOULD send <x:ref>PUSH_PROMISE</x:ref> (<xref target="PUSH_PROMISE"/>)
3331 frames prior to sending any frames that reference the promised responses. This avoids a
3332 race where clients issue requests prior to receiving any <x:ref>PUSH_PROMISE</x:ref>
3336 For example, if the server receives a request for a document containing embedded links
3337 to multiple image files, and the server chooses to push those additional images to the
3338 client, sending push promises before the <x:ref>DATA</x:ref> frames that contain the
3339 image links ensures that the client is able to see the promises before discovering
3340 embedded links. Similarly, if the server pushes responses referenced by the header block
3341 (for instance, in Link header fields), sending the push promises before sending the
3342 header block ensures that clients do not request them.
3346 <x:ref>PUSH_PROMISE</x:ref> frames MUST NOT be sent by the client.
3349 <x:ref>PUSH_PROMISE</x:ref> frames can be sent by the server in response to any
3350 client-initiated stream, but the stream MUST be in either the "open" or "half closed
3351 (remote)" state with respect to the server. <x:ref>PUSH_PROMISE</x:ref> frames are
3352 interspersed with the frames that comprise a response, though they cannot be
3353 interspersed with <x:ref>HEADERS</x:ref> and <x:ref>CONTINUATION</x:ref> frames that
3354 comprise a single header block.
3357 Sending a <x:ref>PUSH_PROMISE</x:ref> frame creates a new stream and puts the stream
3358 into the “reserved (local)” state for the server and the “reserved (remote)” state for
3363 <section anchor="PushResponses" title="Push Responses">
3365 After sending the <x:ref>PUSH_PROMISE</x:ref> frame, the server can begin delivering the
3366 pushed response as a <xref target="HttpResponse">response</xref> on a server-initiated
3367 stream that uses the promised stream identifier. The server uses this stream to
3368 transmit an HTTP response, using the same sequence of frames as defined in <xref
3369 target="HttpSequence"/>. This stream becomes <xref target="StreamStates">"half closed"
3370 to the client</xref> after the initial <x:ref>HEADERS</x:ref> frame is sent.
3374 Once a client receives a <x:ref>PUSH_PROMISE</x:ref> frame and chooses to accept the
3375 pushed response, the client SHOULD NOT issue any requests for the promised response
3376 until after the promised stream has closed.
3380 If the client determines, for any reason, that it does not wish to receive the pushed
3381 response from the server, or if the server takes too long to begin sending the promised
3382 response, the client can send an <x:ref>RST_STREAM</x:ref> frame, using either the
3383 <x:ref>CANCEL</x:ref> or <x:ref>REFUSED_STREAM</x:ref> codes, and referencing the pushed
3384 stream's identifier.
3387 A client can use the <x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> setting to limit the
3388 number of responses that can be concurrently pushed by a server. Advertising a
3389 <x:ref>SETTINGS_MAX_CONCURRENT_STREAMS</x:ref> value of zero disables server push by
3390 preventing the server from creating the necessary streams. This does not prohibit a
3391 server from sending <x:ref>PUSH_PROMISE</x:ref> frames; clients need to reset any
3392 promised streams that are not wanted.
3396 Clients receiving a pushed response MUST validate that either the server is
3397 authoritative (see <xref target="authority"/>), or the proxy that provided the pushed
3398 response is configured for the corresponding request. For example, a server that offers
3399 a certificate for only the <spanx style="verb">example.com</spanx> DNS-ID or Common Name
3400 is not permitted to push a response for <spanx
3401 style="verb">https://www.example.org/doc</spanx>.
3404 The response for a <x:ref>PUSH_PROMISE</x:ref> stream begins with a
3405 <x:ref>HEADERS</x:ref> frame, which immediately puts the stream into the “half closed
3406 (remote)” state for the server and “half closed (local)” state for the client, and ends
3407 with a frame bearing END_STREAM, which places the stream in the "closed" state.
3408 <list style="hanging">
3409 <t hangText="Note:">
3410 The client never sends a frame with the END_STREAM flag for a server push.
3418 <section anchor="CONNECT" title="The CONNECT Method">
3420 In HTTP/1.x, the pseudo-method CONNECT (<xref target="RFC7231" x:fmt=","
3421 x:rel="#CONNECT"/>) is used to convert an HTTP connection into a tunnel to a remote host.
3422 CONNECT is primarily used with HTTP proxies to establish a TLS session with an origin
3423 server for the purposes of interacting with <spanx style="verb">https</spanx> resources.
3426 In HTTP/2, the CONNECT method is used to establish a tunnel over a single HTTP/2 stream to
3427 a remote host, for similar purposes. The HTTP header field mapping works as defined in
3428 <xref target="HttpRequest">Request Header Fields</xref>, with a few
3429 differences. Specifically:
3430 <list style="symbols">
3432 The <spanx style="verb">:method</spanx> header field is set to <spanx
3433 style="verb">CONNECT</spanx>.
3436 The <spanx style="verb">:scheme</spanx> and <spanx style="verb">:path</spanx> header
3437 fields MUST be omitted.
3440 The <spanx style="verb">:authority</spanx> header field contains the host and port to
3441 connect to (equivalent to the authority-form of the request-target of CONNECT
3442 requests, see <xref target="RFC7230" x:fmt="," x:rel="#request-target"/>).
3447 A proxy that supports CONNECT establishes a <xref target="TCP">TCP connection</xref> to
3448 the server identified in the <spanx style="verb">:authority</spanx> header field. Once
3449 this connection is successfully established, the proxy sends a <x:ref>HEADERS</x:ref>
3450 frame containing a 2xx series status code to the client, as defined in <xref
3451 target="RFC7231" x:fmt="," x:rel="#CONNECT"/>.
3454 After the initial <x:ref>HEADERS</x:ref> frame sent by each peer, all subsequent
3455 <x:ref>DATA</x:ref> frames correspond to data sent on the TCP connection. The payload of
3456 any <x:ref>DATA</x:ref> frames sent by the client is transmitted by the proxy to the TCP
3457 server; data received from the TCP server is assembled into <x:ref>DATA</x:ref> frames by
3458 the proxy. Frame types other than <x:ref>DATA</x:ref> or stream management frames
3459 (<x:ref>RST_STREAM</x:ref>, <x:ref>WINDOW_UPDATE</x:ref>, and <x:ref>PRIORITY</x:ref>)
3460 MUST NOT be sent on a connected stream, and MUST be treated as a <xref
3461 target="StreamErrorHandler">stream error</xref> if received.
3464 The TCP connection can be closed by either peer. The END_STREAM flag on a
3465 <x:ref>DATA</x:ref> frame is treated as being equivalent to the TCP FIN bit. A client is
3466 expected to send a <x:ref>DATA</x:ref> frame with the END_STREAM flag set after receiving
3467 a frame bearing the END_STREAM flag. A proxy that receives a <x:ref>DATA</x:ref> frame
3468 with the END_STREAM flag set sends the attached data with the FIN bit set on the last TCP
3469 segment. A proxy that receives a TCP segment with the FIN bit set sends a
3470 <x:ref>DATA</x:ref> frame with the END_STREAM flag set. Note that the final TCP segment
3471 or <x:ref>DATA</x:ref> frame could be empty.
3474 A TCP connection error is signaled with <x:ref>RST_STREAM</x:ref>. A proxy treats any
3475 error in the TCP connection, which includes receiving a TCP segment with the RST bit set,
3476 as a <xref target="StreamErrorHandler">stream error</xref> of type
3477 <x:ref>CONNECT_ERROR</x:ref>. Correspondingly, a proxy MUST send a TCP segment with the
3478 RST bit set if it detects an error with the stream or the HTTP/2 connection.
3483 <section anchor="HttpExtra" title="Additional HTTP Requirements/Considerations">
3485 This section outlines attributes of the HTTP protocol that improve interoperability, reduce
3486 exposure to known security vulnerabilities, or reduce the potential for implementation
3490 <section title="Connection Management">
3492 HTTP/2 connections are persistent. For best performance, it is expected clients will not
3493 close connections until it is determined that no further communication with a server is
3494 necessary (for example, when a user navigates away from a particular web page), or until
3495 the server closes the connection.
3498 Clients SHOULD NOT open more than one HTTP/2 connection to a given host and port pair,
3499 where host is derived from a URI, a selected <xref target="ALT-SVC">alternative
3500 service</xref>, or a configured proxy.
3503 A client can create additional connections as replacements, either to replace connections
3504 that are near to exhausting the available <xref target="StreamIdentifiers">stream
3505 identifier space</xref>, to refresh the keying material for a TLS connection, or to
3506 replace connections that have encountered <xref
3507 target="ConnectionErrorHandler">errors</xref>.
3510 A client MAY open multiple connections to the same IP address and TCP port using different
3511 <xref target="TLS-EXT">Server Name Indication</xref> values or to provide different TLS
3512 client certificates, but SHOULD avoid creating multiple connections with the same
3516 Servers are encouraged to maintain open connections for as long as possible, but are
3517 permitted to terminate idle connections if necessary. When either endpoint chooses to
3518 close the transport-layer TCP connection, the terminating endpoint SHOULD first send a
3519 <x:ref>GOAWAY</x:ref> (<xref target="GOAWAY"/>) frame so that both endpoints can reliably
3520 determine whether previously sent frames have been processed and gracefully complete or
3521 terminate any necessary remaining tasks.
3524 <section anchor="reuse" title="Connection Reuse">
3526 Connections that are made to an origin servers, either directly or through a tunnel
3527 created using the <xref target="CONNECT">CONNECT method</xref> MAY be reused for
3528 requests with multiple different URI authority components. A connection can be reused
3529 as long as the origin server is <xref target="authority">authoritative</xref>. For
3530 <spanx style="verb">http</spanx> resources, this depends on the host having resolved to
3531 the same IP address.
3534 For <spanx style="verb">https</spanx> resources, connection reuse additionally depends
3535 on having a certificate that is valid for the host in the URI. An origin server might
3536 offer a certificate with multiple <spanx style="verb">subjectAltName</spanx> attributes,
3537 or names with wildcards, one of which is valid for the authority in the URI. For
3538 example, a certificate with a <spanx style="verb">subjectAltName</spanx> of <spanx
3539 style="verb">*.example.com</spanx> might permit the use of the same connection for
3540 requests to URIs starting with <spanx style="verb">https://a.example.com/</spanx> and
3541 <spanx style="verb">https://b.example.com/</spanx>.
3544 In some deployments, reusing a connection for multiple origins can result in requests
3545 being directed to the wrong origin server. For example, TLS termination might be
3546 performed by a middlebox that uses the TLS <xref target="TLS-EXT">Server Name Indication
3547 (SNI)</xref> extension to select an origin server. This means that it is possible
3548 for clients to send confidential information to servers that might not be the intended
3549 target for the request, even though the server is otherwise authoritative.
3552 A server that does not wish clients to reuse connections can indicate that it is not
3553 authoritative for a request by sending a 421 (Misdirected Request) status code in response
3554 to the request (see <xref target="MisdirectedRequest"/>).
3557 A client that is configured to use a proxy over HTTP/2 directs requests to that proxy
3558 through a single connection. That is, all requests sent via a proxy reuse the
3559 connection to the proxy.
3563 <section anchor="MisdirectedRequest" title="The 421 (Misdirected Request) Status Code">
3565 The 421 (Misdirected Request) status code indicates that the request was directed at a
3566 server that is not able to produce a response. This can be sent by a server that is not
3567 configured to produce responses for the combination of scheme and authority that are
3568 included in the request URI.
3571 Clients receiving a 421 (Misdirected Request) response from a server MAY retry the
3572 request - whether the request method is idempotent or not - over a different connection.
3573 This is possible if a connection is reused (<xref target="reuse"/>) or if an alternative
3574 service is selected (<xref target="ALT-SVC"/>).
3577 This status code MUST NOT be generated by proxies.
3580 A 421 response is cacheable by default; i.e., unless otherwise indicated by the method
3581 definition or explicit cache controls (see <xref target="RFC7234"
3582 x:rel="#heuristic.freshness" x:fmt="of"/>).
3587 <section title="Use of TLS Features" anchor="TLSUsage">
3589 Implementations of HTTP/2 MUST support <xref target="TLS12">TLS 1.2</xref> for HTTP/2 over
3590 TLS. The general TLS usage guidance in <xref target="TLSBCP"/> SHOULD be followed, with
3591 some additional restrictions that are specific to HTTP/2.
3595 An implementation of HTTP/2 over TLS MUST use TLS 1.2 or higher with the restrictions on
3596 feature set and cipher suite described in this section. Due to implementation
3597 limitations, it might not be possible to fail TLS negotiation. An endpoint MUST
3598 immediately terminate an HTTP/2 connection that does not meet these minimum requirements
3599 with a <xref target="ConnectionErrorHandler">connection error</xref> of type
3600 <x:ref>INADEQUATE_SECURITY</x:ref>.
3603 <section anchor="TLSFeatures" title="TLS Features">
3605 The TLS implementation MUST support the <xref target="TLS-EXT">Server Name Indication
3606 (SNI)</xref> extension to TLS. HTTP/2 clients MUST indicate the target domain name when
3610 The TLS implementation MUST disable compression. TLS compression can lead to the
3611 exposure of information that would not otherwise be revealed <xref target="RFC3749"/>.
3612 Generic compression is unnecessary since HTTP/2 provides compression features that are
3613 more aware of context and therefore likely to be more appropriate for use for
3614 performance, security or other reasons.
3617 The TLS implementation MUST disable renegotiation. An endpoint MUST treat a TLS
3618 renegotiation as a <xref target="ConnectionErrorHandler">connection error</xref> of type
3619 <x:ref>PROTOCOL_ERROR</x:ref>. Note that disabling renegotiation can result in
3620 long-lived connections becoming unusable due to limits on the number of messages the
3621 underlying cipher suite can encipher.
3624 A client MAY use renegotiation to provide confidentiality protection for client
3625 credentials offered in the handshake, but any renegotiation MUST occur prior to sending
3626 the connection preface. A server SHOULD request a client certificate if it sees a
3627 renegotiation request immediately after establishing a connection.
3630 This effectively prevents the use of renegotiation in response to a request for a
3631 specific protected resource. A future specification might provide a way to support this
3632 use case. <!-- <cref> We are tracking this in a non-blocking fashion in issue #496 and
3633 with a new draft. -->
3637 <section title="TLS Cipher Suites">
3639 The set of TLS cipher suites that are permitted in HTTP/2 is restricted. HTTP/2 MUST
3640 only be used with cipher suites that have ephemeral key exchange, such as the <xref
3641 target="TLS12">ephemeral Diffie-Hellman (DHE)</xref> or the <xref
3642 target="RFC4492">elliptic curve variant (ECDHE)</xref>. Ephemeral key exchange MUST
3643 have a minimum size of 2048 bits for DHE or security level of 128 bits for ECDHE.
3644 Clients MUST accept DHE sizes of up to 4096 bits. HTTP MUST NOT be used with cipher
3645 suites that use stream or block ciphers. Authenticated Encryption with Additional Data
3646 (AEAD) modes, such as the <xref target="RFC5288">Galois Counter Model (GCM) mode for
3647 AES</xref> are acceptable.
3650 The effect of these restrictions is that TLS 1.2 implementations could have
3651 non-intersecting sets of available cipher suites, since these prevent the use of the
3652 cipher suite that TLS 1.2 makes mandatory. To avoid this problem, implementations of
3653 HTTP/2 that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 <xref
3654 target="TLS-ECDHE"/> with P256 <xref target="FIPS186"/>.
3657 Clients MAY advertise support of cipher suites that are prohibited by the above
3658 restrictions in order to allow for connection to servers that do not support HTTP/2.
3659 This enables a fallback to protocols without these constraints without the additional
3660 latency imposed by using a separate connection for fallback.
3666 <section anchor="security" title="Security Considerations">
3667 <section title="Server Authority" anchor="authority">
3669 HTTP/2 relies on the HTTP/1.1 definition of authority for determining whether a server is
3670 authoritative in providing a given response, see <xref target="RFC7230" x:fmt=","
3671 x:rel="#establishing.authority"/>. This relies on local name resolution for the "http"
3672 URI scheme, and the authenticated server identity for the "https" scheme (see <xref
3673 target="RFC2818" x:fmt="," x:sec="3"/>).
3677 <section title="Cross-Protocol Attacks">
3679 In a cross-protocol attack, an attacker causes a client to initiate a transaction in one
3680 protocol toward a server that understands a different protocol. An attacker might be able
3681 to cause the transaction to appear as valid transaction in the second protocol. In
3682 combination with the capabilities of the web context, this can be used to interact with
3683 poorly protected servers in private networks.
3686 Completing a TLS handshake with an ALPN identifier for HTTP/2 can be considered sufficient
3687 protection against cross protocol attacks. ALPN provides a positive indication that a
3688 server is willing to proceed with HTTP/2, which prevents attacks on other TLS-based
3692 The encryption in TLS makes it difficult for attackers to control the data which could be
3693 used in a cross-protocol attack on a cleartext protocol.
3696 The cleartext version of HTTP/2 has minimal protection against cross-protocol attacks.
3697 The <xref target="ConnectionHeader">connection preface</xref> contains a string that is
3698 designed to confuse HTTP/1.1 servers, but no special protection is offered for other
3699 protocols. A server that is willing to ignore parts of an HTTP/1.1 request containing an
3700 Upgrade header field in addition to the client connection preface could be exposed to a
3701 cross-protocol attack.
3705 <section title="Intermediary Encapsulation Attacks">
3707 HTTP/2 header field names and values are encoded as sequences of octets with a length
3708 prefix. This enables HTTP/2 to carry any string of octets as the name or value of a
3709 header field. An intermediary that translates HTTP/2 requests or responses into HTTP/1.1
3710 directly could permit the creation of corrupted HTTP/1.1 messages. An attacker might
3711 exploit this behavior to cause the intermediary to create HTTP/1.1 messages with illegal
3712 header fields, extra header fields, or even new messages that are entirely falsified.
3715 Header field names or values that contain characters not permitted by HTTP/1.1, including
3716 carriage return (ASCII 0xd) or line feed (ASCII 0xa) MUST NOT be translated verbatim by an
3717 intermediary, as stipulated in <xref target="RFC7230" x:rel="#field.parsing" x:fmt=","/>.
3720 Translation from HTTP/1.x to HTTP/2 does not produce the same opportunity to an attacker.
3721 Intermediaries that perform translation to HTTP/2 MUST remove any instances of the <spanx
3722 style="verb">obs-fold</spanx> production from header field values.
3726 <section title="Cacheability of Pushed Responses">
3728 Pushed responses do not have an explicit request from the client; the request
3729 is provided by the server in the <x:ref>PUSH_PROMISE</x:ref> frame.
3732 Caching responses that are pushed is possible based on the guidance provided by the origin
3733 server in the Cache-Control header field. However, this can cause issues if a single
3734 server hosts more than one tenant. For example, a server might offer multiple users each
3735 a small portion of its URI space.
3738 Where multiple tenants share space on the same server, that server MUST ensure that
3739 tenants are not able to push representations of resources that they do not have authority
3740 over. Failure to enforce this would allow a tenant to provide a representation that would
3741 be served out of cache, overriding the actual representation that the authoritative tenant
3745 Pushed responses for which an origin server is not authoritative (see
3746 <xref target="authority"/>) are never cached or used.
3750 <section anchor="dos" title="Denial of Service Considerations">
3752 An HTTP/2 connection can demand a greater commitment of resources to operate than a
3753 HTTP/1.1 connection. The use of header compression and flow control depend on a
3754 commitment of resources for storing a greater amount of state. Settings for these
3755 features ensure that memory commitments for these features are strictly bounded.
3758 The number of <x:ref>PUSH_PROMISE</x:ref> frames is not constrained in the same fashion.
3759 A client that accepts server push SHOULD limit the number of streams it allows to be in
3760 the "reserved (remote)" state. Excessive number of server push streams can be treated as
3761 a <xref target="StreamErrorHandler">stream error</xref> of type
3762 <x:ref>ENHANCE_YOUR_CALM</x:ref>.
3765 Processing capacity cannot be guarded as effectively as state capacity.
3768 The <x:ref>SETTINGS</x:ref> frame can be abused to cause a peer to expend additional
3769 processing time. This might be done by pointlessly changing SETTINGS parameters, setting
3770 multiple undefined parameters, or changing the same setting multiple times in the same
3771 frame. <x:ref>WINDOW_UPDATE</x:ref> or <x:ref>PRIORITY</x:ref> frames can be abused to
3772 cause an unnecessary waste of resources.
3775 Large numbers of small or empty frames can be abused to cause a peer to expend time
3776 processing frame headers. Note however that some uses are entirely legitimate, such as
3777 the sending of an empty <x:ref>DATA</x:ref> frame to end a stream.
3780 Header compression also offers some opportunities to waste processing resources; see <xref
3781 target="COMPRESSION" x:fmt="of" x:rel="#Security"/> for more details on potential abuses.
3784 Limits in <x:ref>SETTINGS</x:ref> parameters cannot be reduced instantaneously, which
3785 leaves an endpoint exposed to behavior from a peer that could exceed the new limits. In
3786 particular, immediately after establishing a connection, limits set by a server are not
3787 known to clients and could be exceeded without being an obvious protocol violation.
3790 All these features - i.e., <x:ref>SETTINGS</x:ref> changes, small frames, header
3791 compression - have legitimate uses. These features become a burden only when they are
3792 used unnecessarily or to excess.
3795 An endpoint that doesn't monitor this behavior exposes itself to a risk of denial of
3796 service attack. Implementations SHOULD track the use of these features and set limits on
3797 their use. An endpoint MAY treat activity that is suspicious as a <xref
3798 target="ConnectionErrorHandler">connection error</xref> of type
3799 <x:ref>ENHANCE_YOUR_CALM</x:ref>.
3802 <section anchor="MaxHeaderBlock" title="Limits on Header Block Size">
3804 A large <xref target="HeaderBlock">header block</xref> can cause an implementation to
3805 commit a large amount of state. Header fields that are critical for routing can appear
3806 toward the end of a header block, which prevents streaming of header fields to their
3807 ultimate destination. For this an other reasons, such as ensuring cache correctness,
3808 means that an endpoint might need to buffer the entire header block. Since there is no
3809 hard limit to the size of a header block, some endpoints could be forced commit a large
3810 amount of available memory for header fields.
3813 An endpoint can use the <x:ref>SETTINGS_MAX_HEADER_LIST_SIZE</x:ref> to advise peers of
3814 limits that might apply on the size of header blocks. This setting is only advisory, so
3815 endpoints MAY choose to send header blocks that exceed this limit and risk having the
3816 request or response being treated as malformed. This setting specific to a connection,
3817 so any request or response could encounter a hop with a lower, unknown limit. An
3818 intermediary can attempt to avoid this problem by passing on values presented by
3819 different peers, but they are not obligated to do so.
3822 A server that receives a larger header block than it is willing to handle can send an
3823 HTTP 431 (Request Header Fields Too Large) status code <xref target="RFC6585"/>. A
3824 client can discard responses that it cannot process. The header block MUST be processed
3825 to ensure a consistent connection state, unless the connection is closed.
3830 <section title="Use of Compression">
3832 HTTP/2 enables greater use of compression for both header fields (<xref
3833 target="HeaderBlock"/>) and entity bodies. Compression can allow an attacker to recover
3834 secret data when it is compressed in the same context as data under attacker control.
3837 There are demonstrable attacks on compression that exploit the characteristics of the web
3838 (e.g., <xref target="BREACH"/>). The attacker induces multiple requests containing
3839 varying plaintext, observing the length of the resulting ciphertext in each, which
3840 reveals a shorter length when a guess about the secret is correct.
3843 Implementations communicating on a secure channel MUST NOT compress content that includes
3844 both confidential and attacker-controlled data unless separate compression dictionaries
3845 are used for each source of data. Compression MUST NOT be used if the source of data
3846 cannot be reliably determined. Generic stream compression, such as that provided by TLS
3847 MUST NOT be used with HTTP/2 (<xref target="TLSFeatures"/>).
3850 Further considerations regarding the compression of header fields are described in <xref
3851 target="COMPRESSION"/>.
3855 <section title="Use of Padding" anchor="padding">
3857 Padding within HTTP/2 is not intended as a replacement for general purpose padding, such
3858 as might be provided by <xref target="TLS12">TLS</xref>. Redundant padding could even be
3859 counterproductive. Correct application can depend on having specific knowledge of the
3860 data that is being padded.
3863 To mitigate attacks that rely on compression, disabling or limiting compression might be
3864 preferable to padding as a countermeasure.
3867 Padding can be used to obscure the exact size of frame content, and is provided to
3868 mitigate specific attacks within HTTP. For example, attacks where compressed content
3869 includes both attacker-controlled plaintext and secret data (see for example, <xref
3873 Use of padding can result in less protection than might seem immediately obvious. At
3874 best, padding only makes it more difficult for an attacker to infer length information by
3875 increasing the number of frames an attacker has to observe. Incorrectly implemented
3876 padding schemes can be easily defeated. In particular, randomized padding with a
3877 predictable distribution provides very little protection; similarly, padding payloads to a
3878 fixed size exposes information as payload sizes cross the fixed size boundary, which could
3879 be possible if an attacker can control plaintext.
3882 Intermediaries SHOULD retain padding for <x:ref>DATA</x:ref> frames, but MAY drop padding
3883 for <x:ref>HEADERS</x:ref> and <x:ref>PUSH_PROMISE</x:ref> frames. A valid reason for an
3884 intermediary to change the amount of padding of frames is to improve the protections that
3889 <section title="Privacy Considerations">
3891 Several characteristics of HTTP/2 provide an observer an opportunity to correlate actions
3892 of a single client or server over time. This includes the value of settings, the manner
3893 in which flow control windows are managed, the way priorities are allocated to streams,
3894 timing of reactions to stimulus, and handling of any optional features.
3897 As far as this creates observable differences in behavior, they could be used as a basis
3898 for fingerprinting a specific client, as defined in <xref target="HTML5" x:fmt="of"
3899 x:sec="1.8" x:rel="introduction.html#fingerprint"/>.
3904 <section anchor="iana" title="IANA Considerations">
3906 A string for identifying HTTP/2 is entered into the "Application Layer Protocol Negotiation
3907 (ALPN) Protocol IDs" registry established in <xref target="TLS-ALPN"/>.
3910 This document establishes a registry for frame types, settings, and error codes. These new
3911 registries are entered into a new "Hypertext Transfer Protocol (HTTP) 2 Parameters" section.
3914 This document registers the <spanx style="verb">HTTP2-Settings</spanx> header field for
3915 use in HTTP; and the 421 (Misdirected Request) status code.
3918 This document registers the <spanx style="verb">PRI</spanx> method for use in HTTP, to avoid
3919 collisions with the <xref target="ConnectionHeader">connection preface</xref>.
3922 <section anchor="iana-alpn" title="Registration of HTTP/2 Identification Strings">
3924 This document creates two registrations for the identification of HTTP/2 in the
3925 "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established in <xref
3926 target="TLS-ALPN"/>.
3929 The "h2" string identifies HTTP/2 when used over TLS:
3930 <list style="hanging">
3931 <t hangText="Protocol:">HTTP/2 over TLS</t>
3932 <t hangText="Identification Sequence:">0x68 0x32 ("h2")</t>
3933 <t hangText="Specification:">This document</t>
3937 The "h2c" string identifies HTTP/2 when used over cleartext TCP:
3938 <list style="hanging">
3939 <t hangText="Protocol:">HTTP/2 over TCP</t>
3940 <t hangText="Identification Sequence:">0x68 0x32 0x63 ("h2c")</t>
3941 <t hangText="Specification:">This document</t>
3946 <section anchor="iana-frames" title="Frame Type Registry">
3948 This document establishes a registry for HTTP/2 frame type codes. The "HTTP/2 Frame
3949 Type" registry manages an 8-bit space. The "HTTP/2 Frame Type" registry operates under
3950 either of the <xref target="RFC5226">"IETF Review" or "IESG Approval" policies</xref> for
3951 values between 0x00 and 0xef, with values between 0xf0 and 0xff being reserved for
3955 New entries in this registry require the following information:
3956 <list style="hanging">
3957 <t hangText="Frame Type:">
3958 A name or label for the frame type.
3960 <t hangText="Code:">
3961 The 8-bit code assigned to the frame type.
3963 <t hangText="Specification:">
3964 A reference to a specification that includes a description of the frame layout,
3965 it's semantics and flags that the frame type uses, including any parts of the frame
3966 that are conditionally present based on the value of flags.
3971 The entries in the following table are registered by this document.
3973 <texttable align="left" suppress-title="true">
3974 <ttcol>Frame Type</ttcol>
3976 <ttcol>Section</ttcol>
3977 <c>DATA</c><c>0x0</c><c><xref target="DATA"/></c>
3978 <c>HEADERS</c><c>0x1</c><c><xref target="HEADERS"/></c>
3979 <c>PRIORITY</c><c>0x2</c><c><xref target="PRIORITY"/></c>
3980 <c>RST_STREAM</c><c>0x3</c><c><xref target="RST_STREAM"/></c>
3981 <c>SETTINGS</c><c>0x4</c><c><xref target="SETTINGS"/></c>
3982 <c>PUSH_PROMISE</c><c>0x5</c><c><xref target="PUSH_PROMISE"/></c>
3983 <c>PING</c><c>0x6</c><c><xref target="PING"/></c>
3984 <c>GOAWAY</c><c>0x7</c><c><xref target="GOAWAY"/></c>
3985 <c>WINDOW_UPDATE</c><c>0x8</c><c><xref target="WINDOW_UPDATE"/></c>
3986 <c>CONTINUATION</c><c>0x9</c><c><xref target="CONTINUATION"/></c>
3990 <section anchor="iana-settings" title="Settings Registry">
3992 This document establishes a registry for HTTP/2 settings. The "HTTP/2 Settings" registry
3993 manages a 16-bit space. The "HTTP/2 Settings" registry operates under the <xref
3994 target="RFC5226">"Expert Review" policy</xref> for values in the range from 0x0000 to
3995 0xefff, with values between and 0xf000 and 0xffff being reserved for experimental use.
3998 New registrations are advised to provide the following information:
3999 <list style="hanging">
4000 <t hangText="Name:">
4001 A symbolic name for the setting. Specifying a setting name is optional.
4003 <t hangText="Code:">
4004 The 16-bit code assigned to the setting.
4006 <t hangText="Initial Value:">
4007 An initial value for the setting.
4009 <t hangText="Specification:">
4010 An optional reference to a specification that describes the use of the setting.
4015 An initial set of setting registrations can be found in <xref target="SettingValues"/>.
4017 <texttable align="left" suppress-title="true">
4020 <ttcol>Initial Value</ttcol>
4021 <ttcol>Specification</ttcol>
4022 <c>HEADER_TABLE_SIZE</c>
4023 <c>0x1</c><c>4096</c><c><xref target="SettingValues"/></c>
4025 <c>0x2</c><c>1</c><c><xref target="SettingValues"/></c>
4026 <c>MAX_CONCURRENT_STREAMS</c>
4027 <c>0x3</c><c>(infinite)</c><c><xref target="SettingValues"/></c>
4028 <c>INITIAL_WINDOW_SIZE</c>
4029 <c>0x4</c><c>65535</c><c><xref target="SettingValues"/></c>
4030 <c>MAX_FRAME_SIZE</c>
4031 <c>0x5</c><c>16384</c><c><xref target="SettingValues"/></c>
4032 <c>MAX_HEADER_LIST_SIZE</c>
4033 <c>0x6</c><c>(infinite)</c><c><xref target="SettingValues"/></c>
4038 <section anchor="iana-errors" title="Error Code Registry">
4040 This document establishes a registry for HTTP/2 error codes. The "HTTP/2 Error Code"
4041 registry manages a 32-bit space. The "HTTP/2 Error Code" registry operates under the
4042 <xref target="RFC5226">"Expert Review" policy</xref>.
4045 Registrations for error codes are required to include a description of the error code. An
4046 expert reviewer is advised to examine new registrations for possible duplication with
4047 existing error codes. Use of existing registrations is to be encouraged, but not
4051 New registrations are advised to provide the following information:
4052 <list style="hanging">
4053 <t hangText="Name:">
4054 A name for the error code. Specifying an error code name is optional.
4056 <t hangText="Code:">
4057 The 32-bit error code value.
4059 <t hangText="Description:">
4060 A brief description of the error code semantics, longer if no detailed specification
4063 <t hangText="Specification:">
4064 An optional reference for a specification that defines the error code.
4069 The entries in the following table are registered by this document.
4071 <texttable align="left" suppress-title="true">
4074 <ttcol>Description</ttcol>
4075 <ttcol>Specification</ttcol>
4076 <c>NO_ERROR</c><c>0x0</c>
4077 <c>Graceful shutdown</c>
4078 <c><xref target="ErrorCodes"/></c>
4079 <c>PROTOCOL_ERROR</c><c>0x1</c>
4080 <c>Protocol error detected</c>
4081 <c><xref target="ErrorCodes"/></c>
4082 <c>INTERNAL_ERROR</c><c>0x2</c>
4083 <c>Implementation fault</c>
4084 <c><xref target="ErrorCodes"/></c>
4085 <c>FLOW_CONTROL_ERROR</c><c>0x3</c>
4086 <c>Flow control limits exceeded</c>
4087 <c><xref target="ErrorCodes"/></c>
4088 <c>SETTINGS_TIMEOUT</c><c>0x4</c>
4089 <c>Settings not acknowledged</c>
4090 <c><xref target="ErrorCodes"/></c>
4091 <c>STREAM_CLOSED</c><c>0x5</c>
4092 <c>Frame received for closed stream</c>
4093 <c><xref target="ErrorCodes"/></c>
4094 <c>FRAME_SIZE_ERROR</c><c>0x6</c>
4095 <c>Frame size incorrect</c>
4096 <c><xref target="ErrorCodes"/></c>
4097 <c>REFUSED_STREAM</c><c>0x7</c>
4098 <c>Stream not processed</c>
4099 <c><xref target="ErrorCodes"/></c>
4100 <c>CANCEL</c><c>0x8</c>
4101 <c>Stream cancelled</c>
4102 <c><xref target="ErrorCodes"/></c>
4103 <c>COMPRESSION_ERROR</c><c>0x9</c>
4104 <c>Compression state not updated</c>
4105 <c><xref target="ErrorCodes"/></c>
4106 <c>CONNECT_ERROR</c><c>0xa</c>
4107 <c>TCP connection error for CONNECT method</c>
4108 <c><xref target="ErrorCodes"/></c>
4109 <c>ENHANCE_YOUR_CALM</c><c>0xb</c>
4110 <c>Processing capacity exceeded</c>
4111 <c><xref target="ErrorCodes"/></c>
4112 <c>INADEQUATE_SECURITY</c><c>0xc</c>
4113 <c>Negotiated TLS parameters not acceptable</c>
4114 <c><xref target="ErrorCodes"/></c>
4119 <section title="HTTP2-Settings Header Field Registration">
4121 This section registers the <spanx style="verb">HTTP2-Settings</spanx> header field in the
4122 <xref target="BCP90">Permanent Message Header Field Registry</xref>.
4123 <list style="hanging">
4124 <t hangText="Header field name:">
4127 <t hangText="Applicable protocol:">
4130 <t hangText="Status:">
4133 <t hangText="Author/Change controller:">
4136 <t hangText="Specification document(s):">
4137 <xref target="Http2SettingsHeader"/> of this document
4139 <t hangText="Related information:">
4140 This header field is only used by an HTTP/2 client for Upgrade-based negotiation.
4146 <section title="PRI Method Registration">
4148 This section registers the <spanx style="verb">PRI</spanx> method in the HTTP Method
4149 Registry (<xref target="RFC7231" x:fmt="," x:rel="#method.registry"/>).
4150 <list style="hanging">
4151 <t hangText="Method Name:">
4157 <t hangText="Idempotent">
4160 <t hangText="Specification document(s)">
4161 <xref target="ConnectionHeader"/> of this document
4163 <t hangText="Related information:">
4164 This method is never used by an actual client. This method will appear to be used
4165 when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2 connection
4172 <section title="The 421 (Misdirected Request) HTTP Status Code"
4173 anchor="iana-MisdirectedRequest">
4175 This document registers the 421 (Misdirected Request) HTTP Status code in the Hypertext
4176 Transfer Protocol (HTTP) Status Code Registry (<xref target="RFC7231" x:fmt=","
4177 x:rel="#status.code.registry"/>).
4180 <list style="hanging">
4181 <t hangText="Status Code:">
4184 <t hangText="Short Description:">
4187 <t hangText="Specification:">
4188 <xref target="MisdirectedRequest"/> of this document
4196 <section title="Acknowledgements">
4198 This document includes substantial input from the following individuals:
4199 <list style="symbols">
4201 Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa Wilk, Costin
4202 Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam Barth, Ryan Hamilton, Gavin
4203 Peters, Kent Alstad, Kevin Lindsay, Paul Amer, Fan Yang, Jonathan Leighton (SPDY
4207 Gabriel Montenegro and Willy Tarreau (Upgrade mechanism).
4210 William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, Jitu Padhye, Roberto
4211 Peon, Rob Trace (Flow control).
4214 Mike Bishop (Extensibility).
4217 Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike Bishop, Herve Ruellan
4218 (Substantial editorial contributions).
4221 Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp.
4224 Alexey Melnikov was an editor of this document during 2013.
4227 A substantial proportion of Martin's contribution was supported by Microsoft during his
4236 <references title="Normative References">
4237 <reference anchor="COMPRESSION">
4239 <title>HPACK - Header Compression for HTTP/2</title>
4240 <author initials="H." surname="Ruellan" fullname="Herve Ruellan"/>
4241 <author initials="R." surname="Peon" fullname="Roberto Peon"/>
4242 <date month="July" year="2014" />
4244 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-header-compression-09" />
4245 <x:source href="refs/draft-ietf-httpbis-header-compression-09.xml"/>
4248 <reference anchor="TCP">
4250 <title abbrev="Transmission Control Protocol">
4251 Transmission Control Protocol
4253 <author initials="J." surname="Postel" fullname="Jon Postel">
4254 <organization>University of Southern California (USC)/Information Sciences
4255 Institute</organization>
4257 <date year="1981" month="September" />
4259 <seriesInfo name="STD" value="7" />
4260 <seriesInfo name="RFC" value="793" />
4263 <reference anchor="RFC2119">
4266 Key words for use in RFCs to Indicate Requirement Levels
4268 <author initials="S." surname="Bradner" fullname="Scott Bradner">
4269 <organization>Harvard University</organization>
4270 <address><email>sob@harvard.edu</email></address>
4272 <date month="March" year="1997"/>
4274 <seriesInfo name="BCP" value="14"/>
4275 <seriesInfo name="RFC" value="2119"/>
4278 <reference anchor="RFC2818">
4283 <author initials="E." surname="Rescorla" fullname="Eric Rescorla"/>
4284 <date month="May" year="2000"/>
4286 <seriesInfo name="RFC" value="2818"/>
4289 <reference anchor="RFC3986">
4291 <title abbrev="URI Generic Syntax">Uniform Resource Identifier (URI): Generic
4293 <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee"></author>
4294 <author initials="R." surname="Fielding" fullname="Roy T. Fielding"></author>
4295 <author initials="L." surname="Masinter" fullname="Larry Masinter"></author>
4296 <date year="2005" month="January" />
4298 <seriesInfo name="STD" value="66" />
4299 <seriesInfo name="RFC" value="3986" />
4302 <reference anchor="RFC4648">
4304 <title>The Base16, Base32, and Base64 Data Encodings</title>
4305 <author fullname="S. Josefsson" initials="S." surname="Josefsson"/>
4306 <date year="2006" month="October"/>
4308 <seriesInfo value="4648" name="RFC"/>
4311 <reference anchor="RFC5226">
4313 <title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
4314 <author initials="T." surname="Narten" fullname="T. Narten"/>
4315 <author initials="H." surname="Alvestrand" fullname="H. Alvestrand"/>
4316 <date year="2008" month="May" />
4318 <seriesInfo name="BCP" value="26" />
4319 <seriesInfo name="RFC" value="5226" />
4322 <reference anchor="RFC5234">
4324 <title>Augmented BNF for Syntax Specifications: ABNF</title>
4325 <author initials="D." surname="Crocker" fullname="D. Crocker"/>
4326 <author initials="P." surname="Overell" fullname="P. Overell"/>
4327 <date year="2008" month="January" />
4329 <seriesInfo name="STD" value="68" />
4330 <seriesInfo name="RFC" value="5234" />
4333 <reference anchor="TLS12">
4335 <title>The Transport Layer Security (TLS) Protocol Version 1.2</title>
4336 <author initials="T." surname="Dierks" fullname="Tim Dierks"/>
4337 <author initials="E." surname="Rescorla" fullname="Eric Rescorla"/>
4338 <date year="2008" month="August" />
4340 <seriesInfo name="RFC" value="5246" />
4343 <reference anchor="TLS-EXT">
4346 Transport Layer Security (TLS) Extensions: Extension Definitions
4348 <author initials="D." surname="Eastlake" fullname="D. Eastlake"/>
4349 <date year="2011" month="January"/>
4351 <seriesInfo name="RFC" value="6066"/>
4354 <reference anchor="TLS-ALPN">
4356 <title>Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension</title>
4357 <author initials="S." surname="Friedl" fullname="Stephan Friedl"></author>
4358 <author initials="A." surname="Popov" fullname="Andrei Popov"></author>
4359 <author initials="A." surname="Langley" fullname="Adam Langley"></author>
4360 <author initials="E." surname="Stephan" fullname="Emile Stephan"></author>
4361 <date month="July" year="2014" />
4363 <seriesInfo name="RFC" value="7301" />
4366 <reference anchor="TLS-ECDHE">
4369 TLS Elliptic Curve Cipher Suites with SHA-256/384 and AES Galois
4372 <author initials="E." surname="Rescorla" fullname="E. Rescorla"/>
4373 <date year="2008" month="August" />
4375 <seriesInfo name="RFC" value="5289" />
4378 <reference anchor="FIPS186">
4381 Digital Signature Standard (DSS)
4383 <author><organization>NIST</organization></author>
4384 <date year="2013" month="July" />
4386 <seriesInfo name="FIPS" value="PUB 186-4" />
4389 <reference anchor="RFC7230">
4392 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing</title>
4393 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
4394 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4395 <address><email>fielding@gbiv.com</email></address>
4397 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
4398 <organization abbrev="greenbytes">greenbytes GmbH</organization>
4399 <address><email>julian.reschke@greenbytes.de</email></address>
4401 <date month="June" year="2014" />
4403 <seriesInfo name="RFC" value="7230" />
4404 <x:source href="refs/rfc7230.xml"
4405 basename="https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7230"/>
4407 <reference anchor="RFC7231">
4410 Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</title>
4411 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
4412 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4413 <address><email>fielding@gbiv.com</email></address>
4415 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
4416 <organization abbrev="greenbytes">greenbytes GmbH</organization>
4417 <address><email>julian.reschke@greenbytes.de</email></address>
4419 <date month="June" year="2014" />
4421 <seriesInfo name="RFC" value="7231" />
4422 <x:source href="refs/rfc7231.xml"
4423 basename="https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7231"/>
4425 <reference anchor="RFC7232">
4427 <title>Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests</title>
4428 <author fullname="Roy T. Fielding" initials="R." role="editor" surname="Fielding">
4429 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4430 <address><email>fielding@gbiv.com</email></address>
4432 <author fullname="Julian F. Reschke" initials="J. F." role="editor" surname="Reschke">
4433 <organization abbrev="greenbytes">greenbytes GmbH</organization>
4434 <address><email>julian.reschke@greenbytes.de</email></address>
4436 <date month="June" year="2014" />
4438 <seriesInfo name="RFC" value="7232" />
4440 <reference anchor="RFC7233">
4442 <title>Hypertext Transfer Protocol (HTTP/1.1): Range Requests</title>
4443 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
4444 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4445 <address><email>fielding@gbiv.com</email></address>
4447 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">
4448 <organization abbrev="W3C">World Wide Web Consortium</organization>
4449 <address><email>ylafon@w3.org</email></address>
4451 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
4452 <organization abbrev="greenbytes">greenbytes GmbH</organization>
4453 <address><email>julian.reschke@greenbytes.de</email></address>
4455 <date month="June" year="2014" />
4457 <seriesInfo name="RFC" value="7233" />
4459 <reference anchor="RFC7234">
4461 <title>Hypertext Transfer Protocol (HTTP/1.1): Caching</title>
4462 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
4463 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4464 <address><email>fielding@gbiv.com</email></address>
4466 <author fullname="Mark Nottingham" initials="M." role="editor" surname="Nottingham">
4467 <organization>Akamai</organization>
4468 <address><email>mnot@mnot.net</email></address>
4470 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
4471 <organization abbrev="greenbytes">greenbytes GmbH</organization>
4472 <address><email>julian.reschke@greenbytes.de</email></address>
4474 <date month="June" year="2014" />
4476 <seriesInfo name="RFC" value="7234"/>
4477 <x:source href="refs/rfc7234.xml"
4478 basename="https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7234"/>
4480 <reference anchor="RFC7235">
4482 <title>Hypertext Transfer Protocol (HTTP/1.1): Authentication</title>
4483 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">
4484 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>
4485 <address><email>fielding@gbiv.com</email></address>
4487 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">
4488 <organization abbrev="greenbytes">greenbytes GmbH</organization>
4489 <address><email>julian.reschke@greenbytes.de</email></address>
4491 <date month="June" year="2014" />
4493 <seriesInfo name="RFC" value="7235"/>
4494 <x:source href="refs/rfc7235.xml"
4495 basename="https://svn.tools.ietf.org/svn/wg/httpbis/specs/rfc7235"/>
4498 <reference anchor="COOKIE">
4500 <title>HTTP State Management Mechanism</title>
4501 <author initials="A." surname="Barth" fullname="A. Barth"/>
4502 <date year="2011" month="April" />
4504 <seriesInfo name="RFC" value="6265" />
4508 <references title="Informative References">
4509 <reference anchor="RFC1323">
4512 TCP Extensions for High Performance
4514 <author initials="V." surname="Jacobson" fullname="Van Jacobson"></author>
4515 <author initials="B." surname="Braden" fullname="Bob Braden"></author>
4516 <author initials="D." surname="Borman" fullname="Dave Borman"></author>
4517 <date year="1992" month="May" />
4519 <seriesInfo name="RFC" value="1323" />
4522 <reference anchor="RFC3749">
4524 <title>Transport Layer Security Protocol Compression Methods</title>
4525 <author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck"/>
4526 <date year="2004" month="May" />
4528 <seriesInfo name="RFC" value="3749" />
4531 <reference anchor="RFC6585">
4533 <title>Additional HTTP Status Codes</title>
4534 <author initials="M." surname="Nottingham" fullname="Mark Nottingham"/>
4535 <author initials="R." surname="Fielding" fullname="Roy Fielding"/>
4536 <date year="2012" month="April" />
4538 <seriesInfo name="RFC" value="6585" />
4541 <reference anchor="RFC4492">
4544 Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer Security (TLS)
4546 <author initials="S." surname="Blake-Wilson" fullname="S. Blake-Wilson"/>
4547 <author initials="N." surname="Bolyard" fullname="N. Bolyard"/>
4548 <author initials="V." surname="Gupta" fullname="V. Gupta"/>
4549 <author initials="C." surname="Hawk" fullname="C. Hawk"/>
4550 <author initials="B." surname="Moeller" fullname="B. Moeller"/>
4551 <date year="2006" month="May" />
4553 <seriesInfo name="RFC" value="4492" />
4556 <reference anchor="RFC5288">
4559 AES Galois Counter Mode (GCM) Cipher Suites for TLS
4561 <author initials="J." surname="Salowey" fullname="J. Salowey"/>
4562 <author initials="A." surname="Choudhury" fullname="A. Choudhury"/>
4563 <author initials="D." surname="McGrew" fullname="D. McGrew"/>
4564 <date year="2008" month="August" />
4566 <seriesInfo name="RFC" value="5288" />
4569 <reference anchor='HTML5'
4570 target='http://www.w3.org/TR/2014/CR-html5-20140731/'>
4572 <title>HTML5</title>
4573 <author fullname='Robin Berjon' surname='Berjon' initials='R.'/>
4574 <author fullname='Steve Faulkner' surname='Faulkner' initials='S.'/>
4575 <author fullname='Travis Leithead' surname='Leithead' initials='T.'/>
4576 <author fullname='Erika Doyle Navara' surname='Doyle Navara' initials='E.'/>
4577 <author fullname='Edward O'Connor' surname='O'Connor' initials='E.'/>
4578 <author fullname='Silvia Pfeiffer' surname='Pfeiffer' initials='S.'/>
4579 <date year='2014' month='July' day='31'/>
4581 <seriesInfo name='W3C Candidate Recommendation' value='CR-html5-20140731'/>
4583 Latest version available at
4584 <eref target='http://www.w3.org/TR/html5/'/>.
4588 <reference anchor="TALKING" target="http://w2spconf.com/2011/papers/websocket.pdf">
4591 Talking to Yourself for Fun and Profit
4593 <author initials="L-S." surname="Huang"/>
4594 <author initials="E." surname="Chen"/>
4595 <author initials="A." surname="Barth"/>
4596 <author initials="E." surname="Rescorla"/>
4597 <author initials="C." surname="Jackson"/>
4598 <date year="2011" />
4602 <reference anchor="BREACH"
4603 target="http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf">
4606 BREACH: Reviving the CRIME Attack
4608 <author initials="Y." surname="Gluck"/>
4609 <author initials="N." surname="Harris"/>
4610 <author initials="A." surname="Prado"/>
4611 <date year="2013" month="July" day="12"/>
4615 <reference anchor="BCP90">
4617 <title>Registration Procedures for Message Header Fields</title>
4618 <author initials="G." surname="Klyne" fullname="G. Klyne">
4619 <organization>Nine by Nine</organization>
4620 <address><email>GK-IETF@ninebynine.org</email></address>
4622 <author initials="M." surname="Nottingham" fullname="M. Nottingham">
4623 <organization>BEA Systems</organization>
4624 <address><email>mnot@pobox.com</email></address>
4626 <author initials="J." surname="Mogul" fullname="J. Mogul">
4627 <organization>HP Labs</organization>
4628 <address><email>JeffMogul@acm.org</email></address>
4630 <date year="2004" month="September" />
4632 <seriesInfo name="BCP" value="90" />
4633 <seriesInfo name="RFC" value="3864" />
4636 <reference anchor="TLSBCP">
4638 <title>Recommendations for Secure Use of TLS and DTLS</title>
4639 <author initials="Y" surname="Sheffer" fullname="Yaron Sheffer">
4642 <author initials="R" surname="Holz" fullname="Ralph Holz">
4645 <author initials="P" surname="Saint-Andre" fullname="Peter Saint-Andre">
4648 <date month="June" day="23" year="2014" />
4650 <seriesInfo name="Internet-Draft" value="draft-ietf-uta-tls-bcp-01" />
4653 <reference anchor="ALT-SVC">
4656 HTTP Alternative Services
4658 <author initials="M." surname="Nottingham" fullname="Mark Nottingham">
4659 <organization>Akamai</organization>
4661 <author initials="P." surname="McManus" fullname="Patrick McManus">
4662 <organization>Mozilla</organization>
4664 <author initials="J." surname="Reschke" fullname="Julian Reschke">
4665 <organization>greenbytes</organization>
4667 <date year="2014" month="April"/>
4669 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-alt-svc-02"/>
4670 <x:source href="refs/draft-ietf-httpbis-alt-svc-02.xml"/>
4674 <section title="Change Log" anchor="change.log">
4676 This section is to be removed by RFC Editor before publication.
4679 <section title="Since draft-ietf-httpbis-http2-14" anchor="changes.since.draft-ietf-httpbis-http2-14">
4681 Renamed Not Authoritative status code to Misdirected Request.
4685 <section title="Since draft-ietf-httpbis-http2-13" anchor="changes.since.draft-ietf-httpbis-http2-13">
4687 Pseudo-header fields are now required to appear strictly before regular ones.
4690 Restored 1xx series status codes, except 101.
4693 Changed frame length field 24-bits. Expanded frame header to 9 octets. Added a setting
4694 to limit the damage.
4697 Added a setting to advise peers of header set size limits.
4703 Made non-semantic-bearing <x:ref>HEADERS</x:ref> frames illegal in the HTTP mapping.
4707 <section title="Since draft-ietf-httpbis-http2-12" anchor="changes.since.draft-ietf-httpbis-http2-12">
4709 Restored extensibility options.
4712 Restricting TLS cipher suites to AEAD only.
4715 Removing Content-Encoding requirements.
4718 Permitting the use of <x:ref>PRIORITY</x:ref> after stream close.
4721 Removed ALTSVC frame.
4724 Removed BLOCKED frame.
4727 Reducing the maximum padding size to 256 octets; removing padding from
4728 <x:ref>CONTINUATION</x:ref> frames.
4731 Removed per-frame GZIP compression.
4735 <section title="Since draft-ietf-httpbis-http2-11" anchor="changes.since.draft-ietf-httpbis-http2-11">
4737 Added BLOCKED frame (at risk).
4740 Simplified priority scheme.
4743 Added <x:ref>DATA</x:ref> per-frame GZIP compression.
4747 <section title="Since draft-ietf-httpbis-http2-10" anchor="changes.since.draft-ietf-httpbis-http2-10">
4749 Changed "connection header" to "connection preface" to avoid confusion.
4752 Added dependency-based stream prioritization.
4755 Added "h2c" identifier to distinguish between cleartext and secured HTTP/2.
4758 Adding missing padding to <x:ref>PUSH_PROMISE</x:ref>.
4761 Integrate ALTSVC frame and supporting text.
4764 Dropping requirement on "deflate" Content-Encoding.
4767 Improving security considerations around use of compression.
4771 <section title="Since draft-ietf-httpbis-http2-09" anchor="changes.since.draft-ietf-httpbis-http2-09">
4773 Adding padding for data frames.
4776 Renumbering frame types, error codes, and settings.
4779 Adding INADEQUATE_SECURITY error code.
4782 Updating TLS usage requirements to 1.2; forbidding TLS compression.
4785 Removing extensibility for frames and settings.
4788 Changing setting identifier size.
4791 Removing the ability to disable flow control.
4794 Changing the protocol identification token to "h2".
4797 Changing the use of :authority to make it optional and to allow userinfo in non-HTTP
4801 Allowing split on 0x0 for Cookie.
4804 Reserved PRI method in HTTP/1.1 to avoid possible future collisions.
4808 <section title="Since draft-ietf-httpbis-http2-08" anchor="changes.since.draft-ietf-httpbis-http2-08">
4810 Added cookie crumbling for more efficient header compression.
4813 Added header field ordering with the value-concatenation mechanism.
4817 <section title="Since draft-ietf-httpbis-http2-07" anchor="changes.since.draft-ietf-httpbis-http2-07">
4819 Marked draft for implementation.
4823 <section title="Since draft-ietf-httpbis-http2-06" anchor="changes.since.draft-ietf-httpbis-http2-06">
4825 Adding definition for CONNECT method.
4828 Constraining the use of push to safe, cacheable methods with no request body.
4831 Changing from :host to :authority to remove any potential confusion.
4834 Adding setting for header compression table size.
4837 Adding settings acknowledgement.
4840 Removing unnecessary and potentially problematic flags from CONTINUATION.
4843 Added denial of service considerations.
4846 <section title="Since draft-ietf-httpbis-http2-05" anchor="changes.since.draft-ietf-httpbis-http2-05">
4848 Marking the draft ready for implementation.
4851 Renumbering END_PUSH_PROMISE flag.
4854 Editorial clarifications and changes.
4858 <section title="Since draft-ietf-httpbis-http2-04" anchor="changes.since.draft-ietf-httpbis-http2-04">
4860 Added CONTINUATION frame for HEADERS and PUSH_PROMISE.
4863 PUSH_PROMISE is no longer implicitly prohibited if SETTINGS_MAX_CONCURRENT_STREAMS is
4867 Push expanded to allow all safe methods without a request body.
4870 Clarified the use of HTTP header fields in requests and responses. Prohibited HTTP/1.1
4871 hop-by-hop header fields.
4874 Requiring that intermediaries not forward requests with missing or illegal routing
4878 Clarified requirements around handling different frames after stream close, stream reset
4879 and <x:ref>GOAWAY</x:ref>.
4882 Added more specific prohibitions for sending of different frame types in various stream
4886 Making the last received setting value the effective value.
4889 Clarified requirements on TLS version, extension and ciphers.
4893 <section title="Since draft-ietf-httpbis-http2-03" anchor="changes.since.draft-ietf-httpbis-http2-03">
4895 Committed major restructuring atrocities.
4898 Added reference to first header compression draft.
4901 Added more formal description of frame lifecycle.
4904 Moved END_STREAM (renamed from FINAL) back to <x:ref>HEADERS</x:ref>/<x:ref>DATA</x:ref>.
4907 Removed HEADERS+PRIORITY, added optional priority to <x:ref>HEADERS</x:ref> frame.
4910 Added <x:ref>PRIORITY</x:ref> frame.
4914 <section title="Since draft-ietf-httpbis-http2-02" anchor="changes.since.draft-ietf-httpbis-http2-02">
4916 Added continuations to frames carrying header blocks.
4919 Replaced use of "session" with "connection" to avoid confusion with other HTTP stateful
4920 concepts, like cookies.
4926 Switched to TLS ALPN from NPN.
4933 <section title="Since draft-ietf-httpbis-http2-01" anchor="changes.since.draft-ietf-httpbis-http2-01">
4935 Added IANA considerations section for frame types, error codes and settings.
4938 Removed data frame compression.
4941 Added <x:ref>PUSH_PROMISE</x:ref>.
4944 Added globally applicable flags to framing.
4947 Removed zlib-based header compression mechanism.
4953 Clarified stream identifier reuse.
4956 Removed CREDENTIALS frame and associated mechanisms.
4959 Added advice against naive implementation of flow control.
4962 Added session header section.
4965 Restructured frame header. Removed distinction between data and control frames.
4968 Altered flow control properties to include session-level limits.
4971 Added note on cacheability of pushed resources and multiple tenant servers.
4974 Changed protocol label form based on discussions.
4978 <section title="Since draft-ietf-httpbis-http2-00" anchor="changes.since.draft-ietf-httpbis-http2-00">
4980 Changed title throughout.
4983 Removed section on Incompatibilities with SPDY draft#2.
4986 Changed <x:ref>INTERNAL_ERROR</x:ref> on <x:ref>GOAWAY</x:ref> to have a value of 2 <eref
4987 target="https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/cfUef2gL3iU"/>.
4990 Replaced abstract and introduction.
4993 Added section on starting HTTP/2.0, including upgrade mechanism.
4996 Removed unused references.
4999 Added <xref target="fc-principles">flow control principles</xref> based on <eref
5000 target="https://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-principles-01"/>.
5004 <section title="Since draft-mbelshe-httpbis-spdy-00" anchor="changes.since.draft-mbelshe-httpbis-spdy-00">
5006 Adopted as base for draft-ietf-httpbis-http2.
5009 Updated authors/editors list.