7 Internet Engineering Task Force (IETF) M. Belshe
8 Request for Comments: 7540 BitGo
9 Category: Standards Track R. Peon
10 ISSN: 2070-1721 Google, Inc
16 Hypertext Transfer Protocol Version 2 (HTTP/2)
20 This specification describes an optimized expression of the semantics
21 of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
22 version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
23 resources and a reduced perception of latency by introducing header
24 field compression and allowing multiple concurrent exchanges on the
25 same connection. It also introduces unsolicited push of
26 representations from servers to clients.
28 This specification is an alternative to, but does not obsolete, the
29 HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
33 This is an Internet Standards Track document.
35 This document is a product of the Internet Engineering Task Force
36 (IETF). It represents the consensus of the IETF community. It has
37 received public review and has been approved for publication by the
38 Internet Engineering Steering Group (IESG). Further information on
39 Internet Standards is available in Section 2 of RFC 5741.
41 Information about the current status of this document, any errata,
42 and how to provide feedback on it may be obtained at
43 http://www.rfc-editor.org/info/rfc7540.
58 Belshe, et al. Standards Track [Page 1]
60 RFC 7540 HTTP/2 May 2015
65 Copyright (c) 2015 IETF Trust and the persons identified as the
66 document authors. All rights reserved.
68 This document is subject to BCP 78 and the IETF Trust's Legal
69 Provisions Relating to IETF Documents
70 (http://trustee.ietf.org/license-info) in effect on the date of
71 publication of this document. Please review these documents
72 carefully, as they describe your rights and restrictions with respect
73 to this document. Code Components extracted from this document must
74 include Simplified BSD License text as described in Section 4.e of
75 the Trust Legal Provisions and are provided without warranty as
76 described in the Simplified BSD License.
80 1. Introduction ....................................................4
81 2. HTTP/2 Protocol Overview ........................................5
82 2.1. Document Organization ......................................6
83 2.2. Conventions and Terminology ................................6
84 3. Starting HTTP/2 .................................................7
85 3.1. HTTP/2 Version Identification ..............................8
86 3.2. Starting HTTP/2 for "http" URIs ............................8
87 3.2.1. HTTP2-Settings Header Field .........................9
88 3.3. Starting HTTP/2 for "https" URIs ..........................10
89 3.4. Starting HTTP/2 with Prior Knowledge ......................10
90 3.5. HTTP/2 Connection Preface .................................11
91 4. HTTP Frames ....................................................12
92 4.1. Frame Format ..............................................12
93 4.2. Frame Size ................................................13
94 4.3. Header Compression and Decompression ......................14
95 5. Streams and Multiplexing .......................................15
96 5.1. Stream States .............................................16
97 5.1.1. Stream Identifiers .................................21
98 5.1.2. Stream Concurrency .................................22
99 5.2. Flow Control ..............................................22
100 5.2.1. Flow-Control Principles ............................23
101 5.2.2. Appropriate Use of Flow Control ....................24
102 5.3. Stream Priority ...........................................24
103 5.3.1. Stream Dependencies ................................25
104 5.3.2. Dependency Weighting ...............................26
105 5.3.3. Reprioritization ...................................26
106 5.3.4. Prioritization State Management ....................27
107 5.3.5. Default Priorities .................................28
108 5.4. Error Handling ............................................28
109 5.4.1. Connection Error Handling ..........................29
110 5.4.2. Stream Error Handling ..............................29
114 Belshe, et al. Standards Track [Page 2]
116 RFC 7540 HTTP/2 May 2015
119 5.4.3. Connection Termination .............................30
120 5.5. Extending HTTP/2 ..........................................30
121 6. Frame Definitions ..............................................31
122 6.1. DATA ......................................................31
123 6.2. HEADERS ...................................................32
124 6.3. PRIORITY ..................................................34
125 6.4. RST_STREAM ................................................36
126 6.5. SETTINGS ..................................................36
127 6.5.1. SETTINGS Format ....................................38
128 6.5.2. Defined SETTINGS Parameters ........................38
129 6.5.3. Settings Synchronization ...........................39
130 6.6. PUSH_PROMISE ..............................................40
131 6.7. PING ......................................................42
132 6.8. GOAWAY ....................................................43
133 6.9. WINDOW_UPDATE .............................................46
134 6.9.1. The Flow-Control Window ............................47
135 6.9.2. Initial Flow-Control Window Size ...................48
136 6.9.3. Reducing the Stream Window Size ....................49
137 6.10. CONTINUATION .............................................49
138 7. Error Codes ....................................................50
139 8. HTTP Message Exchanges .........................................51
140 8.1. HTTP Request/Response Exchange ............................52
141 8.1.1. Upgrading from HTTP/2 ..............................53
142 8.1.2. HTTP Header Fields .................................53
143 8.1.3. Examples ...........................................57
144 8.1.4. Request Reliability Mechanisms in HTTP/2 ...........60
145 8.2. Server Push ...............................................60
146 8.2.1. Push Requests ......................................61
147 8.2.2. Push Responses .....................................63
148 8.3. The CONNECT Method ........................................64
149 9. Additional HTTP Requirements/Considerations ....................65
150 9.1. Connection Management .....................................65
151 9.1.1. Connection Reuse ...................................66
152 9.1.2. The 421 (Misdirected Request) Status Code ..........66
153 9.2. Use of TLS Features .......................................67
154 9.2.1. TLS 1.2 Features ...................................67
155 9.2.2. TLS 1.2 Cipher Suites ..............................68
156 10. Security Considerations .......................................69
157 10.1. Server Authority .........................................69
158 10.2. Cross-Protocol Attacks ...................................69
159 10.3. Intermediary Encapsulation Attacks .......................70
160 10.4. Cacheability of Pushed Responses .........................70
161 10.5. Denial-of-Service Considerations .........................70
162 10.5.1. Limits on Header Block Size .......................71
163 10.5.2. CONNECT Issues ....................................72
164 10.6. Use of Compression .......................................72
165 10.7. Use of Padding ...........................................73
166 10.8. Privacy Considerations ...................................73
170 Belshe, et al. Standards Track [Page 3]
172 RFC 7540 HTTP/2 May 2015
175 11. IANA Considerations ...........................................74
176 11.1. Registration of HTTP/2 Identification Strings ............74
177 11.2. Frame Type Registry ......................................75
178 11.3. Settings Registry ........................................75
179 11.4. Error Code Registry ......................................76
180 11.5. HTTP2-Settings Header Field Registration .................77
181 11.6. PRI Method Registration ..................................78
182 11.7. The 421 (Misdirected Request) HTTP Status Code ...........78
183 11.8. The h2c Upgrade Token ....................................78
184 12. References ....................................................79
185 12.1. Normative References .....................................79
186 12.2. Informative References ...................................81
187 Appendix A. TLS 1.2 Cipher Suite Black List .......................83
188 Acknowledgements ..................................................95
189 Authors' Addresses ................................................96
193 The Hypertext Transfer Protocol (HTTP) is a wildly successful
194 protocol. However, the way HTTP/1.1 uses the underlying transport
195 ([RFC7230], Section 6) has several characteristics that have a
196 negative overall effect on application performance today.
198 In particular, HTTP/1.0 allowed only one request to be outstanding at
199 a time on a given TCP connection. HTTP/1.1 added request pipelining,
200 but this only partially addressed request concurrency and still
201 suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1
202 clients that need to make many requests use multiple connections to a
203 server in order to achieve concurrency and thereby reduce latency.
205 Furthermore, HTTP header fields are often repetitive and verbose,
206 causing unnecessary network traffic as well as causing the initial
207 TCP [TCP] congestion window to quickly fill. This can result in
208 excessive latency when multiple requests are made on a new TCP
211 HTTP/2 addresses these issues by defining an optimized mapping of
212 HTTP's semantics to an underlying connection. Specifically, it
213 allows interleaving of request and response messages on the same
214 connection and uses an efficient coding for HTTP header fields. It
215 also allows prioritization of requests, letting more important
216 requests complete more quickly, further improving performance.
226 Belshe, et al. Standards Track [Page 4]
228 RFC 7540 HTTP/2 May 2015
231 The resulting protocol is more friendly to the network because fewer
232 TCP connections can be used in comparison to HTTP/1.x. This means
233 less competition with other flows and longer-lived connections, which
234 in turn lead to better utilization of available network capacity.
236 Finally, HTTP/2 also enables more efficient processing of messages
237 through use of binary message framing.
239 2. HTTP/2 Protocol Overview
241 HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2
242 supports all of the core features of HTTP/1.1 but aims to be more
243 efficient in several ways.
245 The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each
246 frame type serves a different purpose. For example, HEADERS and DATA
247 frames form the basis of HTTP requests and responses (Section 8.1);
248 other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are
249 used in support of other HTTP/2 features.
251 Multiplexing of requests is achieved by having each HTTP request/
252 response exchange associated with its own stream (Section 5).
253 Streams are largely independent of each other, so a blocked or
254 stalled request or response does not prevent progress on other
257 Flow control and prioritization ensure that it is possible to
258 efficiently use multiplexed streams. Flow control (Section 5.2)
259 helps to ensure that only data that can be used by a receiver is
260 transmitted. Prioritization (Section 5.3) ensures that limited
261 resources can be directed to the most important streams first.
263 HTTP/2 adds a new interaction mode whereby a server can push
264 responses to a client (Section 8.2). Server push allows a server to
265 speculatively send data to a client that the server anticipates the
266 client will need, trading off some network usage against a potential
267 latency gain. The server does this by synthesizing a request, which
268 it sends as a PUSH_PROMISE frame. The server is then able to send a
269 response to the synthetic request on a separate stream.
271 Because HTTP header fields used in a connection can contain large
272 amounts of redundant data, frames that contain them are compressed
273 (Section 4.3). This has especially advantageous impact upon request
274 sizes in the common case, allowing many requests to be compressed
282 Belshe, et al. Standards Track [Page 5]
284 RFC 7540 HTTP/2 May 2015
287 2.1. Document Organization
289 The HTTP/2 specification is split into four parts:
291 o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is
294 o The frame (Section 4) and stream (Section 5) layers describe the
295 way HTTP/2 frames are structured and formed into multiplexed
298 o Frame (Section 6) and error (Section 7) definitions include
299 details of the frame and error types used in HTTP/2.
301 o HTTP mappings (Section 8) and additional requirements (Section 9)
302 describe how HTTP semantics are expressed using frames and
305 While some of the frame and stream layer concepts are isolated from
306 HTTP, this specification does not define a completely generic frame
307 layer. The frame and stream layers are tailored to the needs of the
308 HTTP protocol and server push.
310 2.2. Conventions and Terminology
312 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
313 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
314 document are to be interpreted as described in RFC 2119 [RFC2119].
316 All numeric values are in network byte order. Values are unsigned
317 unless otherwise indicated. Literal values are provided in decimal
318 or hexadecimal as appropriate. Hexadecimal literals are prefixed
319 with "0x" to distinguish them from decimal literals.
321 The following terms are used:
323 client: The endpoint that initiates an HTTP/2 connection. Clients
324 send HTTP requests and receive HTTP responses.
326 connection: A transport-layer connection between two endpoints.
328 connection error: An error that affects the entire HTTP/2
331 endpoint: Either the client or server of the connection.
338 Belshe, et al. Standards Track [Page 6]
340 RFC 7540 HTTP/2 May 2015
343 frame: The smallest unit of communication within an HTTP/2
344 connection, consisting of a header and a variable-length sequence
345 of octets structured according to the frame type.
347 peer: An endpoint. When discussing a particular endpoint, "peer"
348 refers to the endpoint that is remote to the primary subject of
351 receiver: An endpoint that is receiving frames.
353 sender: An endpoint that is transmitting frames.
355 server: The endpoint that accepts an HTTP/2 connection. Servers
356 receive HTTP requests and send HTTP responses.
358 stream: A bidirectional flow of frames within the HTTP/2 connection.
360 stream error: An error on the individual HTTP/2 stream.
362 Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"
363 are defined in Section 2.3 of [RFC7230]. Intermediaries act as both
364 client and server at different times.
366 The term "payload body" is defined in Section 3.3 of [RFC7230].
370 An HTTP/2 connection is an application-layer protocol running on top
371 of a TCP connection ([TCP]). The client is the TCP connection
374 HTTP/2 uses the same "http" and "https" URI schemes used by HTTP/1.1.
375 HTTP/2 shares the same default port numbers: 80 for "http" URIs and
376 443 for "https" URIs. As a result, implementations processing
377 requests for target resource URIs like "http://example.org/foo" or
378 "https://example.com/bar" are required to first discover whether the
379 upstream server (the immediate peer to which the client wishes to
380 establish a connection) supports HTTP/2.
382 The means by which support for HTTP/2 is determined is different for
383 "http" and "https" URIs. Discovery for "http" URIs is described in
384 Section 3.2. Discovery for "https" URIs is described in Section 3.3.
394 Belshe, et al. Standards Track [Page 7]
396 RFC 7540 HTTP/2 May 2015
399 3.1. HTTP/2 Version Identification
401 The protocol defined in this document has two identifiers.
403 o The string "h2" identifies the protocol where HTTP/2 uses
404 Transport Layer Security (TLS) [TLS12]. This identifier is used
405 in the TLS application-layer protocol negotiation (ALPN) extension
406 [TLS-ALPN] field and in any place where HTTP/2 over TLS is
409 The "h2" string is serialized into an ALPN protocol identifier as
410 the two-octet sequence: 0x68, 0x32.
412 o The string "h2c" identifies the protocol where HTTP/2 is run over
413 cleartext TCP. This identifier is used in the HTTP/1.1 Upgrade
414 header field and in any place where HTTP/2 over TCP is identified.
416 The "h2c" string is reserved from the ALPN identifier space but
417 describes a protocol that does not use TLS.
419 Negotiating "h2" or "h2c" implies the use of the transport, security,
420 framing, and message semantics described in this document.
422 3.2. Starting HTTP/2 for "http" URIs
424 A client that makes a request for an "http" URI without prior
425 knowledge about support for HTTP/2 on the next hop uses the HTTP
426 Upgrade mechanism (Section 6.7 of [RFC7230]). The client does so by
427 making an HTTP/1.1 request that includes an Upgrade header field with
428 the "h2c" token. Such an HTTP/1.1 request MUST include exactly one
429 HTTP2-Settings (Section 3.2.1) header field.
434 Host: server.example.com
435 Connection: Upgrade, HTTP2-Settings
437 HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
439 Requests that contain a payload body MUST be sent in their entirety
440 before the client can send HTTP/2 frames. This means that a large
441 request can block the use of the connection until it is completely
444 If concurrency of an initial request with subsequent requests is
445 important, an OPTIONS request can be used to perform the upgrade to
446 HTTP/2, at the cost of an additional round trip.
450 Belshe, et al. Standards Track [Page 8]
452 RFC 7540 HTTP/2 May 2015
455 A server that does not support HTTP/2 can respond to the request as
456 though the Upgrade header field were absent:
460 Content-Type: text/html
464 A server MUST ignore an "h2" token in an Upgrade header field.
465 Presence of a token with "h2" implies HTTP/2 over TLS, which is
466 instead negotiated as described in Section 3.3.
468 A server that supports HTTP/2 accepts the upgrade with a 101
469 (Switching Protocols) response. After the empty line that terminates
470 the 101 response, the server can begin sending HTTP/2 frames. These
471 frames MUST include a response to the request that initiated the
476 HTTP/1.1 101 Switching Protocols
480 [ HTTP/2 connection ...
482 The first HTTP/2 frame sent by the server MUST be a server connection
483 preface (Section 3.5) consisting of a SETTINGS frame (Section 6.5).
484 Upon receiving the 101 response, the client MUST send a connection
485 preface (Section 3.5), which includes a SETTINGS frame.
487 The HTTP/1.1 request that is sent prior to upgrade is assigned a
488 stream identifier of 1 (see Section 5.1.1) with default priority
489 values (Section 5.3.5). Stream 1 is implicitly "half-closed" from
490 the client toward the server (see Section 5.1), since the request is
491 completed as an HTTP/1.1 request. After commencing the HTTP/2
492 connection, stream 1 is used for the response.
494 3.2.1. HTTP2-Settings Header Field
496 A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly
497 one "HTTP2-Settings" header field. The HTTP2-Settings header field
498 is a connection-specific header field that includes parameters that
499 govern the HTTP/2 connection, provided in anticipation of the server
500 accepting the request to upgrade.
502 HTTP2-Settings = token68
506 Belshe, et al. Standards Track [Page 9]
508 RFC 7540 HTTP/2 May 2015
511 A server MUST NOT upgrade the connection to HTTP/2 if this header
512 field is not present or if more than one is present. A server MUST
513 NOT send this header field.
515 The content of the HTTP2-Settings header field is the payload of a
516 SETTINGS frame (Section 6.5), encoded as a base64url string (that is,
517 the URL- and filename-safe Base64 encoding described in Section 5 of
518 [RFC4648], with any trailing '=' characters omitted). The ABNF
519 [RFC5234] production for "token68" is defined in Section 2.1 of
522 Since the upgrade is only intended to apply to the immediate
523 connection, a client sending the HTTP2-Settings header field MUST
524 also send "HTTP2-Settings" as a connection option in the Connection
525 header field to prevent it from being forwarded (see Section 6.1 of
528 A server decodes and interprets these values as it would any other
529 SETTINGS frame. Explicit acknowledgement of these settings
530 (Section 6.5.3) is not necessary, since a 101 response serves as
531 implicit acknowledgement. Providing these values in the upgrade
532 request gives a client an opportunity to provide parameters prior to
533 receiving any frames from the server.
535 3.3. Starting HTTP/2 for "https" URIs
537 A client that makes a request to an "https" URI uses TLS [TLS12] with
538 the application-layer protocol negotiation (ALPN) extension
541 HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c"
542 protocol identifier MUST NOT be sent by a client or selected by a
543 server; the "h2c" protocol identifier describes a protocol that does
546 Once TLS negotiation is complete, both the client and the server MUST
547 send a connection preface (Section 3.5).
549 3.4. Starting HTTP/2 with Prior Knowledge
551 A client can learn that a particular server supports HTTP/2 by other
552 means. For example, [ALT-SVC] describes a mechanism for advertising
555 A client MUST send the connection preface (Section 3.5) and then MAY
556 immediately send HTTP/2 frames to such a server; servers can identify
557 these connections by the presence of the connection preface. This
562 Belshe, et al. Standards Track [Page 10]
564 RFC 7540 HTTP/2 May 2015
567 only affects the establishment of HTTP/2 connections over cleartext
568 TCP; implementations that support HTTP/2 over TLS MUST use protocol
569 negotiation in TLS [TLS-ALPN].
571 Likewise, the server MUST send a connection preface (Section 3.5).
573 Without additional information, prior support for HTTP/2 is not a
574 strong signal that a given server will support HTTP/2 for future
575 connections. For example, it is possible for server configurations
576 to change, for configurations to differ between instances in
577 clustered servers, or for network conditions to change.
579 3.5. HTTP/2 Connection Preface
581 In HTTP/2, each endpoint is required to send a connection preface as
582 a final confirmation of the protocol in use and to establish the
583 initial settings for the HTTP/2 connection. The client and server
584 each send a different connection preface.
586 The client connection preface starts with a sequence of 24 octets,
587 which in hex notation is:
589 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
591 That is, the connection preface starts with the string "PRI *
592 HTTP/2.0\r\n\r\nSM\r\n\r\n"). This sequence MUST be followed by a
593 SETTINGS frame (Section 6.5), which MAY be empty. The client sends
594 the client connection preface immediately upon receipt of a 101
595 (Switching Protocols) response (indicating a successful upgrade) or
596 as the first application data octets of a TLS connection. If
597 starting an HTTP/2 connection with prior knowledge of server support
598 for the protocol, the client connection preface is sent upon
599 connection establishment.
601 Note: The client connection preface is selected so that a large
602 proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do
603 not attempt to process further frames. Note that this does not
604 address the concerns raised in [TALKING].
606 The server connection preface consists of a potentially empty
607 SETTINGS frame (Section 6.5) that MUST be the first frame the server
608 sends in the HTTP/2 connection.
610 The SETTINGS frames received from a peer as part of the connection
611 preface MUST be acknowledged (see Section 6.5.3) after sending the
618 Belshe, et al. Standards Track [Page 11]
620 RFC 7540 HTTP/2 May 2015
623 To avoid unnecessary latency, clients are permitted to send
624 additional frames to the server immediately after sending the client
625 connection preface, without waiting to receive the server connection
626 preface. It is important to note, however, that the server
627 connection preface SETTINGS frame might include parameters that
628 necessarily alter how a client is expected to communicate with the
629 server. Upon receiving the SETTINGS frame, the client is expected to
630 honor any parameters established. In some configurations, it is
631 possible for the server to transmit SETTINGS before the client sends
632 additional frames, providing an opportunity to avoid this issue.
634 Clients and servers MUST treat an invalid connection preface as a
635 connection error (Section 5.4.1) of type PROTOCOL_ERROR. A GOAWAY
636 frame (Section 6.8) MAY be omitted in this case, since an invalid
637 preface indicates that the peer is not using HTTP/2.
641 Once the HTTP/2 connection is established, endpoints can begin
646 All frames begin with a fixed 9-octet header followed by a variable-
649 +-----------------------------------------------+
651 +---------------+---------------+---------------+
652 | Type (8) | Flags (8) |
653 +-+-------------+---------------+-------------------------------+
654 |R| Stream Identifier (31) |
655 +=+=============================================================+
656 | Frame Payload (0...) ...
657 +---------------------------------------------------------------+
659 Figure 1: Frame Layout
661 The fields of the frame header are defined as:
663 Length: The length of the frame payload expressed as an unsigned
664 24-bit integer. Values greater than 2^14 (16,384) MUST NOT be
665 sent unless the receiver has set a larger value for
666 SETTINGS_MAX_FRAME_SIZE.
668 The 9 octets of the frame header are not included in this value.
674 Belshe, et al. Standards Track [Page 12]
676 RFC 7540 HTTP/2 May 2015
679 Type: The 8-bit type of the frame. The frame type determines the
680 format and semantics of the frame. Implementations MUST ignore
681 and discard any frame that has a type that is unknown.
683 Flags: An 8-bit field reserved for boolean flags specific to the
686 Flags are assigned semantics specific to the indicated frame type.
687 Flags that have no defined semantics for a particular frame type
688 MUST be ignored and MUST be left unset (0x0) when sending.
690 R: A reserved 1-bit field. The semantics of this bit are undefined,
691 and the bit MUST remain unset (0x0) when sending and MUST be
692 ignored when receiving.
694 Stream Identifier: A stream identifier (see Section 5.1.1) expressed
695 as an unsigned 31-bit integer. The value 0x0 is reserved for
696 frames that are associated with the connection as a whole as
697 opposed to an individual stream.
699 The structure and content of the frame payload is dependent entirely
704 The size of a frame payload is limited by the maximum size that a
705 receiver advertises in the SETTINGS_MAX_FRAME_SIZE setting. This
706 setting can have any value between 2^14 (16,384) and 2^24-1
707 (16,777,215) octets, inclusive.
709 All implementations MUST be capable of receiving and minimally
710 processing frames up to 2^14 octets in length, plus the 9-octet frame
711 header (Section 4.1). The size of the frame header is not included
712 when describing frame sizes.
714 Note: Certain frame types, such as PING (Section 6.7), impose
715 additional limits on the amount of payload data allowed.
717 An endpoint MUST send an error code of FRAME_SIZE_ERROR if a frame
718 exceeds the size defined in SETTINGS_MAX_FRAME_SIZE, exceeds any
719 limit defined for the frame type, or is too small to contain
720 mandatory frame data. A frame size error in a frame that could alter
721 the state of the entire connection MUST be treated as a connection
722 error (Section 5.4.1); this includes any frame carrying a header
723 block (Section 4.3) (that is, HEADERS, PUSH_PROMISE, and
724 CONTINUATION), SETTINGS, and any frame with a stream identifier of 0.
730 Belshe, et al. Standards Track [Page 13]
732 RFC 7540 HTTP/2 May 2015
735 Endpoints are not obligated to use all available space in a frame.
736 Responsiveness can be improved by using frames that are smaller than
737 the permitted maximum size. Sending large frames can result in
738 delays in sending time-sensitive frames (such as RST_STREAM,
739 WINDOW_UPDATE, or PRIORITY), which, if blocked by the transmission of
740 a large frame, could affect performance.
742 4.3. Header Compression and Decompression
744 Just as in HTTP/1, a header field in HTTP/2 is a name with one or
745 more associated values. Header fields are used within HTTP request
746 and response messages as well as in server push operations (see
749 Header lists are collections of zero or more header fields. When
750 transmitted over a connection, a header list is serialized into a
751 header block using HTTP header compression [COMPRESSION]. The
752 serialized header block is then divided into one or more octet
753 sequences, called header block fragments, and transmitted within the
754 payload of HEADERS (Section 6.2), PUSH_PROMISE (Section 6.6), or
755 CONTINUATION (Section 6.10) frames.
757 The Cookie header field [COOKIE] is treated specially by the HTTP
758 mapping (see Section 8.1.2.5).
760 A receiving endpoint reassembles the header block by concatenating
761 its fragments and then decompresses the block to reconstruct the
764 A complete header block consists of either:
766 o a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag
769 o a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared
770 and one or more CONTINUATION frames, where the last CONTINUATION
771 frame has the END_HEADERS flag set.
773 Header compression is stateful. One compression context and one
774 decompression context are used for the entire connection. A decoding
775 error in a header block MUST be treated as a connection error
776 (Section 5.4.1) of type COMPRESSION_ERROR.
778 Each header block is processed as a discrete unit. Header blocks
779 MUST be transmitted as a contiguous sequence of frames, with no
780 interleaved frames of any other type or from any other stream. The
781 last frame in a sequence of HEADERS or CONTINUATION frames has the
786 Belshe, et al. Standards Track [Page 14]
788 RFC 7540 HTTP/2 May 2015
791 END_HEADERS flag set. The last frame in a sequence of PUSH_PROMISE
792 or CONTINUATION frames has the END_HEADERS flag set. This allows a
793 header block to be logically equivalent to a single frame.
795 Header block fragments can only be sent as the payload of HEADERS,
796 PUSH_PROMISE, or CONTINUATION frames because these frames carry data
797 that can modify the compression context maintained by a receiver. An
798 endpoint receiving HEADERS, PUSH_PROMISE, or CONTINUATION frames
799 needs to reassemble header blocks and perform decompression even if
800 the frames are to be discarded. A receiver MUST terminate the
801 connection with a connection error (Section 5.4.1) of type
802 COMPRESSION_ERROR if it does not decompress a header block.
804 5. Streams and Multiplexing
806 A "stream" is an independent, bidirectional sequence of frames
807 exchanged between the client and server within an HTTP/2 connection.
808 Streams have several important characteristics:
810 o A single HTTP/2 connection can contain multiple concurrently open
811 streams, with either endpoint interleaving frames from multiple
814 o Streams can be established and used unilaterally or shared by
815 either the client or server.
817 o Streams can be closed by either endpoint.
819 o The order in which frames are sent on a stream is significant.
820 Recipients process frames in the order they are received. In
821 particular, the order of HEADERS and DATA frames is semantically
824 o Streams are identified by an integer. Stream identifiers are
825 assigned to streams by the endpoint initiating the stream.
842 Belshe, et al. Standards Track [Page 15]
844 RFC 7540 HTTP/2 May 2015
849 The lifecycle of a stream is shown in Figure 2.
853 ,--------| idle |--------.
856 +----------+ | +----------+
858 ,------| reserved | | recv H | reserved |------.
859 | | (local) | | | (remote) | |
860 | +----------+ v +----------+ |
862 | | recv ES | | send ES | |
863 | send H | ,-------| open |-------. | recv H |
865 | v v +--------+ v v |
866 | +----------+ | +----------+ |
867 | | half | | | half | |
868 | | closed | | send R / | closed | |
869 | | (remote) | | recv R | (local) | |
870 | +----------+ | +----------+ |
872 | | send ES / | recv ES / | |
873 | | send R / v send R / | |
874 | | recv R +--------+ recv R | |
875 | send R / `----------->| |<-----------' send R / |
876 | recv R | closed | recv R |
877 `----------------------->| |<----------------------'
880 send: endpoint sends this frame
881 recv: endpoint receives this frame
883 H: HEADERS frame (with implied CONTINUATIONs)
884 PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
888 Figure 2: Stream States
890 Note that this diagram shows stream state transitions and the frames
891 and flags that affect those transitions only. In this regard,
892 CONTINUATION frames do not result in state transitions; they are
893 effectively part of the HEADERS or PUSH_PROMISE that they follow.
898 Belshe, et al. Standards Track [Page 16]
900 RFC 7540 HTTP/2 May 2015
903 For the purpose of state transitions, the END_STREAM flag is
904 processed as a separate event to the frame that bears it; a HEADERS
905 frame with the END_STREAM flag set can cause two state transitions.
907 Both endpoints have a subjective view of the state of a stream that
908 could be different when frames are in transit. Endpoints do not
909 coordinate the creation of streams; they are created unilaterally by
910 either endpoint. The negative consequences of a mismatch in states
911 are limited to the "closed" state after sending RST_STREAM, where
912 frames might be received for some time after closing.
914 Streams have the following states:
917 All streams start in the "idle" state.
919 The following transitions are valid from this state:
921 * Sending or receiving a HEADERS frame causes the stream to
922 become "open". The stream identifier is selected as described
923 in Section 5.1.1. The same HEADERS frame can also cause a
924 stream to immediately become "half-closed".
926 * Sending a PUSH_PROMISE frame on another stream reserves the
927 idle stream that is identified for later use. The stream state
928 for the reserved stream transitions to "reserved (local)".
930 * Receiving a PUSH_PROMISE frame on another stream reserves an
931 idle stream that is identified for later use. The stream state
932 for the reserved stream transitions to "reserved (remote)".
934 * Note that the PUSH_PROMISE frame is not sent on the idle stream
935 but references the newly reserved stream in the Promised Stream
938 Receiving any frame other than HEADERS or PRIORITY on a stream in
939 this state MUST be treated as a connection error (Section 5.4.1)
940 of type PROTOCOL_ERROR.
943 A stream in the "reserved (local)" state is one that has been
944 promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame
945 reserves an idle stream by associating the stream with an open
946 stream that was initiated by the remote peer (see Section 8.2).
954 Belshe, et al. Standards Track [Page 17]
956 RFC 7540 HTTP/2 May 2015
959 In this state, only the following transitions are possible:
961 * The endpoint can send a HEADERS frame. This causes the stream
962 to open in a "half-closed (remote)" state.
964 * Either endpoint can send a RST_STREAM frame to cause the stream
965 to become "closed". This releases the stream reservation.
968 An endpoint MUST NOT send any type of frame other than HEADERS,
969 RST_STREAM, or PRIORITY in this state.
971 A PRIORITY or WINDOW_UPDATE frame MAY be received in this state.
972 Receiving any type of frame other than RST_STREAM, PRIORITY, or
973 WINDOW_UPDATE on a stream in this state MUST be treated as a
974 connection error (Section 5.4.1) of type PROTOCOL_ERROR.
977 A stream in the "reserved (remote)" state has been reserved by a
980 In this state, only the following transitions are possible:
982 * Receiving a HEADERS frame causes the stream to transition to
983 "half-closed (local)".
985 * Either endpoint can send a RST_STREAM frame to cause the stream
986 to become "closed". This releases the stream reservation.
988 An endpoint MAY send a PRIORITY frame in this state to
989 reprioritize the reserved stream. An endpoint MUST NOT send any
990 type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in
993 Receiving any type of frame other than HEADERS, RST_STREAM, or
994 PRIORITY on a stream in this state MUST be treated as a connection
995 error (Section 5.4.1) of type PROTOCOL_ERROR.
998 A stream in the "open" state may be used by both peers to send
999 frames of any type. In this state, sending peers observe
1000 advertised stream-level flow-control limits (Section 5.2).
1002 From this state, either endpoint can send a frame with an
1003 END_STREAM flag set, which causes the stream to transition into
1004 one of the "half-closed" states. An endpoint sending an
1010 Belshe, et al. Standards Track [Page 18]
1012 RFC 7540 HTTP/2 May 2015
1015 END_STREAM flag causes the stream state to become "half-closed
1016 (local)"; an endpoint receiving an END_STREAM flag causes the
1017 stream state to become "half-closed (remote)".
1019 Either endpoint can send a RST_STREAM frame from this state,
1020 causing it to transition immediately to "closed".
1022 half-closed (local):
1023 A stream that is in the "half-closed (local)" state cannot be used
1024 for sending frames other than WINDOW_UPDATE, PRIORITY, and
1027 A stream transitions from this state to "closed" when a frame that
1028 contains an END_STREAM flag is received or when either peer sends
1031 An endpoint can receive any type of frame in this state.
1032 Providing flow-control credit using WINDOW_UPDATE frames is
1033 necessary to continue receiving flow-controlled frames. In this
1034 state, a receiver can ignore WINDOW_UPDATE frames, which might
1035 arrive for a short period after a frame bearing the END_STREAM
1038 PRIORITY frames received in this state are used to reprioritize
1039 streams that depend on the identified stream.
1041 half-closed (remote):
1042 A stream that is "half-closed (remote)" is no longer being used by
1043 the peer to send frames. In this state, an endpoint is no longer
1044 obligated to maintain a receiver flow-control window.
1046 If an endpoint receives additional frames, other than
1047 WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in
1048 this state, it MUST respond with a stream error (Section 5.4.2) of
1051 A stream that is "half-closed (remote)" can be used by the
1052 endpoint to send frames of any type. In this state, the endpoint
1053 continues to observe advertised stream-level flow-control limits
1056 A stream can transition from this state to "closed" by sending a
1057 frame that contains an END_STREAM flag or when either peer sends a
1066 Belshe, et al. Standards Track [Page 19]
1068 RFC 7540 HTTP/2 May 2015
1072 The "closed" state is the terminal state.
1074 An endpoint MUST NOT send frames other than PRIORITY on a closed
1075 stream. An endpoint that receives any frame other than PRIORITY
1076 after receiving a RST_STREAM MUST treat that as a stream error
1077 (Section 5.4.2) of type STREAM_CLOSED. Similarly, an endpoint
1078 that receives any frames after receiving a frame with the
1079 END_STREAM flag set MUST treat that as a connection error
1080 (Section 5.4.1) of type STREAM_CLOSED, unless the frame is
1081 permitted as described below.
1083 WINDOW_UPDATE or RST_STREAM frames can be received in this state
1084 for a short period after a DATA or HEADERS frame containing an
1085 END_STREAM flag is sent. Until the remote peer receives and
1086 processes RST_STREAM or the frame bearing the END_STREAM flag, it
1087 might send frames of these types. Endpoints MUST ignore
1088 WINDOW_UPDATE or RST_STREAM frames received in this state, though
1089 endpoints MAY choose to treat frames that arrive a significant
1090 time after sending END_STREAM as a connection error
1091 (Section 5.4.1) of type PROTOCOL_ERROR.
1093 PRIORITY frames can be sent on closed streams to prioritize
1094 streams that are dependent on the closed stream. Endpoints SHOULD
1095 process PRIORITY frames, though they can be ignored if the stream
1096 has been removed from the dependency tree (see Section 5.3.4).
1098 If this state is reached as a result of sending a RST_STREAM
1099 frame, the peer that receives the RST_STREAM might have already
1100 sent -- or enqueued for sending -- frames on the stream that
1101 cannot be withdrawn. An endpoint MUST ignore frames that it
1102 receives on closed streams after it has sent a RST_STREAM frame.
1103 An endpoint MAY choose to limit the period over which it ignores
1104 frames and treat frames that arrive after this time as being in
1107 Flow-controlled frames (i.e., DATA) received after sending
1108 RST_STREAM are counted toward the connection flow-control window.
1109 Even though these frames might be ignored, because they are sent
1110 before the sender receives the RST_STREAM, the sender will
1111 consider the frames to count against the flow-control window.
1113 An endpoint might receive a PUSH_PROMISE frame after it sends
1114 RST_STREAM. PUSH_PROMISE causes a stream to become "reserved"
1115 even if the associated stream has been reset. Therefore, a
1116 RST_STREAM is needed to close an unwanted promised stream.
1122 Belshe, et al. Standards Track [Page 20]
1124 RFC 7540 HTTP/2 May 2015
1127 In the absence of more specific guidance elsewhere in this document,
1128 implementations SHOULD treat the receipt of a frame that is not
1129 expressly permitted in the description of a state as a connection
1130 error (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can
1131 be sent and received in any stream state. Frames of unknown types
1134 An example of the state transitions for an HTTP request/response
1135 exchange can be found in Section 8.1. An example of the state
1136 transitions for server push can be found in Sections 8.2.1 and 8.2.2.
1138 5.1.1. Stream Identifiers
1140 Streams are identified with an unsigned 31-bit integer. Streams
1141 initiated by a client MUST use odd-numbered stream identifiers; those
1142 initiated by the server MUST use even-numbered stream identifiers. A
1143 stream identifier of zero (0x0) is used for connection control
1144 messages; the stream identifier of zero cannot be used to establish a
1147 HTTP/1.1 requests that are upgraded to HTTP/2 (see Section 3.2) are
1148 responded to with a stream identifier of one (0x1). After the
1149 upgrade completes, stream 0x1 is "half-closed (local)" to the client.
1150 Therefore, stream 0x1 cannot be selected as a new stream identifier
1151 by a client that upgrades from HTTP/1.1.
1153 The identifier of a newly established stream MUST be numerically
1154 greater than all streams that the initiating endpoint has opened or
1155 reserved. This governs streams that are opened using a HEADERS frame
1156 and streams that are reserved using PUSH_PROMISE. An endpoint that
1157 receives an unexpected stream identifier MUST respond with a
1158 connection error (Section 5.4.1) of type PROTOCOL_ERROR.
1160 The first use of a new stream identifier implicitly closes all
1161 streams in the "idle" state that might have been initiated by that
1162 peer with a lower-valued stream identifier. For example, if a client
1163 sends a HEADERS frame on stream 7 without ever sending a frame on
1164 stream 5, then stream 5 transitions to the "closed" state when the
1165 first frame for stream 7 is sent or received.
1167 Stream identifiers cannot be reused. Long-lived connections can
1168 result in an endpoint exhausting the available range of stream
1169 identifiers. A client that is unable to establish a new stream
1170 identifier can establish a new connection for new streams. A server
1171 that is unable to establish a new stream identifier can send a GOAWAY
1172 frame so that the client is forced to open a new connection for new
1178 Belshe, et al. Standards Track [Page 21]
1180 RFC 7540 HTTP/2 May 2015
1183 5.1.2. Stream Concurrency
1185 A peer can limit the number of concurrently active streams using the
1186 SETTINGS_MAX_CONCURRENT_STREAMS parameter (see Section 6.5.2) within
1187 a SETTINGS frame. The maximum concurrent streams setting is specific
1188 to each endpoint and applies only to the peer that receives the
1189 setting. That is, clients specify the maximum number of concurrent
1190 streams the server can initiate, and servers specify the maximum
1191 number of concurrent streams the client can initiate.
1193 Streams that are in the "open" state or in either of the "half-
1194 closed" states count toward the maximum number of streams that an
1195 endpoint is permitted to open. Streams in any of these three states
1196 count toward the limit advertised in the
1197 SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the
1198 "reserved" states do not count toward the stream limit.
1200 Endpoints MUST NOT exceed the limit set by their peer. An endpoint
1201 that receives a HEADERS frame that causes its advertised concurrent
1202 stream limit to be exceeded MUST treat this as a stream error
1203 (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. The choice
1204 of error code determines whether the endpoint wishes to enable
1205 automatic retry (see Section 8.1.4) for details).
1207 An endpoint that wishes to reduce the value of
1208 SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current
1209 number of open streams can either close streams that exceed the new
1210 value or allow streams to complete.
1214 Using streams for multiplexing introduces contention over use of the
1215 TCP connection, resulting in blocked streams. A flow-control scheme
1216 ensures that streams on the same connection do not destructively
1217 interfere with each other. Flow control is used for both individual
1218 streams and for the connection as a whole.
1220 HTTP/2 provides for flow control through use of the WINDOW_UPDATE
1221 frame (Section 6.9).
1234 Belshe, et al. Standards Track [Page 22]
1236 RFC 7540 HTTP/2 May 2015
1239 5.2.1. Flow-Control Principles
1241 HTTP/2 stream flow control aims to allow a variety of flow-control
1242 algorithms to be used without requiring protocol changes. Flow
1243 control in HTTP/2 has the following characteristics:
1245 1. Flow control is specific to a connection. Both types of flow
1246 control are between the endpoints of a single hop and not over
1247 the entire end-to-end path.
1249 2. Flow control is based on WINDOW_UPDATE frames. Receivers
1250 advertise how many octets they are prepared to receive on a
1251 stream and for the entire connection. This is a credit-based
1254 3. Flow control is directional with overall control provided by the
1255 receiver. A receiver MAY choose to set any window size that it
1256 desires for each stream and for the entire connection. A sender
1257 MUST respect flow-control limits imposed by a receiver. Clients,
1258 servers, and intermediaries all independently advertise their
1259 flow-control window as a receiver and abide by the flow-control
1260 limits set by their peer when sending.
1262 4. The initial value for the flow-control window is 65,535 octets
1263 for both new streams and the overall connection.
1265 5. The frame type determines whether flow control applies to a
1266 frame. Of the frames specified in this document, only DATA
1267 frames are subject to flow control; all other frame types do not
1268 consume space in the advertised flow-control window. This
1269 ensures that important control frames are not blocked by flow
1272 6. Flow control cannot be disabled.
1274 7. HTTP/2 defines only the format and semantics of the WINDOW_UPDATE
1275 frame (Section 6.9). This document does not stipulate how a
1276 receiver decides when to send this frame or the value that it
1277 sends, nor does it specify how a sender chooses to send packets.
1278 Implementations are able to select any algorithm that suits their
1281 Implementations are also responsible for managing how requests and
1282 responses are sent based on priority, choosing how to avoid head-of-
1283 line blocking for requests, and managing the creation of new streams.
1284 Algorithm choices for these could interact with any flow-control
1290 Belshe, et al. Standards Track [Page 23]
1292 RFC 7540 HTTP/2 May 2015
1295 5.2.2. Appropriate Use of Flow Control
1297 Flow control is defined to protect endpoints that are operating under
1298 resource constraints. For example, a proxy needs to share memory
1299 between many connections and also might have a slow upstream
1300 connection and a fast downstream one. Flow-control addresses cases
1301 where the receiver is unable to process data on one stream yet wants
1302 to continue to process other streams in the same connection.
1304 Deployments that do not require this capability can advertise a flow-
1305 control window of the maximum size (2^31-1) and can maintain this
1306 window by sending a WINDOW_UPDATE frame when any data is received.
1307 This effectively disables flow control for that receiver.
1308 Conversely, a sender is always subject to the flow-control window
1309 advertised by the receiver.
1311 Deployments with constrained resources (for example, memory) can
1312 employ flow control to limit the amount of memory a peer can consume.
1313 Note, however, that this can lead to suboptimal use of available
1314 network resources if flow control is enabled without knowledge of the
1315 bandwidth-delay product (see [RFC7323]).
1317 Even with full awareness of the current bandwidth-delay product,
1318 implementation of flow control can be difficult. When using flow
1319 control, the receiver MUST read from the TCP receive buffer in a
1320 timely fashion. Failure to do so could lead to a deadlock when
1321 critical frames, such as WINDOW_UPDATE, are not read and acted upon.
1323 5.3. Stream Priority
1325 A client can assign a priority for a new stream by including
1326 prioritization information in the HEADERS frame (Section 6.2) that
1327 opens the stream. At any other time, the PRIORITY frame
1328 (Section 6.3) can be used to change the priority of a stream.
1330 The purpose of prioritization is to allow an endpoint to express how
1331 it would prefer its peer to allocate resources when managing
1332 concurrent streams. Most importantly, priority can be used to select
1333 streams for transmitting frames when there is limited capacity for
1336 Streams can be prioritized by marking them as dependent on the
1337 completion of other streams (Section 5.3.1). Each dependency is
1338 assigned a relative weight, a number that is used to determine the
1339 relative proportion of available resources that are assigned to
1340 streams dependent on the same stream.
1346 Belshe, et al. Standards Track [Page 24]
1348 RFC 7540 HTTP/2 May 2015
1351 Explicitly setting the priority for a stream is input to a
1352 prioritization process. It does not guarantee any particular
1353 processing or transmission order for the stream relative to any other
1354 stream. An endpoint cannot force a peer to process concurrent
1355 streams in a particular order using priority. Expressing priority is
1356 therefore only a suggestion.
1358 Prioritization information can be omitted from messages. Defaults
1359 are used prior to any explicit values being provided (Section 5.3.5).
1361 5.3.1. Stream Dependencies
1363 Each stream can be given an explicit dependency on another stream.
1364 Including a dependency expresses a preference to allocate resources
1365 to the identified stream rather than to the dependent stream.
1367 A stream that is not dependent on any other stream is given a stream
1368 dependency of 0x0. In other words, the non-existent stream 0 forms
1369 the root of the tree.
1371 A stream that depends on another stream is a dependent stream. The
1372 stream upon which a stream is dependent is a parent stream. A
1373 dependency on a stream that is not currently in the tree -- such as a
1374 stream in the "idle" state -- results in that stream being given a
1375 default priority (Section 5.3.5).
1377 When assigning a dependency on another stream, the stream is added as
1378 a new dependency of the parent stream. Dependent streams that share
1379 the same parent are not ordered with respect to each other. For
1380 example, if streams B and C are dependent on stream A, and if stream
1381 D is created with a dependency on stream A, this results in a
1382 dependency order of A followed by B, C, and D in any order.
1388 Figure 3: Example of Default Dependency Creation
1390 An exclusive flag allows for the insertion of a new level of
1391 dependencies. The exclusive flag causes the stream to become the
1392 sole dependency of its parent stream, causing other dependencies to
1393 become dependent on the exclusive stream. In the previous example,
1394 if stream D is created with an exclusive dependency on stream A, this
1395 results in D becoming the dependency parent of B and C.
1402 Belshe, et al. Standards Track [Page 25]
1404 RFC 7540 HTTP/2 May 2015
1413 Figure 4: Example of Exclusive Dependency Creation
1415 Inside the dependency tree, a dependent stream SHOULD only be
1416 allocated resources if either all of the streams that it depends on
1417 (the chain of parent streams up to 0x0) are closed or it is not
1418 possible to make progress on them.
1420 A stream cannot depend on itself. An endpoint MUST treat this as a
1421 stream error (Section 5.4.2) of type PROTOCOL_ERROR.
1423 5.3.2. Dependency Weighting
1425 All dependent streams are allocated an integer weight between 1 and
1428 Streams with the same parent SHOULD be allocated resources
1429 proportionally based on their weight. Thus, if stream B depends on
1430 stream A with weight 4, stream C depends on stream A with weight 12,
1431 and no progress can be made on stream A, stream B ideally receives
1432 one-third of the resources allocated to stream C.
1434 5.3.3. Reprioritization
1436 Stream priorities are changed using the PRIORITY frame. Setting a
1437 dependency causes a stream to become dependent on the identified
1440 Dependent streams move with their parent stream if the parent is
1441 reprioritized. Setting a dependency with the exclusive flag for a
1442 reprioritized stream causes all the dependencies of the new parent
1443 stream to become dependent on the reprioritized stream.
1445 If a stream is made dependent on one of its own dependencies, the
1446 formerly dependent stream is first moved to be dependent on the
1447 reprioritized stream's previous parent. The moved dependency retains
1450 For example, consider an original dependency tree where B and C
1451 depend on A, D and E depend on C, and F depends on D. If A is made
1452 dependent on D, then D takes the place of A. All other dependency
1453 relationships stay the same, except for F, which becomes dependent on
1454 A if the reprioritization is exclusive.
1458 Belshe, et al. Standards Track [Page 26]
1460 RFC 7540 HTTP/2 May 2015
1467 B C ==> F B C ==> F A OR A
1472 (intermediate) (non-exclusive) (exclusive)
1474 Figure 5: Example of Dependency Reordering
1476 5.3.4. Prioritization State Management
1478 When a stream is removed from the dependency tree, its dependencies
1479 can be moved to become dependent on the parent of the closed stream.
1480 The weights of new dependencies are recalculated by distributing the
1481 weight of the dependency of the closed stream proportionally based on
1482 the weights of its dependencies.
1484 Streams that are removed from the dependency tree cause some
1485 prioritization information to be lost. Resources are shared between
1486 streams with the same parent stream, which means that if a stream in
1487 that set closes or becomes blocked, any spare capacity allocated to a
1488 stream is distributed to the immediate neighbors of the stream.
1489 However, if the common dependency is removed from the tree, those
1490 streams share resources with streams at the next highest level.
1492 For example, assume streams A and B share a parent, and streams C and
1493 D both depend on stream A. Prior to the removal of stream A, if
1494 streams A and D are unable to proceed, then stream C receives all the
1495 resources dedicated to stream A. If stream A is removed from the
1496 tree, the weight of stream A is divided between streams C and D. If
1497 stream D is still unable to proceed, this results in stream C
1498 receiving a reduced proportion of resources. For equal starting
1499 weights, C receives one third, rather than one half, of available
1502 It is possible for a stream to become closed while prioritization
1503 information that creates a dependency on that stream is in transit.
1504 If a stream identified in a dependency has no associated priority
1505 information, then the dependent stream is instead assigned a default
1506 priority (Section 5.3.5). This potentially creates suboptimal
1507 prioritization, since the stream could be given a priority that is
1508 different from what is intended.
1514 Belshe, et al. Standards Track [Page 27]
1516 RFC 7540 HTTP/2 May 2015
1519 To avoid these problems, an endpoint SHOULD retain stream
1520 prioritization state for a period after streams become closed. The
1521 longer state is retained, the lower the chance that streams are
1522 assigned incorrect or default priority values.
1524 Similarly, streams that are in the "idle" state can be assigned
1525 priority or become a parent of other streams. This allows for the
1526 creation of a grouping node in the dependency tree, which enables
1527 more flexible expressions of priority. Idle streams begin with a
1528 default priority (Section 5.3.5).
1530 The retention of priority information for streams that are not
1531 counted toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could
1532 create a large state burden for an endpoint. Therefore, the amount
1533 of prioritization state that is retained MAY be limited.
1535 The amount of additional state an endpoint maintains for
1536 prioritization could be dependent on load; under high load,
1537 prioritization state can be discarded to limit resource commitments.
1538 In extreme cases, an endpoint could even discard prioritization state
1539 for active or reserved streams. If a limit is applied, endpoints
1540 SHOULD maintain state for at least as many streams as allowed by
1541 their setting for SETTINGS_MAX_CONCURRENT_STREAMS. Implementations
1542 SHOULD also attempt to retain state for streams that are in active
1543 use in the priority tree.
1545 If it has retained enough state to do so, an endpoint receiving a
1546 PRIORITY frame that changes the priority of a closed stream SHOULD
1547 alter the dependencies of the streams that depend on it.
1549 5.3.5. Default Priorities
1551 All streams are initially assigned a non-exclusive dependency on
1552 stream 0x0. Pushed streams (Section 8.2) initially depend on their
1553 associated stream. In both cases, streams are assigned a default
1558 HTTP/2 framing permits two classes of error:
1560 o An error condition that renders the entire connection unusable is
1563 o An error in an individual stream is a stream error.
1565 A list of error codes is included in Section 7.
1570 Belshe, et al. Standards Track [Page 28]
1572 RFC 7540 HTTP/2 May 2015
1575 5.4.1. Connection Error Handling
1577 A connection error is any error that prevents further processing of
1578 the frame layer or corrupts any connection state.
1580 An endpoint that encounters a connection error SHOULD first send a
1581 GOAWAY frame (Section 6.8) with the stream identifier of the last
1582 stream that it successfully received from its peer. The GOAWAY frame
1583 includes an error code that indicates why the connection is
1584 terminating. After sending the GOAWAY frame for an error condition,
1585 the endpoint MUST close the TCP connection.
1587 It is possible that the GOAWAY will not be reliably received by the
1588 receiving endpoint ([RFC7230], Section 6.6 describes how an immediate
1589 connection close can result in data loss). In the event of a
1590 connection error, GOAWAY only provides a best-effort attempt to
1591 communicate with the peer about why the connection is being
1594 An endpoint can end a connection at any time. In particular, an
1595 endpoint MAY choose to treat a stream error as a connection error.
1596 Endpoints SHOULD send a GOAWAY frame when ending a connection,
1597 providing that circumstances permit it.
1599 5.4.2. Stream Error Handling
1601 A stream error is an error related to a specific stream that does not
1602 affect processing of other streams.
1604 An endpoint that detects a stream error sends a RST_STREAM frame
1605 (Section 6.4) that contains the stream identifier of the stream where
1606 the error occurred. The RST_STREAM frame includes an error code that
1607 indicates the type of error.
1609 A RST_STREAM is the last frame that an endpoint can send on a stream.
1610 The peer that sends the RST_STREAM frame MUST be prepared to receive
1611 any frames that were sent or enqueued for sending by the remote peer.
1612 These frames can be ignored, except where they modify connection
1613 state (such as the state maintained for header compression
1614 (Section 4.3) or flow control).
1616 Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
1617 for any stream. However, an endpoint MAY send additional RST_STREAM
1618 frames if it receives frames on a closed stream after more than a
1619 round-trip time. This behavior is permitted to deal with misbehaving
1626 Belshe, et al. Standards Track [Page 29]
1628 RFC 7540 HTTP/2 May 2015
1631 To avoid looping, an endpoint MUST NOT send a RST_STREAM in response
1632 to a RST_STREAM frame.
1634 5.4.3. Connection Termination
1636 If the TCP connection is closed or reset while streams remain in
1637 "open" or "half-closed" state, then the affected streams cannot be
1638 automatically retried (see Section 8.1.4 for details).
1640 5.5. Extending HTTP/2
1642 HTTP/2 permits extension of the protocol. Within the limitations
1643 described in this section, protocol extensions can be used to provide
1644 additional services or alter any aspect of the protocol. Extensions
1645 are effective only within the scope of a single HTTP/2 connection.
1647 This applies to the protocol elements defined in this document. This
1648 does not affect the existing options for extending HTTP, such as
1649 defining new methods, status codes, or header fields.
1651 Extensions are permitted to use new frame types (Section 4.1), new
1652 settings (Section 6.5.2), or new error codes (Section 7). Registries
1653 are established for managing these extension points: frame types
1654 (Section 11.2), settings (Section 11.3), and error codes
1657 Implementations MUST ignore unknown or unsupported values in all
1658 extensible protocol elements. Implementations MUST discard frames
1659 that have unknown or unsupported types. This means that any of these
1660 extension points can be safely used by extensions without prior
1661 arrangement or negotiation. However, extension frames that appear in
1662 the middle of a header block (Section 4.3) are not permitted; these
1663 MUST be treated as a connection error (Section 5.4.1) of type
1666 Extensions that could change the semantics of existing protocol
1667 components MUST be negotiated before being used. For example, an
1668 extension that changes the layout of the HEADERS frame cannot be used
1669 until the peer has given a positive signal that this is acceptable.
1670 In this case, it could also be necessary to coordinate when the
1671 revised layout comes into effect. Note that treating any frames
1672 other than DATA frames as flow controlled is such a change in
1673 semantics and can only be done through negotiation.
1675 This document doesn't mandate a specific method for negotiating the
1676 use of an extension but notes that a setting (Section 6.5.2) could be
1677 used for that purpose. If both peers set a value that indicates
1678 willingness to use the extension, then the extension can be used. If
1682 Belshe, et al. Standards Track [Page 30]
1684 RFC 7540 HTTP/2 May 2015
1687 a setting is used for extension negotiation, the initial value MUST
1688 be defined in such a fashion that the extension is initially
1691 6. Frame Definitions
1693 This specification defines a number of frame types, each identified
1694 by a unique 8-bit type code. Each frame type serves a distinct
1695 purpose in the establishment and management either of the connection
1696 as a whole or of individual streams.
1698 The transmission of specific frame types can alter the state of a
1699 connection. If endpoints fail to maintain a synchronized view of the
1700 connection state, successful communication within the connection will
1701 no longer be possible. Therefore, it is important that endpoints
1702 have a shared comprehension of how the state is affected by the use
1707 DATA frames (type=0x0) convey arbitrary, variable-length sequences of
1708 octets associated with a stream. One or more DATA frames are used,
1709 for instance, to carry HTTP request or response payloads.
1711 DATA frames MAY also contain padding. Padding can be added to DATA
1712 frames to obscure the size of messages. Padding is a security
1713 feature; see Section 10.7.
1717 +---------------+-----------------------------------------------+
1719 +---------------------------------------------------------------+
1721 +---------------------------------------------------------------+
1723 Figure 6: DATA Frame Payload
1725 The DATA frame contains the following fields:
1727 Pad Length: An 8-bit field containing the length of the frame
1728 padding in units of octets. This field is conditional (as
1729 signified by a "?" in the diagram) and is only present if the
1732 Data: Application data. The amount of data is the remainder of the
1733 frame payload after subtracting the length of the other fields
1738 Belshe, et al. Standards Track [Page 31]
1740 RFC 7540 HTTP/2 May 2015
1743 Padding: Padding octets that contain no application semantic value.
1744 Padding octets MUST be set to zero when sending. A receiver is
1745 not obligated to verify padding but MAY treat non-zero padding as
1746 a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
1748 The DATA frame defines the following flags:
1750 END_STREAM (0x1): When set, bit 0 indicates that this frame is the
1751 last that the endpoint will send for the identified stream.
1752 Setting this flag causes the stream to enter one of the "half-
1753 closed" states or the "closed" state (Section 5.1).
1755 PADDED (0x8): When set, bit 3 indicates that the Pad Length field
1756 and any padding that it describes are present.
1758 DATA frames MUST be associated with a stream. If a DATA frame is
1759 received whose stream identifier field is 0x0, the recipient MUST
1760 respond with a connection error (Section 5.4.1) of type
1763 DATA frames are subject to flow control and can only be sent when a
1764 stream is in the "open" or "half-closed (remote)" state. The entire
1765 DATA frame payload is included in flow control, including the Pad
1766 Length and Padding fields if present. If a DATA frame is received
1767 whose stream is not in "open" or "half-closed (local)" state, the
1768 recipient MUST respond with a stream error (Section 5.4.2) of type
1771 The total number of padding octets is determined by the value of the
1772 Pad Length field. If the length of the padding is the length of the
1773 frame payload or greater, the recipient MUST treat this as a
1774 connection error (Section 5.4.1) of type PROTOCOL_ERROR.
1776 Note: A frame can be increased in size by one octet by including a
1777 Pad Length field with a value of zero.
1781 The HEADERS frame (type=0x1) is used to open a stream (Section 5.1),
1782 and additionally carries a header block fragment. HEADERS frames can
1783 be sent on a stream in the "idle", "reserved (local)", "open", or
1784 "half-closed (remote)" state.
1794 Belshe, et al. Standards Track [Page 32]
1796 RFC 7540 HTTP/2 May 2015
1801 +-+-------------+-----------------------------------------------+
1802 |E| Stream Dependency? (31) |
1803 +-+-------------+-----------------------------------------------+
1805 +-+-------------+-----------------------------------------------+
1806 | Header Block Fragment (*) ...
1807 +---------------------------------------------------------------+
1809 +---------------------------------------------------------------+
1811 Figure 7: HEADERS Frame Payload
1813 The HEADERS frame payload has the following fields:
1815 Pad Length: An 8-bit field containing the length of the frame
1816 padding in units of octets. This field is only present if the
1819 E: A single-bit flag indicating that the stream dependency is
1820 exclusive (see Section 5.3). This field is only present if the
1821 PRIORITY flag is set.
1823 Stream Dependency: A 31-bit stream identifier for the stream that
1824 this stream depends on (see Section 5.3). This field is only
1825 present if the PRIORITY flag is set.
1827 Weight: An unsigned 8-bit integer representing a priority weight for
1828 the stream (see Section 5.3). Add one to the value to obtain a
1829 weight between 1 and 256. This field is only present if the
1830 PRIORITY flag is set.
1832 Header Block Fragment: A header block fragment (Section 4.3).
1834 Padding: Padding octets.
1836 The HEADERS frame defines the following flags:
1838 END_STREAM (0x1): When set, bit 0 indicates that the header block
1839 (Section 4.3) is the last that the endpoint will send for the
1842 A HEADERS frame carries the END_STREAM flag that signals the end
1843 of a stream. However, a HEADERS frame with the END_STREAM flag
1844 set can be followed by CONTINUATION frames on the same stream.
1845 Logically, the CONTINUATION frames are part of the HEADERS frame.
1850 Belshe, et al. Standards Track [Page 33]
1852 RFC 7540 HTTP/2 May 2015
1855 END_HEADERS (0x4): When set, bit 2 indicates that this frame
1856 contains an entire header block (Section 4.3) and is not followed
1857 by any CONTINUATION frames.
1859 A HEADERS frame without the END_HEADERS flag set MUST be followed
1860 by a CONTINUATION frame for the same stream. A receiver MUST
1861 treat the receipt of any other type of frame or a frame on a
1862 different stream as a connection error (Section 5.4.1) of type
1865 PADDED (0x8): When set, bit 3 indicates that the Pad Length field
1866 and any padding that it describes are present.
1868 PRIORITY (0x20): When set, bit 5 indicates that the Exclusive Flag
1869 (E), Stream Dependency, and Weight fields are present; see
1872 The payload of a HEADERS frame contains a header block fragment
1873 (Section 4.3). A header block that does not fit within a HEADERS
1874 frame is continued in a CONTINUATION frame (Section 6.10).
1876 HEADERS frames MUST be associated with a stream. If a HEADERS frame
1877 is received whose stream identifier field is 0x0, the recipient MUST
1878 respond with a connection error (Section 5.4.1) of type
1881 The HEADERS frame changes the connection state as described in
1884 The HEADERS frame can include padding. Padding fields and flags are
1885 identical to those defined for DATA frames (Section 6.1). Padding
1886 that exceeds the size remaining for the header block fragment MUST be
1887 treated as a PROTOCOL_ERROR.
1889 Prioritization information in a HEADERS frame is logically equivalent
1890 to a separate PRIORITY frame, but inclusion in HEADERS avoids the
1891 potential for churn in stream prioritization when new streams are
1892 created. Prioritization fields in HEADERS frames subsequent to the
1893 first on a stream reprioritize the stream (Section 5.3.3).
1897 The PRIORITY frame (type=0x2) specifies the sender-advised priority
1898 of a stream (Section 5.3). It can be sent in any stream state,
1899 including idle or closed streams.
1906 Belshe, et al. Standards Track [Page 34]
1908 RFC 7540 HTTP/2 May 2015
1911 +-+-------------------------------------------------------------+
1912 |E| Stream Dependency (31) |
1913 +-+-------------+-----------------------------------------------+
1917 Figure 8: PRIORITY Frame Payload
1919 The payload of a PRIORITY frame contains the following fields:
1921 E: A single-bit flag indicating that the stream dependency is
1922 exclusive (see Section 5.3).
1924 Stream Dependency: A 31-bit stream identifier for the stream that
1925 this stream depends on (see Section 5.3).
1927 Weight: An unsigned 8-bit integer representing a priority weight for
1928 the stream (see Section 5.3). Add one to the value to obtain a
1929 weight between 1 and 256.
1931 The PRIORITY frame does not define any flags.
1933 The PRIORITY frame always identifies a stream. If a PRIORITY frame
1934 is received with a stream identifier of 0x0, the recipient MUST
1935 respond with a connection error (Section 5.4.1) of type
1938 The PRIORITY frame can be sent on a stream in any state, though it
1939 cannot be sent between consecutive frames that comprise a single
1940 header block (Section 4.3). Note that this frame could arrive after
1941 processing or frame sending has completed, which would cause it to
1942 have no effect on the identified stream. For a stream that is in the
1943 "half-closed (remote)" or "closed" state, this frame can only affect
1944 processing of the identified stream and its dependent streams; it
1945 does not affect frame transmission on that stream.
1947 The PRIORITY frame can be sent for a stream in the "idle" or "closed"
1948 state. This allows for the reprioritization of a group of dependent
1949 streams by altering the priority of an unused or closed parent
1952 A PRIORITY frame with a length other than 5 octets MUST be treated as
1953 a stream error (Section 5.4.2) of type FRAME_SIZE_ERROR.
1962 Belshe, et al. Standards Track [Page 35]
1964 RFC 7540 HTTP/2 May 2015
1969 The RST_STREAM frame (type=0x3) allows for immediate termination of a
1970 stream. RST_STREAM is sent to request cancellation of a stream or to
1971 indicate that an error condition has occurred.
1973 +---------------------------------------------------------------+
1975 +---------------------------------------------------------------+
1977 Figure 9: RST_STREAM Frame Payload
1979 The RST_STREAM frame contains a single unsigned, 32-bit integer
1980 identifying the error code (Section 7). The error code indicates why
1981 the stream is being terminated.
1983 The RST_STREAM frame does not define any flags.
1985 The RST_STREAM frame fully terminates the referenced stream and
1986 causes it to enter the "closed" state. After receiving a RST_STREAM
1987 on a stream, the receiver MUST NOT send additional frames for that
1988 stream, with the exception of PRIORITY. However, after sending the
1989 RST_STREAM, the sending endpoint MUST be prepared to receive and
1990 process additional frames sent on the stream that might have been
1991 sent by the peer prior to the arrival of the RST_STREAM.
1993 RST_STREAM frames MUST be associated with a stream. If a RST_STREAM
1994 frame is received with a stream identifier of 0x0, the recipient MUST
1995 treat this as a connection error (Section 5.4.1) of type
1998 RST_STREAM frames MUST NOT be sent for a stream in the "idle" state.
1999 If a RST_STREAM frame identifying an idle stream is received, the
2000 recipient MUST treat this as a connection error (Section 5.4.1) of
2001 type PROTOCOL_ERROR.
2003 A RST_STREAM frame with a length other than 4 octets MUST be treated
2004 as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR.
2008 The SETTINGS frame (type=0x4) conveys configuration parameters that
2009 affect how endpoints communicate, such as preferences and constraints
2010 on peer behavior. The SETTINGS frame is also used to acknowledge the
2011 receipt of those parameters. Individually, a SETTINGS parameter can
2012 also be referred to as a "setting".
2018 Belshe, et al. Standards Track [Page 36]
2020 RFC 7540 HTTP/2 May 2015
2023 SETTINGS parameters are not negotiated; they describe characteristics
2024 of the sending peer, which are used by the receiving peer. Different
2025 values for the same parameter can be advertised by each peer. For
2026 example, a client might set a high initial flow-control window,
2027 whereas a server might set a lower value to conserve resources.
2029 A SETTINGS frame MUST be sent by both endpoints at the start of a
2030 connection and MAY be sent at any other time by either endpoint over
2031 the lifetime of the connection. Implementations MUST support all of
2032 the parameters defined by this specification.
2034 Each parameter in a SETTINGS frame replaces any existing value for
2035 that parameter. Parameters are processed in the order in which they
2036 appear, and a receiver of a SETTINGS frame does not need to maintain
2037 any state other than the current value of its parameters. Therefore,
2038 the value of a SETTINGS parameter is the last value that is seen by a
2041 SETTINGS parameters are acknowledged by the receiving peer. To
2042 enable this, the SETTINGS frame defines the following flag:
2044 ACK (0x1): When set, bit 0 indicates that this frame acknowledges
2045 receipt and application of the peer's SETTINGS frame. When this
2046 bit is set, the payload of the SETTINGS frame MUST be empty.
2047 Receipt of a SETTINGS frame with the ACK flag set and a length
2048 field value other than 0 MUST be treated as a connection error
2049 (Section 5.4.1) of type FRAME_SIZE_ERROR. For more information,
2050 see Section 6.5.3 ("Settings Synchronization").
2052 SETTINGS frames always apply to a connection, never a single stream.
2053 The stream identifier for a SETTINGS frame MUST be zero (0x0). If an
2054 endpoint receives a SETTINGS frame whose stream identifier field is
2055 anything other than 0x0, the endpoint MUST respond with a connection
2056 error (Section 5.4.1) of type PROTOCOL_ERROR.
2058 The SETTINGS frame affects connection state. A badly formed or
2059 incomplete SETTINGS frame MUST be treated as a connection error
2060 (Section 5.4.1) of type PROTOCOL_ERROR.
2062 A SETTINGS frame with a length other than a multiple of 6 octets MUST
2063 be treated as a connection error (Section 5.4.1) of type
2074 Belshe, et al. Standards Track [Page 37]
2076 RFC 7540 HTTP/2 May 2015
2079 6.5.1. SETTINGS Format
2081 The payload of a SETTINGS frame consists of zero or more parameters,
2082 each consisting of an unsigned 16-bit setting identifier and an
2083 unsigned 32-bit value.
2085 +-------------------------------+
2087 +-------------------------------+-------------------------------+
2089 +---------------------------------------------------------------+
2091 Figure 10: Setting Format
2093 6.5.2. Defined SETTINGS Parameters
2095 The following parameters are defined:
2097 SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the
2098 remote endpoint of the maximum size of the header compression
2099 table used to decode header blocks, in octets. The encoder can
2100 select any size equal to or less than this value by using
2101 signaling specific to the header compression format inside a
2102 header block (see [COMPRESSION]). The initial value is 4,096
2105 SETTINGS_ENABLE_PUSH (0x2): This setting can be used to disable
2106 server push (Section 8.2). An endpoint MUST NOT send a
2107 PUSH_PROMISE frame if it receives this parameter set to a value of
2108 0. An endpoint that has both set this parameter to 0 and had it
2109 acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a
2110 connection error (Section 5.4.1) of type PROTOCOL_ERROR.
2112 The initial value is 1, which indicates that server push is
2113 permitted. Any value other than 0 or 1 MUST be treated as a
2114 connection error (Section 5.4.1) of type PROTOCOL_ERROR.
2116 SETTINGS_MAX_CONCURRENT_STREAMS (0x3): Indicates the maximum number
2117 of concurrent streams that the sender will allow. This limit is
2118 directional: it applies to the number of streams that the sender
2119 permits the receiver to create. Initially, there is no limit to
2120 this value. It is recommended that this value be no smaller than
2121 100, so as to not unnecessarily limit parallelism.
2123 A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be
2124 treated as special by endpoints. A zero value does prevent the
2125 creation of new streams; however, this can also happen for any
2130 Belshe, et al. Standards Track [Page 38]
2132 RFC 7540 HTTP/2 May 2015
2135 limit that is exhausted with active streams. Servers SHOULD only
2136 set a zero value for short durations; if a server does not wish to
2137 accept requests, closing the connection is more appropriate.
2139 SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial
2140 window size (in octets) for stream-level flow control. The
2141 initial value is 2^16-1 (65,535) octets.
2143 This setting affects the window size of all streams (see
2146 Values above the maximum flow-control window size of 2^31-1 MUST
2147 be treated as a connection error (Section 5.4.1) of type
2150 SETTINGS_MAX_FRAME_SIZE (0x5): Indicates the size of the largest
2151 frame payload that the sender is willing to receive, in octets.
2153 The initial value is 2^14 (16,384) octets. The value advertised
2154 by an endpoint MUST be between this initial value and the maximum
2155 allowed frame size (2^24-1 or 16,777,215 octets), inclusive.
2156 Values outside this range MUST be treated as a connection error
2157 (Section 5.4.1) of type PROTOCOL_ERROR.
2159 SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This advisory setting informs a
2160 peer of the maximum size of header list that the sender is
2161 prepared to accept, in octets. The value is based on the
2162 uncompressed size of header fields, including the length of the
2163 name and value in octets plus an overhead of 32 octets for each
2166 For any given request, a lower limit than what is advertised MAY
2167 be enforced. The initial value of this setting is unlimited.
2169 An endpoint that receives a SETTINGS frame with any unknown or
2170 unsupported identifier MUST ignore that setting.
2172 6.5.3. Settings Synchronization
2174 Most values in SETTINGS benefit from or require an understanding of
2175 when the peer has received and applied the changed parameter values.
2176 In order to provide such synchronization timepoints, the recipient of
2177 a SETTINGS frame in which the ACK flag is not set MUST apply the
2178 updated parameters as soon as possible upon receipt.
2180 The values in the SETTINGS frame MUST be processed in the order they
2181 appear, with no other frame processing between values. Unsupported
2182 parameters MUST be ignored. Once all values have been processed, the
2186 Belshe, et al. Standards Track [Page 39]
2188 RFC 7540 HTTP/2 May 2015
2191 recipient MUST immediately emit a SETTINGS frame with the ACK flag
2192 set. Upon receiving a SETTINGS frame with the ACK flag set, the
2193 sender of the altered parameters can rely on the setting having been
2196 If the sender of a SETTINGS frame does not receive an acknowledgement
2197 within a reasonable amount of time, it MAY issue a connection error
2198 (Section 5.4.1) of type SETTINGS_TIMEOUT.
2202 The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint
2203 in advance of streams the sender intends to initiate. The
2204 PUSH_PROMISE frame includes the unsigned 31-bit identifier of the
2205 stream the endpoint plans to create along with a set of headers that
2206 provide additional context for the stream. Section 8.2 contains a
2207 thorough description of the use of PUSH_PROMISE frames.
2211 +-+-------------+-----------------------------------------------+
2212 |R| Promised Stream ID (31) |
2213 +-+-----------------------------+-------------------------------+
2214 | Header Block Fragment (*) ...
2215 +---------------------------------------------------------------+
2217 +---------------------------------------------------------------+
2219 Figure 11: PUSH_PROMISE Payload Format
2221 The PUSH_PROMISE frame payload has the following fields:
2223 Pad Length: An 8-bit field containing the length of the frame
2224 padding in units of octets. This field is only present if the
2227 R: A single reserved bit.
2229 Promised Stream ID: An unsigned 31-bit integer that identifies the
2230 stream that is reserved by the PUSH_PROMISE. The promised stream
2231 identifier MUST be a valid choice for the next stream sent by the
2232 sender (see "new stream identifier" in Section 5.1.1).
2234 Header Block Fragment: A header block fragment (Section 4.3)
2235 containing request header fields.
2237 Padding: Padding octets.
2242 Belshe, et al. Standards Track [Page 40]
2244 RFC 7540 HTTP/2 May 2015
2247 The PUSH_PROMISE frame defines the following flags:
2249 END_HEADERS (0x4): When set, bit 2 indicates that this frame
2250 contains an entire header block (Section 4.3) and is not followed
2251 by any CONTINUATION frames.
2253 A PUSH_PROMISE frame without the END_HEADERS flag set MUST be
2254 followed by a CONTINUATION frame for the same stream. A receiver
2255 MUST treat the receipt of any other type of frame or a frame on a
2256 different stream as a connection error (Section 5.4.1) of type
2259 PADDED (0x8): When set, bit 3 indicates that the Pad Length field
2260 and any padding that it describes are present.
2262 PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that
2263 is in either the "open" or "half-closed (remote)" state. The stream
2264 identifier of a PUSH_PROMISE frame indicates the stream it is
2265 associated with. If the stream identifier field specifies the value
2266 0x0, a recipient MUST respond with a connection error (Section 5.4.1)
2267 of type PROTOCOL_ERROR.
2269 Promised streams are not required to be used in the order they are
2270 promised. The PUSH_PROMISE only reserves stream identifiers for
2273 PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of
2274 the peer endpoint is set to 0. An endpoint that has set this setting
2275 and has received acknowledgement MUST treat the receipt of a
2276 PUSH_PROMISE frame as a connection error (Section 5.4.1) of type
2279 Recipients of PUSH_PROMISE frames can choose to reject promised
2280 streams by returning a RST_STREAM referencing the promised stream
2281 identifier back to the sender of the PUSH_PROMISE.
2283 A PUSH_PROMISE frame modifies the connection state in two ways.
2284 First, the inclusion of a header block (Section 4.3) potentially
2285 modifies the state maintained for header compression. Second,
2286 PUSH_PROMISE also reserves a stream for later use, causing the
2287 promised stream to enter the "reserved" state. A sender MUST NOT
2288 send a PUSH_PROMISE on a stream unless that stream is either "open"
2289 or "half-closed (remote)"; the sender MUST ensure that the promised
2290 stream is a valid choice for a new stream identifier (Section 5.1.1)
2291 (that is, the promised stream MUST be in the "idle" state).
2298 Belshe, et al. Standards Track [Page 41]
2300 RFC 7540 HTTP/2 May 2015
2303 Since PUSH_PROMISE reserves a stream, ignoring a PUSH_PROMISE frame
2304 causes the stream state to become indeterminate. A receiver MUST
2305 treat the receipt of a PUSH_PROMISE on a stream that is neither
2306 "open" nor "half-closed (local)" as a connection error
2307 (Section 5.4.1) of type PROTOCOL_ERROR. However, an endpoint that
2308 has sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE
2309 frames that might have been created before the RST_STREAM frame is
2310 received and processed.
2312 A receiver MUST treat the receipt of a PUSH_PROMISE that promises an
2313 illegal stream identifier (Section 5.1.1) as a connection error
2314 (Section 5.4.1) of type PROTOCOL_ERROR. Note that an illegal stream
2315 identifier is an identifier for a stream that is not currently in the
2318 The PUSH_PROMISE frame can include padding. Padding fields and flags
2319 are identical to those defined for DATA frames (Section 6.1).
2323 The PING frame (type=0x6) is a mechanism for measuring a minimal
2324 round-trip time from the sender, as well as determining whether an
2325 idle connection is still functional. PING frames can be sent from
2328 +---------------------------------------------------------------+
2330 | Opaque Data (64) |
2332 +---------------------------------------------------------------+
2334 Figure 12: PING Payload Format
2336 In addition to the frame header, PING frames MUST contain 8 octets of
2337 opaque data in the payload. A sender can include any value it
2338 chooses and use those octets in any fashion.
2340 Receivers of a PING frame that does not include an ACK flag MUST send
2341 a PING frame with the ACK flag set in response, with an identical
2342 payload. PING responses SHOULD be given higher priority than any
2345 The PING frame defines the following flags:
2347 ACK (0x1): When set, bit 0 indicates that this PING frame is a PING
2348 response. An endpoint MUST set this flag in PING responses. An
2349 endpoint MUST NOT respond to PING frames containing this flag.
2354 Belshe, et al. Standards Track [Page 42]
2356 RFC 7540 HTTP/2 May 2015
2359 PING frames are not associated with any individual stream. If a PING
2360 frame is received with a stream identifier field value other than
2361 0x0, the recipient MUST respond with a connection error
2362 (Section 5.4.1) of type PROTOCOL_ERROR.
2364 Receipt of a PING frame with a length field value other than 8 MUST
2365 be treated as a connection error (Section 5.4.1) of type
2370 The GOAWAY frame (type=0x7) is used to initiate shutdown of a
2371 connection or to signal serious error conditions. GOAWAY allows an
2372 endpoint to gracefully stop accepting new streams while still
2373 finishing processing of previously established streams. This enables
2374 administrative actions, like server maintenance.
2376 There is an inherent race condition between an endpoint starting new
2377 streams and the remote sending a GOAWAY frame. To deal with this
2378 case, the GOAWAY contains the stream identifier of the last peer-
2379 initiated stream that was or might be processed on the sending
2380 endpoint in this connection. For instance, if the server sends a
2381 GOAWAY frame, the identified stream is the highest-numbered stream
2382 initiated by the client.
2384 Once sent, the sender will ignore frames sent on streams initiated by
2385 the receiver if the stream has an identifier higher than the included
2386 last stream identifier. Receivers of a GOAWAY frame MUST NOT open
2387 additional streams on the connection, although a new connection can
2388 be established for new streams.
2390 If the receiver of the GOAWAY has sent data on streams with a higher
2391 stream identifier than what is indicated in the GOAWAY frame, those
2392 streams are not or will not be processed. The receiver of the GOAWAY
2393 frame can treat the streams as though they had never been created at
2394 all, thereby allowing those streams to be retried later on a new
2397 Endpoints SHOULD always send a GOAWAY frame before closing a
2398 connection so that the remote peer can know whether a stream has been
2399 partially processed or not. For example, if an HTTP client sends a
2400 POST at the same time that a server closes a connection, the client
2401 cannot know if the server started to process that POST request if the
2402 server does not send a GOAWAY frame to indicate what streams it might
2405 An endpoint might choose to close a connection without sending a
2406 GOAWAY for misbehaving peers.
2410 Belshe, et al. Standards Track [Page 43]
2412 RFC 7540 HTTP/2 May 2015
2415 A GOAWAY frame might not immediately precede closing of the
2416 connection; a receiver of a GOAWAY that has no more use for the
2417 connection SHOULD still send a GOAWAY frame before terminating the
2420 +-+-------------------------------------------------------------+
2421 |R| Last-Stream-ID (31) |
2422 +-+-------------------------------------------------------------+
2424 +---------------------------------------------------------------+
2425 | Additional Debug Data (*) |
2426 +---------------------------------------------------------------+
2428 Figure 13: GOAWAY Payload Format
2430 The GOAWAY frame does not define any flags.
2432 The GOAWAY frame applies to the connection, not a specific stream.
2433 An endpoint MUST treat a GOAWAY frame with a stream identifier other
2434 than 0x0 as a connection error (Section 5.4.1) of type
2437 The last stream identifier in the GOAWAY frame contains the highest-
2438 numbered stream identifier for which the sender of the GOAWAY frame
2439 might have taken some action on or might yet take action on. All
2440 streams up to and including the identified stream might have been
2441 processed in some way. The last stream identifier can be set to 0 if
2442 no streams were processed.
2444 Note: In this context, "processed" means that some data from the
2445 stream was passed to some higher layer of software that might have
2446 taken some action as a result.
2448 If a connection terminates without a GOAWAY frame, the last stream
2449 identifier is effectively the highest possible stream identifier.
2451 On streams with lower- or equal-numbered identifiers that were not
2452 closed completely prior to the connection being closed, reattempting
2453 requests, transactions, or any protocol activity is not possible,
2454 with the exception of idempotent actions like HTTP GET, PUT, or
2455 DELETE. Any protocol activity that uses higher-numbered streams can
2456 be safely retried using a new connection.
2458 Activity on streams numbered lower or equal to the last stream
2459 identifier might still complete successfully. The sender of a GOAWAY
2460 frame might gracefully shut down a connection by sending a GOAWAY
2461 frame, maintaining the connection in an "open" state until all in-
2462 progress streams complete.
2466 Belshe, et al. Standards Track [Page 44]
2468 RFC 7540 HTTP/2 May 2015
2471 An endpoint MAY send multiple GOAWAY frames if circumstances change.
2472 For instance, an endpoint that sends GOAWAY with NO_ERROR during
2473 graceful shutdown could subsequently encounter a condition that
2474 requires immediate termination of the connection. The last stream
2475 identifier from the last GOAWAY frame received indicates which
2476 streams could have been acted upon. Endpoints MUST NOT increase the
2477 value they send in the last stream identifier, since the peers might
2478 already have retried unprocessed requests on another connection.
2480 A client that is unable to retry requests loses all requests that are
2481 in flight when the server closes the connection. This is especially
2482 true for intermediaries that might not be serving clients using
2483 HTTP/2. A server that is attempting to gracefully shut down a
2484 connection SHOULD send an initial GOAWAY frame with the last stream
2485 identifier set to 2^31-1 and a NO_ERROR code. This signals to the
2486 client that a shutdown is imminent and that initiating further
2487 requests is prohibited. After allowing time for any in-flight stream
2488 creation (at least one round-trip time), the server can send another
2489 GOAWAY frame with an updated last stream identifier. This ensures
2490 that a connection can be cleanly shut down without losing requests.
2492 After sending a GOAWAY frame, the sender can discard frames for
2493 streams initiated by the receiver with identifiers higher than the
2494 identified last stream. However, any frames that alter connection
2495 state cannot be completely ignored. For instance, HEADERS,
2496 PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to
2497 ensure the state maintained for header compression is consistent (see
2498 Section 4.3); similarly, DATA frames MUST be counted toward the
2499 connection flow-control window. Failure to process these frames can
2500 cause flow control or header compression state to become
2503 The GOAWAY frame also contains a 32-bit error code (Section 7) that
2504 contains the reason for closing the connection.
2506 Endpoints MAY append opaque data to the payload of any GOAWAY frame.
2507 Additional debug data is intended for diagnostic purposes only and
2508 carries no semantic value. Debug information could contain security-
2509 or privacy-sensitive data. Logged or otherwise persistently stored
2510 debug data MUST have adequate safeguards to prevent unauthorized
2522 Belshe, et al. Standards Track [Page 45]
2524 RFC 7540 HTTP/2 May 2015
2529 The WINDOW_UPDATE frame (type=0x8) is used to implement flow control;
2530 see Section 5.2 for an overview.
2532 Flow control operates at two levels: on each individual stream and on
2533 the entire connection.
2535 Both types of flow control are hop by hop, that is, only between the
2536 two endpoints. Intermediaries do not forward WINDOW_UPDATE frames
2537 between dependent connections. However, throttling of data transfer
2538 by any receiver can indirectly cause the propagation of flow-control
2539 information toward the original sender.
2541 Flow control only applies to frames that are identified as being
2542 subject to flow control. Of the frame types defined in this
2543 document, this includes only DATA frames. Frames that are exempt
2544 from flow control MUST be accepted and processed, unless the receiver
2545 is unable to assign resources to handling the frame. A receiver MAY
2546 respond with a stream error (Section 5.4.2) or connection error
2547 (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable to accept
2550 +-+-------------------------------------------------------------+
2551 |R| Window Size Increment (31) |
2552 +-+-------------------------------------------------------------+
2554 Figure 14: WINDOW_UPDATE Payload Format
2556 The payload of a WINDOW_UPDATE frame is one reserved bit plus an
2557 unsigned 31-bit integer indicating the number of octets that the
2558 sender can transmit in addition to the existing flow-control window.
2559 The legal range for the increment to the flow-control window is 1 to
2560 2^31-1 (2,147,483,647) octets.
2562 The WINDOW_UPDATE frame does not define any flags.
2564 The WINDOW_UPDATE frame can be specific to a stream or to the entire
2565 connection. In the former case, the frame's stream identifier
2566 indicates the affected stream; in the latter, the value "0" indicates
2567 that the entire connection is the subject of the frame.
2569 A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an
2570 flow-control window increment of 0 as a stream error (Section 5.4.2)
2571 of type PROTOCOL_ERROR; errors on the connection flow-control window
2572 MUST be treated as a connection error (Section 5.4.1).
2578 Belshe, et al. Standards Track [Page 46]
2580 RFC 7540 HTTP/2 May 2015
2583 WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the
2584 END_STREAM flag. This means that a receiver could receive a
2585 WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream.
2586 A receiver MUST NOT treat this as an error (see Section 5.1).
2588 A receiver that receives a flow-controlled frame MUST always account
2589 for its contribution against the connection flow-control window,
2590 unless the receiver treats this as a connection error
2591 (Section 5.4.1). This is necessary even if the frame is in error.
2592 The sender counts the frame toward the flow-control window, but if
2593 the receiver does not, the flow-control window at the sender and
2594 receiver can become different.
2596 A WINDOW_UPDATE frame with a length other than 4 octets MUST be
2597 treated as a connection error (Section 5.4.1) of type
2600 6.9.1. The Flow-Control Window
2602 Flow control in HTTP/2 is implemented using a window kept by each
2603 sender on every stream. The flow-control window is a simple integer
2604 value that indicates how many octets of data the sender is permitted
2605 to transmit; as such, its size is a measure of the buffering capacity
2608 Two flow-control windows are applicable: the stream flow-control
2609 window and the connection flow-control window. The sender MUST NOT
2610 send a flow-controlled frame with a length that exceeds the space
2611 available in either of the flow-control windows advertised by the
2612 receiver. Frames with zero length with the END_STREAM flag set (that
2613 is, an empty DATA frame) MAY be sent if there is no available space
2614 in either flow-control window.
2616 For flow-control calculations, the 9-octet frame header is not
2619 After sending a flow-controlled frame, the sender reduces the space
2620 available in both windows by the length of the transmitted frame.
2622 The receiver of a frame sends a WINDOW_UPDATE frame as it consumes
2623 data and frees up space in flow-control windows. Separate
2624 WINDOW_UPDATE frames are sent for the stream- and connection-level
2625 flow-control windows.
2627 A sender that receives a WINDOW_UPDATE frame updates the
2628 corresponding window by the amount specified in the frame.
2634 Belshe, et al. Standards Track [Page 47]
2636 RFC 7540 HTTP/2 May 2015
2639 A sender MUST NOT allow a flow-control window to exceed 2^31-1
2640 octets. If a sender receives a WINDOW_UPDATE that causes a flow-
2641 control window to exceed this maximum, it MUST terminate either the
2642 stream or the connection, as appropriate. For streams, the sender
2643 sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR; for the
2644 connection, a GOAWAY frame with an error code of FLOW_CONTROL_ERROR
2647 Flow-controlled frames from the sender and WINDOW_UPDATE frames from
2648 the receiver are completely asynchronous with respect to each other.
2649 This property allows a receiver to aggressively update the window
2650 size kept by the sender to prevent streams from stalling.
2652 6.9.2. Initial Flow-Control Window Size
2654 When an HTTP/2 connection is first established, new streams are
2655 created with an initial flow-control window size of 65,535 octets.
2656 The connection flow-control window is also 65,535 octets. Both
2657 endpoints can adjust the initial window size for new streams by
2658 including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS
2659 frame that forms part of the connection preface. The connection
2660 flow-control window can only be changed using WINDOW_UPDATE frames.
2662 Prior to receiving a SETTINGS frame that sets a value for
2663 SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default
2664 initial window size when sending flow-controlled frames. Similarly,
2665 the connection flow-control window is set to the default initial
2666 window size until a WINDOW_UPDATE frame is received.
2668 In addition to changing the flow-control window for streams that are
2669 not yet active, a SETTINGS frame can alter the initial flow-control
2670 window size for streams with active flow-control windows (that is,
2671 streams in the "open" or "half-closed (remote)" state). When the
2672 value of SETTINGS_INITIAL_WINDOW_SIZE changes, a receiver MUST adjust
2673 the size of all stream flow-control windows that it maintains by the
2674 difference between the new value and the old value.
2676 A change to SETTINGS_INITIAL_WINDOW_SIZE can cause the available
2677 space in a flow-control window to become negative. A sender MUST
2678 track the negative flow-control window and MUST NOT send new flow-
2679 controlled frames until it receives WINDOW_UPDATE frames that cause
2680 the flow-control window to become positive.
2682 For example, if the client sends 60 KB immediately on connection
2683 establishment and the server sets the initial window size to be 16
2684 KB, the client will recalculate the available flow-control window to
2690 Belshe, et al. Standards Track [Page 48]
2692 RFC 7540 HTTP/2 May 2015
2695 be -44 KB on receipt of the SETTINGS frame. The client retains a
2696 negative flow-control window until WINDOW_UPDATE frames restore the
2697 window to being positive, after which the client can resume sending.
2699 A SETTINGS frame cannot alter the connection flow-control window.
2701 An endpoint MUST treat a change to SETTINGS_INITIAL_WINDOW_SIZE that
2702 causes any flow-control window to exceed the maximum size as a
2703 connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR.
2705 6.9.3. Reducing the Stream Window Size
2707 A receiver that wishes to use a smaller flow-control window than the
2708 current size can send a new SETTINGS frame. However, the receiver
2709 MUST be prepared to receive data that exceeds this window size, since
2710 the sender might send data that exceeds the lower limit prior to
2711 processing the SETTINGS frame.
2713 After sending a SETTINGS frame that reduces the initial flow-control
2714 window size, a receiver MAY continue to process streams that exceed
2715 flow-control limits. Allowing streams to continue does not allow the
2716 receiver to immediately reduce the space it reserves for flow-control
2717 windows. Progress on these streams can also stall, since
2718 WINDOW_UPDATE frames are needed to allow the sender to resume
2719 sending. The receiver MAY instead send a RST_STREAM with an error
2720 code of FLOW_CONTROL_ERROR for the affected streams.
2724 The CONTINUATION frame (type=0x9) is used to continue a sequence of
2725 header block fragments (Section 4.3). Any number of CONTINUATION
2726 frames can be sent, as long as the preceding frame is on the same
2727 stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without
2728 the END_HEADERS flag set.
2730 +---------------------------------------------------------------+
2731 | Header Block Fragment (*) ...
2732 +---------------------------------------------------------------+
2734 Figure 15: CONTINUATION Frame Payload
2736 The CONTINUATION frame payload contains a header block fragment
2746 Belshe, et al. Standards Track [Page 49]
2748 RFC 7540 HTTP/2 May 2015
2751 The CONTINUATION frame defines the following flag:
2753 END_HEADERS (0x4): When set, bit 2 indicates that this frame ends a
2754 header block (Section 4.3).
2756 If the END_HEADERS bit is not set, this frame MUST be followed by
2757 another CONTINUATION frame. A receiver MUST treat the receipt of
2758 any other type of frame or a frame on a different stream as a
2759 connection error (Section 5.4.1) of type PROTOCOL_ERROR.
2761 The CONTINUATION frame changes the connection state as defined in
2764 CONTINUATION frames MUST be associated with a stream. If a
2765 CONTINUATION frame is received whose stream identifier field is 0x0,
2766 the recipient MUST respond with a connection error (Section 5.4.1) of
2767 type PROTOCOL_ERROR.
2769 A CONTINUATION frame MUST be preceded by a HEADERS, PUSH_PROMISE or
2770 CONTINUATION frame without the END_HEADERS flag set. A recipient
2771 that observes violation of this rule MUST respond with a connection
2772 error (Section 5.4.1) of type PROTOCOL_ERROR.
2776 Error codes are 32-bit fields that are used in RST_STREAM and GOAWAY
2777 frames to convey the reasons for the stream or connection error.
2779 Error codes share a common code space. Some error codes apply only
2780 to either streams or the entire connection and have no defined
2781 semantics in the other context.
2783 The following error codes are defined:
2785 NO_ERROR (0x0): The associated condition is not a result of an
2786 error. For example, a GOAWAY might include this code to indicate
2787 graceful shutdown of a connection.
2789 PROTOCOL_ERROR (0x1): The endpoint detected an unspecific protocol
2790 error. This error is for use when a more specific error code is
2793 INTERNAL_ERROR (0x2): The endpoint encountered an unexpected
2796 FLOW_CONTROL_ERROR (0x3): The endpoint detected that its peer
2797 violated the flow-control protocol.
2802 Belshe, et al. Standards Track [Page 50]
2804 RFC 7540 HTTP/2 May 2015
2807 SETTINGS_TIMEOUT (0x4): The endpoint sent a SETTINGS frame but did
2808 not receive a response in a timely manner. See Section 6.5.3
2809 ("Settings Synchronization").
2811 STREAM_CLOSED (0x5): The endpoint received a frame after a stream
2814 FRAME_SIZE_ERROR (0x6): The endpoint received a frame with an
2817 REFUSED_STREAM (0x7): The endpoint refused the stream prior to
2818 performing any application processing (see Section 8.1.4 for
2821 CANCEL (0x8): Used by the endpoint to indicate that the stream is no
2824 COMPRESSION_ERROR (0x9): The endpoint is unable to maintain the
2825 header compression context for the connection.
2827 CONNECT_ERROR (0xa): The connection established in response to a
2828 CONNECT request (Section 8.3) was reset or abnormally closed.
2830 ENHANCE_YOUR_CALM (0xb): The endpoint detected that its peer is
2831 exhibiting a behavior that might be generating excessive load.
2833 INADEQUATE_SECURITY (0xc): The underlying transport has properties
2834 that do not meet minimum security requirements (see Section 9.2).
2836 HTTP_1_1_REQUIRED (0xd): The endpoint requires that HTTP/1.1 be used
2839 Unknown or unsupported error codes MUST NOT trigger any special
2840 behavior. These MAY be treated by an implementation as being
2841 equivalent to INTERNAL_ERROR.
2843 8. HTTP Message Exchanges
2845 HTTP/2 is intended to be as compatible as possible with current uses
2846 of HTTP. This means that, from the application perspective, the
2847 features of the protocol are largely unchanged. To achieve this, all
2848 request and response semantics are preserved, although the syntax of
2849 conveying those semantics has changed.
2851 Thus, the specification and requirements of HTTP/1.1 Semantics and
2852 Content [RFC7231], Conditional Requests [RFC7232], Range Requests
2853 [RFC7233], Caching [RFC7234], and Authentication [RFC7235] are
2854 applicable to HTTP/2. Selected portions of HTTP/1.1 Message Syntax
2858 Belshe, et al. Standards Track [Page 51]
2860 RFC 7540 HTTP/2 May 2015
2863 and Routing [RFC7230], such as the HTTP and HTTPS URI schemes, are
2864 also applicable in HTTP/2, but the expression of those semantics for
2865 this protocol are defined in the sections below.
2867 8.1. HTTP Request/Response Exchange
2869 A client sends an HTTP request on a new stream, using a previously
2870 unused stream identifier (Section 5.1.1). A server sends an HTTP
2871 response on the same stream as the request.
2873 An HTTP message (request or response) consists of:
2875 1. for a response only, zero or more HEADERS frames (each followed
2876 by zero or more CONTINUATION frames) containing the message
2877 headers of informational (1xx) HTTP responses (see [RFC7230],
2878 Section 3.2 and [RFC7231], Section 6.2),
2880 2. one HEADERS frame (followed by zero or more CONTINUATION frames)
2881 containing the message headers (see [RFC7230], Section 3.2),
2883 3. zero or more DATA frames containing the payload body (see
2884 [RFC7230], Section 3.3), and
2886 4. optionally, one HEADERS frame, followed by zero or more
2887 CONTINUATION frames containing the trailer-part, if present (see
2888 [RFC7230], Section 4.1.2).
2890 The last frame in the sequence bears an END_STREAM flag, noting that
2891 a HEADERS frame bearing the END_STREAM flag can be followed by
2892 CONTINUATION frames that carry any remaining portions of the header
2895 Other frames (from any stream) MUST NOT occur between the HEADERS
2896 frame and any CONTINUATION frames that might follow.
2898 HTTP/2 uses DATA frames to carry message payloads. The "chunked"
2899 transfer encoding defined in Section 4.1 of [RFC7230] MUST NOT be
2902 Trailing header fields are carried in a header block that also
2903 terminates the stream. Such a header block is a sequence starting
2904 with a HEADERS frame, followed by zero or more CONTINUATION frames,
2905 where the HEADERS frame bears an END_STREAM flag. Header blocks
2906 after the first that do not terminate the stream are not part of an
2907 HTTP request or response.
2914 Belshe, et al. Standards Track [Page 52]
2916 RFC 7540 HTTP/2 May 2015
2919 A HEADERS frame (and associated CONTINUATION frames) can only appear
2920 at the start or end of a stream. An endpoint that receives a HEADERS
2921 frame without the END_STREAM flag set after receiving a final (non-
2922 informational) status code MUST treat the corresponding request or
2923 response as malformed (Section 8.1.2.6).
2925 An HTTP request/response exchange fully consumes a single stream. A
2926 request starts with the HEADERS frame that puts the stream into an
2927 "open" state. The request ends with a frame bearing END_STREAM,
2928 which causes the stream to become "half-closed (local)" for the
2929 client and "half-closed (remote)" for the server. A response starts
2930 with a HEADERS frame and ends with a frame bearing END_STREAM, which
2931 places the stream in the "closed" state.
2933 An HTTP response is complete after the server sends -- or the client
2934 receives -- a frame with the END_STREAM flag set (including any
2935 CONTINUATION frames needed to complete a header block). A server can
2936 send a complete response prior to the client sending an entire
2937 request if the response does not depend on any portion of the request
2938 that has not been sent and received. When this is true, a server MAY
2939 request that the client abort transmission of a request without error
2940 by sending a RST_STREAM with an error code of NO_ERROR after sending
2941 a complete response (i.e., a frame with the END_STREAM flag).
2942 Clients MUST NOT discard responses as a result of receiving such a
2943 RST_STREAM, though clients can always discard responses at their
2944 discretion for other reasons.
2946 8.1.1. Upgrading from HTTP/2
2948 HTTP/2 removes support for the 101 (Switching Protocols)
2949 informational status code ([RFC7231], Section 6.2.2).
2951 The semantics of 101 (Switching Protocols) aren't applicable to a
2952 multiplexed protocol. Alternative protocols are able to use the same
2953 mechanisms that HTTP/2 uses to negotiate their use (see Section 3).
2955 8.1.2. HTTP Header Fields
2957 HTTP header fields carry information as a series of key-value pairs.
2958 For a listing of registered HTTP headers, see the "Message Header
2959 Field" registry maintained at <https://www.iana.org/assignments/
2962 Just as in HTTP/1.x, header field names are strings of ASCII
2963 characters that are compared in a case-insensitive fashion. However,
2964 header field names MUST be converted to lowercase prior to their
2965 encoding in HTTP/2. A request or response containing uppercase
2966 header field names MUST be treated as malformed (Section 8.1.2.6).
2970 Belshe, et al. Standards Track [Page 53]
2972 RFC 7540 HTTP/2 May 2015
2975 8.1.2.1. Pseudo-Header Fields
2977 While HTTP/1.x used the message start-line (see [RFC7230],
2978 Section 3.1) to convey the target URI, the method of the request, and
2979 the status code for the response, HTTP/2 uses special pseudo-header
2980 fields beginning with ':' character (ASCII 0x3a) for this purpose.
2982 Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT
2983 generate pseudo-header fields other than those defined in this
2986 Pseudo-header fields are only valid in the context in which they are
2987 defined. Pseudo-header fields defined for requests MUST NOT appear
2988 in responses; pseudo-header fields defined for responses MUST NOT
2989 appear in requests. Pseudo-header fields MUST NOT appear in
2990 trailers. Endpoints MUST treat a request or response that contains
2991 undefined or invalid pseudo-header fields as malformed
2994 All pseudo-header fields MUST appear in the header block before
2995 regular header fields. Any request or response that contains a
2996 pseudo-header field that appears in a header block after a regular
2997 header field MUST be treated as malformed (Section 8.1.2.6).
2999 8.1.2.2. Connection-Specific Header Fields
3001 HTTP/2 does not use the Connection header field to indicate
3002 connection-specific header fields; in this protocol, connection-
3003 specific metadata is conveyed by other means. An endpoint MUST NOT
3004 generate an HTTP/2 message containing connection-specific header
3005 fields; any message containing connection-specific header fields MUST
3006 be treated as malformed (Section 8.1.2.6).
3008 The only exception to this is the TE header field, which MAY be
3009 present in an HTTP/2 request; when it is, it MUST NOT contain any
3010 value other than "trailers".
3012 This means that an intermediary transforming an HTTP/1.x message to
3013 HTTP/2 will need to remove any header fields nominated by the
3014 Connection header field, along with the Connection header field
3015 itself. Such intermediaries SHOULD also remove other connection-
3016 specific header fields, such as Keep-Alive, Proxy-Connection,
3017 Transfer-Encoding, and Upgrade, even if they are not nominated by the
3018 Connection header field.
3020 Note: HTTP/2 purposefully does not support upgrade to another
3021 protocol. The handshake methods described in Section 3 are
3022 believed sufficient to negotiate the use of alternative protocols.
3026 Belshe, et al. Standards Track [Page 54]
3028 RFC 7540 HTTP/2 May 2015
3031 8.1.2.3. Request Pseudo-Header Fields
3033 The following pseudo-header fields are defined for HTTP/2 requests:
3035 o The ":method" pseudo-header field includes the HTTP method
3036 ([RFC7231], Section 4).
3038 o The ":scheme" pseudo-header field includes the scheme portion of
3039 the target URI ([RFC3986], Section 3.1).
3041 ":scheme" is not restricted to "http" and "https" schemed URIs. A
3042 proxy or gateway can translate requests for non-HTTP schemes,
3043 enabling the use of HTTP to interact with non-HTTP services.
3045 o The ":authority" pseudo-header field includes the authority
3046 portion of the target URI ([RFC3986], Section 3.2). The authority
3047 MUST NOT include the deprecated "userinfo" subcomponent for "http"
3048 or "https" schemed URIs.
3050 To ensure that the HTTP/1.1 request line can be reproduced
3051 accurately, this pseudo-header field MUST be omitted when
3052 translating from an HTTP/1.1 request that has a request target in
3053 origin or asterisk form (see [RFC7230], Section 5.3). Clients
3054 that generate HTTP/2 requests directly SHOULD use the ":authority"
3055 pseudo-header field instead of the Host header field. An
3056 intermediary that converts an HTTP/2 request to HTTP/1.1 MUST
3057 create a Host header field if one is not present in a request by
3058 copying the value of the ":authority" pseudo-header field.
3060 o The ":path" pseudo-header field includes the path and query parts
3061 of the target URI (the "path-absolute" production and optionally a
3062 '?' character followed by the "query" production (see Sections 3.3
3063 and 3.4 of [RFC3986]). A request in asterisk form includes the
3064 value '*' for the ":path" pseudo-header field.
3066 This pseudo-header field MUST NOT be empty for "http" or "https"
3067 URIs; "http" or "https" URIs that do not contain a path component
3068 MUST include a value of '/'. The exception to this rule is an
3069 OPTIONS request for an "http" or "https" URI that does not include
3070 a path component; these MUST include a ":path" pseudo-header field
3071 with a value of '*' (see [RFC7230], Section 5.3.4).
3082 Belshe, et al. Standards Track [Page 55]
3084 RFC 7540 HTTP/2 May 2015
3087 All HTTP/2 requests MUST include exactly one valid value for the
3088 ":method", ":scheme", and ":path" pseudo-header fields, unless it is
3089 a CONNECT request (Section 8.3). An HTTP request that omits
3090 mandatory pseudo-header fields is malformed (Section 8.1.2.6).
3092 HTTP/2 does not define a way to carry the version identifier that is
3093 included in the HTTP/1.1 request line.
3095 8.1.2.4. Response Pseudo-Header Fields
3097 For HTTP/2 responses, a single ":status" pseudo-header field is
3098 defined that carries the HTTP status code field (see [RFC7231],
3099 Section 6). This pseudo-header field MUST be included in all
3100 responses; otherwise, the response is malformed (Section 8.1.2.6).
3102 HTTP/2 does not define a way to carry the version or reason phrase
3103 that is included in an HTTP/1.1 status line.
3105 8.1.2.5. Compressing the Cookie Header Field
3107 The Cookie header field [COOKIE] uses a semi-colon (";") to delimit
3108 cookie-pairs (or "crumbs"). This header field doesn't follow the
3109 list construction rules in HTTP (see [RFC7230], Section 3.2.2), which
3110 prevents cookie-pairs from being separated into different name-value
3111 pairs. This can significantly reduce compression efficiency as
3112 individual cookie-pairs are updated.
3114 To allow for better compression efficiency, the Cookie header field
3115 MAY be split into separate header fields, each with one or more
3116 cookie-pairs. If there are multiple Cookie header fields after
3117 decompression, these MUST be concatenated into a single octet string
3118 using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ")
3119 before being passed into a non-HTTP/2 context, such as an HTTP/1.1
3120 connection, or a generic HTTP server application.
3122 Therefore, the following two lists of Cookie header fields are
3123 semantically equivalent.
3125 cookie: a=b; c=d; e=f
3138 Belshe, et al. Standards Track [Page 56]
3140 RFC 7540 HTTP/2 May 2015
3143 8.1.2.6. Malformed Requests and Responses
3145 A malformed request or response is one that is an otherwise valid
3146 sequence of HTTP/2 frames but is invalid due to the presence of
3147 extraneous frames, prohibited header fields, the absence of mandatory
3148 header fields, or the inclusion of uppercase header field names.
3150 A request or response that includes a payload body can include a
3151 content-length header field. A request or response is also malformed
3152 if the value of a content-length header field does not equal the sum
3153 of the DATA frame payload lengths that form the body. A response
3154 that is defined to have no payload, as described in [RFC7230],
3155 Section 3.3.2, can have a non-zero content-length header field, even
3156 though no content is included in DATA frames.
3158 Intermediaries that process HTTP requests or responses (i.e., any
3159 intermediary not acting as a tunnel) MUST NOT forward a malformed
3160 request or response. Malformed requests or responses that are
3161 detected MUST be treated as a stream error (Section 5.4.2) of type
3164 For malformed requests, a server MAY send an HTTP response prior to
3165 closing or resetting the stream. Clients MUST NOT accept a malformed
3166 response. Note that these requirements are intended to protect
3167 against several types of common attacks against HTTP; they are
3168 deliberately strict because being permissive can expose
3169 implementations to these vulnerabilities.
3173 This section shows HTTP/1.1 requests and responses, with
3174 illustrations of equivalent HTTP/2 requests and responses.
3176 An HTTP GET request includes request header fields and no payload
3177 body and is therefore transmitted as a single HEADERS frame, followed
3178 by zero or more CONTINUATION frames containing the serialized block
3179 of request header fields. The HEADERS frame in the following has
3180 both the END_HEADERS and END_STREAM flags set; no CONTINUATION frames
3183 GET /resource HTTP/1.1 HEADERS
3184 Host: example.org ==> + END_STREAM
3185 Accept: image/jpeg + END_HEADERS
3194 Belshe, et al. Standards Track [Page 57]
3196 RFC 7540 HTTP/2 May 2015
3199 Similarly, a response that includes only response header fields is
3200 transmitted as a HEADERS frame (again, followed by zero or more
3201 CONTINUATION frames) containing the serialized block of response
3204 HTTP/1.1 304 Not Modified HEADERS
3205 ETag: "xyzzy" ==> + END_STREAM
3206 Expires: Thu, 23 Jan ... + END_HEADERS
3209 expires = Thu, 23 Jan ...
3211 An HTTP POST request that includes request header fields and payload
3212 data is transmitted as one HEADERS frame, followed by zero or more
3213 CONTINUATION frames containing the request header fields, followed by
3214 one or more DATA frames, with the last CONTINUATION (or HEADERS)
3215 frame having the END_HEADERS flag set and the final DATA frame having
3216 the END_STREAM flag set:
3218 POST /resource HTTP/1.1 HEADERS
3219 Host: example.org ==> - END_STREAM
3220 Content-Type: image/jpeg - END_HEADERS
3221 Content-Length: 123 :method = POST
3223 {binary data} :scheme = https
3227 content-type = image/jpeg
3229 content-length = 123
3235 Note that data contributing to any given header field could be spread
3236 between header block fragments. The allocation of header fields to
3237 frames in this example is illustrative only.
3239 A response that includes header fields and payload data is
3240 transmitted as a HEADERS frame, followed by zero or more CONTINUATION
3241 frames, followed by one or more DATA frames, with the last DATA frame
3242 in the sequence having the END_STREAM flag set:
3250 Belshe, et al. Standards Track [Page 58]
3252 RFC 7540 HTTP/2 May 2015
3255 HTTP/1.1 200 OK HEADERS
3256 Content-Type: image/jpeg ==> - END_STREAM
3257 Content-Length: 123 + END_HEADERS
3259 {binary data} content-type = image/jpeg
3260 content-length = 123
3266 An informational response using a 1xx status code other than 101 is
3267 transmitted as a HEADERS frame, followed by zero or more CONTINUATION
3270 Trailing header fields are sent as a header block after both the
3271 request or response header block and all the DATA frames have been
3272 sent. The HEADERS frame starting the trailers header block has the
3273 END_STREAM flag set.
3275 The following example includes both a 100 (Continue) status code,
3276 which is sent in response to a request containing a "100-continue"
3277 token in the Expect header field, and trailing header fields:
3279 HTTP/1.1 100 Continue HEADERS
3280 Extension-Field: bar ==> - END_STREAM
3283 extension-field = bar
3285 HTTP/1.1 200 OK HEADERS
3286 Content-Type: image/jpeg ==> - END_STREAM
3287 Transfer-Encoding: chunked + END_HEADERS
3288 Trailer: Foo :status = 200
3289 content-length = 123
3290 123 content-type = image/jpeg
3291 {binary data} trailer = Foo
3306 Belshe, et al. Standards Track [Page 59]
3308 RFC 7540 HTTP/2 May 2015
3311 8.1.4. Request Reliability Mechanisms in HTTP/2
3313 In HTTP/1.1, an HTTP client is unable to retry a non-idempotent
3314 request when an error occurs because there is no means to determine
3315 the nature of the error. It is possible that some server processing
3316 occurred prior to the error, which could result in undesirable
3317 effects if the request were reattempted.
3319 HTTP/2 provides two mechanisms for providing a guarantee to a client
3320 that a request has not been processed:
3322 o The GOAWAY frame indicates the highest stream number that might
3323 have been processed. Requests on streams with higher numbers are
3324 therefore guaranteed to be safe to retry.
3326 o The REFUSED_STREAM error code can be included in a RST_STREAM
3327 frame to indicate that the stream is being closed prior to any
3328 processing having occurred. Any request that was sent on the
3329 reset stream can be safely retried.
3331 Requests that have not been processed have not failed; clients MAY
3332 automatically retry them, even those with non-idempotent methods.
3334 A server MUST NOT indicate that a stream has not been processed
3335 unless it can guarantee that fact. If frames that are on a stream
3336 are passed to the application layer for any stream, then
3337 REFUSED_STREAM MUST NOT be used for that stream, and a GOAWAY frame
3338 MUST include a stream identifier that is greater than or equal to the
3339 given stream identifier.
3341 In addition to these mechanisms, the PING frame provides a way for a
3342 client to easily test a connection. Connections that remain idle can
3343 become broken as some middleboxes (for instance, network address
3344 translators or load balancers) silently discard connection bindings.
3345 The PING frame allows a client to safely test whether a connection is
3346 still active without sending a request.
3350 HTTP/2 allows a server to pre-emptively send (or "push") responses
3351 (along with corresponding "promised" requests) to a client in
3352 association with a previous client-initiated request. This can be
3353 useful when the server knows the client will need to have those
3354 responses available in order to fully process the response to the
3362 Belshe, et al. Standards Track [Page 60]
3364 RFC 7540 HTTP/2 May 2015
3367 A client can request that server push be disabled, though this is
3368 negotiated for each hop independently. The SETTINGS_ENABLE_PUSH
3369 setting can be set to 0 to indicate that server push is disabled.
3371 Promised requests MUST be cacheable (see [RFC7231], Section 4.2.3),
3372 MUST be safe (see [RFC7231], Section 4.2.1), and MUST NOT include a
3373 request body. Clients that receive a promised request that is not
3374 cacheable, that is not known to be safe, or that indicates the
3375 presence of a request body MUST reset the promised stream with a
3376 stream error (Section 5.4.2) of type PROTOCOL_ERROR. Note this could
3377 result in the promised stream being reset if the client does not
3378 recognize a newly defined method as being safe.
3380 Pushed responses that are cacheable (see [RFC7234], Section 3) can be
3381 stored by the client, if it implements an HTTP cache. Pushed
3382 responses are considered successfully validated on the origin server
3383 (e.g., if the "no-cache" cache response directive is present
3384 ([RFC7234], Section 5.2.2)) while the stream identified by the
3385 promised stream ID is still open.
3387 Pushed responses that are not cacheable MUST NOT be stored by any
3388 HTTP cache. They MAY be made available to the application
3391 The server MUST include a value in the ":authority" pseudo-header
3392 field for which the server is authoritative (see Section 10.1). A
3393 client MUST treat a PUSH_PROMISE for which the server is not
3394 authoritative as a stream error (Section 5.4.2) of type
3397 An intermediary can receive pushes from the server and choose not to
3398 forward them on to the client. In other words, how to make use of
3399 the pushed information is up to that intermediary. Equally, the
3400 intermediary might choose to make additional pushes to the client,
3401 without any action taken by the server.
3403 A client cannot push. Thus, servers MUST treat the receipt of a
3404 PUSH_PROMISE frame as a connection error (Section 5.4.1) of type
3405 PROTOCOL_ERROR. Clients MUST reject any attempt to change the
3406 SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the
3407 message as a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
3409 8.2.1. Push Requests
3411 Server push is semantically equivalent to a server responding to a
3412 request; however, in this case, that request is also sent by the
3413 server, as a PUSH_PROMISE frame.
3418 Belshe, et al. Standards Track [Page 61]
3420 RFC 7540 HTTP/2 May 2015
3423 The PUSH_PROMISE frame includes a header block that contains a
3424 complete set of request header fields that the server attributes to
3425 the request. It is not possible to push a response to a request that
3426 includes a request body.
3428 Pushed responses are always associated with an explicit request from
3429 the client. The PUSH_PROMISE frames sent by the server are sent on
3430 that explicit request's stream. The PUSH_PROMISE frame also includes
3431 a promised stream identifier, chosen from the stream identifiers
3432 available to the server (see Section 5.1.1).
3434 The header fields in PUSH_PROMISE and any subsequent CONTINUATION
3435 frames MUST be a valid and complete set of request header fields
3436 (Section 8.1.2.3). The server MUST include a method in the ":method"
3437 pseudo-header field that is safe and cacheable. If a client receives
3438 a PUSH_PROMISE that does not include a complete and valid set of
3439 header fields or the ":method" pseudo-header field identifies a
3440 method that is not safe, it MUST respond with a stream error
3441 (Section 5.4.2) of type PROTOCOL_ERROR.
3443 The server SHOULD send PUSH_PROMISE (Section 6.6) frames prior to
3444 sending any frames that reference the promised responses. This
3445 avoids a race where clients issue requests prior to receiving any
3446 PUSH_PROMISE frames.
3448 For example, if the server receives a request for a document
3449 containing embedded links to multiple image files and the server
3450 chooses to push those additional images to the client, sending
3451 PUSH_PROMISE frames before the DATA frames that contain the image
3452 links ensures that the client is able to see that a resource will be
3453 pushed before discovering embedded links. Similarly, if the server
3454 pushes responses referenced by the header block (for instance, in
3455 Link header fields), sending a PUSH_PROMISE before sending the header
3456 block ensures that clients do not request those resources.
3458 PUSH_PROMISE frames MUST NOT be sent by the client.
3460 PUSH_PROMISE frames can be sent by the server in response to any
3461 client-initiated stream, but the stream MUST be in either the "open"
3462 or "half-closed (remote)" state with respect to the server.
3463 PUSH_PROMISE frames are interspersed with the frames that comprise a
3464 response, though they cannot be interspersed with HEADERS and
3465 CONTINUATION frames that comprise a single header block.
3467 Sending a PUSH_PROMISE frame creates a new stream and puts the stream
3468 into the "reserved (local)" state for the server and the "reserved
3469 (remote)" state for the client.
3474 Belshe, et al. Standards Track [Page 62]
3476 RFC 7540 HTTP/2 May 2015
3479 8.2.2. Push Responses
3481 After sending the PUSH_PROMISE frame, the server can begin delivering
3482 the pushed response as a response (Section 8.1.2.4) on a server-
3483 initiated stream that uses the promised stream identifier. The
3484 server uses this stream to transmit an HTTP response, using the same
3485 sequence of frames as defined in Section 8.1. This stream becomes
3486 "half-closed" to the client (Section 5.1) after the initial HEADERS
3489 Once a client receives a PUSH_PROMISE frame and chooses to accept the
3490 pushed response, the client SHOULD NOT issue any requests for the
3491 promised response until after the promised stream has closed.
3493 If the client determines, for any reason, that it does not wish to
3494 receive the pushed response from the server or if the server takes
3495 too long to begin sending the promised response, the client can send
3496 a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code
3497 and referencing the pushed stream's identifier.
3499 A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
3500 the number of responses that can be concurrently pushed by a server.
3501 Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables
3502 server push by preventing the server from creating the necessary
3503 streams. This does not prohibit a server from sending PUSH_PROMISE
3504 frames; clients need to reset any promised streams that are not
3507 Clients receiving a pushed response MUST validate that either the
3508 server is authoritative (see Section 10.1) or the proxy that provided
3509 the pushed response is configured for the corresponding request. For
3510 example, a server that offers a certificate for only the
3511 "example.com" DNS-ID or Common Name is not permitted to push a
3512 response for "https://www.example.org/doc".
3514 The response for a PUSH_PROMISE stream begins with a HEADERS frame,
3515 which immediately puts the stream into the "half-closed (remote)"
3516 state for the server and "half-closed (local)" state for the client,
3517 and ends with a frame bearing END_STREAM, which places the stream in
3520 Note: The client never sends a frame with the END_STREAM flag for
3530 Belshe, et al. Standards Track [Page 63]
3532 RFC 7540 HTTP/2 May 2015
3535 8.3. The CONNECT Method
3537 In HTTP/1.x, the pseudo-method CONNECT ([RFC7231], Section 4.3.6) is
3538 used to convert an HTTP connection into a tunnel to a remote host.
3539 CONNECT is primarily used with HTTP proxies to establish a TLS
3540 session with an origin server for the purposes of interacting with
3543 In HTTP/2, the CONNECT method is used to establish a tunnel over a
3544 single HTTP/2 stream to a remote host for similar purposes. The HTTP
3545 header field mapping works as defined in Section 8.1.2.3 ("Request
3546 Pseudo-Header Fields"), with a few differences. Specifically:
3548 o The ":method" pseudo-header field is set to "CONNECT".
3550 o The ":scheme" and ":path" pseudo-header fields MUST be omitted.
3552 o The ":authority" pseudo-header field contains the host and port to
3553 connect to (equivalent to the authority-form of the request-target
3554 of CONNECT requests (see [RFC7230], Section 5.3)).
3556 A CONNECT request that does not conform to these restrictions is
3557 malformed (Section 8.1.2.6).
3559 A proxy that supports CONNECT establishes a TCP connection [TCP] to
3560 the server identified in the ":authority" pseudo-header field. Once
3561 this connection is successfully established, the proxy sends a
3562 HEADERS frame containing a 2xx series status code to the client, as
3563 defined in [RFC7231], Section 4.3.6.
3565 After the initial HEADERS frame sent by each peer, all subsequent
3566 DATA frames correspond to data sent on the TCP connection. The
3567 payload of any DATA frames sent by the client is transmitted by the
3568 proxy to the TCP server; data received from the TCP server is
3569 assembled into DATA frames by the proxy. Frame types other than DATA
3570 or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY)
3571 MUST NOT be sent on a connected stream and MUST be treated as a
3572 stream error (Section 5.4.2) if received.
3574 The TCP connection can be closed by either peer. The END_STREAM flag
3575 on a DATA frame is treated as being equivalent to the TCP FIN bit. A
3576 client is expected to send a DATA frame with the END_STREAM flag set
3577 after receiving a frame bearing the END_STREAM flag. A proxy that
3578 receives a DATA frame with the END_STREAM flag set sends the attached
3579 data with the FIN bit set on the last TCP segment. A proxy that
3580 receives a TCP segment with the FIN bit set sends a DATA frame with
3581 the END_STREAM flag set. Note that the final TCP segment or DATA
3582 frame could be empty.
3586 Belshe, et al. Standards Track [Page 64]
3588 RFC 7540 HTTP/2 May 2015
3591 A TCP connection error is signaled with RST_STREAM. A proxy treats
3592 any error in the TCP connection, which includes receiving a TCP
3593 segment with the RST bit set, as a stream error (Section 5.4.2) of
3594 type CONNECT_ERROR. Correspondingly, a proxy MUST send a TCP segment
3595 with the RST bit set if it detects an error with the stream or the
3598 9. Additional HTTP Requirements/Considerations
3600 This section outlines attributes of the HTTP protocol that improve
3601 interoperability, reduce exposure to known security vulnerabilities,
3602 or reduce the potential for implementation variation.
3604 9.1. Connection Management
3606 HTTP/2 connections are persistent. For best performance, it is
3607 expected that clients will not close connections until it is
3608 determined that no further communication with a server is necessary
3609 (for example, when a user navigates away from a particular web page)
3610 or until the server closes the connection.
3612 Clients SHOULD NOT open more than one HTTP/2 connection to a given
3613 host and port pair, where the host is derived from a URI, a selected
3614 alternative service [ALT-SVC], or a configured proxy.
3616 A client can create additional connections as replacements, either to
3617 replace connections that are near to exhausting the available stream
3618 identifier space (Section 5.1.1), to refresh the keying material for
3619 a TLS connection, or to replace connections that have encountered
3620 errors (Section 5.4.1).
3622 A client MAY open multiple connections to the same IP address and TCP
3623 port using different Server Name Indication [TLS-EXT] values or to
3624 provide different TLS client certificates but SHOULD avoid creating
3625 multiple connections with the same configuration.
3627 Servers are encouraged to maintain open connections for as long as
3628 possible but are permitted to terminate idle connections if
3629 necessary. When either endpoint chooses to close the transport-layer
3630 TCP connection, the terminating endpoint SHOULD first send a GOAWAY
3631 (Section 6.8) frame so that both endpoints can reliably determine
3632 whether previously sent frames have been processed and gracefully
3633 complete or terminate any necessary remaining tasks.
3642 Belshe, et al. Standards Track [Page 65]
3644 RFC 7540 HTTP/2 May 2015
3647 9.1.1. Connection Reuse
3649 Connections that are made to an origin server, either directly or
3650 through a tunnel created using the CONNECT method (Section 8.3), MAY
3651 be reused for requests with multiple different URI authority
3652 components. A connection can be reused as long as the origin server
3653 is authoritative (Section 10.1). For TCP connections without TLS,
3654 this depends on the host having resolved to the same IP address.
3656 For "https" resources, connection reuse additionally depends on
3657 having a certificate that is valid for the host in the URI. The
3658 certificate presented by the server MUST satisfy any checks that the
3659 client would perform when forming a new TLS connection for the host
3662 An origin server might offer a certificate with multiple
3663 "subjectAltName" attributes or names with wildcards, one of which is
3664 valid for the authority in the URI. For example, a certificate with
3665 a "subjectAltName" of "*.example.com" might permit the use of the
3666 same connection for requests to URIs starting with
3667 "https://a.example.com/" and "https://b.example.com/".
3669 In some deployments, reusing a connection for multiple origins can
3670 result in requests being directed to the wrong origin server. For
3671 example, TLS termination might be performed by a middlebox that uses
3672 the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an
3673 origin server. This means that it is possible for clients to send
3674 confidential information to servers that might not be the intended
3675 target for the request, even though the server is otherwise
3678 A server that does not wish clients to reuse connections can indicate
3679 that it is not authoritative for a request by sending a 421
3680 (Misdirected Request) status code in response to the request (see
3683 A client that is configured to use a proxy over HTTP/2 directs
3684 requests to that proxy through a single connection. That is, all
3685 requests sent via a proxy reuse the connection to the proxy.
3687 9.1.2. The 421 (Misdirected Request) Status Code
3689 The 421 (Misdirected Request) status code indicates that the request
3690 was directed at a server that is not able to produce a response.
3691 This can be sent by a server that is not configured to produce
3692 responses for the combination of scheme and authority that are
3693 included in the request URI.
3698 Belshe, et al. Standards Track [Page 66]
3700 RFC 7540 HTTP/2 May 2015
3703 Clients receiving a 421 (Misdirected Request) response from a server
3704 MAY retry the request -- whether the request method is idempotent or
3705 not -- over a different connection. This is possible if a connection
3706 is reused (Section 9.1.1) or if an alternative service is selected
3709 This status code MUST NOT be generated by proxies.
3711 A 421 response is cacheable by default, i.e., unless otherwise
3712 indicated by the method definition or explicit cache controls (see
3713 Section 4.2.2 of [RFC7234]).
3715 9.2. Use of TLS Features
3717 Implementations of HTTP/2 MUST use TLS version 1.2 [TLS12] or higher
3718 for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP]
3719 SHOULD be followed, with some additional restrictions that are
3722 The TLS implementation MUST support the Server Name Indication (SNI)
3723 [TLS-EXT] extension to TLS. HTTP/2 clients MUST indicate the target
3724 domain name when negotiating TLS.
3726 Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only
3727 support and use the SNI extension; deployments of TLS 1.2 are subject
3728 to the requirements in the following sections. Implementations are
3729 encouraged to provide defaults that comply, but it is recognized that
3730 deployments are ultimately responsible for compliance.
3732 9.2.1. TLS 1.2 Features
3734 This section describes restrictions on the TLS 1.2 feature set that
3735 can be used with HTTP/2. Due to deployment limitations, it might not
3736 be possible to fail TLS negotiation when these restrictions are not
3737 met. An endpoint MAY immediately terminate an HTTP/2 connection that
3738 does not meet these TLS requirements with a connection error
3739 (Section 5.4.1) of type INADEQUATE_SECURITY.
3741 A deployment of HTTP/2 over TLS 1.2 MUST disable compression. TLS
3742 compression can lead to the exposure of information that would not
3743 otherwise be revealed [RFC3749]. Generic compression is unnecessary
3744 since HTTP/2 provides compression features that are more aware of
3745 context and therefore likely to be more appropriate for use for
3746 performance, security, or other reasons.
3748 A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation. An
3749 endpoint MUST treat a TLS renegotiation as a connection error
3750 (Section 5.4.1) of type PROTOCOL_ERROR. Note that disabling
3754 Belshe, et al. Standards Track [Page 67]
3756 RFC 7540 HTTP/2 May 2015
3759 renegotiation can result in long-lived connections becoming unusable
3760 due to limits on the number of messages the underlying cipher suite
3763 An endpoint MAY use renegotiation to provide confidentiality
3764 protection for client credentials offered in the handshake, but any
3765 renegotiation MUST occur prior to sending the connection preface. A
3766 server SHOULD request a client certificate if it sees a renegotiation
3767 request immediately after establishing a connection.
3769 This effectively prevents the use of renegotiation in response to a
3770 request for a specific protected resource. A future specification
3771 might provide a way to support this use case. Alternatively, a
3772 server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to
3773 request the client use a protocol that supports renegotiation.
3775 Implementations MUST support ephemeral key exchange sizes of at least
3776 2048 bits for cipher suites that use ephemeral finite field Diffie-
3777 Hellman (DHE) [TLS12] and 224 bits for cipher suites that use
3778 ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC4492]. Clients
3779 MUST accept DHE sizes of up to 4096 bits. Endpoints MAY treat
3780 negotiation of key sizes smaller than the lower limits as a
3781 connection error (Section 5.4.1) of type INADEQUATE_SECURITY.
3783 9.2.2. TLS 1.2 Cipher Suites
3785 A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher
3786 suites that are listed in the cipher suite black list (Appendix A).
3788 Endpoints MAY choose to generate a connection error (Section 5.4.1)
3789 of type INADEQUATE_SECURITY if one of the cipher suites from the
3790 black list is negotiated. A deployment that chooses to use a black-
3791 listed cipher suite risks triggering a connection error unless the
3792 set of potential peers is known to accept that cipher suite.
3794 Implementations MUST NOT generate this error in reaction to the
3795 negotiation of a cipher suite that is not on the black list.
3796 Consequently, when clients offer a cipher suite that is not on the
3797 black list, they have to be prepared to use that cipher suite with
3800 The black list includes the cipher suite that TLS 1.2 makes
3801 mandatory, which means that TLS 1.2 deployments could have non-
3802 intersecting sets of permitted cipher suites. To avoid this problem
3803 causing TLS handshake failures, deployments of HTTP/2 that use TLS
3804 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE]
3805 with the P-256 elliptic curve [FIPS186].
3810 Belshe, et al. Standards Track [Page 68]
3812 RFC 7540 HTTP/2 May 2015
3815 Note that clients might advertise support of cipher suites that are
3816 on the black list in order to allow for connection to servers that do
3817 not support HTTP/2. This allows servers to select HTTP/1.1 with a
3818 cipher suite that is on the HTTP/2 black list. However, this can
3819 result in HTTP/2 being negotiated with a black-listed cipher suite if
3820 the application protocol and cipher suite are independently selected.
3822 10. Security Considerations
3824 10.1. Server Authority
3826 HTTP/2 relies on the HTTP/1.1 definition of authority for determining
3827 whether a server is authoritative in providing a given response (see
3828 [RFC7230], Section 9.1). This relies on local name resolution for
3829 the "http" URI scheme and the authenticated server identity for the
3830 "https" scheme (see [RFC2818], Section 3).
3832 10.2. Cross-Protocol Attacks
3834 In a cross-protocol attack, an attacker causes a client to initiate a
3835 transaction in one protocol toward a server that understands a
3836 different protocol. An attacker might be able to cause the
3837 transaction to appear as a valid transaction in the second protocol.
3838 In combination with the capabilities of the web context, this can be
3839 used to interact with poorly protected servers in private networks.
3841 Completing a TLS handshake with an ALPN identifier for HTTP/2 can be
3842 considered sufficient protection against cross-protocol attacks.
3843 ALPN provides a positive indication that a server is willing to
3844 proceed with HTTP/2, which prevents attacks on other TLS-based
3847 The encryption in TLS makes it difficult for attackers to control the
3848 data that could be used in a cross-protocol attack on a cleartext
3851 The cleartext version of HTTP/2 has minimal protection against cross-
3852 protocol attacks. The connection preface (Section 3.5) contains a
3853 string that is designed to confuse HTTP/1.1 servers, but no special
3854 protection is offered for other protocols. A server that is willing
3855 to ignore parts of an HTTP/1.1 request containing an Upgrade header
3856 field in addition to the client connection preface could be exposed
3857 to a cross-protocol attack.
3866 Belshe, et al. Standards Track [Page 69]
3868 RFC 7540 HTTP/2 May 2015
3871 10.3. Intermediary Encapsulation Attacks
3873 The HTTP/2 header field encoding allows the expression of names that
3874 are not valid field names in the Internet Message Syntax used by
3875 HTTP/1.1. Requests or responses containing invalid header field
3876 names MUST be treated as malformed (Section 8.1.2.6). An
3877 intermediary therefore cannot translate an HTTP/2 request or response
3878 containing an invalid field name into an HTTP/1.1 message.
3880 Similarly, HTTP/2 allows header field values that are not valid.
3881 While most of the values that can be encoded will not alter header
3882 field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII
3883 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by
3884 an attacker if they are translated verbatim. Any request or response
3885 that contains a character not permitted in a header field value MUST
3886 be treated as malformed (Section 8.1.2.6). Valid characters are
3887 defined by the "field-content" ABNF rule in Section 3.2 of [RFC7230].
3889 10.4. Cacheability of Pushed Responses
3891 Pushed responses do not have an explicit request from the client; the
3892 request is provided by the server in the PUSH_PROMISE frame.
3894 Caching responses that are pushed is possible based on the guidance
3895 provided by the origin server in the Cache-Control header field.
3896 However, this can cause issues if a single server hosts more than one
3897 tenant. For example, a server might offer multiple users each a
3898 small portion of its URI space.
3900 Where multiple tenants share space on the same server, that server
3901 MUST ensure that tenants are not able to push representations of
3902 resources that they do not have authority over. Failure to enforce
3903 this would allow a tenant to provide a representation that would be
3904 served out of cache, overriding the actual representation that the
3905 authoritative tenant provides.
3907 Pushed responses for which an origin server is not authoritative (see
3908 Section 10.1) MUST NOT be used or cached.
3910 10.5. Denial-of-Service Considerations
3912 An HTTP/2 connection can demand a greater commitment of resources to
3913 operate than an HTTP/1.1 connection. The use of header compression
3914 and flow control depend on a commitment of resources for storing a
3915 greater amount of state. Settings for these features ensure that
3916 memory commitments for these features are strictly bounded.
3922 Belshe, et al. Standards Track [Page 70]
3924 RFC 7540 HTTP/2 May 2015
3927 The number of PUSH_PROMISE frames is not constrained in the same
3928 fashion. A client that accepts server push SHOULD limit the number
3929 of streams it allows to be in the "reserved (remote)" state. An
3930 excessive number of server push streams can be treated as a stream
3931 error (Section 5.4.2) of type ENHANCE_YOUR_CALM.
3933 Processing capacity cannot be guarded as effectively as state
3936 The SETTINGS frame can be abused to cause a peer to expend additional
3937 processing time. This might be done by pointlessly changing SETTINGS
3938 parameters, setting multiple undefined parameters, or changing the
3939 same setting multiple times in the same frame. WINDOW_UPDATE or
3940 PRIORITY frames can be abused to cause an unnecessary waste of
3943 Large numbers of small or empty frames can be abused to cause a peer
3944 to expend time processing frame headers. Note, however, that some
3945 uses are entirely legitimate, such as the sending of an empty DATA or
3946 CONTINUATION frame at the end of a stream.
3948 Header compression also offers some opportunities to waste processing
3949 resources; see Section 7 of [COMPRESSION] for more details on
3952 Limits in SETTINGS parameters cannot be reduced instantaneously,
3953 which leaves an endpoint exposed to behavior from a peer that could
3954 exceed the new limits. In particular, immediately after establishing
3955 a connection, limits set by a server are not known to clients and
3956 could be exceeded without being an obvious protocol violation.
3958 All these features -- i.e., SETTINGS changes, small frames, header
3959 compression -- have legitimate uses. These features become a burden
3960 only when they are used unnecessarily or to excess.
3962 An endpoint that doesn't monitor this behavior exposes itself to a
3963 risk of denial-of-service attack. Implementations SHOULD track the
3964 use of these features and set limits on their use. An endpoint MAY
3965 treat activity that is suspicious as a connection error
3966 (Section 5.4.1) of type ENHANCE_YOUR_CALM.
3968 10.5.1. Limits on Header Block Size
3970 A large header block (Section 4.3) can cause an implementation to
3971 commit a large amount of state. Header fields that are critical for
3972 routing can appear toward the end of a header block, which prevents
3973 streaming of header fields to their ultimate destination. This
3974 ordering and other reasons, such as ensuring cache correctness, mean
3978 Belshe, et al. Standards Track [Page 71]
3980 RFC 7540 HTTP/2 May 2015
3983 that an endpoint might need to buffer the entire header block. Since
3984 there is no hard limit to the size of a header block, some endpoints
3985 could be forced to commit a large amount of available memory for
3988 An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE to advise peers
3989 of limits that might apply on the size of header blocks. This
3990 setting is only advisory, so endpoints MAY choose to send header
3991 blocks that exceed this limit and risk having the request or response
3992 being treated as malformed. This setting is specific to a
3993 connection, so any request or response could encounter a hop with a
3994 lower, unknown limit. An intermediary can attempt to avoid this
3995 problem by passing on values presented by different peers, but they
3996 are not obligated to do so.
3998 A server that receives a larger header block than it is willing to
3999 handle can send an HTTP 431 (Request Header Fields Too Large) status
4000 code [RFC6585]. A client can discard responses that it cannot
4001 process. The header block MUST be processed to ensure a consistent
4002 connection state, unless the connection is closed.
4004 10.5.2. CONNECT Issues
4006 The CONNECT method can be used to create disproportionate load on an
4007 proxy, since stream creation is relatively inexpensive when compared
4008 to the creation and maintenance of a TCP connection. A proxy might
4009 also maintain some resources for a TCP connection beyond the closing
4010 of the stream that carries the CONNECT request, since the outgoing
4011 TCP connection remains in the TIME_WAIT state. Therefore, a proxy
4012 cannot rely on SETTINGS_MAX_CONCURRENT_STREAMS alone to limit the
4013 resources consumed by CONNECT requests.
4015 10.6. Use of Compression
4017 Compression can allow an attacker to recover secret data when it is
4018 compressed in the same context as data under attacker control.
4019 HTTP/2 enables compression of header fields (Section 4.3); the
4020 following concerns also apply to the use of HTTP compressed content-
4021 codings ([RFC7231], Section 3.1.2.1).
4023 There are demonstrable attacks on compression that exploit the
4024 characteristics of the web (e.g., [BREACH]). The attacker induces
4025 multiple requests containing varying plaintext, observing the length
4026 of the resulting ciphertext in each, which reveals a shorter length
4027 when a guess about the secret is correct.
4034 Belshe, et al. Standards Track [Page 72]
4036 RFC 7540 HTTP/2 May 2015
4039 Implementations communicating on a secure channel MUST NOT compress
4040 content that includes both confidential and attacker-controlled data
4041 unless separate compression dictionaries are used for each source of
4042 data. Compression MUST NOT be used if the source of data cannot be
4043 reliably determined. Generic stream compression, such as that
4044 provided by TLS, MUST NOT be used with HTTP/2 (see Section 9.2).
4046 Further considerations regarding the compression of header fields are
4047 described in [COMPRESSION].
4049 10.7. Use of Padding
4051 Padding within HTTP/2 is not intended as a replacement for general
4052 purpose padding, such as might be provided by TLS [TLS12]. Redundant
4053 padding could even be counterproductive. Correct application can
4054 depend on having specific knowledge of the data that is being padded.
4056 To mitigate attacks that rely on compression, disabling or limiting
4057 compression might be preferable to padding as a countermeasure.
4059 Padding can be used to obscure the exact size of frame content and is
4060 provided to mitigate specific attacks within HTTP, for example,
4061 attacks where compressed content includes both attacker-controlled
4062 plaintext and secret data (e.g., [BREACH]).
4064 Use of padding can result in less protection than might seem
4065 immediately obvious. At best, padding only makes it more difficult
4066 for an attacker to infer length information by increasing the number
4067 of frames an attacker has to observe. Incorrectly implemented
4068 padding schemes can be easily defeated. In particular, randomized
4069 padding with a predictable distribution provides very little
4070 protection; similarly, padding payloads to a fixed size exposes
4071 information as payload sizes cross the fixed-sized boundary, which
4072 could be possible if an attacker can control plaintext.
4074 Intermediaries SHOULD retain padding for DATA frames but MAY drop
4075 padding for HEADERS and PUSH_PROMISE frames. A valid reason for an
4076 intermediary to change the amount of padding of frames is to improve
4077 the protections that padding provides.
4079 10.8. Privacy Considerations
4081 Several characteristics of HTTP/2 provide an observer an opportunity
4082 to correlate actions of a single client or server over time. These
4083 include the value of settings, the manner in which flow-control
4084 windows are managed, the way priorities are allocated to streams, the
4085 timing of reactions to stimulus, and the handling of any features
4086 that are controlled by settings.
4090 Belshe, et al. Standards Track [Page 73]
4092 RFC 7540 HTTP/2 May 2015
4095 As far as these create observable differences in behavior, they could
4096 be used as a basis for fingerprinting a specific client, as defined
4097 in Section 1.8 of [HTML5].
4099 HTTP/2's preference for using a single TCP connection allows
4100 correlation of a user's activity on a site. Reusing connections for
4101 different origins allows tracking across those origins.
4103 Because the PING and SETTINGS frames solicit immediate responses,
4104 they can be used by an endpoint to measure latency to their peer.
4105 This might have privacy implications in certain scenarios.
4107 11. IANA Considerations
4109 A string for identifying HTTP/2 is entered into the "Application-
4110 Layer Protocol Negotiation (ALPN) Protocol IDs" registry established
4113 This document establishes a registry for frame types, settings, and
4114 error codes. These new registries appear in the new "Hypertext
4115 Transfer Protocol version 2 (HTTP/2) Parameters" section.
4117 This document registers the HTTP2-Settings header field for use in
4118 HTTP; it also registers the 421 (Misdirected Request) status code.
4120 This document registers the "PRI" method for use in HTTP to avoid
4121 collisions with the connection preface (Section 3.5).
4123 11.1. Registration of HTTP/2 Identification Strings
4125 This document creates two registrations for the identification of
4126 HTTP/2 (see Section 3.3) in the "Application-Layer Protocol
4127 Negotiation (ALPN) Protocol IDs" registry established in [TLS-ALPN].
4129 The "h2" string identifies HTTP/2 when used over TLS:
4131 Protocol: HTTP/2 over TLS
4133 Identification Sequence: 0x68 0x32 ("h2")
4135 Specification: This document
4137 The "h2c" string identifies HTTP/2 when used over cleartext TCP:
4139 Protocol: HTTP/2 over TCP
4146 Belshe, et al. Standards Track [Page 74]
4148 RFC 7540 HTTP/2 May 2015
4151 Identification Sequence: 0x68 0x32 0x63 ("h2c")
4153 Specification: This document
4155 11.2. Frame Type Registry
4157 This document establishes a registry for HTTP/2 frame type codes.
4158 The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2
4159 Frame Type" registry operates under either of the "IETF Review" or
4160 "IESG Approval" policies [RFC5226] for values between 0x00 and 0xef,
4161 with values between 0xf0 and 0xff being reserved for Experimental
4164 New entries in this registry require the following information:
4166 Frame Type: A name or label for the frame type.
4168 Code: The 8-bit code assigned to the frame type.
4170 Specification: A reference to a specification that includes a
4171 description of the frame layout, its semantics, and flags that the
4172 frame type uses, including any parts of the frame that are
4173 conditionally present based on the value of flags.
4175 The entries in the following table are registered by this document.
4177 +---------------+------+--------------+
4178 | Frame Type | Code | Section |
4179 +---------------+------+--------------+
4180 | DATA | 0x0 | Section 6.1 |
4181 | HEADERS | 0x1 | Section 6.2 |
4182 | PRIORITY | 0x2 | Section 6.3 |
4183 | RST_STREAM | 0x3 | Section 6.4 |
4184 | SETTINGS | 0x4 | Section 6.5 |
4185 | PUSH_PROMISE | 0x5 | Section 6.6 |
4186 | PING | 0x6 | Section 6.7 |
4187 | GOAWAY | 0x7 | Section 6.8 |
4188 | WINDOW_UPDATE | 0x8 | Section 6.9 |
4189 | CONTINUATION | 0x9 | Section 6.10 |
4190 +---------------+------+--------------+
4192 11.3. Settings Registry
4194 This document establishes a registry for HTTP/2 settings. The
4195 "HTTP/2 Settings" registry manages a 16-bit space. The "HTTP/2
4196 Settings" registry operates under the "Expert Review" policy
4197 [RFC5226] for values in the range from 0x0000 to 0xefff, with values
4198 between and 0xf000 and 0xffff being reserved for Experimental Use.
4202 Belshe, et al. Standards Track [Page 75]
4204 RFC 7540 HTTP/2 May 2015
4207 New registrations are advised to provide the following information:
4209 Name: A symbolic name for the setting. Specifying a setting name is
4212 Code: The 16-bit code assigned to the setting.
4214 Initial Value: An initial value for the setting.
4216 Specification: An optional reference to a specification that
4217 describes the use of the setting.
4219 The entries in the following table are registered by this document.
4221 +------------------------+------+---------------+---------------+
4222 | Name | Code | Initial Value | Specification |
4223 +------------------------+------+---------------+---------------+
4224 | HEADER_TABLE_SIZE | 0x1 | 4096 | Section 6.5.2 |
4225 | ENABLE_PUSH | 0x2 | 1 | Section 6.5.2 |
4226 | MAX_CONCURRENT_STREAMS | 0x3 | (infinite) | Section 6.5.2 |
4227 | INITIAL_WINDOW_SIZE | 0x4 | 65535 | Section 6.5.2 |
4228 | MAX_FRAME_SIZE | 0x5 | 16384 | Section 6.5.2 |
4229 | MAX_HEADER_LIST_SIZE | 0x6 | (infinite) | Section 6.5.2 |
4230 +------------------------+------+---------------+---------------+
4232 11.4. Error Code Registry
4234 This document establishes a registry for HTTP/2 error codes. The
4235 "HTTP/2 Error Code" registry manages a 32-bit space. The "HTTP/2
4236 Error Code" registry operates under the "Expert Review" policy
4239 Registrations for error codes are required to include a description
4240 of the error code. An expert reviewer is advised to examine new
4241 registrations for possible duplication with existing error codes.
4242 Use of existing registrations is to be encouraged, but not mandated.
4244 New registrations are advised to provide the following information:
4246 Name: A name for the error code. Specifying an error code name is
4249 Code: The 32-bit error code value.
4251 Description: A brief description of the error code semantics, longer
4252 if no detailed specification is provided.
4258 Belshe, et al. Standards Track [Page 76]
4260 RFC 7540 HTTP/2 May 2015
4263 Specification: An optional reference for a specification that
4264 defines the error code.
4266 The entries in the following table are registered by this document.
4268 +---------------------+------+----------------------+---------------+
4269 | Name | Code | Description | Specification |
4270 +---------------------+------+----------------------+---------------+
4271 | NO_ERROR | 0x0 | Graceful shutdown | Section 7 |
4272 | PROTOCOL_ERROR | 0x1 | Protocol error | Section 7 |
4274 | INTERNAL_ERROR | 0x2 | Implementation fault | Section 7 |
4275 | FLOW_CONTROL_ERROR | 0x3 | Flow-control limits | Section 7 |
4277 | SETTINGS_TIMEOUT | 0x4 | Settings not | Section 7 |
4278 | | | acknowledged | |
4279 | STREAM_CLOSED | 0x5 | Frame received for | Section 7 |
4280 | | | closed stream | |
4281 | FRAME_SIZE_ERROR | 0x6 | Frame size incorrect | Section 7 |
4282 | REFUSED_STREAM | 0x7 | Stream not processed | Section 7 |
4283 | CANCEL | 0x8 | Stream cancelled | Section 7 |
4284 | COMPRESSION_ERROR | 0x9 | Compression state | Section 7 |
4285 | | | not updated | |
4286 | CONNECT_ERROR | 0xa | TCP connection error | Section 7 |
4287 | | | for CONNECT method | |
4288 | ENHANCE_YOUR_CALM | 0xb | Processing capacity | Section 7 |
4290 | INADEQUATE_SECURITY | 0xc | Negotiated TLS | Section 7 |
4291 | | | parameters not | |
4292 | | | acceptable | |
4293 | HTTP_1_1_REQUIRED | 0xd | Use HTTP/1.1 for the | Section 7 |
4295 +---------------------+------+----------------------+---------------+
4297 11.5. HTTP2-Settings Header Field Registration
4299 This section registers the HTTP2-Settings header field in the
4300 "Permanent Message Header Field Names" registry [BCP90].
4302 Header field name: HTTP2-Settings
4304 Applicable protocol: http
4308 Author/Change controller: IETF
4314 Belshe, et al. Standards Track [Page 77]
4316 RFC 7540 HTTP/2 May 2015
4319 Specification document(s): Section 3.2.1 of this document
4321 Related information: This header field is only used by an HTTP/2
4322 client for Upgrade-based negotiation.
4324 11.6. PRI Method Registration
4326 This section registers the "PRI" method in the "HTTP Method Registry"
4327 ([RFC7231], Section 8.1).
4335 Specification document(s): Section 3.5 of this document
4337 Related information: This method is never used by an actual client.
4338 This method will appear to be used when an HTTP/1.1 server or
4339 intermediary attempts to parse an HTTP/2 connection preface.
4341 11.7. The 421 (Misdirected Request) HTTP Status Code
4343 This document registers the 421 (Misdirected Request) HTTP status
4344 code in the "HTTP Status Codes" registry ([RFC7231], Section 8.2).
4348 Short Description: Misdirected Request
4350 Specification: Section 9.1.2 of this document
4352 11.8. The h2c Upgrade Token
4354 This document registers the "h2c" upgrade token in the "HTTP Upgrade
4355 Tokens" registry ([RFC7230], Section 8.6).
4359 Description: Hypertext Transfer Protocol version 2 (HTTP/2)
4361 Expected Version Tokens: None
4363 Reference: Section 3.2 of this document
4370 Belshe, et al. Standards Track [Page 78]
4372 RFC 7540 HTTP/2 May 2015
4377 12.1. Normative References
4379 [COMPRESSION] Peon, R. and H. Ruellan, "HPACK: Header Compression for
4380 HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
4381 <http://www.rfc-editor.org/info/rfc7541>.
4383 [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
4384 DOI 10.17487/RFC6265, April 2011,
4385 <http://www.rfc-editor.org/info/rfc6265>.
4387 [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB
4389 <http://dx.doi.org/10.6028/NIST.FIPS.186-4>.
4391 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
4392 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
4393 RFC2119, March 1997,
4394 <http://www.rfc-editor.org/info/rfc2119>.
4396 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/
4398 <http://www.rfc-editor.org/info/rfc2818>.
4400 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter,
4401 "Uniform Resource Identifier (URI): Generic Syntax",
4402 STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
4403 <http://www.rfc-editor.org/info/rfc3986>.
4405 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
4406 Encodings", RFC 4648, DOI 10.17487/RFC4648, October
4407 2006, <http://www.rfc-editor.org/info/rfc4648>.
4409 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing
4410 an IANA Considerations Section in RFCs", BCP 26,
4411 RFC 5226, DOI 10.17487/RFC5226, May 2008,
4412 <http://www.rfc-editor.org/info/rfc5226>.
4414 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for
4415 Syntax Specifications: ABNF", STD 68, RFC 5234,
4416 DOI 10.17487/ RFC5234, January 2008,
4417 <http://www.rfc-editor.org/info/rfc5234>.
4419 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4420 Transfer Protocol (HTTP/1.1): Message Syntax and
4421 Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014,
4422 <http://www.rfc-editor.org/info/rfc7230>.
4426 Belshe, et al. Standards Track [Page 79]
4428 RFC 7540 HTTP/2 May 2015
4431 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4432 Transfer Protocol (HTTP/1.1): Semantics and Content",
4433 RFC 7231, DOI 10.17487/RFC7231, June 2014,
4434 <http://www.rfc-editor.org/info/rfc7231>.
4436 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4437 Transfer Protocol (HTTP/1.1): Conditional Requests",
4438 RFC 7232, DOI 10.17487/RFC7232, June 2014,
4439 <http://www.rfc-editor.org/info/rfc7232>.
4441 [RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
4442 "Hypertext Transfer Protocol (HTTP/1.1): Range
4443 Requests", RFC 7233, DOI 10.17487/RFC7233, June 2014,
4444 <http://www.rfc-editor.org/info/rfc7233>.
4446 [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
4447 Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
4448 RFC 7234, DOI 10.17487/RFC7234, June 2014,
4449 <http://www.rfc-editor.org/info/rfc7234>.
4451 [RFC7235] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
4452 Transfer Protocol (HTTP/1.1): Authentication",
4453 RFC 7235, DOI 10.17487/RFC7235, June 2014,
4454 <http://www.rfc-editor.org/info/rfc7235>.
4456 [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
4457 793, DOI 10.17487/RFC0793, September 1981,
4458 <http://www.rfc-editor.org/info/rfc793>.
4460 [TLS-ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
4461 "Transport Layer Security (TLS) Application-Layer
4462 Protocol Negotiation Extension", RFC 7301,
4463 DOI 10.17487/RFC7301, July 2014,
4464 <http://www.rfc-editor.org/info/rfc7301>.
4466 [TLS-ECDHE] Rescorla, E., "TLS Elliptic Curve Cipher Suites with
4467 SHA-256/384 and AES Galois Counter Mode (GCM)",
4468 RFC 5289, DOI 10.17487/RFC5289, August 2008,
4469 <http://www.rfc-editor.org/info/rfc5289>.
4471 [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
4472 Extensions: Extension Definitions", RFC 6066,
4473 DOI 10.17487/RFC6066, January 2011,
4474 <http://www.rfc-editor.org/info/rfc6066>.
4482 Belshe, et al. Standards Track [Page 80]
4484 RFC 7540 HTTP/2 May 2015
4487 [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer
4488 Security (TLS) Protocol Version 1.2", RFC 5246,
4489 DOI 10.17487/ RFC5246, August 2008,
4490 <http://www.rfc-editor.org/info/rfc5246>.
4492 12.2. Informative References
4494 [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
4495 Alternative Services", Work in Progress, draft-ietf-
4496 httpbis-alt-svc-06, February 2015.
4498 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
4499 Procedures for Message Header Fields", BCP 90,
4500 RFC 3864, September 2004,
4501 <http://www.rfc-editor.org/info/bcp90>.
4503 [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving
4504 the CRIME Attack", July 2013,
4505 <http://breachattack.com/resources/
4506 BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
4508 [HTML5] Hickson, I., Berjon, R., Faulkner, S., Leithead, T.,
4509 Doyle Navara, E., O'Connor, E., and S. Pfeiffer,
4510 "HTML5", W3C Recommendation REC-html5-20141028, October
4511 2014, <http://www.w3.org/TR/2014/REC-html5-20141028/>.
4513 [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
4514 Compression Methods", RFC 3749, DOI 10.17487/RFC3749,
4515 May 2004, <http://www.rfc-editor.org/info/rfc3749>.
4517 [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and
4518 B. Moeller, "Elliptic Curve Cryptography (ECC) Cipher
4519 Suites for Transport Layer Security (TLS)", RFC 4492,
4520 DOI 10.17487/RFC4492, May 2006,
4521 <http://www.rfc-editor.org/info/rfc4492>.
4523 [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
4524 Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
4525 <http://www.rfc-editor.org/info/rfc6585>.
4527 [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
4528 Scheffenegger, Ed., "TCP Extensions for High
4529 Performance", RFC 7323, DOI 10.17487/RFC7323, September
4530 2014, <http://www.rfc-editor.org/info/rfc7323>.
4532 [TALKING] Huang, L., Chen, E., Barth, A., Rescorla, E., and C.
4533 Jackson, "Talking to Yourself for Fun and Profit",
4534 2011, <http://w2spconf.com/2011/papers/websocket.pdf>.
4538 Belshe, et al. Standards Track [Page 81]
4540 RFC 7540 HTTP/2 May 2015
4543 [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
4544 "Recommendations for Secure Use of Transport Layer
4545 Security (TLS) and Datagram Transport Layer Security
4546 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May
4547 2015, <http://www.rfc-editor.org/info/rfc7525>.
4594 Belshe, et al. Standards Track [Page 82]
4596 RFC 7540 HTTP/2 May 2015
4599 Appendix A. TLS 1.2 Cipher Suite Black List
4601 An HTTP/2 implementation MAY treat the negotiation of any of the
4602 following cipher suites with TLS 1.2 as a connection error
4603 (Section 5.4.1) of type INADEQUATE_SECURITY:
4605 o TLS_NULL_WITH_NULL_NULL
4607 o TLS_RSA_WITH_NULL_MD5
4609 o TLS_RSA_WITH_NULL_SHA
4611 o TLS_RSA_EXPORT_WITH_RC4_40_MD5
4613 o TLS_RSA_WITH_RC4_128_MD5
4615 o TLS_RSA_WITH_RC4_128_SHA
4617 o TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
4619 o TLS_RSA_WITH_IDEA_CBC_SHA
4621 o TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
4623 o TLS_RSA_WITH_DES_CBC_SHA
4625 o TLS_RSA_WITH_3DES_EDE_CBC_SHA
4627 o TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
4629 o TLS_DH_DSS_WITH_DES_CBC_SHA
4631 o TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA
4633 o TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
4635 o TLS_DH_RSA_WITH_DES_CBC_SHA
4637 o TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA
4639 o TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
4641 o TLS_DHE_DSS_WITH_DES_CBC_SHA
4643 o TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
4645 o TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
4650 Belshe, et al. Standards Track [Page 83]
4652 RFC 7540 HTTP/2 May 2015
4655 o TLS_DHE_RSA_WITH_DES_CBC_SHA
4657 o TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
4659 o TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
4661 o TLS_DH_anon_WITH_RC4_128_MD5
4663 o TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
4665 o TLS_DH_anon_WITH_DES_CBC_SHA
4667 o TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
4669 o TLS_KRB5_WITH_DES_CBC_SHA
4671 o TLS_KRB5_WITH_3DES_EDE_CBC_SHA
4673 o TLS_KRB5_WITH_RC4_128_SHA
4675 o TLS_KRB5_WITH_IDEA_CBC_SHA
4677 o TLS_KRB5_WITH_DES_CBC_MD5
4679 o TLS_KRB5_WITH_3DES_EDE_CBC_MD5
4681 o TLS_KRB5_WITH_RC4_128_MD5
4683 o TLS_KRB5_WITH_IDEA_CBC_MD5
4685 o TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA
4687 o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA
4689 o TLS_KRB5_EXPORT_WITH_RC4_40_SHA
4691 o TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5
4693 o TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5
4695 o TLS_KRB5_EXPORT_WITH_RC4_40_MD5
4697 o TLS_PSK_WITH_NULL_SHA
4699 o TLS_DHE_PSK_WITH_NULL_SHA
4701 o TLS_RSA_PSK_WITH_NULL_SHA
4706 Belshe, et al. Standards Track [Page 84]
4708 RFC 7540 HTTP/2 May 2015
4711 o TLS_RSA_WITH_AES_128_CBC_SHA
4713 o TLS_DH_DSS_WITH_AES_128_CBC_SHA
4715 o TLS_DH_RSA_WITH_AES_128_CBC_SHA
4717 o TLS_DHE_DSS_WITH_AES_128_CBC_SHA
4719 o TLS_DHE_RSA_WITH_AES_128_CBC_SHA
4721 o TLS_DH_anon_WITH_AES_128_CBC_SHA
4723 o TLS_RSA_WITH_AES_256_CBC_SHA
4725 o TLS_DH_DSS_WITH_AES_256_CBC_SHA
4727 o TLS_DH_RSA_WITH_AES_256_CBC_SHA
4729 o TLS_DHE_DSS_WITH_AES_256_CBC_SHA
4731 o TLS_DHE_RSA_WITH_AES_256_CBC_SHA
4733 o TLS_DH_anon_WITH_AES_256_CBC_SHA
4735 o TLS_RSA_WITH_NULL_SHA256
4737 o TLS_RSA_WITH_AES_128_CBC_SHA256
4739 o TLS_RSA_WITH_AES_256_CBC_SHA256
4741 o TLS_DH_DSS_WITH_AES_128_CBC_SHA256
4743 o TLS_DH_RSA_WITH_AES_128_CBC_SHA256
4745 o TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
4747 o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA
4749 o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA
4751 o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA
4753 o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA
4755 o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA
4757 o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA
4762 Belshe, et al. Standards Track [Page 85]
4764 RFC 7540 HTTP/2 May 2015
4767 o TLS_DHE_RSA_WITH_AES_128_CBC_SHA256
4769 o TLS_DH_DSS_WITH_AES_256_CBC_SHA256
4771 o TLS_DH_RSA_WITH_AES_256_CBC_SHA256
4773 o TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
4775 o TLS_DHE_RSA_WITH_AES_256_CBC_SHA256
4777 o TLS_DH_anon_WITH_AES_128_CBC_SHA256
4779 o TLS_DH_anon_WITH_AES_256_CBC_SHA256
4781 o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA
4783 o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA
4785 o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA
4787 o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA
4789 o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA
4791 o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA
4793 o TLS_PSK_WITH_RC4_128_SHA
4795 o TLS_PSK_WITH_3DES_EDE_CBC_SHA
4797 o TLS_PSK_WITH_AES_128_CBC_SHA
4799 o TLS_PSK_WITH_AES_256_CBC_SHA
4801 o TLS_DHE_PSK_WITH_RC4_128_SHA
4803 o TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA
4805 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA
4807 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA
4809 o TLS_RSA_PSK_WITH_RC4_128_SHA
4811 o TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA
4813 o TLS_RSA_PSK_WITH_AES_128_CBC_SHA
4818 Belshe, et al. Standards Track [Page 86]
4820 RFC 7540 HTTP/2 May 2015
4823 o TLS_RSA_PSK_WITH_AES_256_CBC_SHA
4825 o TLS_RSA_WITH_SEED_CBC_SHA
4827 o TLS_DH_DSS_WITH_SEED_CBC_SHA
4829 o TLS_DH_RSA_WITH_SEED_CBC_SHA
4831 o TLS_DHE_DSS_WITH_SEED_CBC_SHA
4833 o TLS_DHE_RSA_WITH_SEED_CBC_SHA
4835 o TLS_DH_anon_WITH_SEED_CBC_SHA
4837 o TLS_RSA_WITH_AES_128_GCM_SHA256
4839 o TLS_RSA_WITH_AES_256_GCM_SHA384
4841 o TLS_DH_RSA_WITH_AES_128_GCM_SHA256
4843 o TLS_DH_RSA_WITH_AES_256_GCM_SHA384
4845 o TLS_DH_DSS_WITH_AES_128_GCM_SHA256
4847 o TLS_DH_DSS_WITH_AES_256_GCM_SHA384
4849 o TLS_DH_anon_WITH_AES_128_GCM_SHA256
4851 o TLS_DH_anon_WITH_AES_256_GCM_SHA384
4853 o TLS_PSK_WITH_AES_128_GCM_SHA256
4855 o TLS_PSK_WITH_AES_256_GCM_SHA384
4857 o TLS_RSA_PSK_WITH_AES_128_GCM_SHA256
4859 o TLS_RSA_PSK_WITH_AES_256_GCM_SHA384
4861 o TLS_PSK_WITH_AES_128_CBC_SHA256
4863 o TLS_PSK_WITH_AES_256_CBC_SHA384
4865 o TLS_PSK_WITH_NULL_SHA256
4867 o TLS_PSK_WITH_NULL_SHA384
4869 o TLS_DHE_PSK_WITH_AES_128_CBC_SHA256
4874 Belshe, et al. Standards Track [Page 87]
4876 RFC 7540 HTTP/2 May 2015
4879 o TLS_DHE_PSK_WITH_AES_256_CBC_SHA384
4881 o TLS_DHE_PSK_WITH_NULL_SHA256
4883 o TLS_DHE_PSK_WITH_NULL_SHA384
4885 o TLS_RSA_PSK_WITH_AES_128_CBC_SHA256
4887 o TLS_RSA_PSK_WITH_AES_256_CBC_SHA384
4889 o TLS_RSA_PSK_WITH_NULL_SHA256
4891 o TLS_RSA_PSK_WITH_NULL_SHA384
4893 o TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256
4895 o TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256
4897 o TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256
4899 o TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256
4901 o TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
4903 o TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256
4905 o TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256
4907 o TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256
4909 o TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256
4911 o TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256
4913 o TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256
4915 o TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256
4917 o TLS_EMPTY_RENEGOTIATION_INFO_SCSV
4919 o TLS_ECDH_ECDSA_WITH_NULL_SHA
4921 o TLS_ECDH_ECDSA_WITH_RC4_128_SHA
4923 o TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA
4925 o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA
4930 Belshe, et al. Standards Track [Page 88]
4932 RFC 7540 HTTP/2 May 2015
4935 o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA
4937 o TLS_ECDHE_ECDSA_WITH_NULL_SHA
4939 o TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
4941 o TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
4943 o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
4945 o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
4947 o TLS_ECDH_RSA_WITH_NULL_SHA
4949 o TLS_ECDH_RSA_WITH_RC4_128_SHA
4951 o TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA
4953 o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA
4955 o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA
4957 o TLS_ECDHE_RSA_WITH_NULL_SHA
4959 o TLS_ECDHE_RSA_WITH_RC4_128_SHA
4961 o TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
4963 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
4965 o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
4967 o TLS_ECDH_anon_WITH_NULL_SHA
4969 o TLS_ECDH_anon_WITH_RC4_128_SHA
4971 o TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA
4973 o TLS_ECDH_anon_WITH_AES_128_CBC_SHA
4975 o TLS_ECDH_anon_WITH_AES_256_CBC_SHA
4977 o TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA
4979 o TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA
4981 o TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA
4986 Belshe, et al. Standards Track [Page 89]
4988 RFC 7540 HTTP/2 May 2015
4991 o TLS_SRP_SHA_WITH_AES_128_CBC_SHA
4993 o TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA
4995 o TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA
4997 o TLS_SRP_SHA_WITH_AES_256_CBC_SHA
4999 o TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA
5001 o TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA
5003 o TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
5005 o TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
5007 o TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256
5009 o TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384
5011 o TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
5013 o TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
5015 o TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256
5017 o TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384
5019 o TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
5021 o TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
5023 o TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
5025 o TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
5027 o TLS_ECDHE_PSK_WITH_RC4_128_SHA
5029 o TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA
5031 o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA
5033 o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA
5035 o TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256
5037 o TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384
5042 Belshe, et al. Standards Track [Page 90]
5044 RFC 7540 HTTP/2 May 2015
5047 o TLS_ECDHE_PSK_WITH_NULL_SHA
5049 o TLS_ECDHE_PSK_WITH_NULL_SHA256
5051 o TLS_ECDHE_PSK_WITH_NULL_SHA384
5053 o TLS_RSA_WITH_ARIA_128_CBC_SHA256
5055 o TLS_RSA_WITH_ARIA_256_CBC_SHA384
5057 o TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256
5059 o TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384
5061 o TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256
5063 o TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384
5065 o TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256
5067 o TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384
5069 o TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256
5071 o TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384
5073 o TLS_DH_anon_WITH_ARIA_128_CBC_SHA256
5075 o TLS_DH_anon_WITH_ARIA_256_CBC_SHA384
5077 o TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256
5079 o TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384
5081 o TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256
5083 o TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384
5085 o TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256
5087 o TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384
5089 o TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256
5091 o TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384
5093 o TLS_RSA_WITH_ARIA_128_GCM_SHA256
5098 Belshe, et al. Standards Track [Page 91]
5100 RFC 7540 HTTP/2 May 2015
5103 o TLS_RSA_WITH_ARIA_256_GCM_SHA384
5105 o TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256
5107 o TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384
5109 o TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256
5111 o TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384
5113 o TLS_DH_anon_WITH_ARIA_128_GCM_SHA256
5115 o TLS_DH_anon_WITH_ARIA_256_GCM_SHA384
5117 o TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256
5119 o TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384
5121 o TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256
5123 o TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384
5125 o TLS_PSK_WITH_ARIA_128_CBC_SHA256
5127 o TLS_PSK_WITH_ARIA_256_CBC_SHA384
5129 o TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256
5131 o TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384
5133 o TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256
5135 o TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384
5137 o TLS_PSK_WITH_ARIA_128_GCM_SHA256
5139 o TLS_PSK_WITH_ARIA_256_GCM_SHA384
5141 o TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256
5143 o TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384
5145 o TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256
5147 o TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384
5149 o TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
5154 Belshe, et al. Standards Track [Page 92]
5156 RFC 7540 HTTP/2 May 2015
5159 o TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
5161 o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256
5163 o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384
5165 o TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256
5167 o TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384
5169 o TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256
5171 o TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384
5173 o TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256
5175 o TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384
5177 o TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256
5179 o TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384
5181 o TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256
5183 o TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384
5185 o TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256
5187 o TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384
5189 o TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256
5191 o TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384
5193 o TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256
5195 o TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384
5197 o TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256
5199 o TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384
5201 o TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256
5203 o TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384
5205 o TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256
5210 Belshe, et al. Standards Track [Page 93]
5212 RFC 7540 HTTP/2 May 2015
5215 o TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384
5217 o TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
5219 o TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
5221 o TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256
5223 o TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384
5225 o TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256
5227 o TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384
5229 o TLS_RSA_WITH_AES_128_CCM
5231 o TLS_RSA_WITH_AES_256_CCM
5233 o TLS_RSA_WITH_AES_128_CCM_8
5235 o TLS_RSA_WITH_AES_256_CCM_8
5237 o TLS_PSK_WITH_AES_128_CCM
5239 o TLS_PSK_WITH_AES_256_CCM
5241 o TLS_PSK_WITH_AES_128_CCM_8
5243 o TLS_PSK_WITH_AES_256_CCM_8
5245 Note: This list was assembled from the set of registered TLS
5246 cipher suites at the time of writing. This list includes those
5247 cipher suites that do not offer an ephemeral key exchange and
5248 those that are based on the TLS null, stream, or block cipher type
5249 (as defined in Section 6.2.3 of [TLS12]). Additional cipher
5250 suites with these properties could be defined; these would not be
5251 explicitly prohibited.
5266 Belshe, et al. Standards Track [Page 94]
5268 RFC 7540 HTTP/2 May 2015
5273 This document includes substantial input from the following
5276 o Adam Langley, Wan-Teh Chang, Jim Morrison, Mark Nottingham, Alyssa
5277 Wilk, Costin Manolache, William Chan, Vitaliy Lvin, Joe Chan, Adam
5278 Barth, Ryan Hamilton, Gavin Peters, Kent Alstad, Kevin Lindsay,
5279 Paul Amer, Fan Yang, and Jonathan Leighton (SPDY contributors).
5281 o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism).
5283 o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro,
5284 Jitu Padhye, Roberto Peon, and Rob Trace (Flow control).
5286 o Mike Bishop (Extensibility).
5288 o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike
5289 Bishop, and Herve Ruellan (Substantial editorial contributions).
5291 o Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp,
5292 and Jonathan Thackray.
5294 o Alexey Melnikov, who was an editor of this document in 2013.
5296 A substantial proportion of Martin's contribution was supported by
5297 Microsoft during his employment there.
5299 The Japanese HTTP/2 community provided invaluable contributions,
5300 including a number of implementations as well as numerous technical
5301 and editorial contributions.
5322 Belshe, et al. Standards Track [Page 95]
5324 RFC 7540 HTTP/2 May 2015
5332 EMail: mike@belshe.com
5338 EMail: fenix@google.com
5341 Martin Thomson (editor)
5344 Mountain View, CA 94041
5347 EMail: martin.thomson@gmail.com
5378 Belshe, et al. Standards Track [Page 96]
Soft'N'Design Software / projects / webserver.git / blob