draft-ietf-httpbis-http2bis-06.txt   draft-ietf-httpbis-http2bis-latest.txt 
HTTPbis Working Group M. Thomson, Ed. HTTPbis Working Group M. Thomson, Ed.
Internet-Draft Mozilla Internet-Draft Mozilla
Obsoletes: 7540, 8740 (if approved) C. Benfield, Ed. Obsoletes: 7540, 8740 (if approved) C. Benfield, Ed.
Intended status: Standards Track Apple Inc. Intended status: Standards Track Apple Inc.
Expires: May 22, 2022 November 18, 2021 Expires: July 18, 2022 January 14, 2022
Hypertext Transfer Protocol Version 2 (HTTP/2) HTTP/2
draft-ietf-httpbis-http2bis-06 draft-ietf-httpbis-http2bis-latest
Abstract Abstract
This specification describes an optimized expression of the semantics This specification describes an optimized expression of the semantics
of the Hypertext Transfer Protocol (HTTP), referred to as HTTP of the Hypertext Transfer Protocol (HTTP), referred to as HTTP
version 2 (HTTP/2). HTTP/2 enables a more efficient use of network version 2 (HTTP/2). HTTP/2 enables a more efficient use of network
resources and a reduced latency by introducing field compression and resources and a reduced latency by introducing field compression and
allowing multiple concurrent exchanges on the same connection. allowing multiple concurrent exchanges on the same connection.
This document obsoletes RFC 7540 and RFC 8740. This document obsoletes RFC 7540 and RFC 8740.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 22, 2022. This Internet-Draft will expire on July 18, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. HTTP/2 Protocol Overview . . . . . . . . . . . . . . . . . . 5 2. HTTP/2 Protocol Overview . . . . . . . . . . . . . . . . . . 5
2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 2.1. Document Organization . . . . . . . . . . . . . . . . . . 6
2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6
3. Starting HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7 3. Starting HTTP/2 . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. HTTP/2 Version Identification . . . . . . . . . . . . . . 8 3.1. HTTP/2 Version Identification . . . . . . . . . . . . . . 8
3.2. Starting HTTP/2 for "https" URIs . . . . . . . . . . . . 8 3.2. Starting HTTP/2 for "https" URIs . . . . . . . . . . . . 8
3.3. Starting HTTP/2 with Prior Knowledge . . . . . . . . . . 9 3.3. Starting HTTP/2 with Prior Knowledge . . . . . . . . . . 8
3.4. HTTP/2 Connection Preface . . . . . . . . . . . . . . . . 9 3.4. HTTP/2 Connection Preface . . . . . . . . . . . . . . . . 9
4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 10
4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . 11
4.3. Field Section Compression and Decompression . . . . . . . 12 4.3. Field Section Compression and Decompression . . . . . . . 12
5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . 13 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . 13
5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 19 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 19
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 20 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 20
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 20
5.2.1. Flow-Control Principles . . . . . . . . . . . . . . . 20 5.2.1. Flow-Control Principles . . . . . . . . . . . . . . . 20
5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22
5.2.3. Flow Control Performance . . . . . . . . . . . . . . 22 5.2.3. Flow Control Performance . . . . . . . . . . . . . . 22
5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 23 5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. Background of Priority in HTTP/2 . . . . . . . . . . 23 5.3.1. Background on Priority in RFC 7540 . . . . . . . . . 23
5.3.2. Priority Signaling in this Document . . . . . . . . . 23 5.3.2. Priority Signaling in this Document . . . . . . . . . 23
5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 24 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 24
5.4.1. Connection Error Handling . . . . . . . . . . . . . . 25 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 25
5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 25 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 25
5.4.3. Connection Termination . . . . . . . . . . . . . . . 26 5.4.3. Connection Termination . . . . . . . . . . . . . . . 26
5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 26 5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 26
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 27 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 27
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 29 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 31 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 31
6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 32 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 32
6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 33 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 33
6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 34 6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 34
6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . 35 6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . 35
6.5.3. Settings Synchronization . . . . . . . . . . . . . . 36 6.5.3. Settings Synchronization . . . . . . . . . . . . . . 37
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 37 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 37
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 40 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 43 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 44
6.9.1. The Flow-Control Window . . . . . . . . . . . . . . . 45 6.9.1. The Flow-Control Window . . . . . . . . . . . . . . . 46
6.9.2. Initial Flow-Control Window Size . . . . . . . . . . 46 6.9.2. Initial Flow-Control Window Size . . . . . . . . . . 47
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 47 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 48
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 47 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 48
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 48 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49
8. Expressing HTTP Semantics in HTTP/2 . . . . . . . . . . . . . 50 8. Expressing HTTP Semantics in HTTP/2 . . . . . . . . . . . . . 50
8.1. HTTP Message Framing . . . . . . . . . . . . . . . . . . 50 8.1. HTTP Message Framing . . . . . . . . . . . . . . . . . . 50
8.1.1. Malformed Messages . . . . . . . . . . . . . . . . . 51 8.1.1. Malformed Messages . . . . . . . . . . . . . . . . . 52
8.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . . 52 8.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . . 53
8.2.1. Field Validity . . . . . . . . . . . . . . . . . . . 52 8.2.1. Field Validity . . . . . . . . . . . . . . . . . . . 53
8.2.2. Connection-Specific Header Fields . . . . . . . . . . 54 8.2.2. Connection-Specific Header Fields . . . . . . . . . . 54
8.2.3. Compressing the Cookie Header Field . . . . . . . . . 54 8.2.3. Compressing the Cookie Header Field . . . . . . . . . 55
8.3. HTTP Control Data . . . . . . . . . . . . . . . . . . . . 55 8.3. HTTP Control Data . . . . . . . . . . . . . . . . . . . . 55
8.3.1. Request Pseudo-Header Fields . . . . . . . . . . . . 55 8.3.1. Request Pseudo-Header Fields . . . . . . . . . . . . 56
8.3.2. Response Pseudo-Header Fields . . . . . . . . . . . . 57 8.3.2. Response Pseudo-Header Fields . . . . . . . . . . . . 58
8.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 57 8.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 58
8.4.1. Push Requests . . . . . . . . . . . . . . . . . . . . 59 8.4.1. Push Requests . . . . . . . . . . . . . . . . . . . . 59
8.4.2. Push Responses . . . . . . . . . . . . . . . . . . . 60 8.4.2. Push Responses . . . . . . . . . . . . . . . . . . . 61
8.5. The CONNECT Method . . . . . . . . . . . . . . . . . . . 61 8.5. The CONNECT Method . . . . . . . . . . . . . . . . . . . 62
8.6. The Upgrade Header Field . . . . . . . . . . . . . . . . 62 8.6. The Upgrade Header Field . . . . . . . . . . . . . . . . 63
8.7. Request Reliability . . . . . . . . . . . . . . . . . . . 62 8.7. Request Reliability . . . . . . . . . . . . . . . . . . . 63
8.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 63 8.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 64
8.8.1. Simple Request . . . . . . . . . . . . . . . . . . . 63 8.8.1. Simple Request . . . . . . . . . . . . . . . . . . . 64
8.8.2. Simple Response . . . . . . . . . . . . . . . . . . . 64 8.8.2. Simple Response . . . . . . . . . . . . . . . . . . . 64
8.8.3. Complex Request . . . . . . . . . . . . . . . . . . . 64 8.8.3. Complex Request . . . . . . . . . . . . . . . . . . . 65
8.8.4. Response with Body . . . . . . . . . . . . . . . . . 65 8.8.4. Response with Body . . . . . . . . . . . . . . . . . 65
8.8.5. Informational Responses . . . . . . . . . . . . . . . 65 8.8.5. Informational Responses . . . . . . . . . . . . . . . 66
9. HTTP/2 Connections . . . . . . . . . . . . . . . . . . . . . 66 9. HTTP/2 Connections . . . . . . . . . . . . . . . . . . . . . 67
9.1. Connection Management . . . . . . . . . . . . . . . . . . 66 9.1. Connection Management . . . . . . . . . . . . . . . . . . 67
9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 67 9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 67
9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 68 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 68
9.2.1. TLS 1.2 Features . . . . . . . . . . . . . . . . . . 68 9.2.1. TLS 1.2 Features . . . . . . . . . . . . . . . . . . 69
9.2.2. TLS 1.2 Cipher Suites . . . . . . . . . . . . . . . . 69 9.2.2. TLS 1.2 Cipher Suites . . . . . . . . . . . . . . . . 69
9.2.3. TLS 1.3 Features . . . . . . . . . . . . . . . . . . 70 9.2.3. TLS 1.3 Features . . . . . . . . . . . . . . . . . . 70
10. Security Considerations . . . . . . . . . . . . . . . . . . . 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 71
10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 70 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 71
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 71 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 71
10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 71 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 72
10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 72 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 72
10.5. Denial-of-Service Considerations . . . . . . . . . . . . 72 10.5. Denial-of-Service Considerations . . . . . . . . . . . . 73
10.5.1. Limits on Field Block Size . . . . . . . . . . . . . 74 10.5.1. Limits on Field Block Size . . . . . . . . . . . . . 74
10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 74 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 75
10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 74 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 75
10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 75 10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 76
10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 76 10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 76
10.9. Remote Timing Attacks . . . . . . . . . . . . . . . . . 76 10.9. Remote Timing Attacks . . . . . . . . . . . . . . . . . 77
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77
11.1. HTTP2-Settings Header Field Registration . . . . . . . . 77 11.1. HTTP2-Settings Header Field Registration . . . . . . . . 77
11.2. The h2c Upgrade Token . . . . . . . . . . . . . . . . . 77 11.2. The h2c Upgrade Token . . . . . . . . . . . . . . . . . 78
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 78
12.1. Normative References . . . . . . . . . . . . . . . . . . 77 12.1. Normative References . . . . . . . . . . . . . . . . . . 78
12.2. Informative References . . . . . . . . . . . . . . . . . 79 12.2. Informative References . . . . . . . . . . . . . . . . . 80
Appendix A. Prohibited TLS 1.2 Cipher Suites . . . . . . . . . . 81 Appendix A. Prohibited TLS 1.2 Cipher Suites . . . . . . . . . . 82
Appendix B. Changes from RFC 7540 . . . . . . . . . . . . . . . 87 Appendix B. Changes from RFC 7540 . . . . . . . . . . . . . . . 88
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 88 Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 88 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 89
1. Introduction 1. Introduction
The performance of applications using the Hypertext Transfer Protocol The performance of applications using the Hypertext Transfer Protocol
(HTTP, [HTTP]) is linked to how each version of HTTP uses the (HTTP, [HTTP]) is linked to how each version of HTTP uses the
underlying transport, and the conditions under which the transport underlying transport, and the conditions under which the transport
operates. operates.
Making multiple concurrent requests can reduce latency and improve Making multiple concurrent requests can reduce latency and improve
application performance. HTTP/1.0 allowed only one request to be application performance. HTTP/1.0 allowed only one request to be
skipping to change at page 5, line 16 skipping to change at page 5, line 16
TCP connections can be used in comparison to HTTP/1.x. This means TCP connections can be used in comparison to HTTP/1.x. This means
less competition with other flows and longer-lived connections, which less competition with other flows and longer-lived connections, which
in turn lead to better utilization of available network capacity. in turn lead to better utilization of available network capacity.
Note, however, that TCP head-of-line blocking is not addressed by Note, however, that TCP head-of-line blocking is not addressed by
this protocol. this protocol.
Finally, HTTP/2 also enables more efficient processing of messages Finally, HTTP/2 also enables more efficient processing of messages
through use of binary message framing. through use of binary message framing.
This document obsoletes RFC 7540 [RFC7540] and RFC 8740 [RFC8740]. This document obsoletes RFC 7540 [RFC7540] and RFC 8740 [RFC8740].
Appendix B lists notable changes.
2. HTTP/2 Protocol Overview 2. HTTP/2 Protocol Overview
HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2 HTTP/2 provides an optimized transport for HTTP semantics. HTTP/2
supports all of the core features of HTTP but aims to be more supports all of the core features of HTTP but aims to be more
efficient than HTTP/1.1. efficient than HTTP/1.1.
The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each The basic protocol unit in HTTP/2 is a frame (Section 4.1). Each
frame type serves a different purpose. For example, HEADERS and DATA frame type serves a different purpose. For example, HEADERS and DATA
frames form the basis of HTTP requests and responses (Section 8.1); frames form the basis of HTTP requests and responses (Section 8.1);
skipping to change at page 8, line 26 skipping to change at page 8, line 26
o The string "h2" identifies the protocol where HTTP/2 uses o The string "h2" identifies the protocol where HTTP/2 uses
Transport Layer Security (TLS); see Section 9.2. This identifier Transport Layer Security (TLS); see Section 9.2. This identifier
is used in the TLS application-layer protocol negotiation (ALPN) is used in the TLS application-layer protocol negotiation (ALPN)
extension [TLS-ALPN] field and in any place where HTTP/2 over TLS extension [TLS-ALPN] field and in any place where HTTP/2 over TLS
is identified. is identified.
The "h2" string is serialized into an ALPN protocol identifier as The "h2" string is serialized into an ALPN protocol identifier as
the two-octet sequence: 0x68, 0x32. the two-octet sequence: 0x68, 0x32.
o The string "h2c" identifies the protocol where HTTP/2 is run over o The "h2c" string was previously used as a token for use in the
cleartext TCP. This identifier is used 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. The security
properties of this protocol do not hold unless TLS is used; see
Section 10.
The "h2c" string was previously used as a token for use in the
HTTP Upgrade mechanism's Upgrade header field (Section 7.8 of HTTP Upgrade mechanism's Upgrade header field (Section 7.8 of
[HTTP]). This usage was never widely deployed, and is no longer [HTTP]) and as an identifier for the protocol where HTTP/2 is run
specified in this document. over cleartext TCP. This usage was never widely deployed, and is
deprecated by this document.
3.2. Starting HTTP/2 for "https" URIs 3.2. Starting HTTP/2 for "https" URIs
A client that makes a request to an "https" URI uses TLS [TLS13] with A client that makes a request to an "https" URI uses TLS [TLS13] with
the application-layer protocol negotiation (ALPN) extension the application-layer protocol negotiation (ALPN) extension
[TLS-ALPN]. [TLS-ALPN].
HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c" HTTP/2 over TLS uses the "h2" protocol identifier. The "h2c"
protocol identifier MUST NOT be sent by a client or selected by a protocol identifier MUST NOT be sent by a client or selected by a
server; the "h2c" protocol identifier describes a protocol that does server; the "h2c" protocol identifier describes a protocol that does
skipping to change at page 11, line 4 skipping to change at page 10, line 48
Stream Identifier (31), Stream Identifier (31),
Frame Payload (..), Frame Payload (..),
} }
Figure 1: Frame Layout Figure 1: Frame Layout
The fields of the frame header are defined as: The fields of the frame header are defined as:
Length: The length of the frame payload expressed as an unsigned Length: The length of the frame payload expressed as an unsigned
24-bit integer. Values greater than 2^14 (16,384) MUST NOT be 24-bit integer in units of octets. Values greater than 2^14
sent unless the receiver has set a larger value for (16,384) MUST NOT be sent unless the receiver has set a larger
SETTINGS_MAX_FRAME_SIZE. value for SETTINGS_MAX_FRAME_SIZE.
The 9 octets of the frame header are not included in this value. The 9 octets of the frame header are not included in this value.
Type: The 8-bit type of the frame. The frame type determines the Type: The 8-bit type of the frame. The frame type determines the
format and semantics of the frame. Frames defined in this format and semantics of the frame. Frames defined in this
documented are listed in Section 6. Implementations MUST ignore documented are listed in Section 6. Implementations MUST ignore
and discard any frame that has a type that is unknown. and discard any frame that has a type that is unknown.
Flags: An 8-bit field reserved for boolean flags specific to the Flags: An 8-bit field reserved for boolean flags specific to the
frame type. frame type.
skipping to change at page 12, line 48 skipping to change at page 12, line 39
Field blocks carry control data and header sections for requests, Field blocks carry control data and header sections for requests,
responses, promised requests, and pushed responses (see Section 8.4). responses, promised requests, and pushed responses (see Section 8.4).
All these messages, except for interim responses and requests All these messages, except for interim responses and requests
contained in PUSH_PROMISE (Section 6.6) frames, can optionally contained in PUSH_PROMISE (Section 6.6) frames, can optionally
include a field block that carries a trailer section. include a field block that carries a trailer section.
A field section is a collection of field lines. Each of the field A field section is a collection of field lines. Each of the field
lines in a field block carry a single value. The serialized field lines in a field block carry a single value. The serialized field
block is then divided into one or more octet sequences, called field block is then divided into one or more octet sequences, called field
block fragments, and transmitted within the frame payload of HEADERS block fragments. The first field block fragment is transmitted
(Section 6.2) or PUSH_PROMISE (Section 6.6), each of which could be within the frame payload of HEADERS (Section 6.2) or PUSH_PROMISE
followed by CONTINUATION (Section 6.10) frames. (Section 6.6), each of which could be followed by CONTINUATION
(Section 6.10) frames to carry subsequent field block fragments.
The Cookie header field [COOKIE] is treated specially by the HTTP The Cookie header field [COOKIE] is treated specially by the HTTP
mapping (see Section 8.2.3). mapping (see Section 8.2.3).
A receiving endpoint reassembles the field block by concatenating its A receiving endpoint reassembles the field block by concatenating its
fragments and then decompresses the block to reconstruct the field fragments and then decompresses the block to reconstruct the field
section. section.
A complete field section consists of either: A complete field section consists of either:
skipping to change at page 16, line 5 skipping to change at page 15, line 46
o Receiving a PUSH_PROMISE frame on another stream reserves an o Receiving a PUSH_PROMISE frame on another stream reserves an
idle stream that is identified for later use. The stream state idle stream that is identified for later use. The stream state
for the reserved stream transitions to "reserved (remote)". for the reserved stream transitions to "reserved (remote)".
Only a client may receive PUSH_PROMISE frames. Only a client may receive PUSH_PROMISE frames.
o Note that the PUSH_PROMISE frame is not sent on the idle stream o Note that the PUSH_PROMISE frame is not sent on the idle stream
but references the newly reserved stream in the Promised Stream but references the newly reserved stream in the Promised Stream
ID field. ID field.
o Opening a stream with a higher-valued stream identifier causes
the stream to transition immediately to a "closed" state; note
that this transition is not shown in the diagram.
Receiving any frame other than HEADERS or PRIORITY on a stream in 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) this state MUST be treated as a connection error (Section 5.4.1)
of type PROTOCOL_ERROR. If this stream is server-initiated, as of type PROTOCOL_ERROR. If this stream is server-initiated, as
described in Section 5.1.1, then receiving a HEADERS frame MUST described in Section 5.1.1, then receiving a HEADERS frame MUST
also be treated as a connection error (Section 5.4.1) of type also be treated as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
reserved (local): A stream in the "reserved (local)" state is one reserved (local): A stream in the "reserved (local)" state is one
that has been promised by sending a PUSH_PROMISE frame. A that has been promised by sending a PUSH_PROMISE frame. A
PUSH_PROMISE frame reserves an idle stream by associating the PUSH_PROMISE frame reserves an idle stream by associating the
skipping to change at page 18, line 43 skipping to change at page 18, line 41
An endpoint can perform this minimal processing for all streams An endpoint can perform this minimal processing for all streams
that are in the "closed" state. Endpoints MAY use other signals that are in the "closed" state. Endpoints MAY use other signals
to detect that a peer has received the frames that caused the to detect that a peer has received the frames that caused the
stream to enter the "closed" state and treat receipt of any frame stream to enter the "closed" state and treat receipt of any frame
other than PRIORITY as a connection error (Section 5.4.1) of type other than PRIORITY as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. Endpoints can use frames that indicate that the PROTOCOL_ERROR. Endpoints can use frames that indicate that the
peer has received the closing signal to drive this. Endpoints peer has received the closing signal to drive this. Endpoints
SHOULD NOT use timers for this purpose. For example, an endpoint SHOULD NOT use timers for this purpose. For example, an endpoint
that sends a SETTINGS frame after closing a stream can safely that sends a SETTINGS frame after closing a stream can safely
treat receipt of a DATA frame on that stream as an error after treat receipt of a DATA frame on that stream as an error after
receiving an acknowledgement of the settings. Other things that receiving an acknowledgment of the settings. Other things that
might be used are PING frames, receiving data on streams that were might be used are PING frames, receiving data on streams that were
created after closing the stream, or responses to requests created created after closing the stream, or responses to requests created
after closing the stream. after closing the stream.
In the absence of more specific rules, implementations SHOULD treat In the absence of more specific rules, implementations SHOULD treat
the receipt of a frame that is not expressly permitted in the 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 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 PROTOCOL_ERROR. Note that PRIORITY can be sent and received in any
stream state. stream state.
skipping to change at page 19, line 16 skipping to change at page 19, line 16
document. Receipt of frames for which the semantics are unknown document. Receipt of frames for which the semantics are unknown
cannot be treated as an error as the conditions for sending and cannot be treated as an error as the conditions for sending and
receiving those frames are also unknown; see Section 5.5. receiving those frames are also unknown; see Section 5.5.
An example of the state transitions for an HTTP request/response An example of the state transitions for an HTTP request/response
exchange can be found in Section 8.8. An example of the state exchange can be found in Section 8.8. An example of the state
transitions for server push can be found in Sections 8.4.1 and 8.4.2. transitions for server push can be found in Sections 8.4.1 and 8.4.2.
5.1.1. Stream Identifiers 5.1.1. Stream Identifiers
Streams are identified with an unsigned 31-bit integer. Streams Streams are identified by an unsigned 31-bit integer. Streams
initiated by a client MUST use odd-numbered stream identifiers; those initiated by a client MUST use odd-numbered stream identifiers; those
initiated by the server MUST use even-numbered stream identifiers. A initiated by the server MUST use even-numbered stream identifiers. A
stream identifier of zero (0x0) is used for connection control stream identifier of zero (0x0) is used for connection control
messages; the stream identifier of zero cannot be used to establish a messages; the stream identifier of zero cannot be used to establish a
new stream. new stream.
The identifier of a newly established stream MUST be numerically The identifier of a newly established stream MUST be numerically
greater than all streams that the initiating endpoint has opened or greater than all streams that the initiating endpoint has opened or
reserved. This governs streams that are opened using a HEADERS frame reserved. This governs streams that are opened using a HEADERS frame
and streams that are reserved using PUSH_PROMISE. An endpoint that and streams that are reserved using PUSH_PROMISE. An endpoint that
receives an unexpected stream identifier MUST respond with a receives an unexpected stream identifier MUST respond with a
connection error (Section 5.4.1) of type PROTOCOL_ERROR. connection error (Section 5.4.1) of type PROTOCOL_ERROR.
A HEADERS frame will transition the client-initiated stream A HEADERS frame will transition the client-initiated stream
identified by the stream identifier in the frame header from "idle" identified by the stream identifier in the frame header from "idle"
to "open". A PUSH_PROMISE frame will transition the server-initiated to "open". A PUSH_PROMISE frame will transition the server-initiated
stream identified by the "Promised Stream ID" field in the frame stream identified by the "Promised Stream ID" field in the frame
payload from "idle" to "reserved". When a stream transitions out of payload from "idle" to "reserved". When a stream transitions out of
the "idle" state, all streams that might have been initiated by that the "idle" state, all "idle" streams that might have been opened by
peer with a lower-valued stream identifier are implicitly the peer with a lower-valued stream identifier immediately transition
transitioned to "closed". That is, an endpoint may skip a stream to "closed". That is, an endpoint may skip a stream identifier, with
identifier, with the effect being that the skipped stream is the effect being that the skipped stream is immediately closed.
immediately closed.
Stream identifiers cannot be reused. Long-lived connections can Stream identifiers cannot be reused. Long-lived connections can
result in an endpoint exhausting the available range of stream result in an endpoint exhausting the available range of stream
identifiers. A client that is unable to establish a new stream identifiers. A client that is unable to establish a new stream
identifier can establish a new connection for new streams. A server identifier can establish a new connection for new streams. A server
that is unable to establish a new stream identifier can send a GOAWAY that is unable to establish a new stream identifier can send a GOAWAY
frame so that the client is forced to open a new connection for new frame so that the client is forced to open a new connection for new
streams. streams.
5.1.2. Stream Concurrency 5.1.2. Stream Concurrency
skipping to change at page 21, line 5 skipping to change at page 21, line 5
HTTP/2 provides for flow control through use of the WINDOW_UPDATE HTTP/2 provides for flow control through use of the WINDOW_UPDATE
frame (Section 6.9). frame (Section 6.9).
5.2.1. Flow-Control Principles 5.2.1. Flow-Control Principles
HTTP/2 stream flow control aims to allow a variety of flow-control HTTP/2 stream flow control aims to allow a variety of flow-control
algorithms to be used without requiring protocol changes. Flow algorithms to be used without requiring protocol changes. Flow
control in HTTP/2 has the following characteristics: control in HTTP/2 has the following characteristics:
1. Flow control is specific to a connection. Both types of flow 1. Flow control is specific to a connection. HTTP/2 flow control
control are between the endpoints of a single hop and not over operates between the endpoints of a single hop and not over the
the entire end-to-end path. entire end-to-end path.
2. Flow control is based on WINDOW_UPDATE frames. Receivers 2. Flow control is based on WINDOW_UPDATE frames. Receivers
advertise how many octets they are prepared to receive on a advertise how many octets they are prepared to receive on a
stream and for the entire connection. This is a credit-based stream and for the entire connection. This is a credit-based
scheme. scheme.
3. Flow control is directional with overall control provided by the 3. Flow control is directional with overall control provided by the
receiver. A receiver MAY choose to set any window size that it receiver. A receiver MAY choose to set any window size that it
desires for each stream and for the entire connection. A sender desires for each stream and for the entire connection. A sender
MUST respect flow-control limits imposed by a receiver. Clients, MUST respect flow-control limits imposed by a receiver. Clients,
skipping to change at page 22, line 10 skipping to change at page 22, line 10
Implementations are also responsible for prioritizing the sending of Implementations are also responsible for prioritizing the sending of
requests and responses, choosing how to avoid head-of-line blocking requests and responses, choosing how to avoid head-of-line blocking
for requests, and managing the creation of new streams. Algorithm for requests, and managing the creation of new streams. Algorithm
choices for these could interact with any flow-control algorithm. choices for these could interact with any flow-control algorithm.
5.2.2. Appropriate Use of Flow Control 5.2.2. Appropriate Use of Flow Control
Flow control is defined to protect endpoints that are operating under Flow control is defined to protect endpoints that are operating under
resource constraints. For example, a proxy needs to share memory resource constraints. For example, a proxy needs to share memory
between many connections and also might have a slow upstream between many connections and also might have a slow upstream
connection and a fast downstream one. Flow-control addresses cases connection and a fast downstream one. Flow control addresses cases
where the receiver is unable to process data on one stream yet wants where the receiver is unable to process data on one stream yet wants
to continue to process other streams in the same connection. to continue to process other streams in the same connection.
Deployments that do not require this capability can advertise a flow- Deployments that do not require this capability can advertise a flow-
control window of the maximum size (2^31-1) and can maintain this control window of the maximum size (2^31-1) and can maintain this
window by sending a WINDOW_UPDATE frame when any data is received. window by sending a WINDOW_UPDATE frame when any data is received.
This effectively disables flow control for that receiver. This effectively disables flow control for that receiver.
Conversely, a sender is always subject to the flow-control window Conversely, a sender is always subject to the flow-control window
advertised by the receiver. advertised by the receiver.
skipping to change at page 23, line 20 skipping to change at page 23, line 20
in HTTP/2 providing poor performance. With no parallelism at the TCP in HTTP/2 providing poor performance. With no parallelism at the TCP
layer, performance could be significantly worse than HTTP/1.1. layer, performance could be significantly worse than HTTP/1.1.
A good prioritization scheme benefits from the application of A good prioritization scheme benefits from the application of
contextual knowledge such as the content of resources, how resources contextual knowledge such as the content of resources, how resources
are interrelated, and how those resources will be used by a peer. In are interrelated, and how those resources will be used by a peer. In
particular, clients can possess knowledge about the priority of particular, clients can possess knowledge about the priority of
requests that is relevant to server prioritization. In those cases, requests that is relevant to server prioritization. In those cases,
having clients provide priority information can improve performance. having clients provide priority information can improve performance.
5.3.1. Background of Priority in HTTP/2 5.3.1. Background on Priority in RFC 7540
HTTP/2 included a rich system for signaling priority of requests. RFC 7540 defined a rich system for signaling priority of requests.
However, this system proved to be complex and it was not uniformly However, this system proved to be complex and it was not uniformly
implemented. implemented.
The flexible scheme meant that it was possible for clients to express The flexible scheme meant that it was possible for clients to express
priorities in very different ways, with little consistency in the priorities in very different ways, with little consistency in the
approaches that were adopted. For servers, implementing generic approaches that were adopted. For servers, implementing generic
support for the scheme was complex. Implementation of priorities was support for the scheme was complex. Implementation of priorities was
uneven in both clients and servers. Many server deployments ignored uneven in both clients and servers. Many server deployments ignored
client signals when prioritizing their handling of requests. client signals when prioritizing their handling of requests.
skipping to change at page 27, line 39 skipping to change at page 27, line 39
DATA frames (type=0x0) convey arbitrary, variable-length sequences of DATA frames (type=0x0) convey arbitrary, variable-length sequences of
octets associated with a stream. One or more DATA frames are used, octets associated with a stream. One or more DATA frames are used,
for instance, to carry HTTP request or response message contents. for instance, to carry HTTP request or response message contents.
DATA frames MAY also contain padding. Padding can be added to DATA DATA frames MAY also contain padding. Padding can be added to DATA
frames to obscure the size of messages. Padding is a security frames to obscure the size of messages. Padding is a security
feature; see Section 10.7. feature; see Section 10.7.
DATA Frame { DATA Frame {
Length (24), Length (24),
Type (8) = 0, Type (8) = 0x0,
Unused Flags (4), Unused Flags (4),
PADDED Flag (1), PADDED Flag (1),
Unused Flags (2), Unused Flags (2),
END_STREAM Flag (1), END_STREAM Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
[Pad Length (8)], [Pad Length (8)],
Data (..), Data (..),
Padding (..), Padding (..2040),
} }
Figure 3: DATA Frame Format Figure 3: DATA Frame Format
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
fields are described in Section 4. The DATA frame contains the fields are described in Section 4. The DATA frame contains the
following additional fields: following additional fields:
Pad Length: An 8-bit field containing the length of the frame Pad Length: An 8-bit field containing the length of the frame
padding in units of octets. This field is conditional and is only padding in units of octets. This field is conditional and is only
present if the PADDED flag is set. present if the PADDED flag is set.
skipping to change at page 29, line 18 skipping to change at page 29, line 18
6.2. HEADERS 6.2. HEADERS
The HEADERS frame (type=0x1) is used to open a stream (Section 5.1), The HEADERS frame (type=0x1) is used to open a stream (Section 5.1),
and additionally carries a field block fragment. Despite the name, a and additionally carries a field block fragment. Despite the name, a
HEADERS frame can carry a header section or a trailer section. HEADERS frame can carry a header section or a trailer section.
HEADERS frames can be sent on a stream in the "idle", "reserved HEADERS frames can be sent on a stream in the "idle", "reserved
(local)", "open", or "half-closed (remote)" state. (local)", "open", or "half-closed (remote)" state.
HEADERS Frame { HEADERS Frame {
Length (24), Length (24),
Type (8) = 1, Type (8) = 0x1,
Unused Flags (2), Unused Flags (2),
PRIORITY Flag (1), PRIORITY Flag (1),
Unused Flag (1), Unused Flag (1),
PADDED Flag (1), PADDED Flag (1),
END_HEADERS Flag (1), END_HEADERS Flag (1),
Unused Flag (1), Unused Flag (1),
END_STREAM Flag (1), END_STREAM Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
[Pad Length (8)], [Pad Length (8)],
[Exclusive (1)], [Exclusive (1)],
[Stream Dependency (31)], [Stream Dependency (31)],
[Weight (8)], [Weight (8)],
Field Block Fragment (..), Field Block Fragment (..),
Padding (..), Padding (..2040),
} }
Figure 4: HEADERS Frame Format Figure 4: HEADERS Frame Format
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
fields are described in Section 4. The HEADERS frame payload has the fields are described in Section 4. The HEADERS frame payload has the
following additional fields: following additional fields:
Pad Length: An 8-bit field containing the length of the frame Pad Length: An 8-bit field containing the length of the frame
padding in units of octets. This field is only present if the padding in units of octets. This field is only present if the
skipping to change at page 31, line 23 skipping to change at page 31, line 23
| Note: A frame can be increased in size by one octet by | Note: A frame can be increased in size by one octet by
| including a Pad Length field with a value of zero. | including a Pad Length field with a value of zero.
6.3. PRIORITY 6.3. PRIORITY
The PRIORITY frame (type=0x2) is deprecated; see Section 5.3.2. A The PRIORITY frame (type=0x2) is deprecated; see Section 5.3.2. A
PRIORITY frame can be sent in any stream state, including idle or PRIORITY frame can be sent in any stream state, including idle or
closed streams. closed streams.
PRIORITY Frame { PRIORITY Frame {
Length (24), Length (24) = 0x5,
Type (8) = 2, Type (8) = 0x2,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Exclusive (1), Exclusive (1),
Stream Dependency (31), Stream Dependency (31),
Weight (8), Weight (8),
} }
skipping to change at page 32, line 26 skipping to change at page 32, line 26
A PRIORITY frame with a length other than 5 octets MUST be treated as 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. a stream error (Section 5.4.2) of type FRAME_SIZE_ERROR.
6.4. RST_STREAM 6.4. RST_STREAM
The RST_STREAM frame (type=0x3) allows for immediate termination of a 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 stream. RST_STREAM is sent to request cancellation of a stream or to
indicate that an error condition has occurred. indicate that an error condition has occurred.
RST_STREAM Frame { RST_STREAM Frame {
Length (24), Length (24) = 0x4,
Type (8) = 3, Type (8) = 0x3,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Error Code (32), Error Code (32),
} }
Figure 6: RST_STREAM Frame Format Figure 6: RST_STREAM Frame Format
skipping to change at page 33, line 8 skipping to change at page 33, line 8
fields are described in Section 4. Additionally, the RST_STREAM fields are described in Section 4. Additionally, the RST_STREAM
frame contains a single unsigned, 32-bit integer identifying the frame contains a single unsigned, 32-bit integer identifying the
error code (Section 7). The error code indicates why the stream is error code (Section 7). The error code indicates why the stream is
being terminated. being terminated.
The RST_STREAM frame does not define any flags. The RST_STREAM frame does not define any flags.
The RST_STREAM frame fully terminates the referenced stream and The RST_STREAM frame fully terminates the referenced stream and
causes it to enter the "closed" state. After receiving a RST_STREAM causes it to enter the "closed" state. After receiving a RST_STREAM
on a stream, the receiver MUST NOT send additional frames for that on a stream, the receiver MUST NOT send additional frames for that
stream, with the exception of PRIORITY. However, after sending the stream, except for PRIORITY. However, after sending the RST_STREAM,
RST_STREAM, the sending endpoint MUST be prepared to receive and the sending endpoint MUST be prepared to receive and process
process additional frames sent on the stream that might have been additional frames sent on the stream that might have been sent by the
sent by the peer prior to the arrival of the RST_STREAM. peer prior to the arrival of the RST_STREAM.
RST_STREAM frames MUST be associated with a stream. If a RST_STREAM RST_STREAM frames MUST be associated with a stream. If a RST_STREAM
frame is received with a stream identifier of 0x0, the recipient MUST frame is received with a stream identifier of 0x0, the recipient MUST
treat this as a connection error (Section 5.4.1) of type treat this as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
RST_STREAM frames MUST NOT be sent for a stream in the "idle" state. RST_STREAM frames MUST NOT be sent for a stream in the "idle" state.
If a RST_STREAM frame identifying an idle stream is received, the If a RST_STREAM frame identifying an idle stream is received, the
recipient MUST treat this as a connection error (Section 5.4.1) of recipient MUST treat this as a connection error (Section 5.4.1) of
type PROTOCOL_ERROR. type PROTOCOL_ERROR.
skipping to change at page 34, line 38 skipping to change at page 34, line 38
FRAME_SIZE_ERROR. FRAME_SIZE_ERROR.
6.5.1. SETTINGS Format 6.5.1. SETTINGS Format
The frame payload of a SETTINGS frame consists of zero or more The frame payload of a SETTINGS frame consists of zero or more
settings, each consisting of an unsigned 16-bit setting identifier settings, each consisting of an unsigned 16-bit setting identifier
and an unsigned 32-bit value. and an unsigned 32-bit value.
SETTINGS Frame { SETTINGS Frame {
Length (24), Length (24),
Type (8) = 4, Type (8) = 0x4,
Unused Flags (7), Unused Flags (7),
ACK Flag (1), ACK Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31) = 0, Stream Identifier (31) = 0,
Setting (48) ..., Setting (48) ...,
} }
Setting { Setting {
Identifier (16), Identifier (16),
Value (32), Value (32),
} }
Figure 7: SETTINGS Frame Format Figure 7: SETTINGS Frame Format
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
fields are described in Section 4. The frame payload of a SETTINGS
frame contains any number of Setting fields, each of which consists
of:
Identifier: A 16-bit setting identifier; see Section 6.5.2.
Value: A 32-bit value for the setting.
6.5.2. Defined Settings 6.5.2. Defined Settings
The following settings are defined: The following settings are defined:
SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the SETTINGS_HEADER_TABLE_SIZE (0x1): Allows the sender to inform the
remote endpoint of the maximum size of the compression table used remote endpoint of the maximum size of the compression table used
to decode field blocks, in octets. The encoder can select any to decode field blocks, in units of octets. The encoder can
size equal to or less than this value by using signaling specific select any size equal to or less than this value by using
to the compression format inside a field block (see signaling specific to the compression format inside a field block
[COMPRESSION]). The initial value is 4,096 octets. (see [COMPRESSION]). The initial value is 4,096 octets.
SETTINGS_ENABLE_PUSH (0x2): This setting can be used to disable SETTINGS_ENABLE_PUSH (0x2): This setting can be used to disable
server push (Section 8.4). A server MUST NOT send a PUSH_PROMISE server push (Section 8.4). A server MUST NOT send a PUSH_PROMISE
frame if it receives this parameter set to a value of 0. A client frame if it receives this parameter set to a value of 0. A client
that has both set this parameter to 0 and had it acknowledged MUST 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 treat the receipt of a PUSH_PROMISE frame as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
The initial value of SETTINGS_ENABLE_PUSH is 1. For a client this The initial value of SETTINGS_ENABLE_PUSH is 1. For a client this
value indicates that it is willing to receive PUSH_PROMISE frames. value indicates that it is willing to receive PUSH_PROMISE frames.
skipping to change at page 36, line 4 skipping to change at page 36, line 13
100, so as to not unnecessarily limit parallelism. 100, so as to not unnecessarily limit parallelism.
A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be
treated as special by endpoints. A zero value does prevent the treated as special by endpoints. A zero value does prevent the
creation of new streams; however, this can also happen for any creation of new streams; however, this can also happen for any
limit that is exhausted with active streams. Servers SHOULD only limit that is exhausted with active streams. Servers SHOULD only
set a zero value for short durations; if a server does not wish to set a zero value for short durations; if a server does not wish to
accept requests, closing the connection is more appropriate. accept requests, closing the connection is more appropriate.
SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial
window size (in octets) for stream-level flow control. The window size (in units of octets) for stream-level flow control.
initial value is 2^16-1 (65,535) octets. The initial value is 2^16-1 (65,535) octets.
This setting affects the window size of all streams (see This setting affects the window size of all streams (see
Section 6.9.2). Section 6.9.2).
Values above the maximum flow-control window size of 2^31-1 MUST 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 be treated as a connection error (Section 5.4.1) of type
FLOW_CONTROL_ERROR. FLOW_CONTROL_ERROR.
SETTINGS_MAX_FRAME_SIZE (0x5): Indicates the size of the largest SETTINGS_MAX_FRAME_SIZE (0x5): Indicates the size of the largest
frame payload that the sender is willing to receive, in octets. frame payload that the sender is willing to receive, in units of
octets.
The initial value is 2^14 (16,384) octets. The value advertised The initial value is 2^14 (16,384) octets. The value advertised
by an endpoint MUST be between this initial value and the maximum by an endpoint MUST be between this initial value and the maximum
allowed frame size (2^24-1 or 16,777,215 octets), inclusive. allowed frame size (2^24-1 or 16,777,215 octets), inclusive.
Values outside this range MUST be treated as a connection error Values outside this range MUST be treated as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This advisory setting informs a SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This advisory setting informs a
peer of the maximum size of field section that the sender is peer of the maximum size of field section that the sender is
prepared to accept, in octets. The value is based on the prepared to accept, in units of octets. The value is based on the
uncompressed size of field lines, including the length of the name uncompressed size of field lines, including the length of the name
and value in octets plus an overhead of 32 octets for each field and value in units of octets plus an overhead of 32 octets for
line. each field line.
For any given request, a lower limit than what is advertised MAY For any given request, a lower limit than what is advertised MAY
be enforced. The initial value of this setting is unlimited. be enforced. The initial value of this setting is unlimited.
An endpoint that receives a SETTINGS frame with any unknown or An endpoint that receives a SETTINGS frame with any unknown or
unsupported identifier MUST ignore that setting. unsupported identifier MUST ignore that setting.
6.5.3. Settings Synchronization 6.5.3. Settings Synchronization
Most values in SETTINGS benefit from or require an understanding of Most values in SETTINGS benefit from or require an understanding of
when the peer has received and applied the changed parameter values. when the peer has received and applied the changed parameter values.
In order to provide such synchronization timepoints, the recipient of In order to provide such synchronization timepoints, the recipient of
a SETTINGS frame in which the ACK flag is not set MUST apply the a SETTINGS frame in which the ACK flag is not set MUST apply the
updated settings as soon as possible upon receipt. updated settings as soon as possible upon receipt. SETTINGS frames
are acknowledged in the order in which they are received.
The values in the SETTINGS frame MUST be processed in the order they The values in the SETTINGS frame MUST be processed in the order they
appear, with no other frame processing between values. Unsupported appear, with no other frame processing between values. Unsupported
settings MUST be ignored. Once all values have been processed, the settings MUST be ignored. Once all values have been processed, the
recipient MUST immediately emit a SETTINGS frame with the ACK flag recipient MUST immediately emit a SETTINGS frame with the ACK flag
set. Upon receiving a SETTINGS frame with the ACK flag set, the set. Upon receiving a SETTINGS frame with the ACK flag set, the
sender of the altered settings can rely on the values from the oldest sender of the altered settings can rely on the values from the oldest
unacknowledged SETTINGS frame having been applied. unacknowledged SETTINGS frame having been applied.
If the sender of a SETTINGS frame does not receive an acknowledgement If the sender of a SETTINGS frame does not receive an acknowledgment
within a reasonable amount of time, it MAY issue a connection error within a reasonable amount of time, it MAY issue a connection error
(Section 5.4.1) of type SETTINGS_TIMEOUT. (Section 5.4.1) of type SETTINGS_TIMEOUT. In setting a timeout, some
allowance need to be made for processing delays at the peer; a
timeout that is solely based on the round trip time between endpoints
might result in spurious errors.
6.6. PUSH_PROMISE 6.6. PUSH_PROMISE
The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint The PUSH_PROMISE frame (type=0x5) is used to notify the peer endpoint
in advance of streams the sender intends to initiate. The in advance of streams the sender intends to initiate. The
PUSH_PROMISE frame includes the unsigned 31-bit identifier of the PUSH_PROMISE frame includes the unsigned 31-bit identifier of the
stream the endpoint plans to create along with a field section that stream the endpoint plans to create along with a field section that
provides additional context for the stream. Section 8.4 contains a provides additional context for the stream. Section 8.4 contains a
thorough description of the use of PUSH_PROMISE frames. thorough description of the use of PUSH_PROMISE frames.
PUSH_PROMISE Frame { PUSH_PROMISE Frame {
Length (24), Length (24),
Type (8) = 5, Type (8) = 0x5,
Unused Flags (4), Unused Flags (4),
PADDED Flag (1), PADDED Flag (1),
END_HEADERS Flag (1), END_HEADERS Flag (1),
Unused Flags (2), Unused Flags (2),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
[Pad Length (8)], [Pad Length (8)],
Reserved (1), Reserved (1),
Promised Stream ID (31), Promised Stream ID (31),
Field Block Fragment (..), Field Block Fragment (..),
Padding (..), Padding (..2040),
} }
Figure 8: PUSH_PROMISE Frame Format Figure 8: PUSH_PROMISE Frame Format
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
fields are described in Section 4. The PUSH_PROMISE frame payload fields are described in Section 4. The PUSH_PROMISE frame payload
has the following additional fields: has the following additional fields:
Pad Length: An 8-bit field containing the length of the frame Pad Length: An 8-bit field containing the length of the frame
padding in units of octets. This field is only present if the padding in units of octets. This field is only present if the
skipping to change at page 38, line 41 skipping to change at page 39, line 28
associated with. If the stream identifier field specifies the value associated with. If the stream identifier field specifies the value
0x0, a recipient MUST respond with a connection error (Section 5.4.1) 0x0, a recipient MUST respond with a connection error (Section 5.4.1)
of type PROTOCOL_ERROR. of type PROTOCOL_ERROR.
Promised streams are not required to be used in the order they are Promised streams are not required to be used in the order they are
promised. The PUSH_PROMISE only reserves stream identifiers for promised. The PUSH_PROMISE only reserves stream identifiers for
later use. later use.
PUSH_PROMISE MUST NOT be sent if the SETTINGS_ENABLE_PUSH setting of 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 the peer endpoint is set to 0. An endpoint that has set this setting
and has received acknowledgement MUST treat the receipt of a and has received acknowledgment MUST treat the receipt of a
PUSH_PROMISE frame as a connection error (Section 5.4.1) of type PUSH_PROMISE frame as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
Recipients of PUSH_PROMISE frames can choose to reject promised Recipients of PUSH_PROMISE frames can choose to reject promised
streams by returning a RST_STREAM referencing the promised stream streams by returning a RST_STREAM referencing the promised stream
identifier back to the sender of the PUSH_PROMISE. identifier back to the sender of the PUSH_PROMISE.
A PUSH_PROMISE frame modifies the connection state in two ways. A PUSH_PROMISE frame modifies the connection state in two ways.
First, the inclusion of a field block (Section 4.3) potentially First, the inclusion of a field block (Section 4.3) potentially
modifies the state maintained for field section compression. Second, modifies the state maintained for field section compression. Second,
skipping to change at page 39, line 41 skipping to change at page 40, line 36
| including a Pad Length field with a value of zero. | including a Pad Length field with a value of zero.
6.7. PING 6.7. PING
The PING frame (type=0x6) is a mechanism for measuring a minimal The PING frame (type=0x6) is a mechanism for measuring a minimal
round-trip time from the sender, as well as determining whether an round-trip time from the sender, as well as determining whether an
idle connection is still functional. PING frames can be sent from idle connection is still functional. PING frames can be sent from
any endpoint. any endpoint.
PING Frame { PING Frame {
Length (24), Length (24) = 0x8,
Type (8) = 6, Type (8) = 0x6,
Unused Flags (7), Unused Flags (7),
ACK Flag (1), ACK Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31) = 0, Stream Identifier (31) = 0,
Opaque Data (64), Opaque Data (64),
} }
Figure 9: PING Frame Format Figure 9: PING Frame Format
The Length, Type, Unused Flag(s), Reserved, and Stream Identifier The Length, Type, Unused Flag(s), Reserved, and Stream Identifier
fields are described in Section 4. fields are described in Section 4.
In addition to the frame header, PING frames MUST contain 8 octets of In addition to the frame header, PING frames MUST contain 8 octets of
opaque data in the frame payload. A sender can include any value it opaque data in the frame payload. A sender can include any value it
chooses and use those octets in any fashion. chooses and use those octets in any fashion.
Receivers of a PING frame that does not include an ACK flag MUST send Receivers of a PING frame that does not include an ACK flag MUST send
skipping to change at page 41, line 36 skipping to change at page 42, line 30
An endpoint might choose to close a connection without sending a An endpoint might choose to close a connection without sending a
GOAWAY for misbehaving peers. GOAWAY for misbehaving peers.
A GOAWAY frame might not immediately precede closing of the A GOAWAY frame might not immediately precede closing of the
connection; a receiver of a GOAWAY that has no more use for the connection; a receiver of a GOAWAY that has no more use for the
connection SHOULD still send a GOAWAY frame before terminating the connection SHOULD still send a GOAWAY frame before terminating the
connection. connection.
GOAWAY Frame { GOAWAY Frame {
Length (24), Length (24),
Type (8) = 7, Type (8) = 0x7,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31) = 0, Stream Identifier (31) = 0,
Reserved (1), Reserved (1),
Last-Stream-ID (31), Last-Stream-ID (31),
Error Code (32), Error Code (32),
Additional Debug Data (..), Additional Debug Data (..),
skipping to change at page 42, line 29 skipping to change at page 43, line 27
| Note: In this context, "processed" means that some data from | Note: In this context, "processed" means that some data from
| the stream was passed to some higher layer of software that | the stream was passed to some higher layer of software that
| might have taken some action as a result. | might have taken some action as a result.
If a connection terminates without a GOAWAY frame, the last stream If a connection terminates without a GOAWAY frame, the last stream
identifier is effectively the highest possible stream identifier. identifier is effectively the highest possible stream identifier.
On streams with lower- or equal-numbered identifiers that were not On streams with lower- or equal-numbered identifiers that were not
closed completely prior to the connection being closed, reattempting closed completely prior to the connection being closed, reattempting
requests, transactions, or any protocol activity is not possible, requests, transactions, or any protocol activity is not possible,
with the exception of idempotent actions like HTTP GET, PUT, or except for idempotent actions like HTTP GET, PUT, or DELETE. Any
DELETE. Any protocol activity that uses higher-numbered streams can protocol activity that uses higher-numbered streams can be safely
be safely retried using a new connection. retried using a new connection.
Activity on streams numbered lower or equal to the last stream Activity on streams numbered lower or equal to the last stream
identifier might still complete successfully. The sender of a GOAWAY identifier might still complete successfully. The sender of a GOAWAY
frame might gracefully shut down a connection by sending a GOAWAY frame might gracefully shut down a connection by sending a GOAWAY
frame, maintaining the connection in an "open" state until all in- frame, maintaining the connection in an "open" state until all in-
progress streams complete. progress streams complete.
An endpoint MAY send multiple GOAWAY frames if circumstances change. An endpoint MAY send multiple GOAWAY frames if circumstances change.
For instance, an endpoint that sends GOAWAY with NO_ERROR during For instance, an endpoint that sends GOAWAY with NO_ERROR during
graceful shutdown could subsequently encounter a condition that graceful shutdown could subsequently encounter a condition that
skipping to change at page 43, line 7 skipping to change at page 44, line 5
already have retried unprocessed requests on another connection. already have retried unprocessed requests on another connection.
A client that is unable to retry requests loses all requests that are A client that is unable to retry requests loses all requests that are
in flight when the server closes the connection. This is especially in flight when the server closes the connection. This is especially
true for intermediaries that might not be serving clients using true for intermediaries that might not be serving clients using
HTTP/2. A server that is attempting to gracefully shut down a HTTP/2. A server that is attempting to gracefully shut down a
connection SHOULD send an initial GOAWAY frame with the last stream connection SHOULD send an initial GOAWAY frame with the last stream
identifier set to 2^31-1 and a NO_ERROR code. This signals to the identifier set to 2^31-1 and a NO_ERROR code. This signals to the
client that a shutdown is imminent and that initiating further client that a shutdown is imminent and that initiating further
requests is prohibited. After allowing time for any in-flight stream requests is prohibited. After allowing time for any in-flight stream
creation (at least one round-trip time), the server can send another creation (at least one round-trip time), the server MAY send another
GOAWAY frame with an updated last stream identifier. This ensures GOAWAY frame with an updated last stream identifier. This ensures
that a connection can be cleanly shut down without losing requests. that a connection can be cleanly shut down without losing requests.
After sending a GOAWAY frame, the sender can discard frames for After sending a GOAWAY frame, the sender can discard frames for
streams initiated by the receiver with identifiers higher than the streams initiated by the receiver with identifiers higher than the
identified last stream. However, any frames that alter connection identified last stream. However, any frames that alter connection
state cannot be completely ignored. For instance, HEADERS, state cannot be completely ignored. For instance, HEADERS,
PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to PUSH_PROMISE, and CONTINUATION frames MUST be minimally processed to
ensure the state maintained for field section compression is ensure the state maintained for field section compression is
consistent (see Section 4.3); similarly, DATA frames MUST be counted consistent (see Section 4.3); similarly, DATA frames MUST be counted
skipping to change at page 44, line 15 skipping to change at page 45, line 6
Flow control only applies to frames that are identified as being Flow control only applies to frames that are identified as being
subject to flow control. Of the frame types defined in this subject to flow control. Of the frame types defined in this
document, this includes only DATA frames. Frames that are exempt document, this includes only DATA frames. Frames that are exempt
from flow control MUST be accepted and processed, unless the receiver from flow control MUST be accepted and processed, unless the receiver
is unable to assign resources to handling the frame. A receiver MAY is unable to assign resources to handling the frame. A receiver MAY
respond with a stream error (Section 5.4.2) or connection error 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 (Section 5.4.1) of type FLOW_CONTROL_ERROR if it is unable to accept
a frame. a frame.
WINDOW_UPDATE Frame { WINDOW_UPDATE Frame {
Length (24), Length (24) = 0x4,
Type (8) = 8, Type (8) = 0x8,
Unused Flags (8), Unused Flags (8),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Reserved (1), Reserved (1),
Window Size Increment (31), Window Size Increment (31),
} }
skipping to change at page 45, line 42 skipping to change at page 46, line 34
For flow-control calculations, the 9-octet frame header is not For flow-control calculations, the 9-octet frame header is not
counted. counted.
After sending a flow-controlled frame, the sender reduces the space After sending a flow-controlled frame, the sender reduces the space
available in both windows by the length of the transmitted frame. available in both windows by the length of the transmitted frame.
The receiver of a frame sends a WINDOW_UPDATE frame as it consumes The receiver of a frame sends a WINDOW_UPDATE frame as it consumes
data and frees up space in flow-control windows. Separate data and frees up space in flow-control windows. Separate
WINDOW_UPDATE frames are sent for the stream- and connection-level WINDOW_UPDATE frames are sent for the stream- and connection-level
flow-control windows. flow-control windows. Receivers are advised to have mechanisms in
place to avoid sending WINDOW_UPDATE frames with very small
increments; see Section 4.2.3.3 of [RFC1122].
A sender that receives a WINDOW_UPDATE frame updates the A sender that receives a WINDOW_UPDATE frame updates the
corresponding window by the amount specified in the frame. corresponding window by the amount specified in the frame.
A sender MUST NOT allow a flow-control window to exceed 2^31-1 A sender MUST NOT allow a flow-control window to exceed 2^31-1
octets. If a sender receives a WINDOW_UPDATE that causes a flow- octets. If a sender receives a WINDOW_UPDATE that causes a flow-
control window to exceed this maximum, it MUST terminate either the control window to exceed this maximum, it MUST terminate either the
stream or the connection, as appropriate. For streams, the sender stream or the connection, as appropriate. For streams, the sender
sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR; for the sends a RST_STREAM with an error code of FLOW_CONTROL_ERROR; for the
connection, a GOAWAY frame with an error code of FLOW_CONTROL_ERROR connection, a GOAWAY frame with an error code of FLOW_CONTROL_ERROR
skipping to change at page 46, line 31 skipping to change at page 47, line 18
created with an initial flow-control window size of 65,535 octets. created with an initial flow-control window size of 65,535 octets.
The connection flow-control window is also 65,535 octets. Both The connection flow-control window is also 65,535 octets. Both
endpoints can adjust the initial window size for new streams by endpoints can adjust the initial window size for new streams by
including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS including a value for SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS
frame that forms part of the connection preface. The connection frame that forms part of the connection preface. The connection
flow-control window can only be changed using WINDOW_UPDATE frames. flow-control window can only be changed using WINDOW_UPDATE frames.
Prior to receiving a SETTINGS frame that sets a value for Prior to receiving a SETTINGS frame that sets a value for
SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default SETTINGS_INITIAL_WINDOW_SIZE, an endpoint can only use the default
initial window size when sending flow-controlled frames. Similarly, initial window size when sending flow-controlled frames. Similarly,
the connection flow-control window is set to the default initial the connection flow-control window is set based on the default
window size until a WINDOW_UPDATE frame is received. initial window size until a WINDOW_UPDATE frame is received.
In addition to changing the flow-control window for streams that are In addition to changing the flow-control window for streams that are
not yet active, a SETTINGS frame can alter the initial flow-control not yet active, a SETTINGS frame can alter the initial flow-control
window size for streams with active flow-control windows (that is, window size for streams with active flow-control windows (that is,
streams in the "open" or "half-closed (remote)" state). When the streams in the "open" or "half-closed (remote)" state). When the
value of SETTINGS_INITIAL_WINDOW_SIZE changes, a receiver MUST adjust value of SETTINGS_INITIAL_WINDOW_SIZE changes, a receiver MUST adjust
the size of all stream flow-control windows that it maintains by the the size of all stream flow-control windows that it maintains by the
difference between the new value and the old value. difference between the new value and the old value.
A change to SETTINGS_INITIAL_WINDOW_SIZE can cause the available A change to SETTINGS_INITIAL_WINDOW_SIZE can cause the available
skipping to change at page 48, line 7 skipping to change at page 48, line 32
6.10. CONTINUATION 6.10. CONTINUATION
The CONTINUATION frame (type=0x9) is used to continue a sequence of The CONTINUATION frame (type=0x9) is used to continue a sequence of
field block fragments (Section 4.3). Any number of CONTINUATION field block fragments (Section 4.3). Any number of CONTINUATION
frames can be sent, as long as the preceding frame is on the same 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 stream and is a HEADERS, PUSH_PROMISE, or CONTINUATION frame without
the END_HEADERS flag set. the END_HEADERS flag set.
CONTINUATION Frame { CONTINUATION Frame {
Length (24), Length (24),
Type (8) = 9, Type (8) = 0x9,
Unused Flags (5), Unused Flags (5),
END_HEADERS Flag (1), END_HEADERS Flag (1),
Unused Flags (2), Unused Flags (2),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Field Block Fragment (..), Field Block Fragment (..),
} }
skipping to change at page 52, line 8 skipping to change at page 52, line 30
A malformed request or response is one that is an otherwise valid A malformed request or response is one that is an otherwise valid
sequence of HTTP/2 frames but is invalid due to the presence of sequence of HTTP/2 frames but is invalid due to the presence of
extraneous frames, prohibited fields or pseudo-header fields, the extraneous frames, prohibited fields or pseudo-header fields, the
absence of mandatory pseudo-header fields, the inclusion of uppercase absence of mandatory pseudo-header fields, the inclusion of uppercase
field names, or invalid field names and/or values (in certain field names, or invalid field names and/or values (in certain
circumstances; see Section 8.2). circumstances; see Section 8.2).
A request or response that includes message content can include a A request or response that includes message content can include a
content-length header field. A request or response is also malformed 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 if the value of a content-length header field does not equal the sum
of the DATA frame payload lengths that form the content. A response of the DATA frame payload lengths that form the content, unless the
that is defined to have no content, as described in Section 6.4 of message is defined as having no content. For example, 204 or 304
[HTTP], can have a non-zero content-length header field, even though responses contain no content, as does the response to a HEAD request.
no content is included in DATA frames. A response that is defined to have no content, as described in
Section 6.4.1 of [HTTP], MAY 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 Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a malformed intermediary not acting as a tunnel) MUST NOT forward a malformed
request or response. Malformed requests or responses that are request or response. Malformed requests or responses that are
detected MUST be treated as a stream error (Section 5.4.2) of type detected MUST be treated as a stream error (Section 5.4.2) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
For malformed requests, a server MAY send an HTTP response prior to For malformed requests, a server MAY send an HTTP response prior to
closing or resetting the stream. Clients MUST NOT accept a malformed closing or resetting the stream. Clients MUST NOT accept a malformed
response. response.
skipping to change at page 52, line 47 skipping to change at page 53, line 29
HTTP fields (Section 5 of [HTTP]) are conveyed by HTTP/2 in the HTTP fields (Section 5 of [HTTP]) are conveyed by HTTP/2 in the
HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with HPACK HEADERS, CONTINUATION, and PUSH_PROMISE frames, compressed with HPACK
[COMPRESSION]. [COMPRESSION].
Field names MUST be converted to lowercase when constructing an Field names MUST be converted to lowercase when constructing an
HTTP/2 message. HTTP/2 message.
8.2.1. Field Validity 8.2.1. Field Validity
The definitions of field names and values in HTTP prohibits some The definitions of field names and values in HTTP prohibit some
characters that HPACK might be able to convey. HTTP/2 characters that HPACK might be able to convey. HTTP/2
implementations SHOULD validate field names and values according to implementations SHOULD validate field names and values according to
their definitions in Sections 5.1 and 5.5 of [HTTP] respectively and their definitions in Sections 5.1 and 5.5 of [HTTP] respectively and
treat messages that contain prohibited characters as malformed treat messages that contain prohibited characters as malformed
(Section 8.1.1). (Section 8.1.1).
Failure to validate fields can be exploited for request smuggling Failure to validate fields can be exploited for request smuggling
attacks. In particular, unvalidated fields might enable attacks when attacks. In particular, unvalidated fields might enable attacks when
messages are forwarded using HTTP 1.1 [HTTP11], where characters such messages are forwarded using HTTP 1.1 [HTTP11], where characters such
as CR, LF, and COLON are used as delimiters. Implementations MUST as CR, LF, and COLON are used as delimiters. Implementations MUST
skipping to change at page 53, line 39 skipping to change at page 54, line 24
| additional check that field names do not include uppercase | additional check that field names do not include uppercase
| characters. | characters.
A request or response that contains a field that violates any of A request or response that contains a field that violates any of
these conditions MUST be treated as malformed (Section 8.1.1). In these conditions MUST be treated as malformed (Section 8.1.1). In
particular, an intermediary that does not process fields when particular, an intermediary that does not process fields when
forwarding messages MUST NOT forward fields that contain any of the forwarding messages MUST NOT forward fields that contain any of the
values that are listed as prohibited above. values that are listed as prohibited above.
When a request message violates one of these requirements, an When a request message violates one of these requirements, an
implementation SHOULD generate a 400 (Bad Request) status code implementation SHOULD generate a 400 (Bad Request) status code (see
[HTTP], unless a more suitable status code is defined or the status Section 15.5.1 of [HTTP]), unless a more suitable status code is
code cannot be sent (e.g., because the error occurs in a trailer defined or the status code cannot be sent (e.g., because the error
field). occurs in a trailer field).
| Note: Field values that are not valid according to the | Note: Field values that are not valid according to the
| definition of the corresponding field do not cause a request to | definition of the corresponding field do not cause a request to
| be malformed; the requirements above only apply to the generic | be malformed; the requirements above only apply to the generic
| syntax for fields as defined in Section 5 of [HTTP]. | syntax for fields as defined in Section 5 of [HTTP].
8.2.2. Connection-Specific Header Fields 8.2.2. Connection-Specific Header Fields
HTTP/2 does not use the Connection header field (Section 7.6.1 of HTTP/2 does not use the Connection header field (Section 7.6.1 of
[HTTP]) to indicate connection-specific header fields; in this [HTTP]) to indicate connection-specific header fields; in this
skipping to change at page 54, line 21 skipping to change at page 55, line 5
connection-specific header fields. This includes the Connection connection-specific header fields. This includes the Connection
header field and those listed as having connection-specific semantics header field and those listed as having connection-specific semantics
in Section 7.6.1 of [HTTP] (that is, Proxy-Connection, Keep-Alive, in Section 7.6.1 of [HTTP] (that is, Proxy-Connection, Keep-Alive,
Transfer-Encoding, and Upgrade). Any message containing connection- Transfer-Encoding, and Upgrade). Any message containing connection-
specific header fields MUST be treated as malformed (Section 8.1.1). specific header fields MUST be treated as malformed (Section 8.1.1).
The only exception to this is the TE header field, which MAY be The only exception to this is the TE header field, which MAY be
present in an HTTP/2 request; when it is, it MUST NOT contain any present in an HTTP/2 request; when it is, it MUST NOT contain any
value other than "trailers". value other than "trailers".
An intermediary transforming a HTTP/1.x message to HTTP/2 MUST remove An intermediary transforming an HTTP/1.x message to HTTP/2 MUST
connection-specific header fields as discussed in Section 7.6.1 of remove connection-specific header fields as discussed in
[HTTP], or their messages will be treated by other HTTP/2 endpoints Section 7.6.1 of [HTTP], or their messages will be treated by other
as malformed (Section 8.1.1). HTTP/2 endpoints as malformed (Section 8.1.1).
| Note: HTTP/2 purposefully does not support upgrade to another | Note: HTTP/2 purposefully does not support upgrade to another
| protocol. The handshake methods described in Section 3 are | protocol. The handshake methods described in Section 3 are
| believed sufficient to negotiate the use of alternative | believed sufficient to negotiate the use of alternative
| protocols. | protocols.
8.2.3. Compressing the Cookie Header Field 8.2.3. Compressing the Cookie Header Field
The Cookie header field [COOKIE] uses a semi-colon (";") to delimit The Cookie header field [COOKIE] uses a semicolon (";") to delimit
cookie-pairs (or "crumbs"). This header field contains multiple cookie-pairs (or "crumbs"). This header field contains multiple
values, but does not use a COMMA (",") as a separator, which prevents values, but does not use a COMMA (",") as a separator, which prevents
cookie-pairs from being sent on multiple field lines (see Section 5.2 cookie-pairs from being sent on multiple field lines (see Section 5.2
of [HTTP]). This can significantly reduce compression efficiency as of [HTTP]). This can significantly reduce compression efficiency as
updates to individual cookie-pairs would invalidate any field lines updates to individual cookie-pairs would invalidate any field lines
that are stored in the HPACK table. that are stored in the HPACK table.
To allow for better compression efficiency, the Cookie header field To allow for better compression efficiency, the Cookie header field
MAY be split into separate header fields, each with one or more MAY be split into separate header fields, each with one or more
cookie-pairs. If there are multiple Cookie header fields after cookie-pairs. If there are multiple Cookie header fields after
skipping to change at page 56, line 11 skipping to change at page 56, line 43
from the scheme of a translated request (for example, see from the scheme of a translated request (for example, see
Section 3.3 of [HTTP11]). Scheme is omitted for CONNECT requests Section 3.3 of [HTTP11]). Scheme is omitted for CONNECT requests
(Section 8.5). (Section 8.5).
:scheme is not restricted to http and https schemed URIs. A proxy :scheme is not restricted to http and https schemed URIs. A proxy
or gateway can translate requests for non-HTTP schemes, enabling or gateway can translate requests for non-HTTP schemes, enabling
the use of HTTP to interact with non-HTTP services. the use of HTTP to interact with non-HTTP services.
o The :authority pseudo-header field conveys the authority portion o The :authority pseudo-header field conveys the authority portion
(Section 3.2 of [RFC3986]) of the target URI (Section 7.1 of (Section 3.2 of [RFC3986]) of the target URI (Section 7.1 of
[HTTP]). The recipient of a HTTP/2 request MUST ignore the Host [HTTP]). The recipient of an HTTP/2 request MUST ignore the Host
header field if :authority is present. header field if :authority is present.
Clients that generate HTTP/2 requests directly MUST use the Clients that generate HTTP/2 requests directly MUST use the
:authority pseudo-header field to convey authority information, :authority pseudo-header field to convey authority information,
unless there is no authority information to convey (in which case unless there is no authority information to convey (in which case
it MUST NOT generate :authority). it MUST NOT generate :authority).
Clients MUST NOT generate a request with a Host header field that Clients MUST NOT generate a request with a Host header field that
differs from the :authority pseudo-header field. A server SHOULD differs from the :authority pseudo-header field. A server SHOULD
treat a request as malformed if it contains a Host header field treat a request as malformed if it contains a Host header field
skipping to change at page 57, line 43 skipping to change at page 58, line 29
For HTTP/2 responses, a single :status pseudo-header field is defined For HTTP/2 responses, a single :status pseudo-header field is defined
that carries the HTTP status code field (see Section 15 of [HTTP]). that carries the HTTP status code field (see Section 15 of [HTTP]).
This pseudo-header field MUST be included in all responses, including This pseudo-header field MUST be included in all responses, including
interim responses; otherwise, the response is malformed interim responses; otherwise, the response is malformed
(Section 8.1.1). (Section 8.1.1).
HTTP/2 responses implicitly have a protocol version of "2.0". HTTP/2 responses implicitly have a protocol version of "2.0".
8.4. Server Push 8.4. Server Push
HTTP/2 allows a server to pre-emptively send (or "push") responses HTTP/2 allows a server to preemptively send (or "push") responses
(along with corresponding "promised" requests) to a client in (along with corresponding "promised" requests) to a client in
association with a previous client-initiated request. association with a previous client-initiated request.
Server push was designed to allow a server to improve client- Server push was designed to allow a server to improve client-
perceived performance by predicting what requests will follow those perceived performance by predicting what requests will follow those
that it receives, thereby removing a round trip for them. For that it receives, thereby removing a round trip for them. For
example, a request for HTML is often followed by requests for example, a request for HTML is often followed by requests for
stylesheets and scripts referenced by that page. When these requests stylesheets and scripts referenced by that page. When these requests
are pushed, the client does not need to wait to receive the are pushed, the client does not need to wait to receive the
references to them in the HTML and issue separate requests. references to them in the HTML and issue separate requests.
skipping to change at page 60, line 43 skipping to change at page 61, line 27
promised response until after the promised stream has closed. promised response until after the promised stream has closed.
If the client determines, for any reason, that it does not wish to If the client determines, for any reason, that it does not wish to
receive the pushed response from the server or if the server takes receive the pushed response from the server or if the server takes
too long to begin sending the promised response, the client can send too long to begin sending the promised response, the client can send
a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code a RST_STREAM frame, using either the CANCEL or REFUSED_STREAM code
and referencing the pushed stream's identifier. and referencing the pushed stream's identifier.
A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit A client can use the SETTINGS_MAX_CONCURRENT_STREAMS setting to limit
the number of responses that can be concurrently pushed by a server. the number of responses that can be concurrently pushed by a server.
Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero disables Advertising a SETTINGS_MAX_CONCURRENT_STREAMS value of zero prevents
server push by preventing the server from creating the necessary the server from opening the streams necessary to push responses.
streams. This does not prohibit a server from sending PUSH_PROMISE However, this does not prevent the server from reserving streams
frames; clients need to reset any promised streams that are not using PUSH_PROMISE frames, because "reserved" streams do not count
wanted. toward the concurrent stream limit. Clients that do not wish to
receive pushed resources need to reset any unwanted reserved streams
or set SETTINGS_ENABLE_PUSH to 0.
Clients receiving a pushed response MUST validate that either the Clients receiving a pushed response MUST validate that either the
server is authoritative (see Section 10.1) or the proxy that provided server is authoritative (see Section 10.1) or the proxy that provided
the pushed response is configured for the corresponding request. For the pushed response is configured for the corresponding request. For
example, a server that offers a certificate for only the example.com example, a server that offers a certificate for only the example.com
DNS-ID is not permitted to push a response for DNS-ID is not permitted to push a response for
https://www.example.org/doc. https://www.example.org/doc.
The response for a PUSH_PROMISE stream begins with a HEADERS frame, The response for a PUSH_PROMISE stream begins with a HEADERS frame,
which immediately puts the stream into the "half-closed (remote)" which immediately puts the stream into the "half-closed (remote)"
skipping to change at page 71, line 39 skipping to change at page 72, line 15
10.3. Intermediary Encapsulation Attacks 10.3. Intermediary Encapsulation Attacks
HPACK permits encoding of field names and values that might be HPACK permits encoding of field names and values that might be
treated as delimiters in other HTTP versions. An intermediary that treated as delimiters in other HTTP versions. An intermediary that
translates an HTTP/2 request or response MUST validate fields translates an HTTP/2 request or response MUST validate fields
according to the rules in Section 8.2 before translating a message to according to the rules in Section 8.2 before translating a message to
another HTTP version. Translating a field that includes invalid another HTTP version. Translating a field that includes invalid
delimiters could be used to cause recipients to incorrectly interpret delimiters could be used to cause recipients to incorrectly interpret
a message, which could be exploited by an attacker. a message, which could be exploited by an attacker.
Section 8.2 does not include specific rules for validation of pseudo-
header fields. If the values of these fields are used, additional
validation is necessary. This is particularly important where
:scheme, :authority, and :path are combined to form a single URI
string ([RFC3986]). Similar problems might occur when that URI or
just :path are combined with :method to construct a request line (as
in Section 3 of [HTTP11]). Simple concatenation is not secure unless
the input values are fully validated.
An intermediary can reject fields that contain invalid field names or An intermediary can reject fields that contain invalid field names or
values for other reasons, in particular those that do not conform to values for other reasons, in particular those that do not conform to
the HTTP ABNF grammar from Section 5 of [HTTP]. Intermediaries that the HTTP ABNF grammar from Section 5 of [HTTP]. Intermediaries that
do not perform any validation of fields other than the minimum do not perform any validation of fields other than the minimum
required by Section 8.2 could forward messages that contain invalid required by Section 8.2 could forward messages that contain invalid
field names or values. field names or values.
An intermediary that receives any field that requires removal before An intermediary that receives any field that requires removal before
forwarding (see Section 7.6.1 of [HTTP]) MUST remove or replace those forwarding (see Section 7.6.1 of [HTTP]) MUST remove or replace those
header fields when forwarding messages. Additionally, intermediaries header fields when forwarding messages. Additionally, intermediaries
skipping to change at page 75, line 46 skipping to change at page 76, line 33
Use of padding can result in less protection than might seem Use of padding can result in less protection than might seem
immediately obvious. At best, padding only makes it more difficult immediately obvious. At best, padding only makes it more difficult
for an attacker to infer length information by increasing the number for an attacker to infer length information by increasing the number
of frames an attacker has to observe. Incorrectly implemented of frames an attacker has to observe. Incorrectly implemented
padding schemes can be easily defeated. In particular, randomized padding schemes can be easily defeated. In particular, randomized
padding with a predictable distribution provides very little padding with a predictable distribution provides very little
protection; similarly, padding frame payloads to a fixed size exposes protection; similarly, padding frame payloads to a fixed size exposes
information as frame payload sizes cross the fixed-sized boundary, information as frame payload sizes cross the fixed-sized boundary,
which could be possible if an attacker can control plaintext. which could be possible if an attacker can control plaintext.
Intermediaries SHOULD retain padding for DATA frames but MAY drop Intermediaries SHOULD retain padding for DATA frames, but MAY drop
padding for HEADERS and PUSH_PROMISE frames. A valid reason for an padding for HEADERS and PUSH_PROMISE frames. A valid reason for an
intermediary to change the amount of padding of frames is to improve intermediary to change the amount of padding of frames is to improve
the protections that padding provides. the protections that padding provides.
10.8. Privacy Considerations 10.8. Privacy Considerations
Several characteristics of HTTP/2 provide an observer an opportunity Several characteristics of HTTP/2 provide an observer an opportunity
to correlate actions of a single client or server over time. These to correlate actions of a single client or server over time. These
include the value of settings, the manner in which flow-control include the value of settings, the manner in which flow-control
windows are managed, the way priorities are allocated to streams, the windows are managed, the way priorities are allocated to streams, the
skipping to change at page 77, line 49 skipping to change at page 78, line 34
Expected Version Tokens: None Expected Version Tokens: None
Reference: Section 3.1 of this document Reference: Section 3.1 of this document
12. References 12. References
12.1. Normative References 12.1. Normative References
[COMPRESSION] [COMPRESSION]
Peon, R. and H. Ruellan, "HPACK: Header Compression for Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, RFC 7541, DOI 10.17487/RFC7541, May HTTP/2", RFC 7541, DOI 10.17487/RFC7541, RFC 7541,
2015, <https://www.rfc-editor.org/rfc/rfc7541>. DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/rfc/rfc7541>.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, [TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, STD 7, RFC 793, DOI 10.17487/RFC0793, September RFC 793, DOI 10.17487/RFC793, STD 7, RFC 793,
1981, <https://www.rfc-editor.org/rfc/rfc793>. DOI 10.17487/RFC793, September 1981,
<https://www.rfc-editor.org/rfc/rfc793>.
[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre, [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, BCP 195, RFC 7525, (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, BCP 195,
DOI 10.17487/RFC7525, May 2015, RFC 7525, DOI 10.17487/RFC7525, May 2015,
<https://www.rfc-editor.org/rfc/rfc7525>. <https://www.rfc-editor.org/rfc/rfc7525>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>. <https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, STD 66, RFC 3986, DOI 10.17487/RFC3986, January RFC 3986, DOI 10.17487/RFC3986, STD 66, RFC 3986,
2005, <https://www.rfc-editor.org/rfc/rfc3986>. DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/rfc/rfc3986>.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, RFC 5246, (TLS) Protocol Version 1.2", RFC 5246,
DOI 10.17487/RFC5246, August 2008, DOI 10.17487/RFC5246, RFC 5246, DOI 10.17487/RFC5246,
<https://www.rfc-editor.org/rfc/rfc5246>. August 2008, <https://www.rfc-editor.org/rfc/rfc5246>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, RFC 8446, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, RFC 8446,
DOI 10.17487/RFC8446, August 2018, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/rfc/rfc8446>. <https://www.rfc-editor.org/rfc/rfc8446>.
[RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early [RFC8470] Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, RFC 8470, Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, RFC 8470,
DOI 10.17487/RFC8470, September 2018, DOI 10.17487/RFC8470, September 2018,
<https://www.rfc-editor.org/rfc/rfc8470>. <https://www.rfc-editor.org/rfc/rfc8470>.
[TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS) [TLS-EXT] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, RFC 6066, DOI 10.17487/RFC6066,
<https://www.rfc-editor.org/rfc/rfc6066>. January 2011, <https://www.rfc-editor.org/rfc/rfc6066>.
[TLS-ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan, [TLS-ALPN] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, RFC 7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
DOI 10.17487/RFC7301, July 2014, RFC 7301, DOI 10.17487/RFC7301, July 2014,
<https://www.rfc-editor.org/rfc/rfc7301>. <https://www.rfc-editor.org/rfc/rfc7301>.
[TLS-ECDHE] [TLS-ECDHE]
Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA- Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
RFC 5289, DOI 10.17487/RFC5289, August 2008, DOI 10.17487/RFC5289, RFC 5289, DOI 10.17487/RFC5289,
<https://www.rfc-editor.org/rfc/rfc5289>. August 2008, <https://www.rfc-editor.org/rfc/rfc5289>.
[FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4, [FIPS186] NIST, "Digital Signature Standard (DSS)",
FIPS PUB 186-4, July 2013, DOI 10.6028/NIST.FIPS.186-4, FIPS PUB 186-4, FIPS PUB
<http://dx.doi.org/10.6028/NIST.FIPS.186-4>. 186-4, DOI 10.6028/NIST.FIPS.186-4, July 2013,
<https://csrc.nist.gov/publications/detail/fips/186/4/
final>.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
RFC 6265, DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, RFC 6265, DOI 10.17487/RFC6265,
<https://www.rfc-editor.org/rfc/rfc6265>. April 2011, <https://www.rfc-editor.org/rfc/rfc6265>.
[HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", Work in Progress, Internet-Draft, Ed., "HTTP Semantics", Work in Progress, Internet-Draft,
draft-ietf-httpbis-semantics-18, Internet-Draft, draft- draft-ietf-httpbis-semantics-18, Internet-Draft, draft-
ietf-httpbis-semantics-18, August 18, 2021, ietf-httpbis-semantics-18, August 18, 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
semantics-18>. semantics-18>.
[CACHE] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [CACHE] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Caching", Work in Progress, Internet-Draft, Ed., "HTTP Caching", Work in Progress, Internet-Draft,
skipping to change at page 80, line 21 skipping to change at page 81, line 10
ietf-httpbis-messaging-18, Internet-Draft, draft-ietf- ietf-httpbis-messaging-18, Internet-Draft, draft-ietf-
httpbis-messaging-18, August 18, 2021, httpbis-messaging-18, August 18, 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
messaging-18>. messaging-18>.
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2", [RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, RFC 8441, RFC 8441, DOI 10.17487/RFC8441, RFC 8441,
DOI 10.17487/RFC8441, September 2018, DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/rfc/rfc8441>. <https://www.rfc-editor.org/rfc/rfc8441>.
[RFC1122] Braden, R., Ed., "Requirements for Internet Hosts -
Communication Layers", RFC 1122, DOI 10.17487/RFC1122,
RFC 1122, DOI 10.17487/RFC1122, October 1989,
<https://www.rfc-editor.org/rfc/rfc1122>.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, Ed., "TCP Extensions for High Performance", Scheffenegger, Ed., "TCP Extensions for High Performance",
RFC 7323, RFC 7323, DOI 10.17487/RFC7323, September 2014, RFC 7323, DOI 10.17487/RFC7323, RFC 7323,
DOI 10.17487/RFC7323, September 2014,
<https://www.rfc-editor.org/rfc/rfc7323>. <https://www.rfc-editor.org/rfc/rfc7323>.
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, RFC 3749, Compression Methods", RFC 3749, DOI 10.17487/RFC3749,
DOI 10.17487/RFC3749, May 2004, RFC 3749, DOI 10.17487/RFC3749, May 2004,
<https://www.rfc-editor.org/rfc/rfc3749>. <https://www.rfc-editor.org/rfc/rfc3749>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, RFC 6585, DOI 10.17487/RFC6585, April Codes", RFC 6585, DOI 10.17487/RFC6585, RFC 6585,
2012, <https://www.rfc-editor.org/rfc/rfc6585>. DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/rfc/rfc6585>.
[RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Curve Cryptography (ECC) Cipher Suites for Transport Layer Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", RFC 8422, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
RFC 8422, DOI 10.17487/RFC8422, August 2018, DOI 10.17487/RFC8422, RFC 8422, DOI 10.17487/RFC8422,
<https://www.rfc-editor.org/rfc/rfc8422>. August 2018, <https://www.rfc-editor.org/rfc/rfc8422>.
[PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [PRIVACY] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, RFC 6973, DOI 10.17487/RFC6973, July DOI 10.17487/RFC6973, RFC 6973, DOI 10.17487/RFC6973, July
2013, <https://www.rfc-editor.org/rfc/rfc6973>. 2013, <https://www.rfc-editor.org/rfc/rfc6973>.
[TALKING] Huang, L., Chen, E., Barth, A., Rescorla, E., and C. [TALKING] Huang, L., Chen, E., Barth, A., Rescorla, E., and C.
Jackson, "Talking to Yourself for Fun and Profit", 2011, Jackson, "Talking to Yourself for Fun and Profit", 2011,
<http://w2spconf.com/2011/papers/websocket.pdf>. <https://www.adambarth.com/papers/2011/huang-chen-barth-
rescorla-jackson.pdf>.
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
CRIME Attack", July 12, 2013, CRIME Attack", July 12, 2013,
<http://breachattack.com/resources/ <https://breachattack.com/resources/
BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>. BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, RFC 7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
DOI 10.17487/RFC7838, April 2016, RFC 7838, DOI 10.17487/RFC7838, April 2016,
<https://www.rfc-editor.org/rfc/rfc7838>. <https://www.rfc-editor.org/rfc/rfc7838>.
[DNS-TERMS] [DNS-TERMS]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019,
<https://www.rfc-editor.org/rfc/rfc8499>. <https://www.rfc-editor.org/rfc/rfc8499>.
[NFLX-2019-002] [NFLX-2019-002]
Netflix, "HTTP/2 Denial of Service Advisory", August 13, Netflix, "HTTP/2 Denial of Service Advisory", August 13,
skipping to change at page 87, line 35 skipping to change at page 88, line 30
o TLS_PSK_WITH_AES_256_CCM_8 o TLS_PSK_WITH_AES_256_CCM_8
| Note: This list was assembled from the set of registered TLS | Note: This list was assembled from the set of registered TLS
| cipher suites when [RFC7540] was developed. This list includes | cipher suites when [RFC7540] was developed. This list includes
| those cipher suites that do not offer an ephemeral key exchange | those cipher suites that do not offer an ephemeral key exchange
| and those that are based on the TLS null, stream, or block | and those that are based on the TLS null, stream, or block
| cipher type (as defined in Section 6.2.3 of [TLS12]). | cipher type (as defined in Section 6.2.3 of [TLS12]).
| Additional cipher suites with these properties could be | Additional cipher suites with these properties could be
| defined; these would not be explicitly prohibited. | defined; these would not be explicitly prohibited.
For more details, see Section 9.2.2
Appendix B. Changes from RFC 7540 Appendix B. Changes from RFC 7540
This revision includes a number of editorial updates, plus the This revision includes the following substantive changes:
following substantive changes:
o Use of TLS 1.3 was defined based on RFC 8740, which this document o Use of TLS 1.3 was defined based on RFC 8740, which this document
obsoletes. obsoletes.
o The priority scheme defined in RFC 7540 is deprecated. o The priority scheme defined in RFC 7540 is deprecated.
Definitions for the format of the PRIORITY frame and the priority Definitions for the format of the PRIORITY frame and the priority
fields in the HEADERS frame have been retained, plus the rules fields in the HEADERS frame have been retained, plus the rules
governing when PRIORITY frames can be sent and received, but the governing when PRIORITY frames can be sent and received, but the
semantics of these fields are only described in RFC 7540. The semantics of these fields are only described in RFC 7540. The
priority signaling scheme from RFC 7540 was not successful. Using priority signaling scheme from RFC 7540 was not successful. Using
the simpler successor signaling [I-D.ietf-httpbis-priority] is the simpler successor signaling [I-D.ietf-httpbis-priority] is
recommended. recommended.
o The HTTP/1.1 Upgrade mechanism is no longer specified in this o The HTTP/1.1 Upgrade mechanism is deprecated and no longer
document. It was never widely deployed, with plaintext HTTP/2 specified in this document. It was never widely deployed, with
users choosing to use the prior-knowledge implementation instead. plaintext HTTP/2 users choosing to use the prior-knowledge
implementation instead.
o Validation for field names and values has been narrowed. The o Validation for field names and values has been narrowed. The
validation that is mandatory for intermediaries is precisely validation that is mandatory for intermediaries is precisely
defined and error reporting for requests has been amended to defined and error reporting for requests has been amended to
encourage sending 400-series status codes. encourage sending 400-series status codes.
o The ranges of codepoints for settings and frame types that were o The ranges of codepoints for settings and frame types that were
reserved for "Experimental Use" are now available for general use. reserved for "Experimental Use" are now available for general use.
o Connection-specific header fields - which are prohibited - are o Connection-specific header fields - which are prohibited - are
more precisely and comprehensively identified. more precisely and comprehensively identified.
o Host and :authority are no longer permitted to disagree. o Host and :authority are no longer permitted to disagree.
Editorial changes are also included. In particular, changes to
terminology and document structure are in response to updates to core
HTTP semantics [HTTP].
Contributors Contributors
The previous version of this document was authored by Mike Belshe and The previous version of this document was authored by Mike Belshe and
Roberto Peon. Roberto Peon.
Acknowledgments Acknowledgments
Credit for non-trivial input to this document is owed to a large Credit for non-trivial input to this document is owed to a large
number of people who have contributed to the HTTP working group over number of people who have contributed to the HTTP working group over
the years. [RFC7540] contains a more extensive list of people that the years. [RFC7540] contains a more extensive list of people that
 End of changes. 96 change blocks. 
187 lines changed or deleted 234 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/