draft-ietf-httpbis-http2bis-03.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: January 13, 2022 July 12, 2021 Expires: March 17, 2022 September 13, 2021
Hypertext Transfer Protocol Version 2 (HTTP/2) Hypertext Transfer Protocol Version 2 (HTTP/2)
draft-ietf-httpbis-http2bis-latest 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 perception of latency by introducing header resources and a reduced latency by introducing field compression and
field compression and allowing multiple concurrent exchanges on the allowing multiple concurrent exchanges on the same connection.
same connection.
This specification is an alternative to, but does not obsolete, the
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
This document obsoletes RFC 7540 and RFC 8740. This document obsoletes RFC 7540 and RFC 8740.
Discussion Venues Discussion Venues
This note is to be removed before publishing as an RFC. This note is to be removed before publishing as an RFC.
Discussion of this document takes place on the HTTPBIS Working Group Discussion of this document takes place on the HTTPBIS Working Group
mailing list (ietf-http-wg@w3.org), which is archived at mailing list (ietf-http-wg@w3.org), which is archived at
<https://lists.w3.org/Archives/Public/ietf-http-wg/>. <https://lists.w3.org/Archives/Public/ietf-http-wg/>.
skipping to change at page 2, line 4 skipping to change at page 1, line 47
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 January 13, 2022.
This Internet-Draft will expire on March 17, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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
skipping to change at page 2, line 26 skipping to change at page 2, line 25
extracted from this document must include Simplified BSD License text extracted from this document must include Simplified BSD License text
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified 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 . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . 9
3.3. Starting HTTP/2 with Prior Knowledge . . . . . . . . . . 8 3.3. Starting HTTP/2 with Prior Knowledge . . . . . . . . . . 9
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 . . . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . 14
5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 19 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 20
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 19 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 20
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 20 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 21
5.2.1. Flow-Control Principles . . . . . . . . . . . . . . . 20 5.2.1. Flow-Control Principles . . . . . . . . . . . . . . . 21
5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 21 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 22
5.2.3. Flow Control Performance . . . . . . . . . . . . . . 22 5.2.3. Flow Control Performance . . . . . . . . . . . . . . 23
5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 22 5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. Background of Priority in HTTP/2 . . . . . . . . . . 22 5.3.1. Background of Priority in HTTP/2 . . . . . . . . . . 23
5.3.2. Priority Signaling in this Document . . . . . . . . . 23 5.3.2. Priority Signaling in this Document . . . . . . . . . 24
5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 23 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 24
5.4.1. Connection Error Handling . . . . . . . . . . . . . . 24 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 25
5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 25 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 26
5.4.3. Connection Termination . . . . . . . . . . . . . . . 25 5.4.3. Connection Termination . . . . . . . . . . . . . . . 26
5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 25 5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 26
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 26 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 27
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 28
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 28 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 29
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 32
6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 31 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 33
6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 32 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 34
6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 33 6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 35
6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . 34 6.5.2. Defined Settings . . . . . . . . . . . . . . . . . . 35
6.5.3. Settings Synchronization . . . . . . . . . . . . . . 36 6.5.3. Settings Synchronization . . . . . . . . . . . . . . 37
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 36 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 37
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 40
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 39 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 41
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 42 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 44
6.9.1. The Flow-Control Window . . . . . . . . . . . . . . . 44 6.9.1. The Flow-Control Window . . . . . . . . . . . . . . . 46
6.9.2. Initial Flow-Control Window Size . . . . . . . . . . 45 6.9.2. Initial Flow-Control Window Size . . . . . . . . . . 47
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 46 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 48
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 46 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 48
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 47 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49
8. Expressing HTTP Semantics in HTTP/2 . . . . . . . . . . . . . 48 8. Expressing HTTP Semantics in HTTP/2 . . . . . . . . . . . . . 50
8.1. HTTP Message Framing . . . . . . . . . . . . . . . . . . 49 8.1. HTTP Message Framing . . . . . . . . . . . . . . . . . . 50
8.1.1. Malformed Messages . . . . . . . . . . . . . . . . . 50 8.1.1. Malformed Messages . . . . . . . . . . . . . . . . . 52
8.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . . 51 8.2. HTTP Fields . . . . . . . . . . . . . . . . . . . . . . . 53
8.2.1. Field Validity . . . . . . . . . . . . . . . . . . . 51 8.2.1. Field Validity . . . . . . . . . . . . . . . . . . . 53
8.2.2. Connection-Specific Header Fields . . . . . . . . . . 52 8.2.2. Connection-Specific Header Fields . . . . . . . . . . 54
8.2.3. Compressing the Cookie Header Field . . . . . . . . . 53 8.2.3. Compressing the Cookie Header Field . . . . . . . . . 55
8.3. HTTP Control Data . . . . . . . . . . . . . . . . . . . . 53 8.3. HTTP Control Data . . . . . . . . . . . . . . . . . . . . 55
8.3.1. Request Pseudo-Header Fields . . . . . . . . . . . . 54 8.3.1. Request Pseudo-Header Fields . . . . . . . . . . . . 56
8.3.2. Response Pseudo-Header Fields . . . . . . . . . . . . 55 8.3.2. Response Pseudo-Header Fields . . . . . . . . . . . . 57
8.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 56 8.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 57
8.4.1. Push Requests . . . . . . . . . . . . . . . . . . . . 57 8.4.1. Push Requests . . . . . . . . . . . . . . . . . . . . 59
8.4.2. Push Responses . . . . . . . . . . . . . . . . . . . 58 8.4.2. Push Responses . . . . . . . . . . . . . . . . . . . 60
8.5. The CONNECT Method . . . . . . . . . . . . . . . . . . . 59 8.5. The CONNECT Method . . . . . . . . . . . . . . . . . . . 61
8.6. The Upgrade Header Field . . . . . . . . . . . . . . . . 60 8.6. The Upgrade Header Field . . . . . . . . . . . . . . . . 62
8.7. Request Reliability . . . . . . . . . . . . . . . . . . . 61 8.7. Request Reliability . . . . . . . . . . . . . . . . . . . 62
8.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 61 8.8. Examples . . . . . . . . . . . . . . . . . . . . . . . . 63
9. HTTP/2 Connections . . . . . . . . . . . . . . . . . . . . . 64 8.8.1. Simple Request . . . . . . . . . . . . . . . . . . . 63
9.1. Connection Management . . . . . . . . . . . . . . . . . . 64 8.8.2. Simple Response . . . . . . . . . . . . . . . . . . . 64
9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 65 8.8.3. Complex Request . . . . . . . . . . . . . . . . . . . 64
9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 66 8.8.4. Response with Body . . . . . . . . . . . . . . . . . 65
9.2.1. TLS 1.2 Features . . . . . . . . . . . . . . . . . . 66 8.8.5. Informational Responses . . . . . . . . . . . . . . . 65
9.2.2. TLS 1.2 Cipher Suites . . . . . . . . . . . . . . . . 67 9. HTTP/2 Connections . . . . . . . . . . . . . . . . . . . . . 66
9.2.3. TLS 1.3 Features . . . . . . . . . . . . . . . . . . 68 9.1. Connection Management . . . . . . . . . . . . . . . . . . 66
10. Security Considerations . . . . . . . . . . . . . . . . . . . 68 9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 67
10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 68 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 68
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 69 9.2.1. TLS 1.2 Features . . . . . . . . . . . . . . . . . . 68
10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 69 9.2.2. TLS 1.2 Cipher Suites . . . . . . . . . . . . . . . . 69
10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 70 9.2.3. TLS 1.3 Features . . . . . . . . . . . . . . . . . . 70
10.5. Denial-of-Service Considerations . . . . . . . . . . . . 70 10. Security Considerations . . . . . . . . . . . . . . . . . . . 70
10.5.1. Limits on Field Block Size . . . . . . . . . . . . . 72 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 70
10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 72 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 71
10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 72 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 71
10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 73 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 72
10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 74 10.5. Denial-of-Service Considerations . . . . . . . . . . . . 72
10.9. Remote Timing Attacks . . . . . . . . . . . . . . . . . 74 10.5.1. Limits on Field Block Size . . . . . . . . . . . . . 74
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 74
11.1. Registration of HTTP/2 Identification Strings . . . . . 75 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 74
11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 75 10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 75
11.3. Settings Registry . . . . . . . . . . . . . . . . . . . 76 10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 76
11.4. Error Code Registry . . . . . . . . . . . . . . . . . . 77 10.9. Remote Timing Attacks . . . . . . . . . . . . . . . . . 76
11.5. HTTP2-Settings Header Field Registration . . . . . . . . 78 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
11.6. PRI Method Registration . . . . . . . . . . . . . . . . 79 11.1. Registration of HTTP/2 Identification Strings . . . . . 77
11.7. The h2c Upgrade Token . . . . . . . . . . . . . . . . . 79 11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 77
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 79 11.3. Settings Registry . . . . . . . . . . . . . . . . . . . 78
12.1. Normative References . . . . . . . . . . . . . . . . . . 79 11.4. Error Code Registry . . . . . . . . . . . . . . . . . . 79
12.2. Informative References . . . . . . . . . . . . . . . . . 81 11.5. HTTP2-Settings Header Field Registration . . . . . . . . 80
Appendix A. Prohibited TLS 1.2 Cipher Suites . . . . . . . . . . 83 11.6. PRI Method Registration . . . . . . . . . . . . . . . . 81
Appendix B. Changes from RFC 7540 . . . . . . . . . . . . . . . 89 11.7. The h2c Upgrade Token . . . . . . . . . . . . . . . . . 81
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 89 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 81
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 90 12.1. Normative References . . . . . . . . . . . . . . . . . . 81
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90 12.2. Informative References . . . . . . . . . . . . . . . . . 83
Appendix A. Prohibited TLS 1.2 Cipher Suites . . . . . . . . . . 85
Appendix B. Changes from RFC 7540 . . . . . . . . . . . . . . . 91
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 92
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 92
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a wildly successful The performance of applications using the Hypertext Transfer Protocol
protocol. However, the way HTTP/1.1 uses the underlying transport (HTTP, [HTTP]) is linked to how each version of HTTP uses the
([HTTP11]) has several characteristics that have a negative overall underlying transport, and the conditions under which the transport
effect on application performance today. operates.
In particular, HTTP/1.0 allowed only one request to be outstanding at Making multiple concurrent requests can reduce latency and improve
a time on a given TCP connection. HTTP/1.1 added request pipelining, application performance. HTTP/1.0 allowed only one request to be
but this only partially addressed request concurrency and still outstanding at a time on a given TCP [TCP] connection. HTTP/1.1
suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 ([HTTP11]) added request pipelining, but this only partially
clients that need to make many requests use multiple connections to a addressed request concurrency and still suffers from application-
server in order to achieve concurrency and thereby reduce latency. layer head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1
clients use multiple connections to a server to make concurrent
requests.
Furthermore, HTTP header fields are often repetitive and verbose, Furthermore, HTTP fields are often repetitive and verbose, causing
causing unnecessary network traffic as well as causing the initial unnecessary network traffic as well as causing the initial TCP
TCP [TCP] congestion window to quickly fill. This can result in congestion window to quickly fill. This can result in excessive
excessive latency when multiple requests are made on a new TCP latency when multiple requests are made on a new TCP connection.
connection.
HTTP/2 addresses these issues by defining an optimized mapping of HTTP/2 addresses these issues by defining an optimized mapping of
HTTP's semantics to an underlying connection. Specifically, it HTTP's semantics to an underlying connection. Specifically, it
allows interleaving of request and response messages on the same allows interleaving of messages on the same connection and uses an
connection and uses an efficient coding for HTTP header fields. It efficient coding for HTTP fields. It also allows prioritization of
also allows prioritization of requests, letting more important requests, letting more important requests complete more quickly,
requests complete more quickly, further improving performance. further improving performance.
The resulting protocol is more friendly to the network because fewer The resulting protocol is more friendly to the network because fewer
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
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].
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
skipping to change at page 5, line 33 skipping to change at page 5, line 42
frames form the basis of HTTP requests and responses (Section 8.1); frames form the basis of HTTP requests and responses (Section 8.1);
other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are other frame types like SETTINGS, WINDOW_UPDATE, and PUSH_PROMISE are
used in support of other HTTP/2 features. used in support of other HTTP/2 features.
Multiplexing of requests is achieved by having each HTTP request/ Multiplexing of requests is achieved by having each HTTP request/
response exchange associated with its own stream (Section 5). response exchange associated with its own stream (Section 5).
Streams are largely independent of each other, so a blocked or Streams are largely independent of each other, so a blocked or
stalled request or response does not prevent progress on other stalled request or response does not prevent progress on other
streams. streams.
Flow control and prioritization ensure that it is possible to Effective use of multiplexing depends on flow control and
efficiently use multiplexed streams. Flow control (Section 5.2) prioritization. Flow control (Section 5.2) ensures that it is
helps to ensure that only data that can be used by a receiver is possible to efficiently use multiplexed streams by restricting data
transmitted. Prioritization (Section 5.3) ensures that limited that is transmitted to what the receiver is able to handle.
resources can be directed to the most important streams first. Prioritization (Section 5.3) ensures that limited resources are used
most effectively. This revision of HTTP/2 deprecates the priority
signaling scheme from [RFC7540].
Because HTTP header fields used in a connection can contain large Because HTTP fields used in a connection can contain large amounts of
amounts of redundant data, frames that contain them are compressed redundant data, frames that contain them are compressed
(Section 4.3). This has especially advantageous impact upon request (Section 4.3). This has especially advantageous impact upon request
sizes in the common case, allowing many requests to be compressed sizes in the common case, allowing many requests to be compressed
into one packet. into one packet.
Finally, HTTP/2 adds a new, optional interaction mode whereby a Finally, HTTP/2 adds a new, optional interaction mode whereby a
server can push responses to a client (Section 8.4). This is server can push responses to a client (Section 8.4). This is
intended to allow a server to speculatively send data to a client intended to allow a server to speculatively send data to a client
that the server anticipates the client will need, trading off some that the server anticipates the client will need, trading off some
network usage against a potential latency gain. The server does this network usage against a potential latency gain. The server does this
by synthesizing a request, which it sends as a PUSH_PROMISE frame. by synthesizing a request, which it sends as a PUSH_PROMISE frame.
skipping to change at page 6, line 31 skipping to change at page 6, line 46
streams. streams.
While some of the frame and stream layer concepts are isolated from While some of the frame and stream layer concepts are isolated from
HTTP, this specification does not define a completely generic frame HTTP, this specification does not define a completely generic frame
layer. The frame and stream layers are tailored to the needs of the layer. The frame and stream layers are tailored to the needs of the
HTTP protocol and server push. HTTP protocol and server push.
2.2. Conventions and Terminology 2.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in RFC 2119 [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
All numeric values are in network byte order. Values are unsigned All numeric values are in network byte order. Values are unsigned
unless otherwise indicated. Literal values are provided in decimal unless otherwise indicated. Literal values are provided in decimal
or hexadecimal as appropriate. Hexadecimal literals are prefixed or hexadecimal as appropriate. Hexadecimal literals are prefixed
with "0x" to distinguish them from decimal literals. with "0x" to distinguish them from decimal literals.
This specification describes binary formats using the convention This specification describes binary formats using the convention
described in RFC 9000 [QUIC]. described in RFC 9000 [QUIC]. Note that this format uses network
byte order and high-valued bits are listed before low-valued bits.
The following terms are used: The following terms are used:
client: The endpoint that initiates an HTTP/2 connection. Clients client: The endpoint that initiates an HTTP/2 connection. Clients
send HTTP requests and receive HTTP responses. send HTTP requests and receive HTTP responses.
connection: A transport-layer connection between two endpoints. connection: A transport-layer connection between two endpoints.
connection error: An error that affects the entire HTTP/2 connection error: An error that affects the entire HTTP/2
connection. connection.
skipping to change at page 8, line 7 skipping to change at page 8, line 26
which the client wishes to establish a connection) supports HTTP/2. which the client wishes to establish a connection) supports HTTP/2.
The means by which support for HTTP/2 is determined is different for The means by which support for HTTP/2 is determined is different for
"http" and "https" URIs. Discovery for "https" URIs is described in "http" and "https" URIs. Discovery for "https" URIs is described in
Section 3.2. HTTP/2 support for "http" URIs can only be discovered Section 3.2. HTTP/2 support for "http" URIs can only be discovered
by out-of-band means, and requires prior knowledge of the support as by out-of-band means, and requires prior knowledge of the support as
described in Section 3.3. described in Section 3.3.
3.1. HTTP/2 Version Identification 3.1. HTTP/2 Version Identification
The protocol defined in this document has two identifiers. The protocol defined in this document has two identifiers. Creating
a connection based on either implies the use of the transport,
framing, and message semantics described in this document.
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) [TLS13]. This identifier is used Transport Layer Security (TLS); see Section 9.2. This identifier
in the TLS application-layer protocol negotiation (ALPN) extension is used in the TLS application-layer protocol negotiation (ALPN)
[TLS-ALPN] field and in any place where HTTP/2 over TLS is extension [TLS-ALPN] field and in any place where HTTP/2 over TLS
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 string "h2c" identifies the protocol where HTTP/2 is run over
cleartext TCP. This identifier is used in any place where HTTP/2 cleartext TCP. This identifier is used in any place where HTTP/2
over TCP is identified. over TCP is identified.
The "h2c" string is reserved from the ALPN identifier space but The "h2c" string is reserved from the ALPN identifier space but
describes a protocol that does not use TLS. 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 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]). This usage was never widely deployed, and is no longer
specified in this document. specified in this document.
Negotiating "h2" or "h2c" implies the use of the transport, security,
framing, and message semantics described in 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
not use TLS. not use TLS.
Once TLS negotiation is complete, both the client and the server MUST Once TLS negotiation is complete, both the client and the server MUST
send a connection preface (Section 3.4). send a connection preface (Section 3.4).
3.3. Starting HTTP/2 with Prior Knowledge 3.3. Starting HTTP/2 with Prior Knowledge
A client can learn that a particular server supports HTTP/2 by other A client can learn that a particular server supports HTTP/2 by other
means. For example, [ALT-SVC] describes a mechanism for advertising means. For example, a client could be configured with knowledge that
this capability. a server supports HTTP/2.
A client MUST send the connection preface (Section 3.4) and then MAY A client that knows that a server supports HTTP/2 can establish a TCP
immediately send HTTP/2 frames to such a server; servers can identify connection and send the connection preface (Section 3.4) followed by
these connections by the presence of the connection preface. This HTTP/2 frames. Servers can identify these connections by the
only affects the establishment of HTTP/2 connections over cleartext presence of the connection preface. This only affects the
TCP; implementations that support HTTP/2 over TLS MUST use protocol establishment of HTTP/2 connections over cleartext TCP; HTTP/2
negotiation in TLS [TLS-ALPN]. connections over TLS MUST use protocol negotiation in TLS [TLS-ALPN].
Likewise, the server MUST send a connection preface (Section 3.4). Likewise, the server MUST send a connection preface (Section 3.4).
Without additional information, prior support for HTTP/2 is not a Without additional information, prior support for HTTP/2 is not a
strong signal that a given server will support HTTP/2 for future strong signal that a given server will support HTTP/2 for future
connections. For example, it is possible for server configurations connections. For example, it is possible for server configurations
to change, for configurations to differ between instances in to change, for configurations to differ between instances in
clustered servers, or for network conditions to change. clustered servers, or for network conditions to change.
3.4. HTTP/2 Connection Preface 3.4. HTTP/2 Connection Preface
skipping to change at page 11, line 11 skipping to change at page 11, line 36
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. Implementations MUST ignore format and semantics of the frame. 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.
Flags are assigned semantics specific to the indicated frame type. Flags are assigned semantics specific to the indicated frame type.
Unused Flags are those that have no defined semantics for a Unused flags are those that have no defined semantics for a
particular frame type, and MUST be ignored and MUST be left unset particular frame type, and MUST be ignored and MUST be left unset
(0x0) when sending. (0x0) when sending.
Reserved: A reserved 1-bit field. The semantics of this bit are Reserved: A reserved 1-bit field. The semantics of this bit are
undefined, and the bit MUST remain unset (0x0) when sending and undefined, and the bit MUST remain unset (0x0) when sending and
MUST be ignored when receiving. MUST be ignored when receiving.
Stream Identifier: A stream identifier (see Section 5.1.1) expressed Stream Identifier: A stream identifier (see Section 5.1.1) expressed
as an unsigned 31-bit integer. The value 0x0 is reserved for as an unsigned 31-bit integer. The value 0x0 is reserved for
frames that are associated with the connection as a whole as frames that are associated with the connection as a whole as
skipping to change at page 12, line 15 skipping to change at page 12, line 39
Endpoints are not obligated to use all available space in a frame. Endpoints are not obligated to use all available space in a frame.
Responsiveness can be improved by using frames that are smaller than Responsiveness can be improved by using frames that are smaller than
the permitted maximum size. Sending large frames can result in the permitted maximum size. Sending large frames can result in
delays in sending time-sensitive frames (such as RST_STREAM, delays in sending time-sensitive frames (such as RST_STREAM,
WINDOW_UPDATE, or PRIORITY), which, if blocked by the transmission of WINDOW_UPDATE, or PRIORITY), which, if blocked by the transmission of
a large frame, could affect performance. a large frame, could affect performance.
4.3. Field Section Compression and Decompression 4.3. Field Section Compression and Decompression
Field section compression is the process of compressing a set of Field section compression is the process of compressing a set of
field lines to form a field block. Field section decompression is field lines (Section 5.2 of [HTTP]) to form a field block. Field
the process of decoding a field block into a set of field lines. section decompression is the process of decoding a field block into a
Details of HTTP/2 field section compression and decompression is set of field lines. Details of HTTP/2 field section compression and
defined in [COMPRESSION], which, for historical reasons, refers to decompression is defined in [COMPRESSION], which, for historical
these processes as header compression and decompression. reasons, refers to these processes as header compression and
decompression.
Field blocks carry the compressed bytes of a field section, with Field blocks carry the compressed bytes of a field section, with
header sections also carrying control data associated with the header sections also carrying control data associated with the
message in the form of pseudo-header fields (Section 8.3) that use message in the form of pseudo-header fields (Section 8.3) that use
the same format as a field line. the same format as a field line.
| Note: Previous versions of this specification used the term | Note: RFC 7540 [RFC7540] used the term "header block" in place
| "header block" in place of the more generic "field block". | of the more generic "field block".
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 include contained in PUSH_PROMISE (Section 6.6) frames, can optionally
a field block that carries a trailer section. include a field block that carries a trailer section.
A field section is a collection of zero or more field lines. Each of A field section is a collection of field lines. Each of the field
the field lines in a field block carry a single value. The lines in a field block carry a single value. The serialized field
serialized field block is then divided into one or more octet block is then divided into one or more octet sequences, called field
sequences, called field block fragments, and transmitted within the block fragments, and transmitted within the frame payload of HEADERS
frame payload of HEADERS (Section 6.2) or PUSH_PROMISE (Section 6.6), (Section 6.2) or PUSH_PROMISE (Section 6.6), each of which could be
each of which could be followed by CONTINUATION (Section 6.10) followed by CONTINUATION (Section 6.10) frames.
frames.
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 13, line 49 skipping to change at page 14, line 29
o A single HTTP/2 connection can contain multiple concurrently open o A single HTTP/2 connection can contain multiple concurrently open
streams, with either endpoint interleaving frames from multiple streams, with either endpoint interleaving frames from multiple
streams. streams.
o Streams can be established and used unilaterally or shared by o Streams can be established and used unilaterally or shared by
either the client or server. either the client or server.
o Streams can be closed by either endpoint. o Streams can be closed by either endpoint.
o The order in which frames are sent on a stream is significant. o The order in which frames are sent is significant. Recipients
Recipients process frames in the order they are received. In process frames in the order they are received. In particular, the
particular, the order of HEADERS and DATA frames is semantically order of HEADERS and DATA frames is semantically significant.
significant.
o Streams are identified by an integer. Stream identifiers are o Streams are identified by an integer. Stream identifiers are
assigned to streams by the endpoint initiating the stream. assigned to streams by the endpoint initiating the stream.
5.1. Stream States 5.1. Stream States
The lifecycle of a stream is shown in Figure 2. The lifecycle of a stream is shown in Figure 2.
+--------+ +--------+
send PP | | recv PP send PP | | recv PP
skipping to change at page 14, line 41 skipping to change at page 15, line 34
| +----------+ | +----------+ | | +----------+ | +----------+ |
| | | | | | | | | |
| | send ES / | recv ES / | | | | send ES / | recv ES / | |
| | send R / v send R / | | | | send R / v send R / | |
| | recv R +--------+ recv R | | | | recv R +--------+ recv R | |
| send R / `----------->| |<-----------' send R / | | send R / `----------->| |<-----------' send R / |
| recv R | closed | recv R | | recv R | closed | recv R |
`----------------------->| |<----------------------' `----------------------->| |<----------------------'
+--------+ +--------+
send: endpoint sends this frame
recv: endpoint receives this frame
H: HEADERS frame (with implied CONTINUATIONs)
ES: END_STREAM flag
R: RST_STREAM frame
PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
Note: State transitions are for the promised stream.
Figure 2: Stream States Figure 2: Stream States
"send": endpoint sends this frame
"recv": endpoint receives this frame
"H": HEADERS frame (with implied CONTINUATION frames)
"ES": END_STREAM flag
"R": RST_STREAM frame
"PP": PUSH_PROMISE frame (with implied CONTINUATION frames); state
transitions are for the promised stream
Note that this diagram shows stream state transitions and the frames Note that this diagram shows stream state transitions and the frames
and flags that affect those transitions only. In this regard, and flags that affect those transitions only. In this regard,
CONTINUATION frames do not result in state transitions; they are CONTINUATION frames do not result in state transitions; they are
effectively part of the HEADERS or PUSH_PROMISE that they follow. effectively part of the HEADERS or PUSH_PROMISE that they follow.
For the purpose of state transitions, the END_STREAM flag is For the purpose of state transitions, the END_STREAM flag is
processed as a separate event to the frame that bears it; a HEADERS processed as a separate event to the frame that bears it; a HEADERS
frame with the END_STREAM flag set can cause two state transitions. frame with the END_STREAM flag set can cause two state transitions.
Both endpoints have a subjective view of the state of a stream that Both endpoints have a subjective view of the state of a stream that
could be different when frames are in transit. Endpoints do not could be different when frames are in transit. Endpoints do not
skipping to change at page 15, line 26 skipping to change at page 16, line 18
either endpoint. The negative consequences of a mismatch in states either endpoint. The negative consequences of a mismatch in states
are limited to the "closed" state after sending RST_STREAM, where are limited to the "closed" state after sending RST_STREAM, where
frames might be received for some time after closing. frames might be received for some time after closing.
Streams have the following states: Streams have the following states:
idle: All streams start in the "idle" state. idle: All streams start in the "idle" state.
The following transitions are valid from this state: The following transitions are valid from this state:
o Sending or receiving a HEADERS frame causes the stream to o Sending a HEADERS frame as a client, or receiving a HEADERS
become "open". The stream identifier is selected as described frame as a server, causes the stream to become "open". The
in Section 5.1.1. The same HEADERS frame can also cause a stream identifier is selected as described in Section 5.1.1.
stream to immediately become "half-closed". The same HEADERS frame can also cause a stream to immediately
become "half-closed".
o Sending a PUSH_PROMISE frame on another stream reserves the o Sending a PUSH_PROMISE frame on another stream reserves the
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 (local)". for the reserved stream transitions to "reserved (local)".
Only a server may send PUSH_PROMISE frames.
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.
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.
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. of type PROTOCOL_ERROR. If this stream is server-initiated, as
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
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
stream with an open stream that was initiated by the remote peer stream with an open stream that was initiated by the remote peer
(see Section 8.4). (see Section 8.4).
In this state, only the following transitions are possible: In this state, only the following transitions are possible:
o The endpoint can send a HEADERS frame. This causes the stream o The endpoint can send a HEADERS frame. This causes the stream
skipping to change at page 17, line 9 skipping to change at page 18, line 7
(local)"; an endpoint receiving an END_STREAM flag causes the (local)"; an endpoint receiving an END_STREAM flag causes the
stream state to become "half-closed (remote)". stream state to become "half-closed (remote)".
Either endpoint can send a RST_STREAM frame from this state, Either endpoint can send a RST_STREAM frame from this state,
causing it to transition immediately to "closed". causing it to transition immediately to "closed".
half-closed (local): A stream that is in the "half-closed (local)" half-closed (local): A stream that is in the "half-closed (local)"
state cannot be used for sending frames other than WINDOW_UPDATE, state cannot be used for sending frames other than WINDOW_UPDATE,
PRIORITY, and RST_STREAM. PRIORITY, and RST_STREAM.
A stream transitions from this state to "closed" when a frame that A stream transitions from this state to "closed" when a frame is
contains an END_STREAM flag is received or when either peer sends received with the END_STREAM flag set or when either peer sends a
a RST_STREAM frame. RST_STREAM frame.
An endpoint can receive any type of frame in this state. An endpoint can receive any type of frame in this state.
Providing flow-control credit using WINDOW_UPDATE frames is Providing flow-control credit using WINDOW_UPDATE frames is
necessary to continue receiving flow-controlled frames. In this necessary to continue receiving flow-controlled frames. In this
state, a receiver can ignore WINDOW_UPDATE frames, which might state, a receiver can ignore WINDOW_UPDATE frames, which might
arrive for a short period after a frame bearing the END_STREAM arrive for a short period after a frame with the END_STREAM flag
flag is sent. set is sent.
PRIORITY frames can be received in this state. PRIORITY frames can be received in this state.
half-closed (remote): A stream that is "half-closed (remote)" is no half-closed (remote): A stream that is "half-closed (remote)" is no
longer being used by the peer to send frames. In this state, an longer being used by the peer to send frames. In this state, an
endpoint is no longer obligated to maintain a receiver flow- endpoint is no longer obligated to maintain a receiver flow-
control window. control window.
If an endpoint receives additional frames, other than If an endpoint receives additional frames, other than
WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in WINDOW_UPDATE, PRIORITY, or RST_STREAM, for a stream that is in
this state, it MUST respond with a stream error (Section 5.4.2) of this state, it MUST respond with a stream error (Section 5.4.2) of
type STREAM_CLOSED. type STREAM_CLOSED.
A stream that is "half-closed (remote)" can be used by the A stream that is "half-closed (remote)" can be used by the
endpoint to send frames of any type. In this state, the endpoint endpoint to send frames of any type. In this state, the endpoint
continues to observe advertised stream-level flow-control limits continues to observe advertised stream-level flow-control limits
(Section 5.2). (Section 5.2).
A stream can transition from this state to "closed" by sending a A stream can transition from this state to "closed" by sending a
frame that contains an END_STREAM flag or when either peer sends a frame with the END_STREAM flag set or when either peer sends a
RST_STREAM frame. RST_STREAM frame.
closed: The "closed" state is the terminal state. closed: The "closed" state is the terminal state.
An stream enters the "closed" state after an endpoint both sends A stream enters the "closed" state after an endpoint both sends
and receives a frame with an END_STREAM flag set. A stream also and receives a frame with an END_STREAM flag set. A stream also
enters the "closed" state after an endpoint either sends or enters the "closed" state after an endpoint either sends or
receives a RST_STREAM frame. receives a RST_STREAM frame.
An endpoint MUST NOT send frames other than PRIORITY on a closed An endpoint MUST NOT send frames other than PRIORITY on a closed
stream. An endpoint MAY treat receipt of any other type of frame stream. An endpoint MAY treat receipt of any other type of frame
on a "closed" stream as a connection error (Section 5.4.1) of type on a closed stream as a connection error (Section 5.4.1) of type
STREAM_CLOSED, except as noted below. STREAM_CLOSED, except as noted below.
An endpoint that sends a frame with the END_STREAM flag set or a An endpoint that sends a frame with the END_STREAM flag set or a
RST_STREAM frame might receive a WINDOW_UPDATE or RST_STREAM frame RST_STREAM frame might receive a WINDOW_UPDATE or RST_STREAM frame
from its peer in the time before the peer receives and processes from its peer in the time before the peer receives and processes
the frame that closes the stream. the frame that closes the stream.
An endpoint that sends a RST_STREAM frame on a stream that is in An endpoint that sends a RST_STREAM frame on a stream that is in
the "open" state could receive any type of frame. The peer might the "open" state could receive any type of frame. The peer might
have sent or enqueued for sending these frames before processing have sent or enqueued for sending these frames before processing
the RST_STREAM frame. An endpoint MUST minimally process and then the RST_STREAM frame. An endpoint MUST minimally process and then
discard any frames it receives in this state. This means updating discard any frames it receives in this state. This means updating
header compression state for HEADERS and PUSH_PROMISE frames; header compression state for HEADERS and PUSH_PROMISE frames;
PUSH_PROMISE frames also cause the promised stream to become PUSH_PROMISE frames also cause the promised stream to become
"reserved", even when the PUSH_PROMISE frame is received on a "reserved", even when the PUSH_PROMISE frame is received on a
closed stream; and, the content of DATA frames counts toward the closed stream; and, the content of DATA frames counts toward the
connection flow-control window. connection flow-control window.
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 stream to detect that a peer has received the frames that caused the
to become "closed" and treat receipt of any frame other than stream to enter the "closed" state and treat receipt of any frame
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 acknowledgement 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 guidance elsewhere in this document, In the absence of more specific rules, implementations SHOULD treat
implementations SHOULD treat the receipt of a frame that is not the receipt of a frame that is not expressly permitted in the
expressly permitted in the description of a state as a connection description of a state as a connection error (Section 5.4.1) of type
error (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can PROTOCOL_ERROR. Note that PRIORITY can be sent and received in any
be sent and received in any stream state. Frames of unknown types stream state.
are ignored.
The rules in this section only apply to frames defined in this
document. Receipt of frames for which the semantics are unknown
cannot be treated as an error as the conditions for sending and
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 with 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
skipping to change at page 20, line 13 skipping to change at page 21, line 13
endpoint is permitted to open. Streams in any of these three states endpoint is permitted to open. Streams in any of these three states
count toward the limit advertised in the count toward the limit advertised in the
SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the SETTINGS_MAX_CONCURRENT_STREAMS setting. Streams in either of the
"reserved" states do not count toward the stream limit. "reserved" states do not count toward the stream limit.
Endpoints MUST NOT exceed the limit set by their peer. An endpoint Endpoints MUST NOT exceed the limit set by their peer. An endpoint
that receives a HEADERS frame that causes its advertised concurrent that receives a HEADERS frame that causes its advertised concurrent
stream limit to be exceeded MUST treat this as a stream error stream limit to be exceeded MUST treat this as a stream error
(Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. The choice (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. The choice
of error code determines whether the endpoint wishes to enable of error code determines whether the endpoint wishes to enable
automatic retry (see Section 8.7) for details). automatic retry (see Section 8.7 for details).
An endpoint that wishes to reduce the value of An endpoint that wishes to reduce the value of
SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current SETTINGS_MAX_CONCURRENT_STREAMS to a value that is below the current
number of open streams can either close streams that exceed the new number of open streams can either close streams that exceed the new
value or allow streams to complete. value or allow streams to complete.
5.2. Flow Control 5.2. Flow Control
Using streams for multiplexing introduces contention over use of the Using streams for multiplexing introduces contention over use of the
TCP connection, resulting in blocked streams. A flow-control scheme TCP connection, resulting in blocked streams. A flow-control scheme
skipping to change at page 25, line 33 skipping to change at page 26, line 33
for any stream. However, an endpoint MAY send additional RST_STREAM for any stream. However, an endpoint MAY send additional RST_STREAM
frames if it receives frames on a closed stream after more than a frames if it receives frames on a closed stream after more than a
round-trip time. This behavior is permitted to deal with misbehaving round-trip time. This behavior is permitted to deal with misbehaving
implementations. implementations.
To avoid looping, an endpoint MUST NOT send a RST_STREAM in response To avoid looping, an endpoint MUST NOT send a RST_STREAM in response
to a RST_STREAM frame. to a RST_STREAM frame.
5.4.3. Connection Termination 5.4.3. Connection Termination
If the TCP connection is closed or reset while streams remain in If the TCP connection is closed or reset while streams remain in the
"open" or "half-closed" state, then the affected streams cannot be "open" or "half-closed" states, then the affected streams cannot be
automatically retried (see Section 8.7 for details). automatically retried (see Section 8.7 for details).
5.5. Extending HTTP/2 5.5. Extending HTTP/2
HTTP/2 permits extension of the protocol. Within the limitations HTTP/2 permits extension of the protocol. Within the limitations
described in this section, protocol extensions can be used to provide described in this section, protocol extensions can be used to provide
additional services or alter any aspect of the protocol. Extensions additional services or alter any aspect of the protocol. Extensions
are effective only within the scope of a single HTTP/2 connection. are effective only within the scope of a single HTTP/2 connection.
This applies to the protocol elements defined in this document. This This applies to the protocol elements defined in this document. This
does not affect the existing options for extending HTTP, such as does not affect the existing options for extending HTTP, such as
defining new methods, status codes, or fields (see Section 16 of defining new methods, status codes, or fields (see Section 16 of
[HTTP]). [HTTP]).
Extensions are permitted to use new frame types (Section 4.1), new Extensions are permitted to use new frame types (Section 4.1), new
settings (Section 6.5.2), or new error codes (Section 7). Registries settings (Section 6.5), or new error codes (Section 7). Registries
are established for managing these extension points: frame types are established for managing these extension points: frame types
(Section 11.2), settings (Section 11.3), and error codes (Section 11.2), settings (Section 11.3), and error codes
(Section 11.4). (Section 11.4).
Implementations MUST ignore unknown or unsupported values in all Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements. Implementations MUST discard frames extensible protocol elements. Implementations MUST discard frames
that have unknown or unsupported types. This means that any of these that have unknown or unsupported types. This means that any of these
extension points can be safely used by extensions without prior extension points can be safely used by extensions without prior
arrangement or negotiation. However, extension frames that appear in arrangement or negotiation. However, extension frames that appear in
the middle of a field block (Section 4.3) are not permitted; these the middle of a field block (Section 4.3) are not permitted; these
MUST be treated as a connection error (Section 5.4.1) of type MUST be treated as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
Extensions SHOULD avoiding changing protocol elements defined in this Extensions SHOULD avoid changing protocol elements defined in this
document or elements for which no extension mechanism is defined. document or elements for which no extension mechanism is defined.
This includes changes to the layout of frames, additions or changes This includes changes to the layout of frames, additions or changes
to the way that frames are composed into HTTP messages (Section 8.1), to the way that frames are composed into HTTP messages (Section 8.1),
the definition of pseudo-header fields, or changes to any protocol the definition of pseudo-header fields, or changes to any protocol
element that a compliant endpoint might treat as a connection error element that a compliant endpoint might treat as a connection error
(Section 5.4.1). (Section 5.4.1).
An extension that changes existing elements MUST be negotiated before An extension that changes existing elements MUST be negotiated before
being used. For example, an extension that changes the layout of the being used. For example, an extension that changes the layout of the
HEADERS frame cannot be used until the peer has given a positive HEADERS frame cannot be used until the peer has given a positive
skipping to change at page 27, line 10 skipping to change at page 28, line 10
This specification defines a number of frame types, each identified This specification defines a number of frame types, each identified
by a unique 8-bit type code. Each frame type serves a distinct by a unique 8-bit type code. Each frame type serves a distinct
purpose in the establishment and management either of the connection purpose in the establishment and management either of the connection
as a whole or of individual streams. as a whole or of individual streams.
The transmission of specific frame types can alter the state of a The transmission of specific frame types can alter the state of a
connection. If endpoints fail to maintain a synchronized view of the connection. If endpoints fail to maintain a synchronized view of the
connection state, successful communication within the connection will connection state, successful communication within the connection will
no longer be possible. Therefore, it is important that endpoints no longer be possible. Therefore, it is important that endpoints
have a shared comprehension of how the state is affected by the use have a shared comprehension of how the state is affected by the use
any given frame. of any given frame.
6.1. DATA 6.1. DATA
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.
skipping to change at page 27, line 25 skipping to change at page 28, line 25
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) = 0,
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 (..),
} }
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 (as padding in units of octets. This field is conditional and is only
signified by a "?" in the diagram) and is only present if the present if the PADDED flag is set.
PADDED flag is set.
Data: Application data. The amount of data is the remainder of the Data: Application data. The amount of data is the remainder of the
frame payload after subtracting the length of the other fields frame payload after subtracting the length of the other fields
that are present. that are present.
Padding: Padding octets that contain no application semantic value. Padding: Padding octets that contain no application semantic value.
Padding octets MUST be set to zero when sending. A receiver is Padding octets MUST be set to zero when sending. A receiver is
not obligated to verify padding but MAY treat non-zero padding as not obligated to verify padding but MAY treat non-zero padding as
a connection error (Section 5.4.1) of type PROTOCOL_ERROR. a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
The DATA frame defines the following flags: The DATA frame defines the following flags:
PADDED (0x8): When set, the PADDED Flag indicates that the Pad PADDED (0x8): When set, the PADDED flag indicates that the Pad
Length field and any padding that it describes are present. Length field and any padding that it describes are present.
END_STREAM (0x1): When set, the END_STREAM Flag indicates that this END_STREAM (0x1): When set, the END_STREAM flag indicates that this
frame is the last that the endpoint will send for the identified frame is the last that the endpoint will send for the identified
stream. Setting this flag causes the stream to enter one of the stream. Setting this flag causes the stream to enter one of the
"half-closed" states or the "closed" state (Section 5.1). "half-closed" states or the "closed" state (Section 5.1).
DATA frames MUST be associated with a stream. If a DATA frame is DATA frames MUST be associated with a stream. If a DATA frame is
received whose stream identifier field is 0x0, the recipient MUST received whose stream identifier field is 0x0, the recipient MUST
respond with a connection error (Section 5.4.1) of type respond with a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
DATA frames are subject to flow control and can only be sent when a DATA frames are subject to flow control and can only be sent when a
skipping to change at page 29, line 46 skipping to change at page 30, line 49
PRIORITY flag is set. PRIORITY flag is set.
Stream Dependency: A 31-bit stream identifier. This field is only Stream Dependency: A 31-bit stream identifier. This field is only
present if the PRIORITY flag is set. present if the PRIORITY flag is set.
Weight: An unsigned 8-bit integer. This field is only present if Weight: An unsigned 8-bit integer. This field is only present if
the PRIORITY flag is set. the PRIORITY flag is set.
Field Block Fragment: A field block fragment (Section 4.3). Field Block Fragment: A field block fragment (Section 4.3).
Padding: Padding octets. Padding: Padding octets that contain no application semantic value.
Padding octets MUST be set to zero when sending. A receiver is
not obligated to verify padding but MAY treat non-zero padding as
a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
The HEADERS frame defines the following flags: The HEADERS frame defines the following flags:
PRIORITY (0x20): When set, the PRIORITY Flag indicates that the PRIORITY (0x20): When set, the PRIORITY flag indicates that the
Exclusive, Stream Dependency, and Weight fields are present. Exclusive, Stream Dependency, and Weight fields are present.
PADDED (0x8): When set, the PADDED Flag indicates that the Pad PADDED (0x8): When set, the PADDED flag indicates that the Pad
Length field and any padding that it describes are present. Length field and any padding that it describes are present.
END_HEADERS (0x4): When set, the END_HEADERS Flag indicates that END_HEADERS (0x4): When set, the END_HEADERS flag indicates that
this frame contains an entire field block (Section 4.3) and is not this frame contains an entire field block (Section 4.3) and is not
followed by any CONTINUATION frames. followed by any CONTINUATION frames.
A HEADERS frame without the END_HEADERS flag set MUST be followed A HEADERS frame without the END_HEADERS flag set MUST be followed
by a CONTINUATION frame for the same stream. A receiver MUST by a CONTINUATION frame for the same stream. A receiver MUST
treat the receipt of any other type of frame or a frame on a treat the receipt of any other type of frame or a frame on a
different stream as a connection error (Section 5.4.1) of type different stream as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
END_STREAM (0x1): When set, the END_STREAM Flag indicates that the END_STREAM (0x1): When set, the END_STREAM flag indicates that the
field block (Section 4.3) is the last that the endpoint will send field block (Section 4.3) is the last that the endpoint will send
for the identified stream. for the identified stream.
A HEADERS frame carries the END_STREAM flag that signals the end A HEADERS frame with the END_STREAM flag set signals the end of a
of a stream. However, a HEADERS frame with the END_STREAM flag stream. However, a HEADERS frame with the END_STREAM flag set can
set can be followed by CONTINUATION frames on the same stream. be followed by CONTINUATION frames on the same stream. Logically,
Logically, the CONTINUATION frames are part of the HEADERS frame. the CONTINUATION frames are part of the HEADERS frame.
The frame payload of a HEADERS frame contains a field block fragment The frame payload of a HEADERS frame contains a field block fragment
(Section 4.3). A field block that does not fit within a HEADERS (Section 4.3). A field block that does not fit within a HEADERS
frame is continued in a CONTINUATION frame (Section 6.10). frame is continued in a CONTINUATION frame (Section 6.10).
HEADERS frames MUST be associated with a stream. If a HEADERS frame HEADERS frames MUST be associated with a stream. If a HEADERS frame
is received whose stream identifier field is 0x0, the recipient MUST is received whose stream identifier field is 0x0, the recipient MUST
respond with a connection error (Section 5.4.1) of type respond with a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
The HEADERS frame changes the connection state as described in The HEADERS frame changes the connection state as described in
Section 4.3. Section 4.3.
The HEADERS frame can include padding. Padding fields and flags are The total number of padding octets is determined by the value of the
identical to those defined for DATA frames (Section 6.1). Padding Pad Length field. If the length of the padding is the length of the
that exceeds the size remaining for the field block fragment MUST be frame payload or greater, the recipient MUST treat this as a
treated as a PROTOCOL_ERROR. connection error (Section 5.4.1) of type PROTOCOL_ERROR.
| Note: A frame can be increased in size by one octet by
| including a Pad Length field with a value of zero.
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),
Type (8) = 2, Type (8) = 2,
skipping to change at page 33, line 26 skipping to change at page 34, line 34
Each parameter in a SETTINGS frame replaces any existing value for Each parameter in a SETTINGS frame replaces any existing value for
that parameter. Settings are processed in the order in which they that parameter. Settings are processed in the order in which they
appear, and a receiver of a SETTINGS frame does not need to maintain appear, and a receiver of a SETTINGS frame does not need to maintain
any state other than the current value of each setting. Therefore, any state other than the current value of each setting. Therefore,
the value of a SETTINGS parameter is the last value that is seen by a the value of a SETTINGS parameter is the last value that is seen by a
receiver. receiver.
SETTINGS frames are acknowledged by the receiving peer. To enable SETTINGS frames are acknowledged by the receiving peer. To enable
this, the SETTINGS frame defines the ACK flag: this, the SETTINGS frame defines the ACK flag:
ACK (0x1): When set, the ACK Flag indicates that this frame ACK (0x1): When set, the ACK flag indicates that this frame
acknowledges receipt and application of the peer's SETTINGS frame. acknowledges receipt and application of the peer's SETTINGS frame.
When this bit is set, the frame payload of the SETTINGS frame MUST When this bit is set, the frame payload of the SETTINGS frame MUST
be empty. Receipt of a SETTINGS frame with the ACK flag set and a be empty. Receipt of a SETTINGS frame with the ACK flag set and a
length field value other than 0 MUST be treated as a connection length field value other than 0 MUST be treated as a connection
error (Section 5.4.1) of type FRAME_SIZE_ERROR. For more error (Section 5.4.1) of type FRAME_SIZE_ERROR. For more
information, see Section 6.5.3 ("Settings Synchronization"). information, see Section 6.5.3 ("Settings Synchronization").
SETTINGS frames always apply to a connection, never a single stream. SETTINGS frames always apply to a connection, never a single stream.
The stream identifier for a SETTINGS frame MUST be zero (0x0). If an The stream identifier for a SETTINGS frame MUST be zero (0x0). If an
endpoint receives a SETTINGS frame whose stream identifier field is endpoint receives a SETTINGS frame whose stream identifier field is
skipping to change at page 34, line 8 skipping to change at page 35, line 18
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) = 4,
Unused Flags (7), Unused Flags (7),
ACK Flag (1), ACK Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
Setting (..) ...,
Setting (48) ...,
} }
Setting { Setting {
Identifier (16), Identifier (16),
Value (32), Value (32),
} }
Figure 7: SETTINGS Frame Format Figure 7: SETTINGS Frame Format
6.5.2. Defined Settings 6.5.2. Defined Settings
skipping to change at page 36, line 37 skipping to change at page 38, line 8
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) = 5,
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 (..),
} }
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
PADDED flag is set. PADDED flag is set.
R: A single reserved bit. Reserved: A single reserved bit.
Promised Stream ID: An unsigned 31-bit integer that identifies the Promised Stream ID: An unsigned 31-bit integer that identifies the
stream that is reserved by the PUSH_PROMISE. The promised stream stream that is reserved by the PUSH_PROMISE. The promised stream
identifier MUST be a valid choice for the next stream sent by the identifier MUST be a valid choice for the next stream sent by the
sender (see "new stream identifier" in Section 5.1.1). sender (see "new stream identifier" in Section 5.1.1).
Field Block Fragment: A field block fragment (Section 4.3) Field Block Fragment: A field block fragment (Section 4.3)
containing request control data and header section. containing request control data and header section.
Padding: Padding octets. Padding: Padding octets that contain no application semantic value.
Padding octets MUST be set to zero when sending. A receiver is
not obligated to verify padding but MAY treat non-zero padding as
a connection error (Section 5.4.1) of type PROTOCOL_ERROR.
The PUSH_PROMISE frame defines the following flags: The PUSH_PROMISE frame defines the following flags:
PADDED (0x8): When set, the PADDED Flag indicates that the Pad PADDED (0x8): When set, the PADDED flag indicates that the Pad
Length field and any padding that it describes are present. Length field and any padding that it describes are present.
END_HEADERS (0x4): When set, the END_HEADERS Flag indicates that END_HEADERS (0x4): When set, the END_HEADERS flag indicates that
this frame contains an entire field block (Section 4.3) and is not this frame contains an entire field block (Section 4.3) and is not
followed by any CONTINUATION frames. followed by any CONTINUATION frames.
A PUSH_PROMISE frame without the END_HEADERS flag set MUST be A PUSH_PROMISE frame without the END_HEADERS flag set MUST be
followed by a CONTINUATION frame for the same stream. A receiver followed by a CONTINUATION frame for the same stream. A receiver
MUST treat the receipt of any other type of frame or a frame on a MUST treat the receipt of any other type of frame or a frame on a
different stream as a connection error (Section 5.4.1) of type different stream as a connection error (Section 5.4.1) of type
PROTOCOL_ERROR. PROTOCOL_ERROR.
PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that PUSH_PROMISE frames MUST only be sent on a peer-initiated stream that
skipping to change at page 38, line 40 skipping to change at page 40, line 20
has sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE has sent RST_STREAM on the associated stream MUST handle PUSH_PROMISE
frames that might have been created before the RST_STREAM frame is frames that might have been created before the RST_STREAM frame is
received and processed. received and processed.
A receiver MUST treat the receipt of a PUSH_PROMISE that promises an A receiver MUST treat the receipt of a PUSH_PROMISE that promises an
illegal stream identifier (Section 5.1.1) as a connection error illegal stream identifier (Section 5.1.1) as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. Note that an illegal stream (Section 5.4.1) of type PROTOCOL_ERROR. Note that an illegal stream
identifier is an identifier for a stream that is not currently in the identifier is an identifier for a stream that is not currently in the
"idle" state. "idle" state.
The PUSH_PROMISE frame can include padding. Padding fields and flags The total number of padding octets is determined by the value of the
are identical to those defined for DATA frames (Section 6.1). Pad Length field. If the length of the padding is the length of the
frame payload or greater, the recipient MUST treat this as a
connection error (Section 5.4.1) of type PROTOCOL_ERROR.
| Note: A frame can be increased in size by one octet by
| including a Pad Length field with a value of zero.
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),
skipping to change at page 39, line 8 skipping to change at page 40, line 38
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),
Type (8) = 6, Type (8) = 6,
Unused Flags (7), Unused Flags (7),
ACK Flag (1), ACK Flag (1),
Reserved (1), Reserved (1),
Stream Identifier (31), Stream Identifier (31),
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
a PING frame with the ACK flag set in response, with an identical a PING frame with the ACK flag set in response, with an identical
frame payload. PING responses SHOULD be given higher priority than frame payload. PING responses SHOULD be given higher priority than
any other frame. any other frame.
The PING frame defines the following flags: The PING frame defines the following flags:
ACK (0x1): When set, the ACK Flag indicates that this PING frame is ACK (0x1): When set, the ACK flag indicates that this PING frame is
a PING response. An endpoint MUST set this flag in PING a PING response. An endpoint MUST set this flag in PING
responses. An endpoint MUST NOT respond to PING frames containing responses. An endpoint MUST NOT respond to PING frames containing
this flag. this flag.
PING frames are not associated with any individual stream. If a PING PING frames are not associated with any individual stream. If a PING
frame is received with a stream identifier field value other than frame is received with a stream identifier field value other than
0x0, the recipient MUST respond with a connection error 0x0, the recipient MUST respond with a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
Receipt of a PING frame with a length field value other than 8 MUST Receipt of a PING frame with a length field value other than 8 MUST
skipping to change at page 43, line 46 skipping to change at page 45, line 40
The WINDOW_UPDATE frame can be specific to a stream or to the entire The WINDOW_UPDATE frame can be specific to a stream or to the entire
connection. In the former case, the frame's stream identifier connection. In the former case, the frame's stream identifier
indicates the affected stream; in the latter, the value "0" indicates indicates the affected stream; in the latter, the value "0" indicates
that the entire connection is the subject of the frame. that the entire connection is the subject of the frame.
A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an A receiver MUST treat the receipt of a WINDOW_UPDATE frame with an
flow-control window increment of 0 as a stream error (Section 5.4.2) flow-control window increment of 0 as a stream error (Section 5.4.2)
of type PROTOCOL_ERROR; errors on the connection flow-control window of type PROTOCOL_ERROR; errors on the connection flow-control window
MUST be treated as a connection error (Section 5.4.1). MUST be treated as a connection error (Section 5.4.1).
WINDOW_UPDATE can be sent by a peer that has sent a frame bearing the WINDOW_UPDATE can be sent by a peer that has sent a frame with the
END_STREAM flag. This means that a receiver could receive a END_STREAM flag set. This means that a receiver could receive a
WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream. WINDOW_UPDATE frame on a "half-closed (remote)" or "closed" stream.
A receiver MUST NOT treat this as an error (see Section 5.1). A receiver MUST NOT treat this as an error (see Section 5.1).
A receiver that receives a flow-controlled frame MUST always account A receiver that receives a flow-controlled frame MUST always account
for its contribution against the connection flow-control window, for its contribution against the connection flow-control window,
unless the receiver treats this as a connection error unless the receiver treats this as a connection error
(Section 5.4.1). This is necessary even if the frame is in error. (Section 5.4.1). This is necessary even if the frame is in error.
The sender counts the frame toward the flow-control window, but if The sender counts the frame toward the flow-control window, but if
the receiver does not, the flow-control window at the sender and the receiver does not, the flow-control window at the sender and
receiver can become different. receiver can become different.
skipping to change at page 46, line 46 skipping to change at page 48, line 33
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) = 9,
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 (..),
} }
Figure 12: CONTINUATION Frame Format Figure 12: CONTINUATION 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 CONTINUATION frame payload fields are described in Section 4. The CONTINUATION frame payload
contains a field block fragment (Section 4.3). contains a field block fragment (Section 4.3).
The CONTINUATION frame defines the following flag: The CONTINUATION frame defines the following flag:
END_HEADERS (0x4): When set, the END_HEADERS Flag indicates that END_HEADERS (0x4): When set, the END_HEADERS flag indicates that
this frame ends a field block (Section 4.3). this frame ends a field block (Section 4.3).
If the END_HEADERS Flag is not set, this frame MUST be followed by If the END_HEADERS flag is not set, this frame MUST be followed by
another CONTINUATION frame. A receiver MUST treat the receipt of another CONTINUATION frame. A receiver MUST treat the receipt of
any other type of frame or a frame on a different stream as a any other type of frame or a frame on a different stream as a
connection error (Section 5.4.1) of type PROTOCOL_ERROR. connection error (Section 5.4.1) of type PROTOCOL_ERROR.
The CONTINUATION frame changes the connection state as defined in The CONTINUATION frame changes the connection state as defined in
Section 4.3. Section 4.3.
CONTINUATION frames MUST be associated with a stream. If a CONTINUATION frames MUST be associated with a stream. If a
CONTINUATION frame is received whose stream identifier field is 0x0, CONTINUATION frame is received whose stream identifier field is 0x0,
the recipient MUST respond with a connection error (Section 5.4.1) of the recipient MUST respond with a connection error (Section 5.4.1) of
skipping to change at page 49, line 19 skipping to change at page 51, line 8
response on the same stream as the request. response on the same stream as the request.
An HTTP message (request or response) consists of: An HTTP message (request or response) consists of:
1. one HEADERS frame (followed by zero or more CONTINUATION frames) 1. one HEADERS frame (followed by zero or more CONTINUATION frames)
containing the header section (see Section 6.3 of [HTTP]), containing the header section (see Section 6.3 of [HTTP]),
2. zero or more DATA frames containing the message content (see 2. zero or more DATA frames containing the message content (see
Section 6.4 of [HTTP]), and Section 6.4 of [HTTP]), and
3. optionally, one HEADERS frame, followed by zero or more 3. optionally, one HEADERS frame (followed by zero or more
CONTINUATION frames containing the trailer-part, if present (see CONTINUATION frames) containing the trailer section, if present
Section 6.5 of [HTTP]). (see Section 6.5 of [HTTP]).
For a response only, a server MAY send any number of interim For a response only, a server MAY send any number of interim
responses before the HEADERS frame containing a final response. An responses before the HEADERS frame containing a final response. An
interim response consists of a HEADERS frames (which might be interim response consists of a HEADERS frame (which might be followed
followed by zero or more CONTINUATION frames) containing the control by zero or more CONTINUATION frames) containing the control data and
data and header section of an interim (1xx) HTTP response (see header section of an interim (1xx) HTTP response (see Section 15 of
Section 15 of [HTTP]). A HEADERS frame with an END_STREAM flag that [HTTP]). A HEADERS frame with the END_STREAM flag set that carries
carries an informational status code is malformed (Section 8.1.1). an informational status code is malformed (Section 8.1.1).
The last frame in the sequence bears an END_STREAM flag, noting that The last frame in the sequence bears an END_STREAM flag, noting that
a HEADERS frame bearing the END_STREAM flag can be followed by a HEADERS frame with the END_STREAM flag set can be followed by
CONTINUATION frames that carry any remaining fragments of the field CONTINUATION frames that carry any remaining fragments of the field
block. block.
Other frames (from any stream) MUST NOT occur between the HEADERS Other frames (from any stream) MUST NOT occur between the HEADERS
frame and any CONTINUATION frames that might follow. frame and any CONTINUATION frames that might follow.
HTTP/2 uses DATA frames to carry message content. The "chunked" HTTP/2 uses DATA frames to carry message content. The "chunked"
transfer encoding defined in Section 7.1 of [HTTP11] cannot be used transfer encoding defined in Section 7.1 of [HTTP11] cannot be used
in HTTP/2. in HTTP/2; see Section 8.2.2.
Trailer fields are carried in a field block that also terminates the Trailer fields are carried in a field block that also terminates the
stream. That is, trailer fields comprise a sequence starting with a stream. That is, trailer fields comprise a sequence starting with a
HEADERS frame, followed by zero or more CONTINUATION frames, where HEADERS frame, followed by zero or more CONTINUATION frames, where
the HEADERS frame bears an END_STREAM flag. Trailers MUST NOT the HEADERS frame bears an END_STREAM flag. Trailers MUST NOT
include pseudo-header fields (Section 8.3). An endpoint that include pseudo-header fields (Section 8.3). An endpoint that
receives pseudo-header fields in trailers MUST treat the request or receives pseudo-header fields in trailers MUST treat the request or
response as malformed (Section 8.1.1). response as malformed (Section 8.1.1).
An endpoint that receives a HEADERS frame without the END_STREAM flag An endpoint that receives a HEADERS frame without the END_STREAM flag
set after receiving the HEADERS frame that opens a request or after set after receiving the HEADERS frame that opens a request or after
receiving a final (non-informational) status code MUST treat the receiving a final (non-informational) status code MUST treat the
corresponding request or response as malformed (Section 8.1.1). corresponding request or response as malformed (Section 8.1.1).
An HTTP request/response exchange fully consumes a single stream. A An HTTP request/response exchange fully consumes a single stream. A
request starts with the HEADERS frame that puts the stream into an request starts with the HEADERS frame that puts the stream into the
"open" state. The request ends with a frame bearing END_STREAM, "open" state. The request ends with a frame with the END_STREAM flag
which causes the stream to become "half-closed (local)" for the set, which causes the stream to become "half-closed (local)" for the
client and "half-closed (remote)" for the server. A response stream client and "half-closed (remote)" for the server. A response stream
starts with zero or more interim responses in HEADERS frames or a starts with zero or more interim responses in HEADERS frames,
HEADERS frame containing a final status code. followed by a HEADERS frame containing a final status code.
An HTTP response is complete after the server sends -- or the client An HTTP response is complete after the server sends -- or the client
receives -- a frame with the END_STREAM flag set (including any receives -- a frame with the END_STREAM flag set (including any
CONTINUATION frames needed to complete a field block). A server can CONTINUATION frames needed to complete a field block). A server can
send a complete response prior to the client sending an entire send a complete response prior to the client sending an entire
request if the response does not depend on any portion of the request request if the response does not depend on any portion of the request
that has not been sent and received. When this is true, a server MAY that has not been sent and received. When this is true, a server MAY
request that the client abort transmission of a request without error request that the client abort transmission of a request without error
by sending a RST_STREAM with an error code of NO_ERROR after sending by sending a RST_STREAM with an error code of NO_ERROR after sending
a complete response (i.e., a frame with the END_STREAM flag). a complete response (i.e., a frame with the END_STREAM flag set).
Clients MUST NOT discard responses as a result of receiving such a Clients MUST NOT discard responses as a result of receiving such a
RST_STREAM, though clients can always discard responses at their RST_STREAM, though clients can always discard responses at their
discretion for other reasons. discretion for other reasons.
8.1.1. Malformed Messages 8.1.1. Malformed Messages
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 fields or pseudo-header fields, the inclusion of absence of mandatory pseudo-header fields, the inclusion of uppercase
uppercase field names, or invalid field names and/or values (in field names, or invalid field names and/or values (in certain
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 "content-length" header field. A request or response is also
malformed if the value of a "content-length" header field does not malformed if the value of a "content-length" header field does not
equal the sum of the DATA frame payload lengths that form the equal the sum of the DATA frame payload lengths that form the
content. A response that is defined to have no content, as described content. A response that is defined to have no content, as described
in Section 6.4 of [HTTP], can have a non-zero "content-length" header in Section 6.4 of [HTTP], can have a non-zero "content-length" header
field, even though no content is included in DATA frames. 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
skipping to change at page 51, line 31 skipping to change at page 53, line 18
These requirements are intended to protect against several types of These requirements are intended to protect against several types of
common attacks against HTTP; they are deliberately strict because common attacks against HTTP; they are deliberately strict because
being permissive can expose implementations to these vulnerabilities. being permissive can expose implementations to these vulnerabilities.
8.2. HTTP Fields 8.2. HTTP Fields
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].
To improve efficiency and interoperability, field names MUST be Field names MUST be converted to lowercase when constructing an
converted to lowercase when constructing an HTTP/2 message. HTTP/2 message.
8.2.1. Field Validity 8.2.1. Field Validity
HPACK is capable of carrying field names or values that are not valid The definitions of field names and values in HTTP prohibits some
in HTTP. Though HPACK can carry any octet, fields are not valid in characters that HPACK might be able to convey. HTTP/2
the following cases: implementations SHOULD validate field names and values according to
their definitions in Sections Section 5.1 of [HTTP] and Section 5.5
of [HTTP] of [HTTP] respectively and treat messages that contain
prohibited characters as malformed (Section 8.1.1).
Failure to validate fields can be exploited for request smuggling
attacks. In particular, unvalidated fields might enable attacks when
messages are forwarded using HTTP 1.1 [HTTP11], where characters such
as CR, LF, and COLON are used as delimiters. Implementations MUST
perform the following minimal validation of field names and values:
o A field name MUST NOT contain characters in the ranges 0x00-0x20, o A field name MUST NOT contain characters in the ranges 0x00-0x20,
0x41-0x5A, or 0x7F-0xFF (all ranges inclusive). This limits field 0x41-0x5a, or 0x7f-0xff (all ranges inclusive). This specifically
names to visible ASCII characters, other than ASCII SP (0x20) and excludes all non-visible ASCII characters, ASCII SP (0x20), and
uppercase characters ('A' to 'Z', ASCII 0x41 to 0x5a). uppercase characters ('A' to 'Z', ASCII 0x41 to 0x5a).
o With the exception of pseudo-header fields (Section 8.3), which o With the exception of pseudo-header fields (Section 8.3), which
have a name that starts with a single colon, field names MUST NOT have a name that starts with a single colon, field names MUST NOT
include a colon (ASCII COLON, 0x3a). include a colon (ASCII COLON, 0x3a).
o A field value MUST NOT contain the zero value (ASCII NUL, 0x0), o A field value MUST NOT contain the zero value (ASCII NUL, 0x0),
line feed (ASCII LF, 0xa), or carriage return (ASCII CR, 0xd) at line feed (ASCII LF, 0xa), or carriage return (ASCII CR, 0xd) at
any position. any position.
o A field value MUST NOT start or end with an ASCII whitespace o A field value MUST NOT start or end with an ASCII whitespace
character (ASCII SP or HTAB, 0x20 or 0x9). character (ASCII SP or HTAB, 0x20 or 0x9).
| Note: An implementation that validates fields according the
| definitions in Sections Section 5.1 of [HTTP] and Section 5.5
| of [HTTP] of [HTTP] only needs an additional check that field
| names do not include uppercase 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.
A recipient MAY treat a message that contains a field name or value When a request message violates one of these requirements, an
that includes other characters disallowed by Section 5.1 of [HTTP] implementation SHOULD generate a 400 (Bad Request) status code
and Section 5.5 of [HTTP] as malformed (Section 8.1.1). [HTTP], unless a more suitable status code is defined or the status
code cannot be sent (e.g., because the error occurs in a trailer
When a request message violates one of the requirements above, it field).
SHOULD be responded to using the 400 (Bad Request) status code
Section 15.5.1 of [HTTP] before the stream is reset, unless a more
suitable status code is defined, or the status code cannot be sent
(e.g., because the error occurs in a trailer field).
Note that field values that are not valid according to the definition | Note: Field values that are not valid according to the
of the corresponding field do not cause a request to be malformed; | definition of the corresponding field do not cause a request to
the requirements above only apply to the generic syntax for field | be malformed; the requirements above only apply to the generic
values as defined in Section 5.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
protocol, connection-specific metadata is conveyed by other means. protocol, connection-specific metadata is conveyed by other means.
An endpoint MUST NOT generate an HTTP/2 message containing An endpoint MUST NOT generate an HTTP/2 message containing
connection-specific header fields; any message containing connection- connection-specific header fields. This includes the "Connection"
specific header fields MUST be treated as malformed (Section 8.1.1). header field and those listed as having connection-specific semantics
in Section 7.6.1 of [HTTP] (that is, "Proxy-Connection", "Keep-
Alive", "Transfer-Encoding", and "Upgrade"). Any message containing
connection-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 a HTTP/1.x message to HTTP/2 MUST remove
connection-specific header fields as discussed in Section 7.6.1 of connection-specific header fields as discussed in Section 7.6.1 of
[HTTP], or their messages will be treated by other HTTP/2 endpoints [HTTP], or their messages will be treated by other HTTP/2 endpoints
as malformed (Section 8.1.1). as malformed (Section 8.1.1).
skipping to change at page 53, line 19 skipping to change at page 55, line 19
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
decompression, these MUST be concatenated into a single octet string decompression, these MUST be concatenated into a single octet string
using the two-octet delimiter of 0x3B, 0x20 (the ASCII string "; ") using the two-octet delimiter of 0x3b, 0x20 (the ASCII string "; ")
before being passed into a non-HTTP/2 context, such as an HTTP/1.1 before being passed into a non-HTTP/2 context, such as an HTTP/1.1
connection, or a generic HTTP server application. connection, or a generic HTTP server application.
Therefore, the following two lists of Cookie header fields are Therefore, the following two lists of Cookie header fields are
semantically equivalent. semantically equivalent.
cookie: a=b; c=d; e=f cookie: a=b; c=d; e=f
cookie: a=b cookie: a=b
cookie: c=d cookie: c=d
skipping to change at page 54, line 10 skipping to change at page 56, line 10
appear in requests. Pseudo-header fields MUST NOT appear in a appear in requests. Pseudo-header fields MUST NOT appear in a
trailer section. Endpoints MUST treat a request or response that trailer section. Endpoints MUST treat a request or response that
contains undefined or invalid pseudo-header fields as malformed contains undefined or invalid pseudo-header fields as malformed
(Section 8.1.1). (Section 8.1.1).
All pseudo-header fields MUST appear in a field block before all All pseudo-header fields MUST appear in a field block before all
regular field lines. Any request or response that contains a pseudo- regular field lines. Any request or response that contains a pseudo-
header field that appears in a field block after a regular field line header field that appears in a field block after a regular field line
MUST be treated as malformed (Section 8.1.1). MUST be treated as malformed (Section 8.1.1).
The same pseudo-header field name MUST NOT appear more than once in a
field block. A field block for an HTTP request or response that
contains a repeated pseudo-header field name MUST be treated as
malformed (Section 8.1.1).
8.3.1. Request Pseudo-Header Fields 8.3.1. Request Pseudo-Header Fields
The following pseudo-header fields are defined for HTTP/2 requests: The following pseudo-header fields are defined for HTTP/2 requests:
o The ":method" pseudo-header field includes the HTTP method o The ":method" pseudo-header field includes the HTTP method
(Section 9 of [HTTP]). (Section 9 of [HTTP]).
o The ":scheme" pseudo-header field includes the scheme portion of o The ":scheme" pseudo-header field includes the scheme portion of
the request target. The scheme is taken from the target URI the request target. The scheme is taken from the target URI
(Section 3.1 of [RFC3986]) when generating a request directly, or (Section 3.1 of [RFC3986]) when generating a request directly, or
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 ":scheme" is not restricted to "http" and "https" schemed URIs. A
proxy or gateway can translate requests for non-HTTP schemes, proxy or gateway can translate requests for non-HTTP schemes,
enabling the use of HTTP to interact with non-HTTP services. enabling the use of HTTP to interact with non-HTTP services.
o The ":authority" pseudo-header field includes the authority o The ":authority" pseudo-header field conveys the authority portion
portion of the target URI (Section 3.2 of [RFC3986]). The (Section 3.2 of [RFC3986]) of the target URI (Section 7.1 of
authority MUST NOT include the deprecated "userinfo" subcomponent [HTTP]). The recipient of a HTTP/2 request MUST ignore the "Host"
for "http" or "https" schemed URIs. header field if ":authority" is present.
Clients that generate HTTP/2 requests directly SHOULD use the Clients that generate HTTP/2 requests directly MUST use the
":authority" pseudo-header field instead of the "Host" header ":authority" pseudo-header field to convey authority information,
field. unless there is no authority information to convey (in which case
it MUST NOT generate :authority).
An intermediary that translates a request to HTTP/2 from another An intermediary that forwards a request over HTTP/2 MUST construct
HTTP version MUST translate any authority information from the an ":authority" pseudo-header field using the authority
request into an ":authority" pseudo-header field. If the control information from the control data of the original request, unless
data in the original request contains authority information, an the the original request's target URI does not contain authority
intermediary MUST include a ":authority" pseudo-header field. If information (in which case it MUST NOT generate ":authority").
control data does not contain authority, an intermediary MUST NOT Note that the Host header field is not the sole source of this
add an ":authority" pseudo-header field. For reference, an information; see Section 7.2 of [HTTP].
HTTP/1.1 request target [HTTP11] in authority-form always includes
authority, a request target in absolute-form includes authority if
the target URI includes authority, and request targets in origin-
or asterisk-form do not include authority.
An intermediary that translates a request to another HTTP version An intermediary that forwards a request over HTTP/2 MUST retain
from HTTP/2 can construct a "Host" header field by copying the any "Host" header field.
value of the ":authority" pseudo-header field if that version
requires that "Host" be included in a request, as HTTP/1.1 does
for some forms of request target (see Section 3.2 of [HTTP11]).
An intermediary that translates a request to HTTP/2 from another Note that request targets for CONNECT or asterisk-form OPTIONS
HTTP version MUST retain any "Host" header field, even if an requests never include authority information.
authority is part of control data.
The value of the "Host" header field MUST be ignored if control ":authority" MUST NOT include the deprecated userinfo subcomponent
data contains authority (that is, the ":authority" pseudo-header for "http" or "https" schemed URIs.
field is present).
o The ":path" pseudo-header field includes the path and query parts o The ":path" pseudo-header field includes the path and query parts
of the target URI (the "path-absolute" production and optionally a of the target URI (the "absolute-path" production and optionally a
'?' character followed by the "query" production (see Sections 3.3 '?' character followed by the "query" production; see Section 4.1
and 3.4 of [RFC3986]). A request in asterisk form includes the of [HTTP]). A request in asterisk form (for OPTIONS) includes the
value '*' for the ":path" pseudo-header field. value '*' for the ":path" pseudo-header field.
This pseudo-header field MUST NOT be empty for "http" or "https" This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'. The exception to this rule is an MUST include a value of '/'. The exceptions to this rule are:
OPTIONS request for an "http" or "https" URI that does not include
a path component; these MUST include a ":path" pseudo-header field * an OPTIONS request for an "http" or "https" URI that does not
with a value of '*' (see Section 7.1 of [HTTP]). include a path component; these MUST include a ":path" pseudo-
header field with a value of '*' (see Section 7.1 of [HTTP])
* CONNECT requests (Section 8.5), where the ":path" pseudo-header
field is omitted.
All HTTP/2 requests MUST include exactly one valid value for the All HTTP/2 requests MUST include exactly one valid value for the
":method", ":scheme", and ":path" pseudo-header fields, unless it is ":method", ":scheme", and ":path" pseudo-header fields, unless it is
a CONNECT request (Section 8.5). An HTTP request that omits a CONNECT request (Section 8.5). An HTTP request that omits
mandatory pseudo-header fields is malformed (Section 8.1.1). mandatory pseudo-header fields is malformed (Section 8.1.1).
Individual HTTP/2 requests do not carry an explicit indicator of Individual HTTP/2 requests do not carry an explicit indicator of
protocol version. All HTTP/2 messages implicitly have a protocol protocol version. All HTTP/2 requests implicitly have a protocol
version of "2.0" (see Section 6.2 of [HTTP]). version of "2.0" (see Section 6.2 of [HTTP]).
8.3.2. Response Pseudo-Header Fields 8.3.2. Response Pseudo-Header Fields
For HTTP/2 responses, a single ":status" pseudo-header field is For HTTP/2 responses, a single ":status" pseudo-header field is
defined that carries the HTTP status code field (see Section 15 of defined that carries the HTTP status code field (see Section 15 of
[HTTP]). This pseudo-header field MUST be included in all responses, [HTTP]). This pseudo-header field MUST be included in all responses,
including interim responses; otherwise, the response is malformed including interim responses; otherwise, the response is malformed
(Section 8.1.1). (Section 8.1.1).
skipping to change at page 56, line 46 skipping to change at page 58, line 40
or that indicates the presence of request content MUST reset the or that indicates the presence of request content MUST reset the
promised stream with a stream error (Section 5.4.2) of type promised stream with a stream error (Section 5.4.2) of type
PROTOCOL_ERROR. Note this could result in the promised stream being PROTOCOL_ERROR. Note this could result in the promised stream being
reset if the client does not recognize a newly defined method as reset if the client does not recognize a newly defined method as
being safe. being safe.
Pushed responses that are cacheable (see Section 3 of [CACHE]) can be Pushed responses that are cacheable (see Section 3 of [CACHE]) can be
stored by the client, if it implements an HTTP cache. Pushed stored by the client, if it implements an HTTP cache. Pushed
responses are considered successfully validated on the origin server responses are considered successfully validated on the origin server
(e.g., if the "no-cache" cache response directive is present; see (e.g., if the "no-cache" cache response directive is present; see
Section 5.2.2.3 of [CACHE]) while the stream identified by the Section 5.2.2.4 of [CACHE]) while the stream identified by the
promised stream ID is still open. promised stream ID is still open.
Pushed responses that are not cacheable MUST NOT be stored by any Pushed responses that are not cacheable MUST NOT be stored by any
HTTP cache. They MAY be made available to the application HTTP cache. They MAY be made available to the application
separately. separately.
The server MUST include a value in the ":authority" pseudo-header The server MUST include a value in the ":authority" pseudo-header
field for which the server is authoritative (see Section 10.1). A field for which the server is authoritative (see Section 10.1). A
client MUST treat a PUSH_PROMISE for which the server is not client MUST treat a PUSH_PROMISE for which the server is not
authoritative as a stream error (Section 5.4.2) of type authoritative as a stream error (Section 5.4.2) of type
skipping to change at page 58, line 11 skipping to change at page 60, line 4
sending any frames that reference the promised responses. This sending any frames that reference the promised responses. This
avoids a race where clients issue requests prior to receiving any avoids a race where clients issue requests prior to receiving any
PUSH_PROMISE frames. PUSH_PROMISE frames.
For example, if the server receives a request for a document For example, if the server receives a request for a document
containing embedded links to multiple image files and the server containing embedded links to multiple image files and the server
chooses to push those additional images to the client, sending chooses to push those additional images to the client, sending
PUSH_PROMISE frames before the DATA frames that contain the image PUSH_PROMISE frames before the DATA frames that contain the image
links ensures that the client is able to see that a resource will be links ensures that the client is able to see that a resource will be
pushed before discovering embedded links. Similarly, if the server pushed before discovering embedded links. Similarly, if the server
pushes responses referenced by the field block (for instance, in Link pushes resources referenced by the field block (for instance, in Link
header fields), sending a PUSH_PROMISE before sending the header header fields), sending a PUSH_PROMISE before sending the header
ensures that clients do not request those resources. ensures that clients do not request those resources.
PUSH_PROMISE frames MUST NOT be sent by the client. PUSH_PROMISE frames MUST NOT be sent by the client.
PUSH_PROMISE frames can be sent by the server in response to any PUSH_PROMISE frames can be sent by the server on any client-initiated
client-initiated stream, but the stream MUST be in either the "open" stream, but the stream MUST be in either the "open" or "half-closed
or "half-closed (remote)" state with respect to the server. (remote)" state with respect to the server. PUSH_PROMISE frames are
PUSH_PROMISE frames are interspersed with the frames that comprise a interspersed with the frames that comprise a response, though they
response, though they cannot be interspersed with HEADERS and cannot be interspersed with HEADERS and CONTINUATION frames that
CONTINUATION frames that comprise a single field block. comprise a single field block.
Sending a PUSH_PROMISE frame creates a new stream and puts the stream Sending a PUSH_PROMISE frame creates a new stream and puts the stream
into the "reserved (local)" state for the server and the "reserved into the "reserved (local)" state for the server and the "reserved
(remote)" state for the client. (remote)" state for the client.
8.4.2. Push Responses 8.4.2. Push Responses
After sending the PUSH_PROMISE frame, the server can begin delivering After sending the PUSH_PROMISE frame, the server can begin delivering
the pushed response as a response (Section 8.3.2) on a server- the pushed response as a response (Section 8.3.2) on a server-
initiated stream that uses the promised stream identifier. The initiated stream that uses the promised stream identifier. The
skipping to change at page 59, line 23 skipping to change at page 61, line 11
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, a server that offers a certificate for only the
"example.com" DNS-ID is not permitted to push a response for "example.com" 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)"
state for the server and "half-closed (local)" state for the client, state for the server and "half-closed (local)" state for the client,
and ends with a frame bearing END_STREAM, which places the stream in and ends with a frame with the END_STREAM flag set, which places the
the "closed" state. stream in the "closed" state.
| Note: The client never sends a frame with the END_STREAM flag | Note: The client never sends a frame with the END_STREAM flag
| for a server push. | set for a server push.
8.5. The CONNECT Method 8.5. The CONNECT Method
The CONNECT method (Section 9.3.6 of [HTTP]) is used to convert an The CONNECT method (Section 9.3.6 of [HTTP]) is used to convert an
HTTP connection into a tunnel to a remote host. CONNECT is primarily HTTP connection into a tunnel to a remote host. CONNECT is primarily
used with HTTP proxies to establish a TLS session with an origin used with HTTP proxies to establish a TLS session with an origin
server for the purposes of interacting with "https" resources. server for the purposes of interacting with "https" resources.
In HTTP/2, the CONNECT method establishes a tunnel over a single In HTTP/2, the CONNECT method establishes a tunnel over a single
HTTP/2 stream to a remote host, rather than converting the entire HTTP/2 stream to a remote host, rather than converting the entire
skipping to change at page 60, line 23 skipping to change at page 62, line 11
payload of any DATA frames sent by the client is transmitted by the payload of any DATA frames sent by the client is transmitted by the
proxy to the TCP server; data received from the TCP server is proxy to the TCP server; data received from the TCP server is
assembled into DATA frames by the proxy. Frame types other than DATA assembled into DATA frames by the proxy. Frame types other than DATA
or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY) or stream management frames (RST_STREAM, WINDOW_UPDATE, and PRIORITY)
MUST NOT be sent on a connected stream and MUST be treated as a MUST NOT be sent on a connected stream and MUST be treated as a
stream error (Section 5.4.2) if received. stream error (Section 5.4.2) if received.
The TCP connection can be closed by either peer. The END_STREAM flag The TCP connection can be closed by either peer. The END_STREAM flag
on a DATA frame is treated as being equivalent to the TCP FIN bit. A on a DATA frame is treated as being equivalent to the TCP FIN bit. A
client is expected to send a DATA frame with the END_STREAM flag set client is expected to send a DATA frame with the END_STREAM flag set
after receiving a frame bearing the END_STREAM flag. A proxy that after receiving a frame with the END_STREAM flag set. A proxy that
receives a DATA frame with the END_STREAM flag set sends the attached receives a DATA frame with the END_STREAM flag set sends the attached
data with the FIN bit set on the last TCP segment. A proxy that data with the FIN bit set on the last TCP segment. A proxy that
receives a TCP segment with the FIN bit set sends a DATA frame with receives a TCP segment with the FIN bit set sends a DATA frame with
the END_STREAM flag set. Note that the final TCP segment or DATA the END_STREAM flag set. Note that the final TCP segment or DATA
frame could be empty. frame could be empty.
A TCP connection error is signaled with RST_STREAM. A proxy treats A TCP connection error is signaled with RST_STREAM. A proxy treats
any error in the TCP connection, which includes receiving a TCP any error in the TCP connection, which includes receiving a TCP
segment with the RST bit set, as a stream error (Section 5.4.2) of segment with the RST bit set, as a stream error (Section 5.4.2) of
type CONNECT_ERROR. Correspondingly, a proxy MUST send a TCP segment type CONNECT_ERROR. Correspondingly, a proxy MUST send a TCP segment
with the RST bit set if it detects an error with the stream or the with the RST bit set if it detects an error with the stream or the
HTTP/2 connection. HTTP/2 connection.
8.6. The Upgrade Header Field 8.6. The Upgrade Header Field
HTTP/2 does not support the 101 (Switching Protocols) informational HTTP/2 does not support the 101 (Switching Protocols) informational
status code (Section 15.2.2 of [HTTP]). status code (Section 15.2.2 of [HTTP]).
The semantics of 101 (Switching Protocols) aren't applicable to a The semantics of 101 (Switching Protocols) aren't applicable to a
multiplexed protocol. Alternative protocols are able to use the same multiplexed protocol. Similar functionality might be enabled through
mechanisms that HTTP/2 uses to negotiate their use (see Section 3). the use of extended CONNECT [RFC8441] and other protocols are able to
use the same mechanisms that HTTP/2 uses to negotiate their use (see
Section 3).
8.7. Request Reliability 8.7. Request Reliability
In general, an HTTP client is unable to retry a non-idempotent In general, an HTTP client is unable to retry a non-idempotent
request when an error occurs because there is no means to determine request when an error occurs because there is no means to determine
the nature of the error (see Section 9.2.2 of [HTTP]). It is the nature of the error (see Section 9.2.2 of [HTTP]). It is
possible that some server processing occurred prior to the error, possible that some server processing occurred prior to the error,
which could result in undesirable effects if the request were which could result in undesirable effects if the request were
reattempted. reattempted.
skipping to change at page 62, line 5 skipping to change at page 63, line 32
become broken as some middleboxes (for instance, network address become broken as some middleboxes (for instance, network address
translators or load balancers) silently discard connection bindings. translators or load balancers) silently discard connection bindings.
The PING frame allows a client to safely test whether a connection is The PING frame allows a client to safely test whether a connection is
still active without sending a request. still active without sending a request.
8.8. Examples 8.8. Examples
This section shows HTTP/1.1 requests and responses, with This section shows HTTP/1.1 requests and responses, with
illustrations of equivalent HTTP/2 requests and responses. illustrations of equivalent HTTP/2 requests and responses.
8.8.1. Simple Request
An HTTP GET request includes control data and a request header with An HTTP GET request includes control data and a request header with
no message content and is therefore transmitted as a single HEADERS no message content and is therefore transmitted as a single HEADERS
frame, followed by zero or more CONTINUATION frames containing the frame, followed by zero or more CONTINUATION frames containing the
serialized block of request header fields. The HEADERS frame in the serialized block of request header fields. The HEADERS frame in the
following has both the END_HEADERS and END_STREAM flags set; no following has both the END_HEADERS and END_STREAM flags set; no
CONTINUATION frames are sent. CONTINUATION frames are sent.
GET /resource HTTP/1.1 HEADERS GET /resource HTTP/1.1 HEADERS
Host: example.org ==> + END_STREAM Host: example.org ==> + END_STREAM
Accept: image/jpeg + END_HEADERS Accept: image/jpeg + END_HEADERS
:method = GET :method = GET
:scheme = https :scheme = https
:authority = example.org
:path = /resource :path = /resource
host = example.org host = example.org
accept = image/jpeg accept = image/jpeg
8.8.2. Simple Response
Similarly, a response that includes only control data and a response Similarly, a response that includes only control data and a response
header is transmitted as a HEADERS frame (again, followed by zero or header is transmitted as a HEADERS frame (again, followed by zero or
more CONTINUATION frames) containing the serialized block of response more CONTINUATION frames) containing the serialized block of response
header fields. header fields.
HTTP/1.1 304 Not Modified HEADERS HTTP/1.1 304 Not Modified HEADERS
ETag: "xyzzy" ==> + END_STREAM ETag: "xyzzy" ==> + END_STREAM
Expires: Thu, 23 Jan ... + END_HEADERS Expires: Thu, 23 Jan ... + END_HEADERS
:status = 304 :status = 304
etag = "xyzzy" etag = "xyzzy"
expires = Thu, 23 Jan ... expires = Thu, 23 Jan ...
8.8.3. Complex Request
An HTTP POST request that includes control data and a request header An HTTP POST request that includes control data and a request header
and message content is transmitted as one HEADERS frame, followed by and message content is transmitted as one HEADERS frame, followed by
zero or more CONTINUATION frames containing the request header, zero or more CONTINUATION frames containing the request header,
followed by one or more DATA frames, with the last CONTINUATION (or followed by one or more DATA frames, with the last CONTINUATION (or
HEADERS) frame having the END_HEADERS flag set and the final DATA HEADERS) frame having the END_HEADERS flag set and the final DATA
frame having the END_STREAM flag set: frame having the END_STREAM flag set:
POST /resource HTTP/1.1 HEADERS POST /resource HTTP/1.1 HEADERS
Host: example.org ==> - END_STREAM Host: example.org ==> - END_STREAM
Content-Type: image/jpeg - END_HEADERS Content-Type: image/jpeg - END_HEADERS
Content-Length: 123 :method = POST Content-Length: 123 :method = POST
:authority = example.org
:path = /resource :path = /resource
{binary data} :scheme = https {binary data} :scheme = https
CONTINUATION CONTINUATION
+ END_HEADERS + END_HEADERS
content-type = image/jpeg content-type = image/jpeg
host = example.org host = example.org
content-length = 123 content-length = 123
DATA DATA
+ END_STREAM + END_STREAM
{binary data} {binary data}
Note that data contributing to any given field line could be spread Note that data contributing to any given field line could be spread
between field block fragments. The allocation of field lines to between field block fragments. The allocation of field lines to
frames in this example is illustrative only. frames in this example is illustrative only.
8.8.4. Response with Body
A response that includes control data and a response header and A response that includes control data and a response header and
message content is transmitted as a HEADERS frame, followed by zero message content is transmitted as a HEADERS frame, followed by zero
or more CONTINUATION frames, followed by one or more DATA frames, or more CONTINUATION frames, followed by one or more DATA frames,
with the last DATA frame in the sequence having the END_STREAM flag with the last DATA frame in the sequence having the END_STREAM flag
set: set:
HTTP/1.1 200 OK HEADERS HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM Content-Type: image/jpeg ==> - END_STREAM
Content-Length: 123 + END_HEADERS Content-Length: 123 + END_HEADERS
:status = 200 :status = 200
{binary data} content-type = image/jpeg {binary data} content-type = image/jpeg
content-length = 123 content-length = 123
DATA DATA
+ END_STREAM + END_STREAM
{binary data} {binary data}
8.8.5. Informational Responses
An informational response using a 1xx status code other than 101 is An informational response using a 1xx status code other than 101 is
transmitted as a HEADERS frame, followed by zero or more CONTINUATION transmitted as a HEADERS frame, followed by zero or more CONTINUATION
frames. frames.
A trailer section is sent as a field block after both the request or A trailer section is sent as a field block after both the request or
response field block and all the DATA frames have been sent. The response field block and all the DATA frames have been sent. The
HEADERS frame starting the field block that comprises the trailer HEADERS frame starting the field block that comprises the trailer
section has the END_STREAM flag set. section has the END_STREAM flag set.
The following example includes both a 100 (Continue) status code, The following example includes both a 100 (Continue) status code,
skipping to change at page 64, line 19 skipping to change at page 66, line 15
HTTP/1.1 100 Continue HEADERS HTTP/1.1 100 Continue HEADERS
Extension-Field: bar ==> - END_STREAM Extension-Field: bar ==> - END_STREAM
+ END_HEADERS + END_HEADERS
:status = 100 :status = 100
extension-field = bar extension-field = bar
HTTP/1.1 200 OK HEADERS HTTP/1.1 200 OK HEADERS
Content-Type: image/jpeg ==> - END_STREAM Content-Type: image/jpeg ==> - END_STREAM
Transfer-Encoding: chunked + END_HEADERS Transfer-Encoding: chunked + END_HEADERS
Trailer: Foo :status = 200 Trailer: Foo :status = 200
content-length = 123 content-type = image/jpeg
123 content-type = image/jpeg 123 trailer = Foo
{binary data} trailer = Foo {binary data}
0 0 DATA
Foo: bar DATA Foo: bar - END_STREAM
- END_STREAM
{binary data} {binary data}
HEADERS HEADERS
+ END_STREAM + END_STREAM
+ END_HEADERS + END_HEADERS
foo = bar foo = bar
9. HTTP/2 Connections 9. HTTP/2 Connections
This section outlines attributes of the HTTP protocol that improve This section outlines attributes of the HTTP protocol that improve
skipping to change at page 67, line 20 skipping to change at page 69, line 14
This effectively prevents the use of renegotiation in response to a This effectively prevents the use of renegotiation in response to a
request for a specific protected resource. A future specification request for a specific protected resource. A future specification
might provide a way to support this use case. Alternatively, a might provide a way to support this use case. Alternatively, a
server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to
request the client use a protocol that supports renegotiation. request the client use a protocol that supports renegotiation.
Implementations MUST support ephemeral key exchange sizes of at least Implementations MUST support ephemeral key exchange sizes of at least
2048 bits for cipher suites that use ephemeral finite field Diffie- 2048 bits for cipher suites that use ephemeral finite field Diffie-
Hellman (DHE) [TLS13] and 224 bits for cipher suites that use Hellman (DHE) [TLS13] and 224 bits for cipher suites that use
ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC4492]. Clients ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC8422]. Clients
MUST accept DHE sizes of up to 4096 bits. Endpoints MAY treat MUST accept DHE sizes of up to 4096 bits. Endpoints MAY treat
negotiation of key sizes smaller than the lower limits as a negotiation of key sizes smaller than the lower limits as a
connection error (Section 5.4.1) of type INADEQUATE_SECURITY. connection error (Section 5.4.1) of type INADEQUATE_SECURITY.
9.2.2. TLS 1.2 Cipher Suites 9.2.2. TLS 1.2 Cipher Suites
A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher
suites that are listed in the list of prohibited cipher suites suites that are listed in the list of prohibited cipher suites
(Appendix A). (Appendix A).
skipping to change at page 68, line 41 skipping to change at page 70, line 34
HTTP/2. Unless the use of a new type of TLS message depends on an HTTP/2. Unless the use of a new type of TLS message depends on an
interaction with the application-layer protocol, that TLS message can interaction with the application-layer protocol, that TLS message can
be sent after the handshake completes. be sent after the handshake completes.
TLS early data MAY be used to send requests, provided that the TLS early data MAY be used to send requests, provided that the
guidance in [RFC8470] is observed. Clients send requests in early guidance in [RFC8470] is observed. Clients send requests in early
data assuming initial values for all server settings. data assuming initial values for all server settings.
10. Security Considerations 10. Security Considerations
The use of TLS is necessary to provide many of the security
properties of this protocol. Many of the claims in this section do
not hold unless TLS is used as described in Section 9.2.
10.1. Server Authority 10.1. Server Authority
HTTP/2 relies on the HTTP definition of authority for determining HTTP/2 relies on the HTTP definition of authority for determining
whether a server is authoritative in providing a given response (see whether a server is authoritative in providing a given response (see
Section 4.3 of [HTTP]). This relies on local name resolution for the Section 4.3 of [HTTP]). This relies on local name resolution for the
"http" URI scheme and the authenticated server identity for the "http" URI scheme and the authenticated server identity for the
"https" scheme. "https" scheme.
10.2. Cross-Protocol Attacks 10.2. Cross-Protocol Attacks
skipping to change at page 72, line 19 skipping to change at page 74, line 19
routing can appear toward the end of a field block, which prevents routing can appear toward the end of a field block, which prevents
streaming of fields to their ultimate destination. This ordering and streaming of fields to their ultimate destination. This ordering and
other reasons, such as ensuring cache correctness, mean that an other reasons, such as ensuring cache correctness, mean that an
endpoint might need to buffer the entire field block. Since there is endpoint might need to buffer the entire field block. Since there is
no hard limit to the size of a field block, some endpoints could be no hard limit to the size of a field block, some endpoints could be
forced to commit a large amount of available memory for field blocks. forced to commit a large amount of available memory for field blocks.
An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE to advise peers An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE to advise peers
of limits that might apply on the size of uncompressed field blocks. of limits that might apply on the size of uncompressed field blocks.
This setting is only advisory, so endpoints MAY choose to send field This setting is only advisory, so endpoints MAY choose to send field
blocks that exceed this limit and risk having the request or response blocks that exceed this limit and risk the request or response being
being treated as malformed. This setting is specific to a treated as malformed. This setting is specific to a connection, so
connection, so any request or response could encounter a hop with a any request or response could encounter a hop with a lower, unknown
lower, unknown limit. An intermediary can attempt to avoid this limit. An intermediary can attempt to avoid this problem by passing
problem by passing on values presented by different peers, but they on values presented by different peers, but they are not obliged to
are not obliged to do so. do so.
A server that receives a larger field block than it is willing to A server that receives a larger field block than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status handle can send an HTTP 431 (Request Header Fields Too Large) status
code [RFC6585]. A client can discard responses that it cannot code [RFC6585]. A client can discard responses that it cannot
process. The field block MUST be processed to ensure a consistent process. The field block MUST be processed to ensure a consistent
connection state, unless the connection is closed. connection state, unless the connection is closed.
10.5.2. CONNECT Issues 10.5.2. CONNECT Issues
The CONNECT method can be used to create disproportionate load on an The CONNECT method can be used to create disproportionate load on an
skipping to change at page 75, line 35 skipping to change at page 77, line 35
Identification Sequence: 0x68 0x32 0x63 ("h2c") Identification Sequence: 0x68 0x32 0x63 ("h2c")
Specification: This document Specification: This document
11.2. Frame Type Registry 11.2. Frame Type Registry
This document establishes a registry for HTTP/2 frame type codes. This document establishes a registry for HTTP/2 frame type codes.
The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2 The "HTTP/2 Frame Type" registry manages an 8-bit space. The "HTTP/2
Frame Type" registry operates under either of the "IETF Review" Frame Type" registry operates under either of the "IETF Review"
[RFC8126] or "IESG Approval" [RFC8126] policies. (Section 4.8 of [RFC8126]) or "IESG Approval" (Section 4.10 of
[RFC8126]) policies.
New entries in this registry require the following information: New entries in this registry require the following information:
Frame Type: A name or label for the frame type. Frame Type: A name or label for the frame type.
Code: The 8-bit code assigned to the frame type. Code: The 8-bit code assigned to the frame type.
Specification: A reference to a specification that includes a Specification: A reference to a specification that includes a
description of the frame layout, its semantics, and flags that the description of the frame layout, its semantics, and flags that the
frame type uses, including any parts of the frame that are frame type uses, including any parts of the frame that are
skipping to change at page 76, line 27 skipping to change at page 78, line 27
| CONTINUATION | 0x9 | Section 6.10 | | CONTINUATION | 0x9 | Section 6.10 |
+---------------+------+--------------+ +---------------+------+--------------+
Table 1 Table 1
11.3. Settings Registry 11.3. Settings Registry
This document establishes a registry for HTTP/2 settings. The This document establishes a registry for HTTP/2 settings. The
"HTTP/2 Settings" registry manages a 16-bit space. The "HTTP/2 "HTTP/2 Settings" registry manages a 16-bit space. The "HTTP/2
Settings" registry operates under the "Expert Review" policy Settings" registry operates under the "Expert Review" policy
[RFC8126]. (Section 4.5 of [RFC8126]).
New registrations are advised to provide the following information: New registrations are advised to provide the following information:
Name: A symbolic name for the setting. Specifying a setting name is Name: A symbolic name for the setting. Specifying a setting name is
optional. optional.
Code: The 16-bit code assigned to the setting. Code: The 16-bit code assigned to the setting.
Initial Value: An initial value for the setting. Initial Value: An initial value for the setting.
skipping to change at page 77, line 23 skipping to change at page 79, line 23
| MAX_HEADER_LIST_SIZE | 0x6 | (infinite) | Section 6.5.2 | | MAX_HEADER_LIST_SIZE | 0x6 | (infinite) | Section 6.5.2 |
+------------------------+------+---------------+---------------+ +------------------------+------+---------------+---------------+
Table 2 Table 2
11.4. Error Code Registry 11.4. Error Code Registry
This document establishes a registry for HTTP/2 error codes. The This document establishes a registry for HTTP/2 error codes. The
"HTTP/2 Error Code" registry manages a 32-bit space. The "HTTP/2 "HTTP/2 Error Code" registry manages a 32-bit space. The "HTTP/2
Error Code" registry operates under the "Expert Review" policy Error Code" registry operates under the "Expert Review" policy
[RFC8126]. (Section 4.5 of [RFC8126]).
Registrations for error codes are required to include a description Registrations for error codes are required to include a description
of the error code. An expert reviewer is advised to examine new of the error code. An expert reviewer is advised to examine new
registrations for possible duplication with existing error codes. registrations for possible duplication with existing error codes.
Use of existing registrations is to be encouraged, but not mandated. Use of existing registrations is to be encouraged, but not mandated.
New registrations are advised to provide the following information: New registrations are advised to provide the following information:
Name: A name for the error code. Specifying an error code name is Name: A name for the error code. Specifying an error code name is
optional. optional.
Code: The 32-bit error code value. Code: The 32-bit error code value.
Description: A brief description of the error code semantics, longer Description: A brief description of the error code semantics; longer
if no detailed specification is provided. if no detailed specification is provided.
Specification: An optional reference for a specification that Specification: An optional reference for a specification that
defines the error code. defines the error code.
The entries in the following table are registered by this document. The entries in the following table are registered by this document.
+---------------------+------+----------------------+---------------+ +---------------------+------+----------------------+---------------+
| Name | Code | Description | Specification | | Name | Code | Description | Specification |
+---------------------+------+----------------------+---------------+ +---------------------+------+----------------------+---------------+
skipping to change at page 78, line 43 skipping to change at page 80, line 43
| | | acceptable | | | | | acceptable | |
| HTTP_1_1_REQUIRED | 0xd | Use HTTP/1.1 for | Section 7 | | HTTP_1_1_REQUIRED | 0xd | Use HTTP/1.1 for | Section 7 |
| | | the request | | | | | the request | |
+---------------------+------+----------------------+---------------+ +---------------------+------+----------------------+---------------+
Table 3 Table 3
11.5. HTTP2-Settings Header Field Registration 11.5. HTTP2-Settings Header Field Registration
This section marks the "HTTP2-Settings" header field registered in This section marks the "HTTP2-Settings" header field registered in
Section 11.5 of [RFC7540] as obsoleted. The registration is updated Section 11.5 of [RFC7540] as obsoleted. This capability has been
to include the details as required by Section 18.4 of [HTTP]: removed: see Section 3.1. The registration is updated to include the
details as required by Section 18.4 of [HTTP]:
Field Name: HTTP2-Settings Field Name: HTTP2-Settings
Status: Standard Status: Standard
Ref.: Section 3.2.1 of [RFC7540] Ref.: Section 3.2.1 of [RFC7540]
Comments: Obsolete; see Section 11.5 Comments: Obsolete; see Section 11.5
11.6. PRI Method Registration 11.6. PRI Method Registration
This section registers the "PRI" method in the "HTTP Method Registry" This section registers the "PRI" method in the "HTTP Method Registry"
(Section 18.2 of [HTTP]). (Section 18.2 of [HTTP]).
Method Name: PRI Method Name: PRI
Safe: Yes Safe: Yes
skipping to change at page 79, line 24 skipping to change at page 81, line 25
Idempotent: Yes Idempotent: Yes
Specification document(s): Section 3.4 of this document Specification document(s): Section 3.4 of this document
Related information: This method is never used by an actual client. Related information: This method is never used by an actual client.
This method will appear to be used when an HTTP/1.1 server or This method will appear to be used when an HTTP/1.1 server or
intermediary attempts to parse an HTTP/2 connection preface. intermediary attempts to parse an HTTP/2 connection preface.
11.7. The h2c Upgrade Token 11.7. The h2c Upgrade Token
Previous versions of this document (Section 11.8 of [RFC7540]) This section records the "h2c" upgrade token registered in
registered an upgrade token. This capability has been removed: see Section 11.8 of [RFC7540] as obsolete. This capability has been
Section 3.1. removed: see Section 3.1. The registration is updated as follows:
Value: h2c
Description: Hypertext Transfer Protocol version 2 (HTTP/2)
Expected Version Tokens: None
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, RFC 7541, DOI 10.17487/RFC7541, May
2015, <https://www.rfc-editor.org/rfc/rfc7541>. 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, STD 7, RFC 793, DOI 10.17487/RFC0793, September
1981, <https://www.rfc-editor.org/rfc/rfc793>. 1981, <https://www.rfc-editor.org/rfc/rfc793>.
[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, 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
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/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, STD 66, RFC 3986, DOI 10.17487/RFC3986, January
2005, <https://www.rfc-editor.org/rfc/rfc3986>. 2005, <https://www.rfc-editor.org/rfc/rfc3986>.
[RFC8126] Cotton, M., Leiba, B., and R. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and R. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, BCP 26, RFC 8126, RFC 8126, DOI 10.17487/RFC8126, BCP 26, RFC 8126,
DOI 10.17487/RFC8126, June 2017, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/rfc/rfc8126>. <https://www.rfc-editor.org/rfc/rfc8126>.
skipping to change at page 81, line 7 skipping to change at page 83, line 21
[FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4, [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4,
FIPS PUB 186-4, July 2013, FIPS PUB 186-4, July 2013,
<http://dx.doi.org/10.6028/NIST.FIPS.186-4>. <http://dx.doi.org/10.6028/NIST.FIPS.186-4>.
[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, RFC 6265, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/rfc/rfc6265>. <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-15, Internet-Draft, draft- draft-ietf-httpbis-semantics-18, Internet-Draft, draft-
ietf-httpbis-semantics-15, March 30, 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-15>. 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,
draft-ietf-httpbis-cache-15, Internet-Draft, draft-ietf- draft-ietf-httpbis-cache-18, Internet-Draft, draft-ietf-
httpbis-cache-15, March 30, 2021, httpbis-cache-18, August 18, 2021,
<https://datatracker.ietf.org/doc/html/draft-ietf-httpbis- <https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-
cache-15>. cache-18>.
[QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based [QUIC] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", RFC 9000, Multiplexed and Secure Transport", RFC 9000,
DOI 10.17487/RFC9000, May 2021, DOI 10.17487/RFC9000, May 2021,
<https://www.rfc-editor.org/info/rfc9000>. <https://www.rfc-editor.org/info/rfc9000>.
12.2. Informative References 12.2. Informative References
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, RFC 7540, DOI 10.17487/RFC7540, May DOI 10.17487/RFC7540, RFC 7540, DOI 10.17487/RFC7540, May
2015, <https://www.rfc-editor.org/rfc/rfc7540>. 2015, <https://www.rfc-editor.org/rfc/rfc7540>.
[RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740,
DOI 10.17487/RFC8740, RFC 8740, DOI 10.17487/RFC8740, DOI 10.17487/RFC8740, RFC 8740, DOI 10.17487/RFC8740,
February 2020, <https://www.rfc-editor.org/rfc/rfc8740>. February 2020, <https://www.rfc-editor.org/rfc/rfc8740>.
[HTTP11] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [HTTP11] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft- Ed., "HTTP/1.1", Work in Progress, Internet-Draft, draft-
ietf-httpbis-messaging-15, Internet-Draft, draft-ietf- ietf-httpbis-messaging-18, Internet-Draft, draft-ietf-
httpbis-messaging-15, March 30, 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-15>. messaging-18>.
[RFC8441] McManus, P., "Bootstrapping WebSockets with HTTP/2",
RFC 8441, DOI 10.17487/RFC8441, RFC 8441,
DOI 10.17487/RFC8441, September 2018,
<https://www.rfc-editor.org/rfc/rfc8441>.
[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, 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, RFC 3749,
DOI 10.17487/RFC3749, May 2004, 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, RFC 6585, DOI 10.17487/RFC6585, April
2012, <https://www.rfc-editor.org/rfc/rfc6585>. 2012, <https://www.rfc-editor.org/rfc/rfc6585>.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC8422] Nir, Y., Josefsson, S., and M. Pegourie-Gonnard, "Elliptic
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Curve Cryptography (ECC) Cipher Suites for Transport Layer
for Transport Layer Security (TLS)", RFC 4492, RFC 4492, Security (TLS) Versions 1.2 and Earlier", RFC 8422,
DOI 10.17487/RFC4492, May 2006, RFC 8422, DOI 10.17487/RFC8422, August 2018,
<https://www.rfc-editor.org/rfc/rfc4492>. <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>. <http://w2spconf.com/2011/papers/websocket.pdf>.
skipping to change at page 89, line 7 skipping to change at page 91, line 30
o TLS_RSA_WITH_AES_128_CCM o TLS_RSA_WITH_AES_128_CCM
o TLS_RSA_WITH_AES_256_CCM o TLS_RSA_WITH_AES_256_CCM
o TLS_RSA_WITH_AES_128_CCM_8 o TLS_RSA_WITH_AES_128_CCM_8
o TLS_RSA_WITH_AES_256_CCM_8 o TLS_RSA_WITH_AES_256_CCM_8
o TLS_PSK_WITH_AES_128_CCM o TLS_PSK_WITH_AES_128_CCM
o TLS_PSK_WITH_AES_256_CCM o TLS_PSK_WITH_AES_256_CCM
o TLS_PSK_WITH_AES_128_CCM_8 o TLS_PSK_WITH_AES_128_CCM_8
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 at the time of writing. This list includes those | cipher suites when [RFC7540] was developed. This list includes
| cipher suites that do not offer an ephemeral key exchange and | those cipher suites that do not offer an ephemeral key exchange
| those that are based on the TLS null, stream, or block cipher | and those that are based on the TLS null, stream, or block
| type (as defined in Section 6.2.3 of [TLS12]). Additional | cipher type (as defined in Section 6.2.3 of [TLS12]).
| cipher suites with these properties could be defined; these | Additional cipher suites with these properties could be
| would not be explicitly prohibited. | defined; these would not be explicitly prohibited.
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 a number of editorial updates, plus the
following substantive changes: following substantive changes:
o Use of TLS 1.3 is defined based on RFC 8740, which this document o Use of TLS 1.3 is 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 is 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 no longer specified in this
document. It was never widely deployed, with plaintext HTTP/2 document. It was never widely deployed, with plaintext HTTP/2
users choosing to use the prior-knowledge implementation instead. 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
more precisely and comprehensively identified.
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. 148 change blocks. 
370 lines changed or deleted 471 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/