--- 1/draft-ietf-httpbis-http2-16.txt 2015-02-10 19:14:59.773421855 -0800 +++ 2/draft-ietf-httpbis-http2-17.txt 2015-02-10 19:14:59.941425890 -0800 @@ -1,29 +1,29 @@ HTTPbis Working Group M. Belshe Internet-Draft Twist Intended status: Standards Track R. Peon -Expires: June 2, 2015 Google, Inc +Expires: August 15, 2015 Google, Inc M. Thomson, Ed. Mozilla - November 29, 2014 + February 11, 2015 Hypertext Transfer Protocol version 2 - draft-ietf-httpbis-http2-16 + draft-ietf-httpbis-http2-17 Abstract This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple - concurrent messages on the same connection. It also introduces + concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the HTTPBIS working group mailing list (ietf-http-wg@w3.org), which is archived at [1]. @@ -39,25 +39,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on June 2, 2015. + This Internet-Draft will expire on August 15, 2015. Copyright Notice - Copyright (c) 2014 IETF Trust and the persons identified as the + Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -70,39 +70,39 @@ 2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6 3. Starting HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. HTTP/2 Version Identification . . . . . . . . . . . . . . 8 3.2. Starting HTTP/2 for "http" URIs . . . . . . . . . . . . . 9 3.2.1. HTTP2-Settings Header Field . . . . . . . . . . . . . 10 3.3. Starting HTTP/2 for "https" URIs . . . . . . . . . . . . 11 3.4. Starting HTTP/2 with Prior Knowledge . . . . . . . . . . 11 3.5. HTTP/2 Connection Preface . . . . . . . . . . . . . . . . 11 4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 13 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . 14 4.3. Header Compression and Decompression . . . . . . . . . . 14 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . 15 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 16 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 21 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 22 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 23 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 23 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 24 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 25 5.3.1. Stream Dependencies . . . . . . . . . . . . . . . . . 25 5.3.2. Dependency Weighting . . . . . . . . . . . . . . . . 26 - 5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . 26 + 5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . 27 5.3.4. Prioritization State Management . . . . . . . . . . . 27 5.3.5. Default Priorities . . . . . . . . . . . . . . . . . 29 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 29 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 29 - 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 29 + 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 30 5.4.3. Connection Termination . . . . . . . . . . . . . . . 30 5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 30 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 31 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 31 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 33 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 35 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 36 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 37 6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 38 6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 38 @@ -110,60 +110,61 @@ 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 40 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 43 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 46 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 47 6.9.2. Initial Flow Control Window Size . . . . . . . . . . 48 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 49 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 49 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 50 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . 51 - 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . 52 + 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . 51 8.1.1. Upgrading From HTTP/2 . . . . . . . . . . . . . . . . 53 8.1.2. HTTP Header Fields . . . . . . . . . . . . . . . . . 53 8.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 57 - 8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . 60 - 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 61 - 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 62 - 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . 63 - 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . 64 - 9. Additional HTTP Requirements/Considerations . . . . . . . . . 65 - 9.1. Connection Management . . . . . . . . . . . . . . . . . . 65 - 9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 66 - 9.1.2. The 421 (Misdirected Request) Status Code . . . . . . 67 - 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 67 + 8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . 59 + 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 60 + 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 61 + 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . 62 + 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . 63 + 9. Additional HTTP Requirements/Considerations . . . . . . . . . 64 + 9.1. Connection Management . . . . . . . . . . . . . . . . . . 64 + 9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 65 + 9.1.2. The 421 (Misdirected Request) Status Code . . . . . . 66 + 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 66 9.2.1. TLS 1.2 Features . . . . . . . . . . . . . . . . . . 67 9.2.2. TLS 1.2 Cipher Suites . . . . . . . . . . . . . . . . 68 - 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69 - 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 69 - 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 69 - 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 70 - 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 70 + 10. Security Considerations . . . . . . . . . . . . . . . . . . . 68 + 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 68 + 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 68 + 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 69 + 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 69 10.5. Denial of Service Considerations . . . . . . . . . . . . 70 - 10.5.1. Limits on Header Block Size . . . . . . . . . . . . 72 + 10.5.1. Limits on Header Block Size . . . . . . . . . . . . 71 + 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 71 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 72 - 10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 73 + 10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 72 10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 73 - 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 + 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 73 11.1. Registration of HTTP/2 Identification Strings . . . . . 74 - 11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 75 + 11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 74 11.3. Settings Registry . . . . . . . . . . . . . . . . . . . 75 11.4. Error Code Registry . . . . . . . . . . . . . . . . . . 76 11.5. HTTP2-Settings Header Field Registration . . . . . . . . 77 11.6. PRI Method Registration . . . . . . . . . . . . . . . . 78 11.7. The 421 (Misdirected Request) HTTP Status Code . . . . . 78 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 79 13.2. Informative References . . . . . . . . . . . . . . . . . 80 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 81 - Appendix A. Prohibited TLS 1.2 Cipher Suites . . . . . . . . . . 82 + Appendix A. TLS 1.2 Cipher Suite Black List . . . . . . . . . . 82 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 86 B.1. Since draft-ietf-httpbis-http2-15 . . . . . . . . . . . . 86 B.2. Since draft-ietf-httpbis-http2-14 . . . . . . . . . . . . 86 B.3. Since draft-ietf-httpbis-http2-13 . . . . . . . . . . . . 87 B.4. Since draft-ietf-httpbis-http2-12 . . . . . . . . . . . . 87 B.5. Since draft-ietf-httpbis-http2-11 . . . . . . . . . . . . 87 B.6. Since draft-ietf-httpbis-http2-10 . . . . . . . . . . . . 87 B.7. Since draft-ietf-httpbis-http2-09 . . . . . . . . . . . . 88 B.8. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 88 B.9. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 89 @@ -179,22 +180,22 @@ 1. Introduction The Hypertext Transfer Protocol (HTTP) is a wildly successful protocol. However, how HTTP/1.1 uses the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative overall effect on application performance today. In particular, HTTP/1.0 allowed only one request to be outstanding at a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still - suffers from head-of-line blocking. Therefore, HTTP/1.1 clients that - need to make many requests typically use multiple connections to a + suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 + clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. Furthermore, HTTP header fields are often repetitive and verbose, causing unnecessary network traffic, as well as causing the initial TCP [TCP] congestion window to quickly fill. This can result in excessive latency when multiple requests are made on a new TCP connection. HTTP/2 addresses these issues by defining an optimized mapping of HTTP's semantics to an underlying connection. Specifically, it @@ -241,21 +242,21 @@ speculatively send data to a client that the server anticipates the client will need, trading off some network usage against a potential latency gain. The server does this by synthesizing a request, which it sends as a PUSH_PROMISE frame. The server is then able to send a response to the synthetic request on a separate stream. Because HTTP header fields used in a connection can contain large amounts of redundant data, frames that contain them are compressed (Section 4.3). This has especially advantageous impact upon request sizes in the common case, allowing many requests to be compressed - into one TCP packet. + into one packet. 2.1. Document Organization The HTTP/2 specification is split into four parts: o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is initiated. o The framing (Section 4) and streams (Section 5) layers describe the way HTTP/2 frames are structured and formed into multiplexed @@ -279,50 +280,55 @@ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. All numeric values are in network byte order. Values are unsigned unless otherwise indicated. Literal values are provided in decimal or hexadecimal as appropriate. Hexadecimal literals are prefixed with "0x" to distinguish them from decimal literals. The following terms are used: - client: The endpoint initiating the HTTP/2 connection. + client: The endpoint that initiates an HTTP/2 connection. Clients + send HTTP requests and receive HTTP responses. connection: A transport-layer connection between two endpoints. connection error: An error that affects the entire HTTP/2 connection. endpoint: Either the client or server of the connection. frame: The smallest unit of communication within an HTTP/2 connection, consisting of a header and a variable-length sequence of octets structured according to the frame type. peer: An endpoint. When discussing a particular endpoint, "peer" refers to the endpoint that is remote to the primary subject of discussion. receiver: An endpoint that is receiving frames. sender: An endpoint that is transmitting frames. - server: The endpoint which did not initiate the HTTP/2 connection. + server: The endpoint that accepts an HTTP/2 connection. Servers + receive HTTP requests and serve HTTP responses. - stream: A bi-directional flow of frames across a virtual channel - within the HTTP/2 connection. + stream: A bi-directional flow of frames within the HTTP/2 + connection. stream error: An error on the individual HTTP/2 stream. Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" - are defined in Section 2.3 of [RFC7230]. + are defined in Section 2.3 of [RFC7230]. Intermediaries act as both + client and server at different times. + + The term "payload body" is defined in Section 3.3 of [RFC7230]. 3. Starting HTTP/2 An HTTP/2 connection is an application layer protocol running on top of a TCP connection ([TCP]). The client is the TCP connection initiator. HTTP/2 uses the same "http" and "https" URI schemes used by HTTP/1.1. HTTP/2 shares the same default port numbers: 80 for "http" URIs and 443 for "https" URIs. As a result, implementations processing @@ -344,35 +350,34 @@ protocol negotiation extension (ALPN) [TLS-ALPN] field and in any place where HTTP/2 over TLS is identified. The "h2" string is serialized into an ALPN protocol identifier as the two octet sequence: 0x68, 0x32. o The string "h2c" identifies the protocol where HTTP/2 is run over cleartext TCP. This identifier is used in the HTTP/1.1 Upgrade header field and in any place where HTTP/2 over TCP is identified. + The "h2c" string is reserved from the ALPN identifier space, but + describes a protocol that does not use TLS. + Negotiating "h2" or "h2c" implies the use of the transport, security, framing and message semantics described in this document. [[CREF1: RFC Editor's Note: please remove the remainder of this section prior to the publication of a final version of this document.]] Only implementations of the final, published RFC can identify themselves as "h2" or "h2c". Until such an RFC exists, implementations MUST NOT identify themselves using these strings. - Examples and text throughout the rest of this document use "h2" as a - matter of editorial convenience only. Implementations of draft - versions MUST NOT identify using this string. - Implementations of draft versions of the protocol MUST add the string "-" and the corresponding draft number to the identifier. For example, draft-ietf-httpbis-http2-11 over TLS is identified using the string "h2-11". Non-compatible experiments that are based on these draft versions MUST append the string "-" and an experiment name to the identifier. For example, an experimental implementation of packet mood-based encoding based on draft-ietf-httpbis-http2-09 might identify itself as "h2-09-emo". Note that any label MUST conform to the "token" @@ -390,66 +395,67 @@ HTTP2-Settings (Section 3.2.1) header field. For example: GET / HTTP/1.1 Host: server.example.com Connection: Upgrade, HTTP2-Settings Upgrade: h2c HTTP2-Settings: - Requests that contain an entity body MUST be sent in their entirety + Requests that contain an payload body MUST be sent in their entirety before the client can send HTTP/2 frames. This means that a large - request entity can block the use of the connection until it is - completely sent. + request can block the use of the connection until it is completely + sent. If concurrency of an initial request with subsequent requests is important, an OPTIONS request can be used to perform the upgrade to HTTP/2, at the cost of an additional round-trip. A server that does not support HTTP/2 can respond to the request as though the Upgrade header field were absent: HTTP/1.1 200 OK Content-Length: 243 Content-Type: text/html ... - A server MUST ignore a "h2" token in an Upgrade header field. + A server MUST ignore an "h2" token in an Upgrade header field. Presence of a token with "h2" implies HTTP/2 over TLS, which is instead negotiated as described in Section 3.3. - A server that supports HTTP/2 can accept the upgrade with a 101 + A server that supports HTTP/2 accepts the upgrade with a 101 (Switching Protocols) response. After the empty line that terminates the 101 response, the server can begin sending HTTP/2 frames. These frames MUST include a response to the request that initiated the Upgrade. For example: HTTP/1.1 101 Switching Protocols Connection: Upgrade Upgrade: h2c [ HTTP/2 connection ... The first HTTP/2 frame sent by the server MUST be a SETTINGS frame (Section 6.5) as the server connection preface (Section 3.5). Upon receiving the 101 response, the client MUST send a connection preface (Section 3.5), which includes a SETTINGS frame. - The HTTP/1.1 request that is sent prior to upgrade is assigned stream - identifier 1 and is assigned default priority values (Section 5.3.5). - Stream 1 is implicitly half closed from the client toward the server, - since the request is completed as an HTTP/1.1 request. After - commencing the HTTP/2 connection, stream 1 is used for the response. + The HTTP/1.1 request that is sent prior to upgrade is assigned a + stream identifier of 1 (see Section 5.1.1) with default priority + values (Section 5.3.5). Stream 1 is implicitly "half closed" from + the client toward the server (see Section 5.1), since the request is + completed as an HTTP/1.1 request. After commencing the HTTP/2 + connection, stream 1 is used for the response. 3.2.1. HTTP2-Settings Header Field A request that upgrades from HTTP/1.1 to HTTP/2 MUST include exactly one "HTTP2-Settings" header field. The "HTTP2-Settings" header field is a connection-specific header field that includes parameters that govern the HTTP/2 connection, provided in anticipation of the server accepting the request to upgrade. HTTP2-Settings = token68 @@ -474,42 +480,45 @@ A server decodes and interprets these values as it would any other SETTINGS frame. Explicit acknowledgement of these settings (Section 6.5.3) is not necessary, since a 101 response serves as implicit acknowledgment. Providing these values in the Upgrade request gives a client an opportunity to provide parameters prior to receiving any frames from the server. 3.3. Starting HTTP/2 for "https" URIs A client that makes a request to an "https" URI uses TLS [TLS12] with - the application layer protocol negotiation extension [TLS-ALPN]. + the application layer protocol negotiation (ALPN) extension + [TLS-ALPN]. - HTTP/2 over TLS uses the "h2" application token. The "h2c" token - MUST NOT be sent by a client or selected by a server. + HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" + protocol identifier MUST NOT be sent by a client or selected by a + server; the "h2c" protocol identifier describes a protocol that does + not use TLS. Once TLS negotiation is complete, both the client and the server MUST send a connection preface (Section 3.5). 3.4. Starting HTTP/2 with Prior Knowledge A client can learn that a particular server supports HTTP/2 by other means. For example, [ALT-SVC] describes a mechanism for advertising this capability. A client MUST send the connection preface (Section 3.5), and then MAY immediately send HTTP/2 frames to such a server; servers can identify these connections by the presence of the connection preface. This only affects the establishment of HTTP/2 connections over cleartext TCP; implementations that support HTTP/2 over TLS MUST use protocol negotiation in TLS [TLS-ALPN]. - Likewise, the sever MUST send a connection preface (Section 3.5). + Likewise, the server MUST send a connection preface (Section 3.5). Without additional information, prior support for HTTP/2 is not a strong signal that a given server will support HTTP/2 for future connections. For example, it is possible for server configurations to change, for configurations to differ between instances in clustered servers, or for network conditions to change. 3.5. HTTP/2 Connection Preface In HTTP/2, each endpoint is required to send a connection preface as @@ -563,27 +572,25 @@ 4. HTTP Frames Once the HTTP/2 connection is established, endpoints can begin exchanging frames. 4.1. Frame Format All frames begin with a fixed 9-octet header followed by a variable- length payload. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-----------------------------------------------+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | - +-+-+-----------+---------------+-------------------------------+ + +-+-------------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+ Figure 1: Frame Layout The fields of the frame header are defined as: Length: The length of the frame payload expressed as an unsigned @@ -595,29 +602,30 @@ Type: The 8-bit type of the frame. The frame type determines the format and semantics of the frame. Implementations MUST ignore and discard any frame that has a type that is unknown. Flags: An 8-bit field reserved for frame-type specific boolean flags. Flags are assigned semantics specific to the indicated frame type. Flags that have no defined semantics for a particular frame type - MUST be ignored, and MUST be left unset (0) when sending. + MUST be ignored, and MUST be left unset (0x0) when sending. R: A reserved 1-bit field. The semantics of this bit are undefined - and the bit MUST remain unset (0) when sending and MUST be ignored - when receiving. + and the bit MUST remain unset (0x0) when sending and MUST be + ignored when receiving. - Stream Identifier: A 31-bit stream identifier (see Section 5.1.1). - The value 0 is reserved for frames that are associated with the - connection as a whole as opposed to an individual stream. + Stream Identifier: A stream identifier (see Section 5.1.1) expressed + as an unsigned 31-bit integer. The value 0x0 is reserved for + frames that are associated with the connection as a whole as + opposed to an individual stream. The structure and content of the frame payload is dependent entirely on the frame type. 4.2. Frame Size The size of a frame payload is limited by the maximum size that a receiver advertises in the SETTINGS_MAX_FRAME_SIZE setting. This setting can have any value between 2^14 (16,384) and 2^24-1 (16,777,215) octets, inclusive. @@ -671,37 +679,40 @@ A complete header block consists of either: o a single HEADERS or PUSH_PROMISE frame, with the END_HEADERS flag set, or o a HEADERS or PUSH_PROMISE frame with the END_HEADERS flag cleared and one or more CONTINUATION frames, where the last CONTINUATION frame has the END_HEADERS flag set. Header compression is stateful. One compression context and one - decompression context is used for the entire connection. Each header - block is processed as a discrete unit. Header blocks MUST be - transmitted as a contiguous sequence of frames, with no interleaved - frames of any other type or from any other stream. The last frame in - a sequence of HEADERS or CONTINUATION frames MUST have the + decompression context is used for the entire connection. A decoding + error in a header block MUST be treated as a connection error + (Section 5.4.1) of type COMPRESSION_ERROR. + + Each header block is processed as a discrete unit. Header blocks + MUST be transmitted as a contiguous sequence of frames, with no + interleaved frames of any other type or from any other stream. The + last frame in a sequence of HEADERS or CONTINUATION frames has the END_HEADERS flag set. The last frame in a sequence of PUSH_PROMISE - or CONTINUATION frames MUST have the END_HEADERS flag set. This - allows a header block to be logically equivalent to a single frame. + or CONTINUATION frames has the END_HEADERS flag set. This allows a + header block to be logically equivalent to a single frame. Header block fragments can only be sent as the payload of HEADERS, PUSH_PROMISE or CONTINUATION frames, because these frames carry data that can modify the compression context maintained by a receiver. An - endpoint receiving HEADERS, PUSH_PROMISE or CONTINUATION frames MUST - reassemble header blocks and perform decompression even if the frames - are to be discarded. A receiver MUST terminate the connection with a - connection error (Section 5.4.1) of type COMPRESSION_ERROR if it does - not decompress a header block. + endpoint receiving HEADERS, PUSH_PROMISE or CONTINUATION frames needs + to reassemble header blocks and perform decompression even if the + frames are to be discarded. A receiver MUST terminate the connection + with a connection error (Section 5.4.1) of type COMPRESSION_ERROR if + it does not decompress a header block. 5. Streams and Multiplexing A "stream" is an independent, bi-directional sequence of frames exchanged between the client and server within an HTTP/2 connection. Streams have several important characteristics: o A single HTTP/2 connection can contain multiple concurrently open streams, with either endpoint interleaving frames from multiple streams. @@ -723,91 +734,94 @@ The lifecycle of a stream is shown in Figure 2. +--------+ send PP | | recv PP ,--------| idle |--------. / | | \ v +--------+ v +----------+ | +----------+ | | | send H/ | | - ,-----| reserved | | recv H | reserved |-----. + ,------| reserved | | recv H | reserved |------. | | (local) | | | (remote) | | | +----------+ v +----------+ | | | +--------+ | | | | recv ES | | send ES | | | send H | ,-------| open |-------. | recv H | | | / | | \ | | | v v +--------+ v v | | +----------+ | +----------+ | | | half | | | half | | | | closed | | send R/ | closed | | | | (remote) | | recv R | (local) | | | +----------+ | +----------+ | | | | | | | | send ES/ | recv ES/ | | | | send R/ v send R/ | | | | recv R +--------+ recv R | | | send R/ `----------->| |<-----------' send R/ | | recv R | closed | recv R | - `---------------------->| |<----------------------' + `----------------------->| |<----------------------' +--------+ send: endpoint sends this frame recv: endpoint receives this frame H: HEADERS frame (with implied CONTINUATIONs) PP: PUSH_PROMISE frame (with implied CONTINUATIONs) ES: END_STREAM flag R: RST_STREAM frame Figure 2: Stream States Note that this diagram shows stream state transitions and the frames and flags that affect those transitions only. In this regard, CONTINUATION frames do not result in state transitions; they are effectively part of the HEADERS or PUSH_PROMISE that they follow. - For this purpose, the END_STREAM flag is processed as a separate - event to the frame that bears it; a HEADERS frame with the END_STREAM - flag set can cause two state transitions. + For the purpose of state transitions, the END_STREAM flag is + processed as a separate event to the frame that bears it; a HEADERS + frame with the END_STREAM flag set can cause two state transitions. Both endpoints have a subjective view of the state of a stream that could be different when frames are in transit. Endpoints do not coordinate the creation of streams; they are created unilaterally by either endpoint. The negative consequences of a mismatch in states are limited to the "closed" state after sending RST_STREAM, where frames might be received for some time after closing. Streams have the following states: idle: - All streams start in the "idle" state. In this state, no frames - have been exchanged. + All streams start in the "idle" state. The following transitions are valid from this state: * Sending or receiving a HEADERS frame causes the stream to become "open". The stream identifier is selected as described in Section 5.1.1. The same HEADERS frame can also cause a stream to immediately become "half closed". - * Sending a PUSH_PROMISE frame reserves an idle stream for later - use. The stream state for the reserved stream transitions to - "reserved (local)". + * Sending a PUSH_PROMISE frame on another stream reserves the + idle stream that is identified for later use. The stream state + for the reserved stream transitions to "reserved (local)". - * Receiving a PUSH_PROMISE frame reserves an idle stream for - later use. The stream state for the reserved stream - transitions to "reserved (remote)". + * Receiving a PUSH_PROMISE frame on another stream reserves an + idle stream that is identified for later use. The stream state + for the reserved stream transitions to "reserved (remote)". - Receiving any frames other than HEADERS, PUSH_PROMISE or PRIORITY - on a stream in this state MUST be treated as a connection error - (Section 5.4.1) of type PROTOCOL_ERROR. + * Note that the PUSH_PROMISE frame is not sent on the idle + stream, but references the newly reserved stream in the + Promised Stream ID field. + + Receiving any frame other than HEADERS or PRIORITY on a stream in + this state MUST be treated as a connection error (Section 5.4.1) + of type PROTOCOL_ERROR. reserved (local): A stream in the "reserved (local)" state is one that has been promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame reserves an idle stream by associating the stream with an open stream that was initiated by the remote peer (see Section 8.2). In this state, only the following transitions are possible: * The endpoint can send a HEADERS frame. This causes the stream @@ -855,39 +869,41 @@ one of the "half closed" states: an endpoint sending an END_STREAM flag causes the stream state to become "half closed (local)"; an endpoint receiving an END_STREAM flag causes the stream state to become "half closed (remote)". Either endpoint can send a RST_STREAM frame from this state, causing it to transition immediately to "closed". half closed (local): A stream that is in the "half closed (local)" state cannot be used - for sending frames. Only WINDOW_UPDATE, PRIORITY and RST_STREAM - frames can be sent in this state. + for sending frames other than WINDOW_UPDATE, PRIORITY and + RST_STREAM. A stream transitions from this state to "closed" when a frame that contains an END_STREAM flag is received, or when either peer sends a RST_STREAM frame. - A receiver can ignore WINDOW_UPDATE frames in this state, which + An endpoint can receive any type of frame in this state. + Providing flow control credit using WINDOW_UPDATE frames is + necessary to continue receiving flow controlled frames. A + receiver can ignore WINDOW_UPDATE frames in this state, which might arrive for a short period after a frame bearing the END_STREAM flag is sent. PRIORITY frames received in this state are used to reprioritize - streams that depend on the current stream. + streams that depend on the identified stream. half closed (remote): A stream that is "half closed (remote)" is no longer being used by the peer to send frames. In this state, an endpoint is no longer - obligated to maintain a receiver flow control window if it - performs flow control. + obligated to maintain a receiver flow control window. If an endpoint receives additional frames for a stream that is in this state, other than WINDOW_UPDATE, PRIORITY or RST_STREAM, it MUST respond with a stream error (Section 5.4.2) of type STREAM_CLOSED. A stream that is "half closed (remote)" can be used by the endpoint to send frames of any type. In this state, the endpoint continues to observe advertised stream level flow control limits (Section 5.2). @@ -939,22 +955,22 @@ An endpoint might receive a PUSH_PROMISE frame after it sends RST_STREAM. PUSH_PROMISE causes a stream to become "reserved" even if the associated stream has been reset. Therefore, a RST_STREAM is needed to close an unwanted promised stream. In the absence of more specific guidance elsewhere in this document, implementations SHOULD treat the receipt of a frame that is not expressly permitted in the description of a state as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can - be sent and received in any stream state. Frame of unknown types are - ignored. + be sent and received in any stream state. Frames of unknown types + are ignored. An example of the state transitions for an HTTP request/response exchange can be found in Section 8.1. An example of the state transitions for server push can be found in Section 8.2.1 and Section 8.2.2. 5.1.1. Stream Identifiers Streams are identified with an unsigned 31-bit integer. Streams initiated by a client MUST use odd-numbered stream identifiers; those @@ -1004,22 +1020,25 @@ Streams that are in the "open" state, or either of the "half closed" states count toward the maximum number of streams that an endpoint is permitted to open. Streams in any of these three states count toward the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the "reserved" states do not count toward the stream limit. Endpoints MUST NOT exceed the limit set by their peer. An endpoint that receives a HEADERS frame that causes their advertised concurrent stream limit to be exceeded MUST treat this as a stream error - (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. An - endpoint that wishes to reduce the value of + (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. The choice + of error code determines whether the endpoint wishes to enable + automatic retry, see Section 8.1.4) for details. + + An endpoint that wishes to reduce the value of SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current number of open streams can either close streams that exceed the new value or allow streams to complete. 5.2. Flow Control Using streams for multiplexing introduces contention over use of the TCP connection, resulting in blocked streams. A flow control scheme ensures that streams on the same connection do not destructively interfere with each other. Flow control is used for both individual @@ -1027,22 +1046,23 @@ HTTP/2 provides for flow control through use of the WINDOW_UPDATE frame (Section 6.9). 5.2.1. Flow Control Principles HTTP/2 stream flow control aims to allow a variety of flow control algorithms to be used without requiring protocol changes. Flow control in HTTP/2 has the following characteristics: - 1. Flow control is specific to a connection; i.e., it is "hop-by- - hop", not "end-to-end". + 1. Flow control is specific to a connection. Both types of flow + control are between the endpoints of a single hop, and not over + the entire end-to-end path. 2. Flow control is based on window update frames. Receivers advertise how many octets they are prepared to receive on a stream and for the entire connection. This is a credit-based scheme. 3. Flow control is directional with overall control provided by the receiver. A receiver MAY choose to set any window size that it desires for each stream and for the entire connection. A sender MUST respect flow control limits imposed by a receiver. Clients, @@ -1078,24 +1098,25 @@ 5.2.2. Appropriate Use of Flow Control Flow control is defined to protect endpoints that are operating under resource constraints. For example, a proxy needs to share memory between many connections, and also might have a slow upstream connection and a fast downstream one. Flow control addresses cases where the receiver is unable to process data on one stream, yet wants to continue to process other streams in the same connection. Deployments that do not require this capability can advertise a flow - control window of the maximum size, incrementing the available space - when new data is received. This effectively disables flow control - for that receiver. Conversely, a sender is always subject to the - flow control window advertised by the receiver. + control window of the maximum size (2^31-1), and by maintaining this + window by sending a WINDOW_UPDATE frame when any data is received. + This effectively disables flow control for that receiver. + Conversely, a sender is always subject to the flow control window + advertised by the receiver. Deployments with constrained resources (for example, memory) can employ flow control to limit the amount of memory a peer can consume. Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the bandwidth-delay product (see [RFC7323]). Even with full awareness of the current bandwidth-delay product, implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a @@ -1120,22 +1141,22 @@ relative proportion of available resources that are assigned to streams dependent on the same stream. Explicitly setting the priority for a stream is input to a prioritization process. It does not guarantee any particular processing or transmission order for the stream relative to any other stream. An endpoint cannot force a peer to process concurrent streams in a particular order using priority. Expressing priority is therefore only ever a suggestion. - Providing prioritization information is optional, so default values - are used if no explicit indicator is provided (Section 5.3.5). + Prioritization information can be omitted from messages. Defaults + are used prior to any explicit values being provided (Section 5.3.5). 5.3.1. Stream Dependencies Each stream can be given an explicit dependency on another stream. Including a dependency expresses a preference to allocate resources to the identified stream rather than to the dependent stream. A stream that is not dependent on any other stream is given a stream dependency of 0x0. In other words, the non-existent stream 0 forms the root of the tree. @@ -1263,23 +1285,22 @@ different to what is intended. To avoid these problems, an endpoint SHOULD retain stream prioritization state for a period after streams become closed. The longer state is retained, the lower the chance that streams are assigned incorrect or default priority values. Similarly, streams that are in the "idle" state can be assigned priority or become a parent of other streams. This allows for the creation of a grouping node in the dependency tree, which enables - more flexible expressions of priority. Idle streams that are made a - parent of another stream are assigned a default priority - (Section 5.3.5). + more flexible expressions of priority. Idle streams begin with a + default priority (Section 5.3.5). The retention of priority information for streams that are not counted toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could create a large state burden for an endpoint. Therefore the amount of prioritization state that is retained MAY be limited. The amount of additional state an endpoint maintains for prioritization could be dependent on load; under high load, prioritization state can be discarded to limit resource commitments. In extreme cases, an endpoint could even discard prioritization state @@ -1288,24 +1309,24 @@ their setting for SETTINGS_MAX_CONCURRENT_STREAMS. Implementations SHOULD also attempt to retain state for streams that are in active use in the priority tree. An endpoint receiving a PRIORITY frame that changes the priority of a closed stream SHOULD alter the dependencies of the streams that depend on it, if it has retained enough state to do so. 5.3.5. Default Priorities - Providing priority information is optional. Streams are assigned a - non-exclusive dependency on stream 0x0 by default. Pushed streams - (Section 8.2) initially depend on their associated stream. In both - cases, streams are assigned a default weight of 16. + All streams are initially assigned a non-exclusive dependency on + stream 0x0. Pushed streams (Section 8.2) initially depend on their + associated stream. In both cases, streams are assigned a default + weight of 16. 5.4. Error Handling HTTP/2 framing permits two classes of error: o An error condition that renders the entire connection unusable is a connection error. o An error in an individual stream is a stream error. @@ -1356,31 +1377,35 @@ frames if it receives frames on a closed stream after more than a round-trip time. This behavior is permitted to deal with misbehaving implementations. An endpoint MUST NOT send a RST_STREAM in response to a RST_STREAM frame, to avoid looping. 5.4.3. Connection Termination If the TCP connection is closed or reset while streams remain in open - or half closed states, then the endpoint MUST assume that those - streams were abnormally interrupted and could be incomplete. + or half closed states, then the affected streams cannot be + automatically retried (see Section 8.1.4 for details). 5.5. Extending HTTP/2 HTTP/2 permits extension of the protocol. Protocol extensions can be used to provide additional services or alter any aspect of the protocol, within the limitations described in this section. Extensions are effective only within the scope of a single HTTP/2 connection. + This applies to the protocol elements defined in this document. This + does not affect the existing options for extending HTTP, such as + defining new methods, status codes, or header fields. + Extensions are permitted to use new frame types (Section 4.1), new settings (Section 6.5.2), or new error codes (Section 7). Registries are established for managing these extension points: frame types (Section 11.2), settings (Section 11.3) and error codes (Section 11.4). Implementations MUST ignore unknown or unsupported values in all extensible protocol elements. Implementations MUST discard frames that have unknown or unsupported types. This means that any of these extension points can be safely used by extensions without prior @@ -1419,39 +1444,38 @@ no longer be possible. Therefore, it is important that endpoints have a shared comprehension of how the state is affected by the use any given frame. 6.1. DATA DATA frames (type=0x0) convey arbitrary, variable-length sequences of octets associated with a stream. One or more DATA frames are used, for instance, to carry HTTP request or response payloads. - DATA frames MAY also contain arbitrary padding. Padding can be added - to DATA frames to obscure the size of messages. + DATA frames MAY also contain padding. Padding can be added to DATA + frames to obscure the size of messages. Padding is a security + feature; see Section 10.7. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +---------------+ |Pad Length? (8)| +---------------+-----------------------------------------------+ | Data (*) ... +---------------------------------------------------------------+ | Padding (*) ... +---------------------------------------------------------------+ Figure 6: DATA Frame Payload The DATA frame contains the following fields: Pad Length: An 8-bit field containing the length of the frame - padding in units of octets. This field is optional and is only + padding in units of octets. This field is conditional and is only present if the PADDED flag is set. Data: Application data. The amount of data is the remainder of the frame payload after subtracting the length of the other fields that are present. Padding: Padding octets that contain no application semantic value. Padding octets MUST be set to zero when sending. A receiver is not obligated to verify padding, but MAY treat non-zero padding as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. @@ -1480,31 +1504,27 @@ STREAM_CLOSED. The total number of padding octets is determined by the value of the Pad Length field. If the length of the padding is the length of the frame payload or greater, the recipient MUST treat this as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Note: A frame can be increased in size by one octet by including a Pad Length field with a value of zero. - Padding is a security feature; see Section 10.7. - 6.2. HEADERS The HEADERS frame (type=0x1) is used to open a stream (Section 5.1), and additionally carries a header block fragment. HEADERS frames can be sent on a stream in the "open" or "half closed (remote)" states. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +---------------+ |Pad Length? (8)| +-+-------------+-----------------------------------------------+ |E| Stream Dependency? (31) | +-+-------------+-----------------------------------------------+ | Weight? (8) | +-+-------------+-----------------------------------------------+ | Header Block Fragment (*) ... +---------------------------------------------------------------+ | Padding (*) ... +---------------------------------------------------------------+ @@ -1518,36 +1538,34 @@ PADDED flag is set. E: A single bit flag indicates that the stream dependency is exclusive, see Section 5.3. This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier for the stream that this stream depends on, see Section 5.3. This field is only present if the PRIORITY flag is set. - Weight: An 8-bit weight for the stream, see Section 5.3. Add one to - the value to obtain a weight between 1 and 256. This field is - only present if the PRIORITY flag is set. + Weight: An unsigned 8-bit integer representing a priority weight for + the stream, see Section 5.3. Add one to the value to obtain a + weight between 1 and 256. This field is only present if the + PRIORITY flag is set. Header Block Fragment: A header block fragment (Section 4.3). - Padding: Padding octets that contain no application semantic value. - Padding octets MUST be set to zero when sending and ignored when - receiving. + Padding: Padding octets. The HEADERS frame defines the following flags: END_STREAM (0x1): Bit 0 being set indicates that the header block (Section 4.3) is the last that the endpoint will send for the - identified stream. Setting this flag causes the stream to enter - one of "half closed" states (Section 5.1). + identified stream. A HEADERS frame carries the END_STREAM flag that signals the end of a stream. However, a HEADERS frame with the END_STREAM flag set can be followed by CONTINUATION frames on the same stream. Logically, the CONTINUATION frames are part of the HEADERS frame. END_HEADERS (0x4): Bit 2 being set indicates that this frame contains an entire header block (Section 4.3) and is not followed by any CONTINUATION frames. @@ -1569,89 +1587,86 @@ frame is continued in a CONTINUATION frame (Section 6.10). HEADERS frames MUST be associated with a stream. If a HEADERS frame is received whose stream identifier field is 0x0, the recipient MUST respond with a connection error (Section 5.4.1) of type PROTOCOL_ERROR. The HEADERS frame changes the connection state as described in Section 4.3. - The HEADERS frame includes optional padding. Padding fields and - flags are identical to those defined for DATA frames (Section 6.1). + The HEADERS frame can include padding. Padding fields and flags are + identical to those defined for DATA frames (Section 6.1). Prioritization information in a HEADERS frame is logically equivalent to a separate PRIORITY frame, but inclusion in HEADERS avoids the potential for churn in stream prioritization when new streams are - created. Priorization fields in HEADERS frames subsequent to the + created. Prioritization fields in HEADERS frames subsequent to the first on a stream reprioritize the stream (Section 5.3.3). 6.3. PRIORITY The PRIORITY frame (type=0x2) specifies the sender-advised priority of a stream (Section 5.3). It can be sent at any time for any stream, including idle or closed streams. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-------------------------------------------------------------+ |E| Stream Dependency (31) | +-+-------------+-----------------------------------------------+ | Weight (8) | +-+-------------+ Figure 8: PRIORITY Frame Payload The payload of a PRIORITY frame contains the following fields: E: A single bit flag indicates that the stream dependency is exclusive, see Section 5.3. Stream Dependency: A 31-bit stream identifier for the stream that this stream depends on, see Section 5.3. - Weight: An 8-bit weight for the identified stream dependency, see - Section 5.3. Add one to the value to obtain a weight between 1 - and 256. + Weight: An unsigned 8-bit integer representing a priority weight for + the stream, see Section 5.3. Add one to the value to obtain a + weight between 1 and 256. The PRIORITY frame does not define any flags. - The PRIORITY frame is associated with an existing stream. If a - PRIORITY frame is received with a stream identifier of 0x0, the - recipient MUST respond with a connection error (Section 5.4.1) of - type PROTOCOL_ERROR. + The PRIORITY frame always identifies a stream. If a PRIORITY frame + is received with a stream identifier of 0x0, the recipient MUST + respond with a connection error (Section 5.4.1) of type + PROTOCOL_ERROR. The PRIORITY frame can be sent on a stream in any state, though it cannot be sent between consecutive frames that comprise a single header block (Section 4.3). Note that this frame could arrive after processing or frame sending has completed, which would cause it to - have no effect on the current stream. For a stream that is in the + have no effect on the identified stream. For a stream that is in the "half closed (remote)" or "closed" - state, this frame can only - affect processing of the current stream and not frame transmission. + affect processing of the identified stream and its dependent streams + and not frame transmission on that stream. The PRIORITY frame can be sent for a stream in the "idle" or "closed" states. This allows for the reprioritization of a group of dependent streams by altering the priority of an unused or closed parent stream. A PRIORITY frame with a length other than 5 octets MUST be treated as a stream error (Section 5.4.2) of type FRAME_SIZE_ERROR. 6.4. RST_STREAM The RST_STREAM frame (type=0x3) allows for immediate termination of a stream. RST_STREAM is sent to request cancellation of a stream, or to indicate that an error condition has occurred. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +---------------------------------------------------------------+ | Error Code (32) | +---------------------------------------------------------------+ Figure 9: RST_STREAM Frame Payload The RST_STREAM frame contains a single unsigned, 32-bit integer identifying the error code (Section 7). The error code indicates why the stream is being terminated. The RST_STREAM frame does not define any flags. @@ -1727,40 +1742,39 @@ A SETTINGS frame with a length other than a multiple of 6 octets MUST be treated as a connection error (Section 5.4.1) of type FRAME_SIZE_ERROR. 6.5.1. SETTINGS Format The payload of a SETTINGS frame consists of zero or more parameters, each consisting of an unsigned 16-bit setting identifier and an unsigned 32-bit value. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-------------------------------+ | Identifier (16) | +-------------------------------+-------------------------------+ | Value (32) | +---------------------------------------------------------------+ Figure 10: Setting Format 6.5.2. Defined SETTINGS Parameters The following parameters are defined: SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the remote endpoint of the maximum size of the header compression table used to decode header blocks, in octets. The encoder can select any size equal to or less than this value by using signaling specific to the header compression format inside a - header block. The initial value is 4,096 octets. + header block, see [COMPRESSION]. The initial value is 4,096 + octets. SETTINGS_ENABLE_PUSH (0x2): This setting can be use to disable server push (Section 8.2). An endpoint MUST NOT send a PUSH_PROMISE frame if it receives this parameter set to a value of 0. An endpoint that has both set this parameter to 0 and had it acknowledged MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. The initial value is 1, which indicates that server push is permitted. Any value other than 0 or 1 MUST be treated as a @@ -1777,22 +1791,22 @@ treated as special by endpoints. A zero value does prevent the creation of new streams, however this can also happen for any limit that is exhausted with active streams. Servers SHOULD only set a zero value for short durations; if a server does not wish to accept requests, closing the connection is more appropriate. SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial window size (in octets) for stream level flow control. The initial value is 2^16-1 (65,535) octets. - This setting affects the window size of all streams, including - existing streams, see Section 6.9.2. + This setting affects the window size of all streams, see + Section 6.9.2. Values above the maximum flow control window size of 2^31-1 MUST be treated as a connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR. SETTINGS_MAX_FRAME_SIZE (0x5): Indicates the size of the largest frame payload that the sender is willing to receive, in octets. The initial value is 2^14 (16,384) octets. The value advertised by an endpoint MUST be between this initial value and the maximum @@ -1835,23 +1849,21 @@ 6.6. PUSH_PROMISE The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint in advance of streams the sender intends to initiate. The PUSH_PROMISE frame includes the unsigned 31-bit identifier of the stream the endpoint plans to create along with a set of headers that provide additional context for the stream. Section 8.2 contains a thorough description of the use of PUSH_PROMISE frames. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +---------------+ |Pad Length? (8)| +-+-------------+-----------------------------------------------+ |R| Promised Stream ID (31) | +-+-----------------------------+-------------------------------+ | Header Block Fragment (*) ... +---------------------------------------------------------------+ | Padding (*) ... +---------------------------------------------------------------+ Figure 11: PUSH_PROMISE Payload Format @@ -1882,25 +1894,26 @@ A PUSH_PROMISE frame without the END_HEADERS flag set MUST be followed by a CONTINUATION frame for the same stream. A receiver MUST treat the receipt of any other type of frame or a frame on a different stream as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. PADDED (0x8): Bit 3 being set indicates that the Pad Length field and any padding that it describes is present. - PUSH_PROMISE frames MUST be associated with an existing, peer- - initiated stream. The stream identifier of a PUSH_PROMISE frame - indicates the stream it is associated with. If the stream identifier - field specifies the value 0x0, a recipient MUST respond with a - connection error (Section 5.4.1) of type PROTOCOL_ERROR. + PUSH_PROMISE frames MUST be associated with a peer-initiated stream + that is in either the "open" or "half closed (remote)" state. The + stream identifier of a PUSH_PROMISE frame indicates the stream it is + associated with. If the stream identifier field specifies the value + 0x0, a recipient MUST respond with a connection error (Section 5.4.1) + of type PROTOCOL_ERROR. Promised streams are not required to be used in the order they are promised. The PUSH_PROMISE only reserves stream identifiers for later use. PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of the peer endpoint is set to 0. An endpoint that has set this setting and has received acknowledgement MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. @@ -1926,33 +1939,31 @@ (Section 5.4.1) of type PROTOCOL_ERROR. However, an endpoint that has sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE frames that might have been created before the RST_STREAM frame is received and processed. A receiver MUST treat the receipt of a PUSH_PROMISE that promises an illegal stream identifier (Section 5.1.1) (that is, an identifier for a stream that is not currently in the "idle" state) as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. - The PUSH_PROMISE frame includes optional padding. Padding fields and - flags are identical to those defined for DATA frames (Section 6.1). + The PUSH_PROMISE frame can include padding. Padding fields and flags + are identical to those defined for DATA frames (Section 6.1). 6.7. PING The PING frame (type=0x6) is a mechanism for measuring a minimal round trip time from the sender, as well as determining whether an idle connection is still functional. PING frames can be sent from any endpoint. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +---------------------------------------------------------------+ | | | Opaque Data (64) | | | +---------------------------------------------------------------+ Figure 12: PING Payload Format In addition to the frame header, PING frames MUST contain 8 octets of data in the payload. A sender can include any value it chooses and use those octets in any fashion. @@ -1983,51 +1994,49 @@ streams on this connection. GOAWAY can be sent by either the client or the server. Once sent, the sender will ignore frames sent on any new streams with identifiers higher than the included last stream identifier. Receivers of a GOAWAY frame MUST NOT open additional streams on the connection, although a new connection can be established for new streams. The purpose of this frame is to allow an endpoint to gracefully stop accepting new streams, while still finishing processing of previously established streams. This enables administrative actions, like - server maintainance. + server maintenance. There is an inherent race condition between an endpoint starting new streams and the remote sending a GOAWAY frame. To deal with this case, the GOAWAY contains the stream identifier of the last peer- initiated stream which was or might be processed on the sending endpoint in this connection. For instance, if the server sends a GOAWAY frame, the identified stream is the highest numbered stream initiated by the client. If the receiver of the GOAWAY has sent data on streams with a higher stream identifier than what is indicated in the GOAWAY frame, those streams are not or will not be processed. The receiver of the GOAWAY frame can treat the streams as though they had never been created at all, thereby allowing those streams to be retried later on a new connection. Endpoints SHOULD always send a GOAWAY frame before closing a - connection so that the remote can know whether a stream has been + connection so that the remote peer can know whether a stream has been partially processed or not. For example, if an HTTP client sends a POST at the same time that a server closes a connection, the client cannot know if the server started to process that POST request if the server does not send a GOAWAY frame to indicate what streams it might have acted on. An endpoint might choose to close a connection without sending GOAWAY for misbehaving peers. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-------------------------------------------------------------+ |R| Last-Stream-ID (31) | +-+-------------------------------------------------------------+ | Error Code (32) | +---------------------------------------------------------------+ | Additional Debug Data (*) | +---------------------------------------------------------------+ Figure 13: GOAWAY Payload Format The GOAWAY frame does not define any flags. @@ -2059,21 +2068,21 @@ be safely retried using a new connection. Activity on streams numbered lower or equal to the last stream identifier might still complete successfully. The sender of a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY frame, maintaining the connection in an open state until all in- progress streams complete. An endpoint MAY send multiple GOAWAY frames if circumstances change. For instance, an endpoint that sends GOAWAY with NO_ERROR during - graceful shutdown could subsequently encounter an condition that + graceful shutdown could subsequently encounter a condition that requires immediate termination of the connection. The last stream identifier from the last GOAWAY frame received indicates which streams could have been acted upon. Endpoints MUST NOT increase the value they send in the last stream identifier, since the peers might already have retried unprocessed requests on another connection. A client that is unable to retry requests loses all requests that are in flight when the server closes the connection. This is especially true for intermediaries that might not be serving clients using HTTP/2. A server that is attempting to gracefully shut down a @@ -2121,23 +2130,21 @@ Flow control only applies to frames that are identified as being subject to flow control. Of the frame types defined in this document, this includes only DATA frames. Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to handling the frame. A receiver MAY respond with a stream error (Section 5.4.2) or connection error (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable to accept a frame. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-------------------------------------------------------------+ |R| Window Size Increment (31) | +-+-------------------------------------------------------------+ Figure 14: WINDOW_UPDATE Payload Format The payload of a WINDOW_UPDATE frame is one reserved bit, plus an unsigned 31-bit integer indicating the number of octets that the sender can transmit in addition to the existing flow control window. The legal range for the increment to the flow control window is 1 to 2^31-1 (2,147,483,647) octets. @@ -2223,24 +2230,24 @@ forms part of the connection preface. The connection flow control window can only be changed using WINDOW_UPDATE frames. Prior to receiving a SETTINGS frame that sets a value for SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default initial window size when sending flow controlled frames. Similarly, the connection flow control window is set to the default initial window size until a WINDOW_UPDATE frame is received. A SETTINGS frame can alter the initial flow control window size for - all current streams. When the value of SETTINGS_INITIAL_WINDOW_SIZE - changes, a receiver MUST adjust the size of all stream flow control - windows that it maintains by the difference between the new value and - the old value. + all streams in the "open" or "half closed (remote)" state. When the + value of SETTINGS_INITIAL_WINDOW_SIZE changes, a receiver MUST adjust + the size of all stream flow control windows that it maintains by the + difference between the new value and the old value. A change to SETTINGS_INITIAL_WINDOW_SIZE can cause the available space in a flow control window to become negative. A sender MUST track the negative flow control window, and MUST NOT send new flow controlled frames until it receives WINDOW_UPDATE frames that cause the flow control window to become positive. For example, if the client sends 60KB immediately on connection establishment, and the server sets the initial window size to be 16KB, the client will recalculate the available flow control window @@ -2256,41 +2263,37 @@ 6.9.3. Reducing the Stream Window Size A receiver that wishes to use a smaller flow control window than the current size can send a new SETTINGS frame. However, the receiver MUST be prepared to receive data that exceeds this window size, since the sender might send data that exceeds the lower limit prior to processing the SETTINGS frame. After sending a SETTINGS frame that reduces the initial flow control - window size, a receiver has two options for handling streams that - exceed flow control limits: - - 1. The receiver can immediately send RST_STREAM with + window size, a receiver MAY continue to process streams that exceed + flow control limits. Allowing streams to continue does not allow the + receiver to immediately reduce the space it reserves for flow control + windows. Progress on these streams can also stall, since + WINDOW_UPDATE frames are needed to allow the sender to resume + sending. The receiver MAY instead send a RST_STREAM with FLOW_CONTROL_ERROR error code for the affected streams. - 2. The receiver can accept the streams and tolerate the resulting - head of line blocking, sending WINDOW_UPDATE frames as it - consumes data. - 6.10. CONTINUATION The CONTINUATION frame (type=0x9) is used to continue a sequence of header block fragments (Section 4.3). Any number of CONTINUATION - frames can be sent on an existing stream, as long as the preceding - frame is on the same stream and is a HEADERS, PUSH_PROMISE or - CONTINUATION frame without the END_HEADERS flag set. + frames can be sent, as long as the preceding frame is on the same + stream and is a HEADERS, PUSH_PROMISE or CONTINUATION frame without + the END_HEADERS flag set. - 0 1 2 3 - 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +---------------------------------------------------------------+ | Header Block Fragment (*) ... +---------------------------------------------------------------+ Figure 15: CONTINUATION Frame Payload The CONTINUATION frame payload contains a header block fragment (Section 4.3). The CONTINUATION frame defines the following flag: @@ -2401,21 +2404,21 @@ An HTTP message (request or response) consists of: 1. for a response only, zero or more HEADERS frames (each followed by zero or more CONTINUATION frames) containing the message headers of informational (1xx) HTTP responses (see [RFC7230], Section 3.2 and [RFC7231], Section 6.2), and 2. one HEADERS frame (followed by zero or more CONTINUATION frames) containing the message headers (see [RFC7230], Section 3.2), and - 3. zero or more DATA frames containing the message payload (see + 3. zero or more DATA frames containing the payload body (see [RFC7230], Section 3.3), and 4. optionally, one HEADERS frame, followed by zero or more CONTINUATION frames containing the trailer-part, if present (see [RFC7230], Section 4.1.2). The last frame in the sequence bears an END_STREAM flag, noting that a HEADERS frame bearing the END_STREAM flag can be followed by CONTINUATION frames that carry any remaining portions of the header block. @@ -2547,21 +2550,21 @@ o The ":authority" pseudo-header field includes the authority portion of the target URI ([RFC3986], Section 3.2). The authority MUST NOT include the deprecated "userinfo" subcomponent for "http" or "https" schemed URIs. To ensure that the HTTP/1.1 request line can be reproduced accurately, this pseudo-header field MUST be omitted when translating from an HTTP/1.1 request that has a request target in origin or asterisk form (see [RFC7230], Section 5.3). Clients - that generate HTTP/2 requests directly SHOULD use the _:authority_ + that generate HTTP/2 requests directly SHOULD use the ":authority" pseudo-header field instead of the "Host" header field. An intermediary that converts an HTTP/2 request to HTTP/1.1 MUST create a "Host" header field if one is not present in a request by copying the value of the ":authority" pseudo-header field. o The ":path" pseudo-header field includes the path and query parts of the target URI (the "path-absolute" production from [RFC3986] and optionally a '?' character followed by the "query" production, see [RFC3986], Section 3.3 and [RFC3986], Section 3.4). A request in asterisk form includes the value '*' for the ":path" pseudo- @@ -2619,21 +2622,21 @@ cookie: e=f 8.1.2.6. Malformed Requests and Responses A malformed request or response is one that is an otherwise valid sequence of HTTP/2 frames, but is otherwise invalid due to the presence of extraneous frames, prohibited header fields, the absence of mandatory header fields, or the inclusion of uppercase header field names. - A request or response that includes an entity body can include a + A request or response that includes an payload body can include a "content-length" header field. A request or response is also malformed if the value of a "content-length" header field does not equal the sum of the DATA frame payload lengths that form the body. A response that is defined to have no payload, as described in [RFC7230], Section 3.3.2, can have a non-zero "content-length" header field, even though no content is included in DATA frames. Intermediaries that process HTTP requests or responses (i.e., any intermediary not acting as a tunnel) MUST NOT forward a malformed request or response. Malformed requests or responses that are @@ -2645,26 +2648,26 @@ response. Note that these requirements are intended to protect against several types of common attacks against HTTP; they are deliberately strict, because being permissive can expose implementations to these vulnerabilities. 8.1.3. Examples This section shows HTTP/1.1 requests and responses, with illustrations of equivalent HTTP/2 requests and responses. - An HTTP GET request includes request header fields and no body and is - therefore transmitted as a single HEADERS frame, followed by zero or - more CONTINUATION frames containing the serialized block of request - header fields. The HEADERS frame in the following has both the - END_HEADERS and END_STREAM flags set; no CONTINUATION frames are - sent: + An HTTP GET request includes request header fields and no payload + body and is therefore transmitted as a single HEADERS frame, followed + by zero or more CONTINUATION frames containing the serialized block + of request header fields. The HEADERS frame in the following has + both the END_HEADERS and END_STREAM flags set; no CONTINUATION frames + are sent: GET /resource HTTP/1.1 HEADERS Host: example.org ==> + END_STREAM Accept: image/jpeg + END_HEADERS :method = GET :scheme = https :path = /resource host = example.org accept = image/jpeg @@ -2799,41 +2802,49 @@ 8.2. Server Push HTTP/2 allows a server to pre-emptively send (or "push") responses (along with corresponding "promised" requests) to a client in association with a previous client-initiated request. This can be useful when the server knows the client will need to have those responses available in order to fully process the response to the original request. - Pushing additional message exchanges in this fashion is optional, and - is negotiated between individual endpoints. The SETTINGS_ENABLE_PUSH + A client can request that server push be disabled, though this is + negotiated for each hop independently. The SETTINGS_ENABLE_PUSH setting can be set to 0 to indicate that server push is disabled. Promised requests MUST be cacheable (see [RFC7231], Section 4.2.3), MUST be safe (see [RFC7231], Section 4.2.1) and MUST NOT include a request body. Clients that receive a promised request that is not - cacheable, unsafe or that includes a request body MUST reset the - stream with a stream error (Section 5.4.2) of type PROTOCOL_ERROR. + cacheable, is not known to be safe or that indicates the presence of + a request body MUST reset the promised stream with a stream error + (Section 5.4.2) of type PROTOCOL_ERROR. Note this could result in + the promised stream being reset if the client does not recognize a + newly defined method as being safe. Pushed responses that are cacheable (see [RFC7234], Section 3) can be stored by the client, if it implements an HTTP cache. Pushed responses are considered successfully validated on the origin server (e.g., if the "no-cache" cache response directive [RFC7234], Section 5.2.2 is present) while the stream identified by the promised stream ID is still open. Pushed responses that are not cacheable MUST NOT be stored by any HTTP cache. They MAY be made available to the application separately. + The server MUST include a value in the ":authority" header field for + which the server is authoritative (see Section 10.1). A client MUST + treat a PUSH_PROMISE for which the server is not authoritative as a + stream error (Section 5.4.2) of type PROTOCOL_ERROR. + An intermediary can receive pushes from the server and choose not to forward them on to the client. In other words, how to make use of the pushed information is up to that intermediary. Equally, the intermediary might choose to make additional pushes to the client, without any action taken by the server. A client cannot push. Thus, servers MUST treat the receipt of a PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PROTOCOL_ERROR. Clients MUST reject any attempt to change the SETTINGS_ENABLE_PUSH setting to a value other than 0 by treating the @@ -3025,30 +3036,34 @@ Servers are encouraged to maintain open connections for as long as possible, but are permitted to terminate idle connections if necessary. When either endpoint chooses to close the transport-layer TCP connection, the terminating endpoint SHOULD first send a GOAWAY (Section 6.8) frame so that both endpoints can reliably determine whether previously sent frames have been processed and gracefully complete or terminate any necessary remaining tasks. 9.1.1. Connection Reuse - Connections that are made to an origin servers, either directly or + Connections that are made to an origin server, either directly or through a tunnel created using the CONNECT method (Section 8.3) MAY be reused for requests with multiple different URI authority components. A connection can be reused as long as the origin server - is authoritative (Section 10.1). For "http" resources, this depends - on the host having resolved to the same IP address. + is authoritative (Section 10.1). For TCP connections without TLS, + this depends on the host having resolved to the same IP address. For "https" resources, connection reuse additionally depends on - having a certificate that is valid for the host in the URI. An - origin server might offer a certificate with multiple + having a certificate that is valid for the host in the URI. The + certificate presented by the server MUST satisfy any checks that the + client would perform when forming a new TLS connection for the host + in the URI. + + An origin server might offer a certificate with multiple "subjectAltName" attributes, or names with wildcards, one of which is valid for the authority in the URI. For example, a certificate with a "subjectAltName" of "*.example.com" might permit the use of the same connection for requests to URIs starting with "https://a.example.com/" and "https://b.example.com/". In some deployments, reusing a connection for multiple origins can result in requests being directed to the wrong origin server. For example, TLS termination might be performed by a middlebox that uses the TLS Server Name Indication (SNI) [TLS-EXT] extension to select an @@ -3142,48 +3157,47 @@ 2048 bits for cipher suites that use ephemeral finite field Diffie- Hellman (DHE) [TLS12] and 224 bits for cipher suites that use ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC4492]. Clients MUST accept DHE sizes of up to 4096 bits. Endpoints MAY treat negotiation of key sizes smaller than the lower limits as a connection error (Section 5.4.1) of type INADEQUATE_SECURITY. 9.2.2. TLS 1.2 Cipher Suites A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher - suites that are listed in Appendix A. + suites that are listed in the cipher suite black list (Appendix A). Endpoints MAY choose to generate a connection error (Section 5.4.1) - of type INADEQUATE_SECURITY if one of the prohibited cipher suites - are negotiated. A deployment that chooses to use a prohibited cipher - suite risks triggering a connection error unless the set of potential - peers is known to accept that cipher suite. + of type INADEQUATE_SECURITY if one of the cipher suites from the + black list are negotiated. A deployment that chooses to use a black- + listed cipher suite risks triggering a connection error unless the + set of potential peers is known to accept that cipher suite. Implementations MUST NOT generate this error in reaction to the - negotiation of a cipher suite that is not in the prohibited list. - Consequently, when clients offer a cipher suite that is not - prohibited, they have to be prepared to use that cipher suite with + negotiation of a cipher suite that is not on the black list. + Consequently, when clients offer a cipher suite that is not on the + black list, they have to be prepared to use that cipher suite with HTTP/2. - The effect of prohibiting these cipher suites is that TLS 1.2 - deployments could have non-intersecting sets of available cipher - suites, since the prohibited set includes the cipher suite that TLS - 1.2 makes mandatory. To avoid this problem, deployments of HTTP/2 - that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - [TLS-ECDHE] with the P256 elliptic curve [FIPS186]. + The black list includes the cipher suite that TLS 1.2 makes + mandatory, which means that TLS 1.2 deployments could have non- + intersecting sets of permitted cipher suites. To avoid this problem + causing TLS handshake failures, deployments of HTTP/2 that use TLS + 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 [TLS-ECDHE] + with the P256 elliptic curve [FIPS186]. Note that clients might advertise support of cipher suites that are - prohibited by the above restrictions in order to allow for connection - to servers that do not support HTTP/2 and support only prohibited - cipher suites. This allows servers to select HTTP/1.1 with a cipher - suite that is prohibited for HTTP/2. However, this can result in - HTTP/2 being negotiated with a prohibited cipher suite if the - application protocol and cipher suite are independently selected. + on the black list in order to allow for connection to servers that do + not support HTTP/2. This allows servers to select HTTP/1.1 with a + cipher suite that is on the HTTP/2 black list. However, this can + result in HTTP/2 being negotiated with a black-listed cipher suite if + the application protocol and cipher suite are independently selected. 10. Security Considerations 10.1. Server Authority HTTP/2 relies on the HTTP/1.1 definition of authority for determining whether a server is authoritative in providing a given response, see [RFC7230], Section 9.1. This relies on local name resolution for the "http" URI scheme, and the authenticated server identity for the "https" scheme (see [RFC2818], Section 3). @@ -3221,21 +3236,21 @@ are not valid field names in the Internet Message Syntax used by HTTP/1.1. Requests or responses containing invalid header field names MUST be treated as malformed (Section 8.1.2.6). An intermediary therefore cannot translate an HTTP/2 request or response containing an invalid field name into an HTTP/1.1 message. Similarly, HTTP/2 allows header field values that are not valid. While most of the values that can be encoded will not alter header field parsing, carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the zero character (NUL, ASCII 0x0) might be exploited by - an attacker if they are translater verbatim. Any request or response + an attacker if they are translated verbatim. Any request or response that contains a character not permitted in a header field value MUST be treated as malformed (Section 8.1.2.6). Valid characters are defined by the "field-content" ABNF rule in Section 3.2 of [RFC7230]. 10.4. Cacheability of Pushed Responses Pushed responses do not have an explicit request from the client; the request is provided by the server in the PUSH_PROMISE frame. Caching responses that are pushed is possible based on the guidance @@ -3245,21 +3260,21 @@ small portion of its URI space. Where multiple tenants share space on the same server, that server MUST ensure that tenants are not able to push representations of resources that they do not have authority over. Failure to enforce this would allow a tenant to provide a representation that would be served out of cache, overriding the actual representation that the authoritative tenant provides. Pushed responses for which an origin server is not authoritative (see - Section 10.1) are never cached or used. + Section 10.1) MUST NOT be used or cached. 10.5. Denial of Service Considerations An HTTP/2 connection can demand a greater commitment of resources to operate than a HTTP/1.1 connection. The use of header compression and flow control depend on a commitment of resources for storing a greater amount of state. Settings for these features ensure that memory commitments for these features are strictly bounded. The number of PUSH_PROMISE frames is not constrained in the same @@ -3301,62 +3316,74 @@ risk of denial of service attack. Implementations SHOULD track the use of these features and set limits on their use. An endpoint MAY treat activity that is suspicious as a connection error (Section 5.4.1) of type ENHANCE_YOUR_CALM. 10.5.1. Limits on Header Block Size A large header block (Section 4.3) can cause an implementation to commit a large amount of state. Header fields that are critical for routing can appear toward the end of a header block, which prevents - streaming of header fields to their ultimate destination. For this - an other reasons, such as ensuring cache correctness, means that an - endpoint might need to buffer the entire header block. Since there - is no hard limit to the size of a header block, some endpoints could - be forced commit a large amount of available memory for header - fields. + streaming of header fields to their ultimate destination. This + ordering and other reasons, such as ensuring cache correctness, means + that an endpoint might need to buffer the entire header block. Since + there is no hard limit to the size of a header block, some endpoints + could be forced to commit a large amount of available memory for + header fields. An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE to advise peers of limits that might apply on the size of header blocks. This setting is only advisory, so endpoints MAY choose to send header blocks that exceed this limit and risk having the request or response - being treated as malformed. This setting specific to a connection, - so any request or response could encounter a hop with a lower, - unknown limit. An intermediary can attempt to avoid this problem by - passing on values presented by different peers, but they are not - obligated to do so. + being treated as malformed. This setting is specific to a + connection, so any request or response could encounter a hop with a + lower, unknown limit. An intermediary can attempt to avoid this + problem by passing on values presented by different peers, but they + are not obligated to do so. A server that receives a larger header block than it is willing to handle can send an HTTP 431 (Request Header Fields Too Large) status code [RFC6585]. A client can discard responses that it cannot process. The header block MUST be processed to ensure a consistent connection state, unless the connection is closed. +10.5.2. CONNECT Issues + + The CONNECT method can be used to create disproportionate load on an + proxy, since stream creation is relatively inexpensive when compared + to the creation and maintenance of a TCP connection. A proxy might + also maintain some resources for a TCP connection beyond the closing + of the stream that carries the CONNECT request, since the outgoing + TCP connection remains in the TIME_WAIT state. A proxy therefore + cannot rely on SETTINGS_MAX_CONCURRENT_STREAMS alone to limit the + resources consumed by CONNECT requests. + 10.6. Use of Compression - HTTP/2 enables greater use of compression for both header fields - (Section 4.3) and entity bodies. Compression can allow an attacker - to recover secret data when it is compressed in the same context as - data under attacker control. + Compression can allow an attacker to recover secret data when it is + compressed in the same context as data under attacker control. + HTTP/2 enables compression of header fields (Section 4.3); the + following concerns also apply to the use of HTTP compressed content- + codings ([RFC7231], Section 3.1.2.1). There are demonstrable attacks on compression that exploit the characteristics of the web (e.g., [BREACH]). The attacker induces multiple requests containing varying plaintext, observing the length of the resulting ciphertext in each, which reveals a shorter length when a guess about the secret is correct. Implementations communicating on a secure channel MUST NOT compress content that includes both confidential and attacker-controlled data unless separate compression dictionaries are used for each source of data. Compression MUST NOT be used if the source of data cannot be reliably determined. Generic stream compression, such as that - provided by TLS MUST NOT be used with HTTP/2 (Section 9.2). + provided by TLS MUST NOT be used with HTTP/2 (see Section 9.2). Further considerations regarding the compression of header fields are described in [COMPRESSION]. 10.7. Use of Padding Padding within HTTP/2 is not intended as a replacement for general purpose padding, such as might be provided by TLS [TLS12]. Redundant padding could even be counterproductive. Correct application can depend on having specific knowledge of the data that is being padded. @@ -3383,22 +3410,22 @@ padding for HEADERS and PUSH_PROMISE frames. A valid reason for an intermediary to change the amount of padding of frames is to improve the protections that padding provides. 10.8. Privacy Considerations Several characteristics of HTTP/2 provide an observer an opportunity to correlate actions of a single client or server over time. This includes the value of settings, the manner in which flow control windows are managed, the way priorities are allocated to streams, - timing of reactions to stimulus, and handling of any optional - features. + timing of reactions to stimulus, and handling of any features that + are controlled by settings. As far as this creates observable differences in behavior, they could be used as a basis for fingerprinting a specific client, as defined in Section 1.8 of [HTML5]. HTTP/2's preference for using a single TCP connection allows correlation of a user's activity on a site. If connections are reused for different origins, this allows tracking across those origins. @@ -3589,23 +3616,23 @@ Related information: This header field is only used by an HTTP/2 client for Upgrade-based negotiation. 11.6. PRI Method Registration This section registers the "PRI" method in the HTTP Method Registry ([RFC7231], Section 8.1). Method Name: PRI - Safe No + Safe Yes - Idempotent No + Idempotent Yes Specification document(s) Section 3.5 of this document Related information: This method is never used by an actual client. This method will appear to be used when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2 connection preface. 11.7. The 421 (Misdirected Request) HTTP Status Code This document registers the 421 (Misdirected Request) HTTP Status @@ -3649,28 +3676,28 @@ o The Japanese HTTP/2 community provided an invaluable contribution, including a number of implementations, plus numerous technical and editorial contributions. 13. References 13.1. Normative References [COMPRESSION] Ruellan, H. and R. Peon, "HPACK - Header Compression for - HTTP/2", draft-ietf-httpbis-header-compression-10 (work in - progress), November 2014. + HTTP/2", draft-ietf-httpbis-header-compression-11 (work in + progress), February 2015. [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, April 2011. [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4, - July 2013. + July 2013, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. @@ -3709,43 +3736,43 @@ [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [TLS-ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, July 2014. [TLS-ECDHE] - Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- - 256/384 and AES Galois Counter Mode (GCM)", RFC 5289, + Rescorla, E., "TLS Elliptic Curve Cipher Suites with + SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, August 2008. [TLS-EXT] Eastlake, D., "Transport Layer Security (TLS) Extensions: Extension Definitions", RFC 6066, January 2011. [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008. 13.2. Informative References [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP - Alternative Services", draft-ietf-httpbis-alt-svc-04 (work - in progress), October 2014. + Alternative Services", draft-ietf-httpbis-alt-svc-06 (work + in progress), February 2015. [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004. [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the - CRIME Attack", July 2013, - . [HTML5] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C Recommendation REC-html5-20141028, October 2014, . Latest version available at [5]. [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol @@ -3761,42 +3788,44 @@ [RFC7323] Borman, D., Braden, B., Jacobson, V., and R. Scheffenegger, "TCP Extensions for High Performance", RFC 7323, September 2014. [TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. Jackson, "Talking to Yourself for Fun and Profit", 2011, . [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of TLS and DTLS", draft- - ietf-uta-tls-bcp-07 (work in progress), November 2014. + ietf-uta-tls-bcp-08 (work in progress), December 2014. 13.3. URIs [1] https://www.iana.org/assignments/message-headers [2] https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/ cfUef2gL3iU [3] https://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc- principles-01 -Appendix A. Prohibited TLS 1.2 Cipher Suites +Appendix A. TLS 1.2 Cipher Suite Black List - The following cipher suites are prohibited for use in HTTP/2 over TLS - 1.2: TLS_NULL_WITH_NULL_NULL, TLS_RSA_WITH_NULL_MD5, - TLS_RSA_WITH_NULL_SHA, TLS_RSA_EXPORT_WITH_RC4_40_MD5, - TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_RC4_128_SHA, - TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5, TLS_RSA_WITH_IDEA_CBC_SHA, - TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_RSA_WITH_DES_CBC_SHA, - TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA, - TLS_DH_DSS_WITH_DES_CBC_SHA, TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA, + An HTTP/2 implementation MAY treat the negotiation of any of the + following cipher suites with TLS 1.2 as a connection error + (Section 5.4.1) of type INADEQUATE_SECURITY: TLS_NULL_WITH_NULL_NULL, + TLS_RSA_WITH_NULL_MD5, TLS_RSA_WITH_NULL_SHA, + TLS_RSA_EXPORT_WITH_RC4_40_MD5, TLS_RSA_WITH_RC4_128_MD5, + TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5, + TLS_RSA_WITH_IDEA_CBC_SHA, TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, + TLS_RSA_WITH_DES_CBC_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA, + TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_DH_DSS_WITH_DES_CBC_SHA, + TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA, TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_DH_RSA_WITH_DES_CBC_SHA, TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_DHE_DSS_WITH_DES_CBC_SHA, TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA, TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_DHE_RSA_WITH_DES_CBC_SHA, TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DH_anon_EXPORT_WITH_RC4_40_MD5, TLS_DH_anon_WITH_RC4_128_MD5, TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA, TLS_DH_anon_WITH_DES_CBC_SHA, TLS_DH_anon_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_DES_CBC_SHA, TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA,