draft-ietf-httpbis-http2-15.txt   draft-ietf-httpbis-http2-16.txt 
HTTPbis Working Group M. Belshe HTTPbis Working Group M. Belshe
Internet-Draft Twist Internet-Draft Twist
Intended status: Standards Track R. Peon Intended status: Standards Track R. Peon
Expires: April 30, 2015 Google, Inc Expires: June 2, 2015 Google, Inc
M. Thomson, Ed. M. Thomson, Ed.
Mozilla Mozilla
October 27, 2014 November 29, 2014
Hypertext Transfer Protocol version 2 Hypertext Transfer Protocol version 2
draft-ietf-httpbis-http2-15 draft-ietf-httpbis-http2-16
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). HTTP/2 enables a more of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more
efficient use of network resources and a reduced perception of efficient use of network resources and a reduced perception of
latency by introducing header field compression and allowing multiple latency by introducing header field compression and allowing multiple
concurrent messages on the same connection. It also introduces concurrent messages on the same connection. It also introduces
unsolicited push of representations from servers to clients. unsolicited push of representations from servers to clients.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged. HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.
Editorial Note (To be removed by RFC Editor) Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the HTTPBIS working group Discussion of this draft takes place on the HTTPBIS working group
mailing list (ietf-http-wg@w3.org), which is archived at [1]. mailing list (ietf-http-wg@w3.org), which is archived at [1].
Working Group information can be found at [2]; that specific to Working Group information can be found at [2]; that specific to
HTTP/2 are at [3]. HTTP/2 are at [3].
The changes in this draft are summarized in Appendix A. The changes in this draft are summarized in Appendix B.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 April 30, 2015. This Internet-Draft will expire on June 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
3.3. Starting HTTP/2 for "https" URIs . . . . . . . . . . . . 11 3.3. Starting HTTP/2 for "https" URIs . . . . . . . . . . . . 11
3.4. Starting HTTP/2 with Prior Knowledge . . . . . . . . . . 11 3.4. Starting HTTP/2 with Prior Knowledge . . . . . . . . . . 11
3.5. HTTP/2 Connection Preface . . . . . . . . . . . . . . . . 11 3.5. HTTP/2 Connection Preface . . . . . . . . . . . . . . . . 11
4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. HTTP Frames . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Frame Format . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . 14 4.2. Frame Size . . . . . . . . . . . . . . . . . . . . . . . 14
4.3. Header Compression and Decompression . . . . . . . . . . 14 4.3. Header Compression and Decompression . . . . . . . . . . 14
5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . 15 5. Streams and Multiplexing . . . . . . . . . . . . . . . . . . 15
5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 16 5.1. Stream States . . . . . . . . . . . . . . . . . . . . . . 16
5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 21 5.1.1. Stream Identifiers . . . . . . . . . . . . . . . . . 21
5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 21 5.1.2. Stream Concurrency . . . . . . . . . . . . . . . . . 22
5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 22 5.2. Flow Control . . . . . . . . . . . . . . . . . . . . . . 23
5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 22 5.2.1. Flow Control Principles . . . . . . . . . . . . . . . 23
5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 23 5.2.2. Appropriate Use of Flow Control . . . . . . . . . . . 24
5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 24 5.3. Stream priority . . . . . . . . . . . . . . . . . . . . . 25
5.3.1. Stream Dependencies . . . . . . . . . . . . . . . . . 24 5.3.1. Stream Dependencies . . . . . . . . . . . . . . . . . 25
5.3.2. Dependency Weighting . . . . . . . . . . . . . . . . 25 5.3.2. Dependency Weighting . . . . . . . . . . . . . . . . 26
5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . 26 5.3.3. Reprioritization . . . . . . . . . . . . . . . . . . 26
5.3.4. Prioritization State Management . . . . . . . . . . . 26 5.3.4. Prioritization State Management . . . . . . . . . . . 27
5.3.5. Default Priorities . . . . . . . . . . . . . . . . . 27 5.3.5. Default Priorities . . . . . . . . . . . . . . . . . 29
5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 28 5.4. Error Handling . . . . . . . . . . . . . . . . . . . . . 29
5.4.1. Connection Error Handling . . . . . . . . . . . . . . 28 5.4.1. Connection Error Handling . . . . . . . . . . . . . . 29
5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 28 5.4.2. Stream Error Handling . . . . . . . . . . . . . . . . 29
5.4.3. Connection Termination . . . . . . . . . . . . . . . 29 5.4.3. Connection Termination . . . . . . . . . . . . . . . 30
5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 29 5.5. Extending HTTP/2 . . . . . . . . . . . . . . . . . . . . 30
6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 30 6. Frame Definitions . . . . . . . . . . . . . . . . . . . . . . 31
6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 30 6.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . . . 31
6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 32 6.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . . . 33
6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 34 6.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . . . 35
6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 35 6.4. RST_STREAM . . . . . . . . . . . . . . . . . . . . . . . 36
6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 36 6.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . . . 37
6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 37 6.5.1. SETTINGS Format . . . . . . . . . . . . . . . . . . . 38
6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 37 6.5.2. Defined SETTINGS Parameters . . . . . . . . . . . . . 38
6.5.3. Settings Synchronization . . . . . . . . . . . . . . 38 6.5.3. Settings Synchronization . . . . . . . . . . . . . . 40
6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 39 6.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . . . 40
6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 41 6.7. PING . . . . . . . . . . . . . . . . . . . . . . . . . . 42
6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.8. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . . . 43
6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 45 6.9. WINDOW_UPDATE . . . . . . . . . . . . . . . . . . . . . . 46
6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 46 6.9.1. The Flow Control Window . . . . . . . . . . . . . . . 47
6.9.2. Initial Flow Control Window Size . . . . . . . . . . 47 6.9.2. Initial Flow Control Window Size . . . . . . . . . . 48
6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 48 6.9.3. Reducing the Stream Window Size . . . . . . . . . . . 49
6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 48 6.10. CONTINUATION . . . . . . . . . . . . . . . . . . . . . . 49
7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 49 7. Error Codes . . . . . . . . . . . . . . . . . . . . . . . . . 50
8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . 50 8. HTTP Message Exchanges . . . . . . . . . . . . . . . . . . . 51
8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . 51 8.1. HTTP Request/Response Exchange . . . . . . . . . . . . . 52
8.1.1. Upgrading From HTTP/2 . . . . . . . . . . . . . . . . 52 8.1.1. Upgrading From HTTP/2 . . . . . . . . . . . . . . . . 53
8.1.2. HTTP Header Fields . . . . . . . . . . . . . . . . . 52 8.1.2. HTTP Header Fields . . . . . . . . . . . . . . . . . 53
8.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 56 8.1.3. Examples . . . . . . . . . . . . . . . . . . . . . . 57
8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . 59 8.1.4. Request Reliability Mechanisms in HTTP/2 . . . . . . 60
8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 59 8.2. Server Push . . . . . . . . . . . . . . . . . . . . . . . 61
8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 60 8.2.1. Push Requests . . . . . . . . . . . . . . . . . . . . 62
8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . 61 8.2.2. Push Responses . . . . . . . . . . . . . . . . . . . 63
8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . 62 8.3. The CONNECT Method . . . . . . . . . . . . . . . . . . . 64
9. Additional HTTP Requirements/Considerations . . . . . . . . . 63 9. Additional HTTP Requirements/Considerations . . . . . . . . . 65
9.1. Connection Management . . . . . . . . . . . . . . . . . . 64 9.1. Connection Management . . . . . . . . . . . . . . . . . . 65
9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 64 9.1.1. Connection Reuse . . . . . . . . . . . . . . . . . . 66
9.1.2. The 421 (Misdirected Request) Status Code . . . . . . 65 9.1.2. The 421 (Misdirected Request) Status Code . . . . . . 67
9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 65 9.2. Use of TLS Features . . . . . . . . . . . . . . . . . . . 67
9.2.1. TLS Features . . . . . . . . . . . . . . . . . . . . 66 9.2.1. TLS 1.2 Features . . . . . . . . . . . . . . . . . . 67
9.2.2. TLS Cipher Suites . . . . . . . . . . . . . . . . . . 66 9.2.2. TLS 1.2 Cipher Suites . . . . . . . . . . . . . . . . 68
10. Security Considerations . . . . . . . . . . . . . . . . . . . 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 69
10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 67 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 69
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 67 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 69
10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 68 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 70
10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 68 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 70
10.5. Denial of Service Considerations . . . . . . . . . . . . 68 10.5. Denial of Service Considerations . . . . . . . . . . . . 70
10.5.1. Limits on Header Block Size . . . . . . . . . . . . 70 10.5.1. Limits on Header Block Size . . . . . . . . . . . . 72
10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 70 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 72
10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 71 10.7. Use of Padding . . . . . . . . . . . . . . . . . . . . . 73
10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 71 10.8. Privacy Considerations . . . . . . . . . . . . . . . . . 73
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74
11.1. Registration of HTTP/2 Identification Strings . . . . . 72 11.1. Registration of HTTP/2 Identification Strings . . . . . 74
11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 72 11.2. Frame Type Registry . . . . . . . . . . . . . . . . . . 75
11.3. Settings Registry . . . . . . . . . . . . . . . . . . . 73 11.3. Settings Registry . . . . . . . . . . . . . . . . . . . 75
11.4. Error Code Registry . . . . . . . . . . . . . . . . . . 74 11.4. Error Code Registry . . . . . . . . . . . . . . . . . . 76
11.5. HTTP2-Settings Header Field Registration . . . . . . . . 75 11.5. HTTP2-Settings Header Field Registration . . . . . . . . 77
11.6. PRI Method Registration . . . . . . . . . . . . . . . . 76 11.6. PRI Method Registration . . . . . . . . . . . . . . . . 78
11.7. The 421 (Misdirected Request) HTTP Status Code . . . . . 76 11.7. The 421 (Misdirected Request) HTTP Status Code . . . . . 78
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 76 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 78
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 79
13.1. Normative References . . . . . . . . . . . . . . . . . . 77 13.1. Normative References . . . . . . . . . . . . . . . . . . 79
13.2. Informative References . . . . . . . . . . . . . . . . . 78 13.2. Informative References . . . . . . . . . . . . . . . . . 80
13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 79 13.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 81
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 80 Appendix A. Prohibited TLS 1.2 Cipher Suites . . . . . . . . . . 82
A.1. Since draft-ietf-httpbis-http2-14 . . . . . . . . . . . . 80 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 86
A.2. Since draft-ietf-httpbis-http2-13 . . . . . . . . . . . . 80 B.1. Since draft-ietf-httpbis-http2-15 . . . . . . . . . . . . 86
A.3. Since draft-ietf-httpbis-http2-12 . . . . . . . . . . . . 80 B.2. Since draft-ietf-httpbis-http2-14 . . . . . . . . . . . . 86
A.4. Since draft-ietf-httpbis-http2-11 . . . . . . . . . . . . 80 B.3. Since draft-ietf-httpbis-http2-13 . . . . . . . . . . . . 87
A.5. Since draft-ietf-httpbis-http2-10 . . . . . . . . . . . . 81 B.4. Since draft-ietf-httpbis-http2-12 . . . . . . . . . . . . 87
A.6. Since draft-ietf-httpbis-http2-09 . . . . . . . . . . . . 81 B.5. Since draft-ietf-httpbis-http2-11 . . . . . . . . . . . . 87
A.7. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 82 B.6. Since draft-ietf-httpbis-http2-10 . . . . . . . . . . . . 87
A.8. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 82 B.7. Since draft-ietf-httpbis-http2-09 . . . . . . . . . . . . 88
A.9. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 82 B.8. Since draft-ietf-httpbis-http2-08 . . . . . . . . . . . . 88
A.10. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 82 B.9. Since draft-ietf-httpbis-http2-07 . . . . . . . . . . . . 89
A.11. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 82 B.10. Since draft-ietf-httpbis-http2-06 . . . . . . . . . . . . 89
A.12. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 83 B.11. Since draft-ietf-httpbis-http2-05 . . . . . . . . . . . . 89
A.13. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 83 B.12. Since draft-ietf-httpbis-http2-04 . . . . . . . . . . . . 89
A.14. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 83 B.13. Since draft-ietf-httpbis-http2-03 . . . . . . . . . . . . 90
A.15. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 84 B.14. Since draft-ietf-httpbis-http2-02 . . . . . . . . . . . . 90
A.16. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 84 B.15. Since draft-ietf-httpbis-http2-01 . . . . . . . . . . . . 90
B.16. Since draft-ietf-httpbis-http2-00 . . . . . . . . . . . . 91
B.17. Since draft-mbelshe-httpbis-spdy-00 . . . . . . . . . . . 91
1. Introduction 1. Introduction
The Hypertext Transfer Protocol (HTTP) is a wildly successful The Hypertext Transfer Protocol (HTTP) is a wildly successful
protocol. However, the HTTP/1.1 message format ([RFC7230], protocol. However, how HTTP/1.1 uses the underlying transport
Section 3) has several characteristics that have a negative overall ([RFC7230], Section 6) has several characteristics that have a
effect on application performance today. negative overall effect on application performance today.
In particular, HTTP/1.0 allowed only one request to be outstanding at In particular, HTTP/1.0 allowed only one request to be outstanding at
a time on a given TCP connection. HTTP/1.1 added request pipelining, a time on a given TCP connection. HTTP/1.1 added request pipelining,
but this only partially addressed request concurrency and still but this only partially addressed request concurrency and still
suffers from head-of-line blocking. Therefore, HTTP/1.1 clients that suffers from head-of-line blocking. Therefore, HTTP/1.1 clients that
need to make many requests typically use multiple connections to a need to make many requests typically use multiple connections to a
server in order to achieve concurrency and thereby reduce latency. server in order to achieve concurrency and thereby reduce latency.
Furthermore, HTTP header fields are often repetitive and verbose, Furthermore, HTTP header fields are often repetitive and verbose,
causing unnecessary network traffic, as well as causing the initial causing unnecessary network traffic, as well as causing the initial
skipping to change at page 6, line 8 skipping to change at page 6, line 10
resources can be directed to the most important streams first. resources can be directed to the most important streams first.
HTTP/2 adds a new interaction mode, whereby a server can push HTTP/2 adds a new interaction mode, whereby a server can push
responses to a client (Section 8.2). Server push allows a server to responses to a client (Section 8.2). Server push allows a server to
speculatively send data to a client that the server anticipates the speculatively send data to a client that the server anticipates the
client will need, trading off some network usage against a potential client will need, trading off some network usage against a potential
latency gain. The server does this by synthesizing a request, which latency gain. The server does this by synthesizing a request, which
it sends as a PUSH_PROMISE frame. The server is then able to send a it sends as a PUSH_PROMISE frame. The server is then able to send a
response to the synthetic request on a separate stream. response to the synthetic request on a separate stream.
Frames that contain HTTP header fields are compressed (Section 4.3). Because HTTP header fields used in a connection can contain large
HTTP requests can be highly redundant, so compression can reduce the amounts of redundant data, frames that contain them are compressed
size of requests and responses significantly. (Section 4.3). This has especially advantageous impact upon request
sizes in the common case, allowing many requests to be compressed
into one TCP packet.
2.1. Document Organization 2.1. Document Organization
The HTTP/2 specification is split into four parts: The HTTP/2 specification is split into four parts:
o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is o Starting HTTP/2 (Section 3) covers how an HTTP/2 connection is
initiated. initiated.
o The framing (Section 4) and streams (Section 5) layers describe o The framing (Section 4) and streams (Section 5) layers describe
the way HTTP/2 frames are structured and formed into multiplexed the way HTTP/2 frames are structured and formed into multiplexed
skipping to change at page 9, line 8 skipping to change at page 9, line 8
For example, an experimental implementation of packet mood-based For example, an experimental implementation of packet mood-based
encoding based on draft-ietf-httpbis-http2-09 might identify itself encoding based on draft-ietf-httpbis-http2-09 might identify itself
as "h2-09-emo". Note that any label MUST conform to the "token" as "h2-09-emo". Note that any label MUST conform to the "token"
syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are syntax defined in Section 3.2.6 of [RFC7230]. Experimenters are
encouraged to coordinate their experiments on the ietf-http-wg@w3.org encouraged to coordinate their experiments on the ietf-http-wg@w3.org
mailing list. mailing list.
3.2. Starting HTTP/2 for "http" URIs 3.2. Starting HTTP/2 for "http" URIs
A client that makes a request for an "http" URI without prior A client that makes a request for an "http" URI without prior
knowledge about support for HTTP/2 uses the HTTP Upgrade mechanism knowledge about support for HTTP/2 on the next hop uses the HTTP
(Section 6.7 of [RFC7230]). The client makes an HTTP/1.1 request Upgrade mechanism (Section 6.7 of [RFC7230]). The client does so by
that includes an Upgrade header field identifying HTTP/2 with the making an HTTP/1.1 request that includes an Upgrade header field with
"h2c" token. The HTTP/1.1 request MUST include exactly one the "h2c" token. Such an HTTP/1.1 request MUST include exactly one
HTTP2-Settings (Section 3.2.1) header field. HTTP2-Settings (Section 3.2.1) header field.
For example: For example:
GET / HTTP/1.1 GET / HTTP/1.1
Host: server.example.com Host: server.example.com
Connection: Upgrade, HTTP2-Settings Connection: Upgrade, HTTP2-Settings
Upgrade: h2c Upgrade: h2c
HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload> HTTP2-Settings: <base64url encoding of HTTP/2 SETTINGS payload>
skipping to change at page 10, line 13 skipping to change at page 10, line 13
Upgrade. Upgrade.
For example: For example:
HTTP/1.1 101 Switching Protocols HTTP/1.1 101 Switching Protocols
Connection: Upgrade Connection: Upgrade
Upgrade: h2c Upgrade: h2c
[ HTTP/2 connection ... [ HTTP/2 connection ...
The first HTTP/2 frame sent by the server is a SETTINGS frame The first HTTP/2 frame sent by the server MUST be a SETTINGS frame
(Section 6.5) as the server connection preface (Section 3.5). Upon (Section 6.5) as the server connection preface (Section 3.5). Upon
receiving the 101 response, the client sends a connection preface receiving the 101 response, the client MUST send a connection preface
(Section 3.5), which includes a SETTINGS frame. (Section 3.5), which includes a SETTINGS frame.
The HTTP/1.1 request that is sent prior to upgrade is assigned stream The HTTP/1.1 request that is sent prior to upgrade is assigned stream
identifier 1 and is assigned default priority values (Section 5.3.5). identifier 1 and is assigned default priority values (Section 5.3.5).
Stream 1 is implicitly half closed from the client toward the server, Stream 1 is implicitly half closed from the client toward the server,
since the request is completed as an HTTP/1.1 request. After since the request is completed as an HTTP/1.1 request. After
commencing the HTTP/2 connection, stream 1 is used for the response. commencing the HTTP/2 connection, stream 1 is used for the response.
3.2.1. HTTP2-Settings Header Field 3.2.1. HTTP2-Settings Header Field
skipping to change at page 10, line 52 skipping to change at page 10, line 52
[RFC5234] production for "token68" is defined in Section 2.1 of [RFC5234] production for "token68" is defined in Section 2.1 of
[RFC7235]. [RFC7235].
Since the upgrade is only intended to apply to the immediate Since the upgrade is only intended to apply to the immediate
connection, a client sending "HTTP2-Settings" MUST also send connection, a client sending "HTTP2-Settings" MUST also send
"HTTP2-Settings" as a connection option in the "Connection" header "HTTP2-Settings" as a connection option in the "Connection" header
field to prevent it from being forwarded (see Section 6.1 of field to prevent it from being forwarded (see Section 6.1 of
[RFC7230]). [RFC7230]).
A server decodes and interprets these values as it would any other A server decodes and interprets these values as it would any other
SETTINGS frame. Acknowledgement of the SETTINGS parameters SETTINGS frame. Explicit acknowledgement of these settings
(Section 6.5.3) is not necessary, since a 101 response serves as (Section 6.5.3) is not necessary, since a 101 response serves as
implicit acknowledgment. Providing these values in the Upgrade implicit acknowledgment. Providing these values in the Upgrade
request gives a client an opportunity to provide parameters prior to request gives a client an opportunity to provide parameters prior to
receiving any frames from the server. receiving any frames from the server.
3.3. Starting HTTP/2 for "https" URIs 3.3. Starting HTTP/2 for "https" URIs
A client that makes a request to an "https" URI uses TLS [TLS12] with A client that makes a request to an "https" URI uses TLS [TLS12] with
the application layer protocol negotiation extension [TLS-ALPN]. the application layer protocol negotiation extension [TLS-ALPN].
HTTP/2 over TLS uses the "h2" application token. The "h2c" token HTTP/2 over TLS uses the "h2" application token. The "h2c" token
MUST NOT be sent by a client or selected by a server. MUST NOT be sent by a client or selected by a server.
Once TLS negotiation is complete, both the client and the server send Once TLS negotiation is complete, both the client and the server MUST
a connection preface (Section 3.5). send a connection preface (Section 3.5).
3.4. Starting HTTP/2 with Prior Knowledge 3.4. 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, [ALT-SVC] describes a mechanism for advertising
this capability. this capability.
A client MAY immediately send HTTP/2 frames to a server that is known A client MUST send the connection preface (Section 3.5), and then MAY
to support HTTP/2, after the connection preface (Section 3.5); a immediately send HTTP/2 frames to such a server; servers can identify
server can identify such a connection by the presence of the these connections by the presence of the connection preface. This
connection preface. This only affects the establishment of HTTP/2 only affects the establishment of HTTP/2 connections over cleartext
connections over cleartext TCP; implementations that support HTTP/2 TCP; implementations that support HTTP/2 over TLS MUST use protocol
over TLS MUST use protocol negotiation in TLS [TLS-ALPN]. negotiation in TLS [TLS-ALPN].
Likewise, the sever MUST send a connection preface (Section 3.5).
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.5. HTTP/2 Connection Preface 3.5. HTTP/2 Connection Preface
Upon establishment of a TCP connection and determination that HTTP/2 In HTTP/2, each endpoint is required to send a connection preface as
will be used by both peers, each endpoint MUST send a connection a final confirmation of the protocol in use, and to establish the
preface as a final confirmation and to establish the initial SETTINGS initial settings for the HTTP/2 connection. The client and server
parameters for the HTTP/2 connection. The client and server each each send a different connection preface.
send a different connection preface.
The client connection preface starts with a sequence of 24 octets, The client connection preface starts with a sequence of 24 octets,
which in hex notation are: which in hex notation are:
0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a 0x505249202a20485454502f322e300d0a0d0a534d0d0a0d0a
(the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"). This sequence is (the string "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"). This sequence MUST
followed by a SETTINGS frame (Section 6.5). The SETTINGS frame MAY be followed by a SETTINGS frame (Section 6.5), which MAY be empty.
be empty. The client sends the client connection preface immediately The client sends the client connection preface immediately upon
upon receipt of a 101 Switching Protocols response (indicating a receipt of a 101 Switching Protocols response (indicating a
successful upgrade), or as the first application data octets of a TLS successful upgrade), or as the first application data octets of a TLS
connection. If starting an HTTP/2 connection with prior knowledge of connection. If starting an HTTP/2 connection with prior knowledge of
server support for the protocol, the client connection preface is server support for the protocol, the client connection preface is
sent upon connection establishment. sent upon connection establishment.
The client connection preface is selected so that a large The client connection preface is selected so that a large
proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do proportion of HTTP/1.1 or HTTP/1.0 servers and intermediaries do
not attempt to process further frames. Note that this does not not attempt to process further frames. Note that this does not
address the concerns raised in [TALKING]. address the concerns raised in [TALKING].
skipping to change at page 14, line 32 skipping to change at page 14, line 32
frame type, or it is too small to contain mandatory frame data. A frame type, or it is too small to contain mandatory frame data. A
frame size error in a frame that could alter the state of the entire frame size error in a frame that could alter the state of the entire
connection MUST be treated as a connection error (Section 5.4.1); connection MUST be treated as a connection error (Section 5.4.1);
this includes any frame carrying a header block (Section 4.3) (that this includes any frame carrying a header block (Section 4.3) (that
is, HEADERS, PUSH_PROMISE, and CONTINUATION), SETTINGS, and any frame is, HEADERS, PUSH_PROMISE, and CONTINUATION), SETTINGS, and any frame
with a stream identifier of 0. with a stream identifier of 0.
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 RST_STREAM, delays in sending time-sensitive frames (such as RST_STREAM,
WINDOW_UPDATE, or PRIORITY) which if blocked by the transmission of a WINDOW_UPDATE, or PRIORITY) which if blocked by the transmission of a
large frame, could affect performance. large frame, could affect performance.
4.3. Header Compression and Decompression 4.3. Header Compression and Decompression
Just as in HTTP/1, a header field in HTTP/2 is a name with one or Just as in HTTP/1, a header field in HTTP/2 is a name with one or
more associated values. They are used within HTTP request and more associated values. They are used within HTTP request and
response messages as well as server push operations (see response messages as well as server push operations (see
Section 8.2). Section 8.2).
skipping to change at page 16, line 17 skipping to change at page 17, line 5
particular, the order of HEADERS, and DATA frames is semantically particular, the 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.
+--------+ +--------+
PP | | PP send PP | | recv PP
,--------| idle |--------. ,--------| idle |--------.
/ | | \ / | | \
v +--------+ v v +--------+ v
+----------+ | +----------+ +----------+ | +----------+
| | | H | | | | | send H/ | |
,---| reserved | | | reserved |---. ,-----| reserved | | recv H | reserved |-----.
| | (local) | v | (remote) | | | | (local) | | | (remote) | |
| +----------+ +--------+ +----------+ | | +----------+ v +----------+ |
| | ES | | ES | | | | +--------+ | |
| | H ,-------| open |-------. | H | | | recv ES | | send ES | |
| | / | | \ | | | send H | ,-------| open |-------. | recv H |
| v v +--------+ v v | | | / | | \ | |
| +----------+ | +----------+ | | v v +--------+ v v |
| | half | | | half | | | +----------+ | +----------+ |
| | closed | | R | closed | | | | half | | | half | |
| | (remote) | | | (local) | | | | closed | | send R/ | closed | |
| +----------+ | +----------+ | | | (remote) | | recv R | (local) | |
| | v | | | +----------+ | +----------+ |
| | ES / R +--------+ ES / R | | | | | | |
| `----------->| |<-----------' | | | send ES/ | recv ES/ | |
| R | closed | R | | | send R/ v send R/ | |
`-------------------->| |<--------------------' | | recv R +--------+ recv R | |
+--------+ | send R/ `----------->| |<-----------' send R/ |
| recv R | closed | recv R |
`---------------------->| |<----------------------'
+--------+
send: endpoint sends this frame
recv: endpoint receives this frame
H: HEADERS frame (with implied CONTINUATIONs) H: HEADERS frame (with implied CONTINUATIONs)
PP: PUSH_PROMISE frame (with implied CONTINUATIONs) PP: PUSH_PROMISE frame (with implied CONTINUATIONs)
ES: END_STREAM flag ES: END_STREAM flag
R: RST_STREAM frame R: RST_STREAM frame
Figure 2: Stream States Figure 2: Stream States
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,
skipping to change at page 17, line 33 skipping to change at page 18, line 25
All streams start in the "idle" state. In this state, no frames All streams start in the "idle" state. In this state, no frames
have been exchanged. have been exchanged.
The following transitions are valid from this state: The following transitions are valid from this state:
* Sending or receiving a HEADERS frame causes the stream to * Sending or receiving a HEADERS frame causes the stream to
become "open". The stream identifier is selected as described become "open". The stream identifier is selected as described
in Section 5.1.1. The same HEADERS frame can also cause a in Section 5.1.1. The same HEADERS frame can also cause a
stream to immediately become "half closed". stream to immediately become "half closed".
* Sending a PUSH_PROMISE frame marks the associated stream for * Sending a PUSH_PROMISE frame reserves an idle stream for later
later use. The stream state for the reserved stream use. The stream state for the reserved stream transitions to
transitions to "reserved (local)". "reserved (local)".
* Receiving a PUSH_PROMISE frame marks the associated stream as * Receiving a PUSH_PROMISE frame reserves an idle stream for
reserved by the remote peer. The state of the stream becomes later use. The stream state for the reserved stream
"reserved (remote)". transitions to "reserved (remote)".
Receiving any frames other than HEADERS or PUSH_PROMISE on a Receiving any frames other than HEADERS, PUSH_PROMISE or PRIORITY
stream in this state MUST be treated as a connection error on a stream in this state MUST be treated as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. (Section 5.4.1) of type PROTOCOL_ERROR.
reserved (local): reserved (local):
A stream in the "reserved (local)" state is one that has been A stream in the "reserved (local)" state is one that has been
promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame promised by sending a PUSH_PROMISE frame. A PUSH_PROMISE frame
reserves an idle stream by associating the stream with an open reserves an idle stream by associating the stream with an open
stream that was initiated by the remote peer (see Section 8.2). stream that was initiated by the remote peer (see Section 8.2).
In this state, only the following transitions are possible: In this state, only the following transitions are possible:
* The endpoint can send a HEADERS frame. This causes the stream * The endpoint can send a HEADERS frame. This causes the stream
to open in a "half closed (remote)" state. to open in a "half closed (remote)" state.
* Either endpoint can send a RST_STREAM frame to cause the stream * Either endpoint can send a RST_STREAM frame to cause the stream
to become "closed". This releases the stream reservation. to become "closed". This releases the stream reservation.
An endpoint MUST NOT send any type of frame other than HEADERS or An endpoint MUST NOT send any type of frame other than HEADERS,
RST_STREAM in this state. RST_STREAM, or PRIORITY in this state.
A PRIORITY or WINDOW_UPDATE frame MAY be received in this state. A PRIORITY or WINDOW_UPDATE frame MAY be received in this state.
Receiving any type of frame other than RST_STREAM, PRIORITY or Receiving any type of frame other than RST_STREAM, PRIORITY or
WINDOW_UPDATE on a stream in this state MUST be treated as a WINDOW_UPDATE on a stream in this state MUST be treated as a
connection error (Section 5.4.1) of type PROTOCOL_ERROR. connection error (Section 5.4.1) of type PROTOCOL_ERROR.
reserved (remote): reserved (remote):
A stream in the "reserved (remote)" state has been reserved by a A stream in the "reserved (remote)" state has been reserved by a
remote peer. remote peer.
skipping to change at page 18, line 36 skipping to change at page 19, line 27
"half closed (local)". "half closed (local)".
* Either endpoint can send a RST_STREAM frame to cause the stream * Either endpoint can send a RST_STREAM frame to cause the stream
to become "closed". This releases the stream reservation. to become "closed". This releases the stream reservation.
An endpoint MAY send a PRIORITY frame in this state to An endpoint MAY send a PRIORITY frame in this state to
reprioritize the reserved stream. An endpoint MUST NOT send any reprioritize the reserved stream. An endpoint MUST NOT send any
type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in type of frame other than RST_STREAM, WINDOW_UPDATE, or PRIORITY in
this state. this state.
Receiving any type of frame other than HEADERS or RST_STREAM on a Receiving any type of frame other than HEADERS, RST_STREAM or
stream in this state MUST be treated as a connection error PRIORITY on a stream in this state MUST be treated as a connection
(Section 5.4.1) of type PROTOCOL_ERROR. error (Section 5.4.1) of type PROTOCOL_ERROR.
open: open:
A stream in the "open" state may be used by both peers to send A stream in the "open" state may be used by both peers to send
frames of any type. In this state, sending peers observe frames of any type. In this state, sending peers observe
advertised stream level flow control limits (Section 5.2). advertised stream level flow control limits (Section 5.2).
From this state either endpoint can send a frame with an From this state either endpoint can send a frame with an
END_STREAM flag set, which causes the stream to transition into END_STREAM flag set, which causes the stream to transition into
one of the "half closed" states: an endpoint sending an END_STREAM one of the "half closed" states: an endpoint sending an END_STREAM
flag causes the stream state to become "half closed (local)"; an flag causes the stream state to become "half closed (local)"; an
skipping to change at page 20, line 44 skipping to change at page 21, line 36
consider the frames to count against the flow control window. consider the frames to count against the flow control window.
An endpoint might receive a PUSH_PROMISE frame after it sends An endpoint might receive a PUSH_PROMISE frame after it sends
RST_STREAM. PUSH_PROMISE causes a stream to become "reserved" RST_STREAM. PUSH_PROMISE causes a stream to become "reserved"
even if the associated stream has been reset. Therefore, a even if the associated stream has been reset. Therefore, a
RST_STREAM is needed to close an unwanted promised stream. RST_STREAM is needed to close an unwanted promised stream.
In the absence of more specific guidance elsewhere in this document, In the absence of more specific guidance elsewhere in this document,
implementations SHOULD treat the receipt of a frame that is not implementations SHOULD treat the receipt of a frame that is not
expressly permitted in the description of a state as a connection expressly permitted in the description of a state as a connection
error (Section 5.4.1) of type PROTOCOL_ERROR. Frame of unknown types error (Section 5.4.1) of type PROTOCOL_ERROR. Note that PRIORITY can
are ignored. be sent and received in any stream state. Frame of unknown types are
ignored.
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.1. An example of the state exchange can be found in Section 8.1. An example of the state
transitions for server push can be found in Section 8.2.1 and transitions for server push can be found in Section 8.2.1 and
Section 8.2.2. Section 8.2.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
skipping to change at page 22, line 15 skipping to change at page 23, line 8
Streams that are in the "open" state, or either of the "half closed" Streams that are in the "open" state, or either of the "half closed"
states count toward the maximum number of streams that an endpoint is states count toward the maximum number of streams that an endpoint is
permitted to open. Streams in any of these three states count toward permitted to open. Streams in any of these three states count toward
the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting. the limit advertised in the SETTINGS_MAX_CONCURRENT_STREAMS setting.
Streams in either of the "reserved" states do not count toward the Streams in either of the "reserved" states do not count toward the
stream limit. 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 their advertised concurrent that receives a HEADERS frame that causes their 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). An endpoint that wishes to reduce the value of (Section 5.4.2) of type PROTOCOL_ERROR or REFUSED_STREAM. 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
ensures that streams on the same connection do not destructively ensures that streams on the same connection do not destructively
interfere with each other. Flow control is used for both individual interfere with each other. Flow control is used for both individual
skipping to change at page 24, line 12 skipping to change at page 25, line 9
Even with full awareness of the current bandwidth-delay product, Even with full awareness of the current bandwidth-delay product,
implementation of flow control can be difficult. When using flow implementation of flow control can be difficult. When using flow
control, the receiver MUST read from the TCP receive buffer in a control, the receiver MUST read from the TCP receive buffer in a
timely fashion. Failure to do so could lead to a deadlock when timely fashion. Failure to do so could lead to a deadlock when
critical frames, such as WINDOW_UPDATE, are not read and acted upon. critical frames, such as WINDOW_UPDATE, are not read and acted upon.
5.3. Stream priority 5.3. Stream priority
A client can assign a priority for a new stream by including A client can assign a priority for a new stream by including
prioritization information in the HEADERS frame (Section 6.2) that prioritization information in the HEADERS frame (Section 6.2) that
opens the stream. For an existing stream, the PRIORITY frame opens the stream. At any other time, the PRIORITY frame
(Section 6.3) can be used to change the priority. (Section 6.3) can be used to change the priority of a stream.
The purpose of prioritization is to allow an endpoint to express how The purpose of prioritization is to allow an endpoint to express how
it would prefer its peer allocate resources when managing concurrent it would prefer its peer allocate resources when managing concurrent
streams. Most importantly, priority can be used to select streams streams. Most importantly, priority can be used to select streams
for transmitting frames when there is limited capacity for sending. for transmitting frames when there is limited capacity for sending.
Streams can be prioritized by marking them as dependent on the Streams can be prioritized by marking them as dependent on the
completion of other streams (Section 5.3.1). Each dependency is completion of other streams (Section 5.3.1). Each dependency is
assigned a relative weight, a number that is used to determine the assigned a relative weight, a number that is used to determine the
relative proportion of available resources that are assigned to relative proportion of available resources that are assigned to
skipping to change at page 27, line 31 skipping to change at page 28, line 24
information, then the dependent stream is instead assigned a default information, then the dependent stream is instead assigned a default
priority (Section 5.3.5). This potentially creates suboptimal priority (Section 5.3.5). This potentially creates suboptimal
prioritization, since the stream could be given a priority that is prioritization, since the stream could be given a priority that is
different to what is intended. different to what is intended.
To avoid these problems, an endpoint SHOULD retain stream To avoid these problems, an endpoint SHOULD retain stream
prioritization state for a period after streams become closed. The prioritization state for a period after streams become closed. The
longer state is retained, the lower the chance that streams are longer state is retained, the lower the chance that streams are
assigned incorrect or default priority values. assigned incorrect or default priority values.
This could create a large state burden for an endpoint, so this state Similarly, streams that are in the "idle" state can be assigned
MAY be limited. An endpoint MAY apply a fixed upper limit on the priority or become a parent of other streams. This allows for the
number of closed streams for which prioritization state is tracked to creation of a grouping node in the dependency tree, which enables
limit state exposure. The amount of additional state an endpoint more flexible expressions of priority. Idle streams that are made a
maintains could be dependent on load; under high load, prioritization parent of another stream are assigned a default priority
state can be discarded to limit resource commitments. In extreme (Section 5.3.5).
cases, an endpoint could even discard prioritization state for active
or reserved streams. If a fixed limit is applied, endpoints SHOULD The retention of priority information for streams that are not
maintain state for at least as many streams as allowed by their counted toward the limit set by SETTINGS_MAX_CONCURRENT_STREAMS could
setting for SETTINGS_MAX_CONCURRENT_STREAMS. create a large state burden for an endpoint. Therefore the amount of
prioritization state that is retained MAY be limited.
The amount of additional state an endpoint maintains for
prioritization could be dependent on load; under high load,
prioritization state can be discarded to limit resource commitments.
In extreme cases, an endpoint could even discard prioritization state
for active or reserved streams. If a limit is applied, endpoints
SHOULD maintain state for at least as many streams as allowed by
their setting for SETTINGS_MAX_CONCURRENT_STREAMS. Implementations
SHOULD also attempt to retain state for streams that are in active
use in the priority tree.
An endpoint receiving a PRIORITY frame that changes the priority of a An endpoint receiving a PRIORITY frame that changes the priority of a
closed stream SHOULD alter the dependencies of the streams that closed stream SHOULD alter the dependencies of the streams that
depend on it, if it has retained enough state to do so. depend on it, if it has retained enough state to do so.
5.3.5. Default Priorities 5.3.5. Default Priorities
Providing priority information is optional. Streams are assigned a Providing priority information is optional. Streams are assigned a
non-exclusive dependency on stream 0x0 by default. Pushed streams non-exclusive dependency on stream 0x0 by default. Pushed streams
(Section 8.2) initially depend on their associated stream. In both (Section 8.2) initially depend on their associated stream. In both
skipping to change at page 29, line 13 skipping to change at page 30, line 20
These frames can be ignored, except where they modify connection These frames can be ignored, except where they modify connection
state (such as the state maintained for header compression state (such as the state maintained for header compression
(Section 4.3), or flow control). (Section 4.3), or flow control).
Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame Normally, an endpoint SHOULD NOT send more than one RST_STREAM frame
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.
An endpoint MUST NOT send a RST_STREAM in response to an RST_STREAM An endpoint MUST NOT send a RST_STREAM in response to a RST_STREAM
frame, to avoid looping. frame, to avoid looping.
5.4.3. Connection Termination 5.4.3. Connection Termination
If the TCP connection is closed or reset while streams remain in open If the TCP connection is closed or reset while streams remain in open
or half closed states, then the endpoint MUST assume that those or half closed states, then the endpoint MUST assume that those
streams were abnormally interrupted and could be incomplete. streams were abnormally interrupted and could be incomplete.
5.5. Extending HTTP/2 5.5. Extending HTTP/2
skipping to change at page 29, line 45 skipping to change at page 31, line 5
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 header block (Section 4.3) are not permitted; these the middle of a header 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.
However, extensions that could change the semantics of existing Extensions that could change the semantics of existing protocol
protocol components MUST be negotiated before being used. For components MUST be negotiated before being used. For example, an
example, an extension that changes the layout of the HEADERS frame extension that changes the layout of the HEADERS frame cannot be used
cannot be used until the peer has given a positive signal that this until the peer has given a positive signal that this is acceptable.
is acceptable. In this case, it could also be necessary to In this case, it could also be necessary to coordinate when the
coordinate when the revised layout comes into effect. Note that revised layout comes into effect. Note that treating any frame other
treating any frame other than DATA frames as flow controlled is such than DATA frames as flow controlled is such a change in semantics,
a change in semantics, and can only be done through negotiation. and can only be done through negotiation.
This document doesn't mandate a specific method for negotiating the This document doesn't mandate a specific method for negotiating the
use of an extension, but notes that a setting (Section 6.5.2) could use of an extension, but notes that a setting (Section 6.5.2) could
be used for that purpose. If both peers set a value that indicates be used for that purpose. If both peers set a value that indicates
willingness to use the extension, then the extension can be used. If willingness to use the extension, then the extension can be used. If
a setting is used for extension negotiation, the initial value MUST a setting is used for extension negotiation, the initial value MUST
be defined in such a fashion that the extension is initially be defined in such a fashion that the extension is initially
disabled. disabled.
6. Frame Definitions 6. Frame Definitions
skipping to change at page 34, line 8 skipping to change at page 35, line 20
Prioritization information in a HEADERS frame is logically equivalent Prioritization information in a HEADERS frame is logically equivalent
to a separate PRIORITY frame, but inclusion in HEADERS avoids the to a separate PRIORITY frame, but inclusion in HEADERS avoids the
potential for churn in stream prioritization when new streams are potential for churn in stream prioritization when new streams are
created. Priorization fields in HEADERS frames subsequent to the created. Priorization fields in HEADERS frames subsequent to the
first on a stream reprioritize the stream (Section 5.3.3). first on a stream reprioritize the stream (Section 5.3.3).
6.3. PRIORITY 6.3. PRIORITY
The PRIORITY frame (type=0x2) specifies the sender-advised priority The PRIORITY frame (type=0x2) specifies the sender-advised priority
of a stream (Section 5.3). It can be sent at any time for an of a stream (Section 5.3). It can be sent at any time for any
existing stream, including closed streams. This enables stream, including idle or closed streams.
reprioritization of existing streams.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|E| Stream Dependency (31) | |E| Stream Dependency (31) |
+-+-------------+-----------------------------------------------+ +-+-------------+-----------------------------------------------+
| Weight (8) | | Weight (8) |
+-+-------------+ +-+-------------+
Figure 8: PRIORITY Frame Payload Figure 8: PRIORITY Frame Payload
skipping to change at page 34, line 41 skipping to change at page 36, line 5
Section 5.3. Add one to the value to obtain a weight between 1 Section 5.3. Add one to the value to obtain a weight between 1
and 256. and 256.
The PRIORITY frame does not define any flags. The PRIORITY frame does not define any flags.
The PRIORITY frame is associated with an existing stream. If a The PRIORITY frame is associated with an existing stream. If a
PRIORITY frame is received with a stream identifier of 0x0, the PRIORITY frame is received with a stream identifier of 0x0, the
recipient MUST respond with a connection error (Section 5.4.1) of recipient MUST respond with a connection error (Section 5.4.1) of
type PROTOCOL_ERROR. type PROTOCOL_ERROR.
The PRIORITY frame can be sent on a stream in any of the "reserved The PRIORITY frame can be sent on a stream in any state, though it
(remote)", "open", "half closed (local)", "half closed (remote)", or cannot be sent between consecutive frames that comprise a single
"closed" states, though it cannot be sent between consecutive frames header block (Section 4.3). Note that this frame could arrive after
that comprise a single header block (Section 4.3). Note that this processing or frame sending has completed, which would cause it to
frame could arrive after processing or frame sending has completed, have no effect on the current stream. For a stream that is in the
which would cause it to have no effect on the current stream. For a "half closed (remote)" or "closed" - state, this frame can only
stream that is in the "half closed (remote)" or "closed" - state, affect processing of the current stream and not frame transmission.
this frame can only affect processing of the current stream and not
frame transmission.
The PRIORITY frame is the only frame that can be sent for a stream in The PRIORITY frame can be sent for a stream in the "idle" or "closed"
the "closed" state. This allows for the reprioritization of a group states. This allows for the reprioritization of a group of dependent
of dependent streams by altering the priority of a parent stream, streams by altering the priority of an unused or closed parent
which might be closed. However, a PRIORITY frame sent on a closed stream.
stream risks being ignored due to the peer having discarded priority
state information for that stream.
A PRIORITY frame with a length other than 5 octets MUST be treated as A PRIORITY frame with a length other than 5 octets MUST be treated as
a stream error (Section 5.4.2) of type FRAME_SIZE_ERROR. a stream error (Section 5.4.2) of type FRAME_SIZE_ERROR.
6.4. RST_STREAM 6.4. RST_STREAM
The RST_STREAM frame (type=0x3) allows for immediate termination of a The RST_STREAM frame (type=0x3) allows for immediate termination of a
stream. RST_STREAM is sent to request cancellation of a stream, or stream. RST_STREAM is sent to request cancellation of a stream, or
to indicate that an error condition has occurred. to indicate that an error condition has occurred.
skipping to change at page 38, line 10 skipping to change at page 39, line 17
directional: it applies to the number of streams that the sender directional: it applies to the number of streams that the sender
permits the receiver to create. Initially there is no limit to permits the receiver to create. Initially there is no limit to
this value. It is recommended that this value be no smaller than this value. It is recommended that this value be no smaller than
100, so as to not unnecessarily limit parallelism. 100, so as to not unnecessarily limit parallelism.
A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be A value of 0 for SETTINGS_MAX_CONCURRENT_STREAMS SHOULD NOT be
treated as special by endpoints. A zero value does prevent the treated as special by endpoints. A zero value does prevent the
creation of new streams, however this can also happen for any creation of new streams, however this can also happen for any
limit that is exhausted with active streams. Servers SHOULD only limit that is exhausted with active streams. Servers SHOULD only
set a zero value for short durations; if a server does not wish to set a zero value for short durations; if a server does not wish to
accept requests, closing the connection could be preferable. accept requests, closing the connection is more appropriate.
SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial SETTINGS_INITIAL_WINDOW_SIZE (0x4): Indicates the sender's initial
window size (in octets) for stream level flow control. The window size (in octets) for stream level flow control. The
initial value is 2^16-1 (65,535) octets. initial value is 2^16-1 (65,535) octets.
This setting affects the window size of all streams, including This setting affects the window size of all streams, including
existing streams, see Section 6.9.2. existing streams, see Section 6.9.2.
Values above the maximum flow control window size of 2^31-1 MUST Values above the maximum flow control window size of 2^31-1 MUST
be treated as a connection error (Section 5.4.1) of type be treated as a connection error (Section 5.4.1) of type
skipping to change at page 52, line 41 skipping to change at page 53, line 49
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. Alternative protocols are able to use the same
mechanisms that HTTP/2 uses to negotiate their use (see Section 3). mechanisms that HTTP/2 uses to negotiate their use (see Section 3).
8.1.2. HTTP Header Fields 8.1.2. HTTP Header Fields
HTTP header fields carry information as a series of key-value pairs. HTTP header fields carry information as a series of key-value pairs.
For a listing of registered HTTP headers, see the Message Header For a listing of registered HTTP headers, see the Message Header
Field Registry maintained at [4]. Field Registry maintained at [4].
Just as in HTTP/1.x, header field names are strings of ASCII
characters that are compared in a case-insensitive fashion. However,
header field names MUST be converted to lowercase prior to their
encoding in HTTP/2. A request or response containing uppercase
header field names MUST be treated as malformed (Section 8.1.2.6).
8.1.2.1. Pseudo-Header Fields 8.1.2.1. Pseudo-Header Fields
While HTTP/1.x used the message start-line (see [RFC7230], While HTTP/1.x used the message start-line (see [RFC7230],
Section 3.1) to convey the target URI and method of the request, and Section 3.1) to convey the target URI and method of the request, and
the status code for the response, HTTP/2 uses special pseudo-header the status code for the response, HTTP/2 uses special pseudo-header
fields beginning with ':' character (ASCII 0x3a) for this purpose. fields beginning with ':' character (ASCII 0x3a) for this purpose.
Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT
generate pseudo-header fields other than those defined in this generate pseudo-header fields other than those defined in this
document. document.
Pseudo-header fields are only valid in the context in which they are Pseudo-header fields are only valid in the context in which they are
defined. Pseudo-header fields defined for requests MUST NOT appear defined. Pseudo-header fields defined for requests MUST NOT appear
in responses; pseudo-header fields defined for responses MUST NOT in responses; pseudo-header fields defined for responses MUST NOT
appear in requests. Pseudo-header fields MUST NOT appear in appear in requests. Pseudo-header fields MUST NOT appear in
trailers. Endpoints MUST treat a request or response that contains trailers. Endpoints MUST treat a request or response that contains
undefined or invalid pseudo-header fields as malformed undefined or invalid pseudo-header fields as malformed
(Section 8.1.2.6). (Section 8.1.2.6).
Just as in HTTP/1.x, header field names are strings of ASCII
characters that are compared in a case-insensitive fashion. However,
header field names MUST be converted to lowercase prior to their
encoding in HTTP/2. A request or response containing uppercase
header field names MUST be treated as malformed (Section 8.1.2.6).
All pseudo-header fields MUST appear in the header block before All pseudo-header fields MUST appear in the header block before
regular header fields. Any request or response that contains a regular header fields. Any request or response that contains a
pseudo-header field that appears in a header block after a regular pseudo-header field that appears in a header block after a regular
header field MUST be treated as malformed (Section 8.1.2.6). header field MUST be treated as malformed (Section 8.1.2.6).
8.1.2.2. Connection-Specific Header Fields 8.1.2.2. Connection-Specific Header Fields
HTTP/2 does not use the "Connection" header field to indicate HTTP/2 does not use the "Connection" header field to indicate
connection-specific header fields; in this protocol, connection- connection-specific header fields; in this protocol, connection-
specific metadata is conveyed by other means. An endpoint MUST NOT specific metadata is conveyed by other means. An endpoint MUST NOT
generate an HTTP/2 message containing connection-specific header generate an HTTP/2 message containing connection-specific header
fields; any message containing connection-specific header fields MUST fields; any message containing connection-specific header fields MUST
be treated as malformed (Section 8.1.2.6). be treated as malformed (Section 8.1.2.6).
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
value other than "trailers".
This means that an intermediary transforming an HTTP/1.x message to This means that an intermediary transforming an HTTP/1.x message to
HTTP/2 will need to remove any header fields nominated by the HTTP/2 will need to remove any header fields nominated by the
Connection header field, along with the Connection header field Connection header field, along with the Connection header field
itself. Such intermediaries SHOULD also remove other connection- itself. Such intermediaries SHOULD also remove other connection-
specific header fields, such as Keep-Alive, Proxy-Connection, specific header fields, such as Keep-Alive, Proxy-Connection,
Transfer-Encoding and Upgrade, even if they are not nominated by Transfer-Encoding and Upgrade, even if they are not nominated by
Connection. Connection.
One exception to this is the TE header field, which MAY be present in
an HTTP/2 request, but when it is, it MUST NOT contain any value
other than "trailers".
Note: HTTP/2 purposefully does not support upgrade to another Note: HTTP/2 purposefully does not support upgrade to another
protocol. The handshake methods described in Section 3 are protocol. The handshake methods described in Section 3 are
believed sufficient to negotiate the use of alternative protocols. believed sufficient to negotiate the use of alternative protocols.
8.1.2.3. Request Pseudo-Header Fields 8.1.2.3. 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
([RFC7231], Section 4). ([RFC7231], Section 4).
skipping to change at page 55, line 20 skipping to change at page 56, line 25
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 [RFC7231], defined that carries the HTTP status code field (see [RFC7231],
Section 6). This pseudo-header field MUST be included in all Section 6). This pseudo-header field MUST be included in all
responses, otherwise the response is malformed (Section 8.1.2.6). responses, otherwise the response is malformed (Section 8.1.2.6).
HTTP/2 does not define a way to carry the version or reason phrase HTTP/2 does not define a way to carry the version or reason phrase
that is included in an HTTP/1.1 status line. that is included in an HTTP/1.1 status line.
8.1.2.5. Compressing the Cookie Header Field 8.1.2.5. Compressing the Cookie Header Field
The Cookie header field [COOKIE] can carry a significant amount of The Cookie header field [COOKIE] uses a semi-colon (";") to delimit
redundant data. cookie-pairs (or "crumbs"). This header field doesn't follow the
list construction rules in HTTP (see [RFC7230], Section 3.2.2), which
The Cookie header field uses a semi-colon (";") to delimit cookie-
pairs (or "crumbs"). This header field doesn't follow the list
construction rules in HTTP (see [RFC7230], Section 3.2.2), which
prevents cookie-pairs from being separated into different name-value prevents cookie-pairs from being separated into different name-value
pairs. This can significantly reduce compression efficiency as pairs. This can significantly reduce compression efficiency as
individual cookie-pairs are updated. individual cookie-pairs are updated.
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
skipping to change at page 58, line 29 skipping to change at page 60, line 9
Trailing header fields are sent as a header block after both the Trailing header fields are sent as a header block after both the
request or response header block and all the DATA frames have been request or response header block and all the DATA frames have been
sent. The HEADERS frame starting the trailers header block has the sent. The HEADERS frame starting the trailers header block has the
END_STREAM flag set. END_STREAM flag set.
The following example includes both a 100 (Continue) status code, The following example includes both a 100 (Continue) status code,
which is sent in response to a request containing a "100-continue" which is sent in response to a request containing a "100-continue"
token in the Expect header field, and trailing header fields: token in the Expect header field, and trailing header fields:
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-length = 123
skipping to change at page 63, line 15 skipping to change at page 64, line 39
(Section 8.1.2.3), with a few differences. Specifically: (Section 8.1.2.3), with a few differences. Specifically:
o The ":method" header field is set to "CONNECT". o The ":method" header field is set to "CONNECT".
o The ":scheme" and ":path" header fields MUST be omitted. o The ":scheme" and ":path" header fields MUST be omitted.
o The ":authority" header field contains the host and port to o The ":authority" header field contains the host and port to
connect to (equivalent to the authority-form of the request-target connect to (equivalent to the authority-form of the request-target
of CONNECT requests, see [RFC7230], Section 5.3). of CONNECT requests, see [RFC7230], Section 5.3).
A CONNECT request that does not conform to these restrictions is
malformed (Section 8.1.2.6).
A proxy that supports CONNECT establishes a TCP connection [TCP] to A proxy that supports CONNECT establishes a TCP connection [TCP] to
the server identified in the ":authority" header field. Once this the server identified in the ":authority" header field. Once this
connection is successfully established, the proxy sends a HEADERS connection is successfully established, the proxy sends a HEADERS
frame containing a 2xx series status code to the client, as defined frame containing a 2xx series status code to the client, as defined
in [RFC7231], Section 4.3.6. in [RFC7231], Section 4.3.6.
After the initial HEADERS frame sent by each peer, all subsequent After the initial HEADERS frame sent by each peer, all subsequent
DATA frames correspond to data sent on the TCP connection. The DATA frames correspond to data sent on the TCP connection. The
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
skipping to change at page 65, line 45 skipping to change at page 67, line 27
([ALT-SVC]). ([ALT-SVC]).
This status code MUST NOT be generated by proxies. This status code MUST NOT be generated by proxies.
A 421 response is cacheable by default; i.e., unless otherwise A 421 response is cacheable by default; i.e., unless otherwise
indicated by the method definition or explicit cache controls (see indicated by the method definition or explicit cache controls (see
Section 4.2.2 of [RFC7234]). Section 4.2.2 of [RFC7234]).
9.2. Use of TLS Features 9.2. Use of TLS Features
Implementations of HTTP/2 MUST support TLS 1.2 [TLS12] for HTTP/2 Implementations of HTTP/2 MUST use TLS [TLS12] version 1.2 or higher
over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP]
followed, with some additional restrictions that are specific to SHOULD be followed, with some additional restrictions that are
HTTP/2. specific to HTTP/2.
An implementation of HTTP/2 over TLS MUST use TLS 1.2 or higher with
the restrictions on feature set and cipher suite described in this
section. Due to implementation limitations, it might not be possible
to fail TLS negotiation. An endpoint MUST immediately terminate an
HTTP/2 connection that does not meet these minimum requirements with
a connection error (Section 5.4.1) of type INADEQUATE_SECURITY.
9.2.1. TLS Features
The TLS implementation MUST support the Server Name Indication (SNI) The TLS implementation MUST support the Server Name Indication (SNI)
[TLS-EXT] extension to TLS. HTTP/2 clients MUST indicate the target [TLS-EXT] extension to TLS. HTTP/2 clients MUST indicate the target
domain name when negotiating TLS. domain name when negotiating TLS.
The TLS implementation MUST disable compression. TLS compression can Deployments of HTTP/2 that negotiate TLS 1.3 or higher need only
lead to the exposure of information that would not otherwise be support and use the SNI extension; deployments of TLS 1.2 are subject
revealed [RFC3749]. Generic compression is unnecessary since HTTP/2 to the requirements in the following sections. Implementations are
provides compression features that are more aware of context and encouraged to provide defaults that comply, but it is recognized that
therefore likely to be more appropriate for use for performance, deployments are ultimately responsible for compliance.
security or other reasons.
The TLS implementation MUST disable renegotiation. An endpoint MUST 9.2.1. TLS 1.2 Features
treat a TLS renegotiation as a connection error (Section 5.4.1) of
type PROTOCOL_ERROR. Note that disabling renegotiation can result in
long-lived connections becoming unusable due to limits on the number
of messages the underlying cipher suite can encipher.
A client MAY use renegotiation to provide confidentiality protection This section describes restrictions on the TLS 1.2 feature set that
for client credentials offered in the handshake, but any can be used with HTTP/2. Due to deployment limitations, it might not
be possible to fail TLS negotiation when these restrictions are not
met. An endpoint MAY immediately terminate an HTTP/2 connection that
does not meet these TLS requirements with a connection error
(Section 5.4.1) of type INADEQUATE_SECURITY.
A deployment of HTTP/2 over TLS 1.2 MUST disable compression. TLS
compression can lead to the exposure of information that would not
otherwise be revealed [RFC3749]. Generic compression is unnecessary
since HTTP/2 provides compression features that are more aware of
context and therefore likely to be more appropriate for use for
performance, security or other reasons.
A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation. An
endpoint MUST treat a TLS renegotiation as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR. Note that disabling
renegotiation can result in long-lived connections becoming unusable
due to limits on the number of messages the underlying cipher suite
can encipher.
An endpoint MAY use renegotiation to provide confidentiality
protection for client credentials offered in the handshake, but any
renegotiation MUST occur prior to sending the connection preface. A renegotiation MUST occur prior to sending the connection preface. A
server SHOULD request a client certificate if it sees a renegotiation server SHOULD request a client certificate if it sees a renegotiation
request immediately after establishing a connection. request immediately after establishing a connection.
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 a connection error (Section 5.4.1) of type server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to
HTTP_1_1_REQUIRED to request the client use a protocol which supports request the client use a protocol which supports renegotiation.
renegotiation.
9.2.2. TLS Cipher Suites Implementations MUST support ephemeral key exchange sizes of at least
2048 bits for cipher suites that use ephemeral finite field Diffie-
Hellman (DHE) [TLS12] and 224 bits for cipher suites that use
ephemeral elliptic curve Diffie-Hellman (ECDHE) [RFC4492]. Clients
MUST accept DHE sizes of up to 4096 bits. Endpoints MAY treat
negotiation of key sizes smaller than the lower limits as a
connection error (Section 5.4.1) of type INADEQUATE_SECURITY.
The set of TLS cipher suites that are permitted in HTTP/2 is 9.2.2. TLS 1.2 Cipher Suites
restricted. HTTP/2 MUST only be used with cipher suites that have
ephemeral key exchange, such as the ephemeral Diffie-Hellman (DHE)
[TLS12] or the elliptic curve variant (ECDHE) [RFC4492]. Ephemeral
key exchange MUST have a minimum size of 2048 bits for DHE or
security level of 128 bits for ECDHE. Clients MUST accept DHE sizes
of up to 4096 bits. HTTP MUST NOT be used with cipher suites that
use stream or block ciphers. Authenticated Encryption with
Additional Data (AEAD) modes, such as the Galois Counter Model (GCM)
mode for AES [RFC5288] are acceptable.
The effect of these restrictions is that TLS 1.2 implementations A deployment of HTTP/2 over TLS 1.2 SHOULD NOT use any of the cipher
could have non-intersecting sets of available cipher suites, since suites that are listed in Appendix A.
these prevent the use of the cipher suite that TLS 1.2 makes
mandatory. To avoid this problem, implementations of HTTP/2 that use
TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[TLS-ECDHE] with P256 [FIPS186].
Clients MAY advertise support of cipher suites that are prohibited by Endpoints MAY choose to generate a connection error (Section 5.4.1)
the above restrictions in order to allow for connection to servers of type INADEQUATE_SECURITY if one of the prohibited cipher suites
that do not support HTTP/2. This enables a fallback to protocols are negotiated. A deployment that chooses to use a prohibited cipher
without these constraints without the additional latency imposed by suite risks triggering a connection error unless the set of potential
using a separate connection for fallback. peers is known to accept that cipher suite.
Implementations MUST NOT generate this error in reaction to the
negotiation of a cipher suite that is not in the prohibited list.
Consequently, when clients offer a cipher suite that is not
prohibited, they have to be prepared to use that cipher suite with
HTTP/2.
The effect of prohibiting these cipher suites is that TLS 1.2
deployments could have non-intersecting sets of available cipher
suites, since the prohibited set includes the cipher suite that TLS
1.2 makes mandatory. To avoid this problem, deployments of HTTP/2
that use TLS 1.2 MUST support TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
[TLS-ECDHE] with the P256 elliptic curve [FIPS186].
Note that clients might advertise support of cipher suites that are
prohibited by the above restrictions in order to allow for connection
to servers that do not support HTTP/2 and support only prohibited
cipher suites. This allows servers to select HTTP/1.1 with a cipher
suite that is prohibited for HTTP/2. However, this can result in
HTTP/2 being negotiated with a prohibited cipher suite if the
application protocol and cipher suite are independently selected.
10. Security Considerations 10. Security Considerations
10.1. Server Authority 10.1. Server Authority
HTTP/2 relies on the HTTP/1.1 definition of authority for determining HTTP/2 relies on the HTTP/1.1 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
[RFC7230], Section 9.1. This relies on local name resolution for the [RFC7230], Section 9.1. 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 (see [RFC2818], Section 3). "https" scheme (see [RFC2818], Section 3).
skipping to change at page 69, line 29 skipping to change at page 71, line 29
same setting multiple times in the same frame. WINDOW_UPDATE or same setting multiple times in the same frame. WINDOW_UPDATE or
PRIORITY frames can be abused to cause an unnecessary waste of PRIORITY frames can be abused to cause an unnecessary waste of
resources. resources.
Large numbers of small or empty frames can be abused to cause a peer Large numbers of small or empty frames can be abused to cause a peer
to expend time processing frame headers. Note however that some uses to expend time processing frame headers. Note however that some uses
are entirely legitimate, such as the sending of an empty DATA or are entirely legitimate, such as the sending of an empty DATA or
CONTINUATION frame at the end of a stream. CONTINUATION frame at the end of a stream.
Header compression also offers some opportunities to waste processing Header compression also offers some opportunities to waste processing
resources; see Section 8 of [COMPRESSION] for more details on resources; see Section 7 of [COMPRESSION] for more details on
potential abuses. potential abuses.
Limits in SETTINGS parameters cannot be reduced instantaneously, Limits in SETTINGS parameters cannot be reduced instantaneously,
which leaves an endpoint exposed to behavior from a peer that could which leaves an endpoint exposed to behavior from a peer that could
exceed the new limits. In particular, immediately after establishing exceed the new limits. In particular, immediately after establishing
a connection, limits set by a server are not known to clients and a connection, limits set by a server are not known to clients and
could be exceeded without being an obvious protocol violation. could be exceeded without being an obvious protocol violation.
All these features - i.e., SETTINGS changes, small frames, header All these features - i.e., SETTINGS changes, small frames, header
compression - have legitimate uses. These features become a burden compression - have legitimate uses. These features become a burden
skipping to change at page 70, line 51 skipping to change at page 72, line 51
characteristics of the web (e.g., [BREACH]). The attacker induces characteristics of the web (e.g., [BREACH]). The attacker induces
multiple requests containing varying plaintext, observing the length multiple requests containing varying plaintext, observing the length
of the resulting ciphertext in each, which reveals a shorter length of the resulting ciphertext in each, which reveals a shorter length
when a guess about the secret is correct. when a guess about the secret is correct.
Implementations communicating on a secure channel MUST NOT compress Implementations communicating on a secure channel MUST NOT compress
content that includes both confidential and attacker-controlled data content that includes both confidential and attacker-controlled data
unless separate compression dictionaries are used for each source of unless separate compression dictionaries are used for each source of
data. Compression MUST NOT be used if the source of data cannot be data. Compression MUST NOT be used if the source of data cannot be
reliably determined. Generic stream compression, such as that reliably determined. Generic stream compression, such as that
provided by TLS MUST NOT be used with HTTP/2 (Section 9.2.1). provided by TLS MUST NOT be used with HTTP/2 (Section 9.2).
Further considerations regarding the compression of header fields are Further considerations regarding the compression of header fields are
described in [COMPRESSION]. described in [COMPRESSION].
10.7. Use of Padding 10.7. Use of Padding
Padding within HTTP/2 is not intended as a replacement for general Padding within HTTP/2 is not intended as a replacement for general
purpose padding, such as might be provided by TLS [TLS12]. Redundant purpose padding, such as might be provided by TLS [TLS12]. Redundant
padding could even be counterproductive. Correct application can padding could even be counterproductive. Correct application can
depend on having specific knowledge of the data that is being padded. depend on having specific knowledge of the data that is being padded.
skipping to change at page 72, line 5 skipping to change at page 73, line 51
to correlate actions of a single client or server over time. This to correlate actions of a single client or server over time. This
includes the value of settings, the manner in which flow control includes the value of settings, the manner in which flow control
windows are managed, the way priorities are allocated to streams, windows are managed, the way priorities are allocated to streams,
timing of reactions to stimulus, and handling of any optional timing of reactions to stimulus, and handling of any optional
features. features.
As far as this creates observable differences in behavior, they could As far as this creates observable differences in behavior, they could
be used as a basis for fingerprinting a specific client, as defined be used as a basis for fingerprinting a specific client, as defined
in Section 1.8 of [HTML5]. in Section 1.8 of [HTML5].
HTTP/2's preference for using a single TCP connection allows
correlation of a user's activity on a site. If connections are
reused for different origins, this allows tracking across those
origins.
Because the PING and SETTINGS frames solicit immediate responses,
they can be used by an endpoint to measure latency to their peer.
This might have privacy implications in certain scenarios.
11. IANA Considerations 11. IANA Considerations
A string for identifying HTTP/2 is entered into the "Application A string for identifying HTTP/2 is entered into the "Application
Layer Protocol Negotiation (ALPN) Protocol IDs" registry established Layer Protocol Negotiation (ALPN) Protocol IDs" registry established
in [TLS-ALPN]. in [TLS-ALPN].
This document establishes a registry for frame types, settings, and This document establishes a registry for frame types, settings, and
error codes. These new registries are entered into a new "Hypertext error codes. These new registries are entered into a new "Hypertext
Transfer Protocol (HTTP) 2 Parameters" section. Transfer Protocol (HTTP) 2 Parameters" section.
skipping to change at page 75, line 30 skipping to change at page 77, line 32
| CANCEL | 0x8 | Stream cancelled | Section 7 | | CANCEL | 0x8 | Stream cancelled | Section 7 |
| COMPRESSION_ERROR | 0x9 | Compression state | Section 7 | | COMPRESSION_ERROR | 0x9 | Compression state | Section 7 |
| | | not updated | | | | | not updated | |
| CONNECT_ERROR | 0xa | TCP connection error | Section 7 | | CONNECT_ERROR | 0xa | TCP connection error | Section 7 |
| | | for CONNECT method | | | | | for CONNECT method | |
| ENHANCE_YOUR_CALM | 0xb | Processing capacity | Section 7 | | ENHANCE_YOUR_CALM | 0xb | Processing capacity | Section 7 |
| | | exceeded | | | | | exceeded | |
| INADEQUATE_SECURITY | 0xc | Negotiated TLS | Section 7 | | INADEQUATE_SECURITY | 0xc | Negotiated TLS | Section 7 |
| | | parameters not | | | | | parameters not | |
| | | acceptable | | | | | acceptable | |
| HTTP_1_1_REQUIRED | 0xc | Use HTTP/1.1 for the | Section 7 | | HTTP_1_1_REQUIRED | 0xd | Use HTTP/1.1 for the | Section 7 |
| | | request | | | | | request | |
+---------------------+------+----------------------+---------------+ +---------------------+------+----------------------+---------------+
11.5. HTTP2-Settings Header Field Registration 11.5. HTTP2-Settings Header Field Registration
This section registers the "HTTP2-Settings" header field in the This section registers the "HTTP2-Settings" header field in the
Permanent Message Header Field Registry [BCP90]. Permanent Message Header Field Registry [BCP90].
Header field name: HTTP2-Settings Header field name: HTTP2-Settings
skipping to change at page 77, line 5 skipping to change at page 79, line 5
o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism). o Gabriel Montenegro and Willy Tarreau (Upgrade mechanism).
o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro, o William Chan, Salvatore Loreto, Osama Mazahir, Gabriel Montenegro,
Jitu Padhye, Roberto Peon, Rob Trace (Flow control). Jitu Padhye, Roberto Peon, Rob Trace (Flow control).
o Mike Bishop (Extensibility). o Mike Bishop (Extensibility).
o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike o Mark Nottingham, Julian Reschke, James Snell, Jeff Pinner, Mike
Bishop, Herve Ruellan (Substantial editorial contributions). Bishop, Herve Ruellan (Substantial editorial contributions).
o Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp. o Kari Hurtta, Tatsuhiro Tsujikawa, Greg Wilkins, Poul-Henning Kamp,
Jonathan Thackray.
o Alexey Melnikov was an editor of this document during 2013. o Alexey Melnikov was an editor of this document during 2013.
o A substantial proportion of Martin's contribution was supported by o A substantial proportion of Martin's contribution was supported by
Microsoft during his employment there. Microsoft during his employment there.
o The Japanese HTTP/2 community provided an invaluable contribution,
including a number of implementations, plus numerous technical and
editorial contributions.
13. References 13. References
13.1. Normative References 13.1. Normative References
[COMPRESSION] [COMPRESSION]
Ruellan, H. and R. Peon, "HPACK - Header Compression for Ruellan, H. and R. Peon, "HPACK - Header Compression for
HTTP/2", draft-ietf-httpbis-header-compression-09 (work in HTTP/2", draft-ietf-httpbis-header-compression-10 (work in
progress), July 2014. progress), November 2014.
[COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265, [COOKIE] Barth, A., "HTTP State Management Mechanism", RFC 6265,
April 2011. April 2011.
[FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4, [FIPS186] NIST, "Digital Signature Standard (DSS)", FIPS PUB 186-4,
July 2013. July 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 78, line 29 skipping to change at page 80, line 37
[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC [TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC
793, September 1981. 793, September 1981.
[TLS-ALPN] [TLS-ALPN]
Friedl, S., Popov, A., Langley, A., and E. Stephan, Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, July 2014. Negotiation Extension", RFC 7301, July 2014.
[TLS-ECDHE] [TLS-ECDHE]
Rescorla, E., "TLS Elliptic Curve Cipher Suites with Rescorla, E., "TLS Elliptic Curve Cipher Suites with SHA-
SHA-256/384 and AES Galois Counter Mode (GCM)", RFC 5289, 256/384 and AES Galois Counter Mode (GCM)", RFC 5289,
August 2008. August 2008.
[TLS-EXT] Eastlake, D., "Transport Layer Security (TLS) Extensions: [TLS-EXT] Eastlake, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", RFC 6066, January 2011. Extension Definitions", RFC 6066, January 2011.
[TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS12] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
13.2. Informative References 13.2. Informative References
[ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALT-SVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", draft-ietf-httpbis-alt-svc-04 (work Alternative Services", draft-ietf-httpbis-alt-svc-04 (work
in progress), October 2014. in progress), October 2014.
[BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration
Procedures for Message Header Fields", BCP 90, RFC 3864, Procedures for Message Header Fields", BCP 90, RFC 3864,
September 2004. September 2004.
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
CRIME Attack", July 2013, <http://breachattack.com/ CRIME Attack", July 2013,
resources/ <http://breachattack.com/resources/
BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>. BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[HTML5] Berjon, R., Faulkner, S., Leithead, T., Doyle Navara, E., [HTML5] Hickson, I., Berjon, R., Faulkner, S., Leithead, T., Doyle
O'Connor, E., and S. Pfeiffer, "HTML5", W3C Candidate Navara, E., O'Connor, E., and S. Pfeiffer, "HTML5", W3C
Recommendation CR-html5-20140731, July 2014, Recommendation REC-html5-20141028, October 2014,
<http://www.w3.org/TR/2014/CR-html5-20140731/>. <http://www.w3.org/TR/2014/REC-html5-20141028/>.
Latest version available at [5]. Latest version available at [5].
[RFC3749] Hollenbeck, S., "Transport Layer Security Protocol [RFC3749] Hollenbeck, S., "Transport Layer Security Protocol
Compression Methods", RFC 3749, May 2004. Compression Methods", RFC 3749, May 2004.
[RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B. [RFC4492] Blake-Wilson, S., Bolyard, N., Gupta, V., Hawk, C., and B.
Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites Moeller, "Elliptic Curve Cryptography (ECC) Cipher Suites
for Transport Layer Security (TLS)", RFC 4492, May 2006. for Transport Layer Security (TLS)", RFC 4492, May 2006.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, April 2012. Codes", RFC 6585, April 2012.
[RFC7323] Borman, D., Braden, B., Jacobson, V., and R. [RFC7323] Borman, D., Braden, B., Jacobson, V., and R.
Scheffenegger, "TCP Extensions for High Performance", RFC Scheffenegger, "TCP Extensions for High Performance", RFC
7323, September 2014. 7323, September 2014.
[TALKING] Huang, L-S., Chen, E., Barth, A., Rescorla, E., and C. [TALKING] Huang, L-S., 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>.
[TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre, [TLSBCP] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of TLS and DTLS", draft- "Recommendations for Secure Use of TLS and DTLS", draft-
ietf-uta-tls-bcp-01 (work in progress), June 2014. ietf-uta-tls-bcp-07 (work in progress), November 2014.
13.3. URIs 13.3. URIs
[1] https://www.iana.org/assignments/message-headers [1] https://www.iana.org/assignments/message-headers
[2] https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/ [2] https://groups.google.com/forum/?fromgroups#!topic/spdy-dev/
cfUef2gL3iU cfUef2gL3iU
[3] https://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc- [3] https://tools.ietf.org/html/draft-montenegro-httpbis-http2-fc-
principles-01 principles-01
Appendix A. Change Log Appendix A. Prohibited TLS 1.2 Cipher Suites
The following cipher suites are prohibited for use in HTTP/2 over TLS
1.2: TLS_NULL_WITH_NULL_NULL, TLS_RSA_WITH_NULL_MD5,
TLS_RSA_WITH_NULL_SHA, TLS_RSA_EXPORT_WITH_RC4_40_MD5,
TLS_RSA_WITH_RC4_128_MD5, TLS_RSA_WITH_RC4_128_SHA,
TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5, TLS_RSA_WITH_IDEA_CBC_SHA,
TLS_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_RSA_WITH_DES_CBC_SHA,
TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA,
TLS_DH_DSS_WITH_DES_CBC_SHA, TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_DH_RSA_WITH_DES_CBC_SHA,
TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_DHE_DSS_WITH_DES_CBC_SHA,
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, TLS_DHE_RSA_WITH_DES_CBC_SHA,
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_DH_anon_EXPORT_WITH_RC4_40_MD5, TLS_DH_anon_WITH_RC4_128_MD5,
TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA, TLS_DH_anon_WITH_DES_CBC_SHA,
TLS_DH_anon_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_DES_CBC_SHA,
TLS_KRB5_WITH_3DES_EDE_CBC_SHA, TLS_KRB5_WITH_RC4_128_SHA,
TLS_KRB5_WITH_IDEA_CBC_SHA, TLS_KRB5_WITH_DES_CBC_MD5,
TLS_KRB5_WITH_3DES_EDE_CBC_MD5, TLS_KRB5_WITH_RC4_128_MD5,
TLS_KRB5_WITH_IDEA_CBC_MD5, TLS_KRB5_EXPORT_WITH_DES_CBC_40_SHA,
TLS_KRB5_EXPORT_WITH_RC2_CBC_40_SHA, TLS_KRB5_EXPORT_WITH_RC4_40_SHA,
TLS_KRB5_EXPORT_WITH_DES_CBC_40_MD5,
TLS_KRB5_EXPORT_WITH_RC2_CBC_40_MD5, TLS_KRB5_EXPORT_WITH_RC4_40_MD5,
TLS_PSK_WITH_NULL_SHA, TLS_DHE_PSK_WITH_NULL_SHA,
TLS_RSA_PSK_WITH_NULL_SHA, TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_DSS_WITH_AES_128_CBC_SHA, TLS_DH_RSA_WITH_AES_128_CBC_SHA,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA,
TLS_DH_anon_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA,
TLS_DH_DSS_WITH_AES_256_CBC_SHA, TLS_DH_RSA_WITH_AES_256_CBC_SHA,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA,
TLS_DH_anon_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_NULL_SHA256,
TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA256,
TLS_DH_DSS_WITH_AES_128_CBC_SHA256,
TLS_DH_RSA_WITH_AES_128_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256,
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA,
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA,
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA,
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_DH_DSS_WITH_AES_256_CBC_SHA256,
TLS_DH_RSA_WITH_AES_256_CBC_SHA256,
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256,
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256,
TLS_DH_anon_WITH_AES_128_CBC_SHA256,
TLS_DH_anon_WITH_AES_256_CBC_SHA256,
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA,
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA,
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA, TLS_PSK_WITH_RC4_128_SHA,
TLS_PSK_WITH_3DES_EDE_CBC_SHA, TLS_PSK_WITH_AES_128_CBC_SHA,
TLS_PSK_WITH_AES_256_CBC_SHA, TLS_DHE_PSK_WITH_RC4_128_SHA,
TLS_DHE_PSK_WITH_3DES_EDE_CBC_SHA, TLS_DHE_PSK_WITH_AES_128_CBC_SHA,
TLS_DHE_PSK_WITH_AES_256_CBC_SHA, TLS_RSA_PSK_WITH_RC4_128_SHA,
TLS_RSA_PSK_WITH_3DES_EDE_CBC_SHA, TLS_RSA_PSK_WITH_AES_128_CBC_SHA,
TLS_RSA_PSK_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_SEED_CBC_SHA,
TLS_DH_DSS_WITH_SEED_CBC_SHA, TLS_DH_RSA_WITH_SEED_CBC_SHA,
TLS_DHE_DSS_WITH_SEED_CBC_SHA, TLS_DHE_RSA_WITH_SEED_CBC_SHA,
TLS_DH_anon_WITH_SEED_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256,
TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_DH_RSA_WITH_AES_128_GCM_SHA256,
TLS_DH_RSA_WITH_AES_256_GCM_SHA384,
TLS_DH_DSS_WITH_AES_128_GCM_SHA256,
TLS_DH_DSS_WITH_AES_256_GCM_SHA384,
TLS_DH_anon_WITH_AES_128_GCM_SHA256,
TLS_DH_anon_WITH_AES_256_GCM_SHA384, TLS_PSK_WITH_AES_128_GCM_SHA256,
TLS_PSK_WITH_AES_256_GCM_SHA384, TLS_RSA_PSK_WITH_AES_128_GCM_SHA256,
TLS_RSA_PSK_WITH_AES_256_GCM_SHA384, TLS_PSK_WITH_AES_128_CBC_SHA256,
TLS_PSK_WITH_AES_256_CBC_SHA384, TLS_PSK_WITH_NULL_SHA256,
TLS_PSK_WITH_NULL_SHA384, TLS_DHE_PSK_WITH_AES_128_CBC_SHA256,
TLS_DHE_PSK_WITH_AES_256_CBC_SHA384, TLS_DHE_PSK_WITH_NULL_SHA256,
TLS_DHE_PSK_WITH_NULL_SHA384, TLS_RSA_PSK_WITH_AES_128_CBC_SHA256,
TLS_RSA_PSK_WITH_AES_256_CBC_SHA384, TLS_RSA_PSK_WITH_NULL_SHA256,
TLS_RSA_PSK_WITH_NULL_SHA384, TLS_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DH_anon_WITH_CAMELLIA_128_CBC_SHA256,
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA256,
TLS_DH_anon_WITH_CAMELLIA_256_CBC_SHA256,
TLS_EMPTY_RENEGOTIATION_INFO_SCSV, TLS_ECDH_ECDSA_WITH_NULL_SHA,
TLS_ECDH_ECDSA_WITH_RC4_128_SHA,
TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_NULL_SHA,
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA,
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDH_RSA_WITH_NULL_SHA,
TLS_ECDH_RSA_WITH_RC4_128_SHA, TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA, TLS_ECDH_RSA_WITH_AES_256_CBC_SHA,
TLS_ECDHE_RSA_WITH_NULL_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA,
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDH_anon_WITH_NULL_SHA,
TLS_ECDH_anon_WITH_RC4_128_SHA, TLS_ECDH_anon_WITH_3DES_EDE_CBC_SHA,
TLS_ECDH_anon_WITH_AES_128_CBC_SHA,
TLS_ECDH_anon_WITH_AES_256_CBC_SHA,
TLS_SRP_SHA_WITH_3DES_EDE_CBC_SHA,
TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA,
TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA,
TLS_SRP_SHA_WITH_AES_128_CBC_SHA,
TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA,
TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA,
TLS_SRP_SHA_WITH_AES_256_CBC_SHA,
TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA,
TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA,
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_PSK_WITH_RC4_128_SHA,
TLS_ECDHE_PSK_WITH_3DES_EDE_CBC_SHA,
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA,
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA,
TLS_ECDHE_PSK_WITH_AES_128_CBC_SHA256,
TLS_ECDHE_PSK_WITH_AES_256_CBC_SHA384, TLS_ECDHE_PSK_WITH_NULL_SHA,
TLS_ECDHE_PSK_WITH_NULL_SHA256, TLS_ECDHE_PSK_WITH_NULL_SHA384,
TLS_RSA_WITH_ARIA_128_CBC_SHA256, TLS_RSA_WITH_ARIA_256_CBC_SHA384,
TLS_DH_DSS_WITH_ARIA_128_CBC_SHA256,
TLS_DH_DSS_WITH_ARIA_256_CBC_SHA384,
TLS_DH_RSA_WITH_ARIA_128_CBC_SHA256,
TLS_DH_RSA_WITH_ARIA_256_CBC_SHA384,
TLS_DHE_DSS_WITH_ARIA_128_CBC_SHA256,
TLS_DHE_DSS_WITH_ARIA_256_CBC_SHA384,
TLS_DHE_RSA_WITH_ARIA_128_CBC_SHA256,
TLS_DHE_RSA_WITH_ARIA_256_CBC_SHA384,
TLS_DH_anon_WITH_ARIA_128_CBC_SHA256,
TLS_DH_anon_WITH_ARIA_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_ARIA_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_ARIA_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_ARIA_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_ARIA_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_ARIA_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_ARIA_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_ARIA_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_ARIA_256_CBC_SHA384,
TLS_RSA_WITH_ARIA_128_GCM_SHA256, TLS_RSA_WITH_ARIA_256_GCM_SHA384,
TLS_DH_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_DH_RSA_WITH_ARIA_256_GCM_SHA384,
TLS_DH_DSS_WITH_ARIA_128_GCM_SHA256,
TLS_DH_DSS_WITH_ARIA_256_GCM_SHA384,
TLS_DH_anon_WITH_ARIA_128_GCM_SHA256,
TLS_DH_anon_WITH_ARIA_256_GCM_SHA384,
TLS_ECDH_ECDSA_WITH_ARIA_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_ARIA_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_ARIA_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_ARIA_256_GCM_SHA384,
TLS_PSK_WITH_ARIA_128_CBC_SHA256, TLS_PSK_WITH_ARIA_256_CBC_SHA384,
TLS_DHE_PSK_WITH_ARIA_128_CBC_SHA256,
TLS_DHE_PSK_WITH_ARIA_256_CBC_SHA384,
TLS_RSA_PSK_WITH_ARIA_128_CBC_SHA256,
TLS_RSA_PSK_WITH_ARIA_256_CBC_SHA384,
TLS_PSK_WITH_ARIA_128_GCM_SHA256, TLS_PSK_WITH_ARIA_256_GCM_SHA384,
TLS_RSA_PSK_WITH_ARIA_128_GCM_SHA256,
TLS_RSA_PSK_WITH_ARIA_256_GCM_SHA384,
TLS_ECDHE_PSK_WITH_ARIA_128_CBC_SHA256,
TLS_ECDHE_PSK_WITH_ARIA_256_CBC_SHA384,
TLS_ECDHE_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDHE_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_RSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDH_RSA_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDH_RSA_WITH_CAMELLIA_256_CBC_SHA384,
TLS_RSA_WITH_CAMELLIA_128_GCM_SHA256,
TLS_RSA_WITH_CAMELLIA_256_GCM_SHA384,
TLS_DH_RSA_WITH_CAMELLIA_128_GCM_SHA256,
TLS_DH_RSA_WITH_CAMELLIA_256_GCM_SHA384,
TLS_DH_DSS_WITH_CAMELLIA_128_GCM_SHA256,
TLS_DH_DSS_WITH_CAMELLIA_256_GCM_SHA384,
TLS_DH_anon_WITH_CAMELLIA_128_GCM_SHA256,
TLS_DH_anon_WITH_CAMELLIA_256_GCM_SHA384,
TLS_ECDH_ECDSA_WITH_CAMELLIA_128_GCM_SHA256,
TLS_ECDH_ECDSA_WITH_CAMELLIA_256_GCM_SHA384,
TLS_ECDH_RSA_WITH_CAMELLIA_128_GCM_SHA256,
TLS_ECDH_RSA_WITH_CAMELLIA_256_GCM_SHA384,
TLS_PSK_WITH_CAMELLIA_128_GCM_SHA256,
TLS_PSK_WITH_CAMELLIA_256_GCM_SHA384,
TLS_RSA_PSK_WITH_CAMELLIA_128_GCM_SHA256,
TLS_RSA_PSK_WITH_CAMELLIA_256_GCM_SHA384,
TLS_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_DHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_DHE_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_RSA_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_RSA_PSK_WITH_CAMELLIA_256_CBC_SHA384,
TLS_ECDHE_PSK_WITH_CAMELLIA_128_CBC_SHA256,
TLS_ECDHE_PSK_WITH_CAMELLIA_256_CBC_SHA384, TLS_RSA_WITH_AES_128_CCM,
TLS_RSA_WITH_AES_256_CCM, TLS_RSA_WITH_AES_128_CCM_8,
TLS_RSA_WITH_AES_256_CCM_8, TLS_PSK_WITH_AES_128_CCM,
TLS_PSK_WITH_AES_256_CCM, TLS_PSK_WITH_AES_128_CCM_8,
TLS_PSK_WITH_AES_256_CCM_8.
Note: This list was assembled from the set of registered TLS cipher
suites at the time of writing. This list includes those cipher
suites that do not offer an ephemeral key exchange and those that
are based on the TLS null, stream or block cipher type (as defined
in Section 6.2.3 of [TLS12]). Additional cipher suites with these
properties could be defined; these would not be explicitly
prohibited.
Appendix B. Change Log
This section is to be removed by RFC Editor before publication. This section is to be removed by RFC Editor before publication.
A.1. Since draft-ietf-httpbis-http2-14 B.1. Since draft-ietf-httpbis-http2-15
Enabled the sending of PRIORITY for any stream state.
Added a cipher suite blacklist and made several changes to the TLS
usage section.
B.2. Since draft-ietf-httpbis-http2-14
Renamed Not Authoritative status code to Misdirected Request. Renamed Not Authoritative status code to Misdirected Request.
A.2. Since draft-ietf-httpbis-http2-13 Added HTTP_1_1_REQUIRED error code.
B.3. Since draft-ietf-httpbis-http2-13
Pseudo-header fields are now required to appear strictly before Pseudo-header fields are now required to appear strictly before
regular ones. regular ones.
Restored 1xx series status codes, except 101. Restored 1xx series status codes, except 101.
Changed frame length field 24-bits. Expanded frame header to 9 Changed frame length field 24-bits. Expanded frame header to 9
octets. Added a setting to limit the damage. octets. Added a setting to limit the damage.
Added a setting to advise peers of header set size limits. Added a setting to advise peers of header set size limits.
Removed segments. Removed segments.
Made non-semantic-bearing HEADERS frames illegal in the HTTP mapping. Made non-semantic-bearing HEADERS frames illegal in the HTTP mapping.
A.3. Since draft-ietf-httpbis-http2-12 B.4. Since draft-ietf-httpbis-http2-12
Restored extensibility options. Restored extensibility options.
Restricting TLS cipher suites to AEAD only. Restricting TLS cipher suites to AEAD only.
Removing Content-Encoding requirements. Removing Content-Encoding requirements.
Permitting the use of PRIORITY after stream close. Permitting the use of PRIORITY after stream close.
Removed ALTSVC frame. Removed ALTSVC frame.
Removed BLOCKED frame. Removed BLOCKED frame.
Reducing the maximum padding size to 256 octets; removing padding Reducing the maximum padding size to 256 octets; removing padding
from CONTINUATION frames. from CONTINUATION frames.
Removed per-frame GZIP compression. Removed per-frame GZIP compression.
A.4. Since draft-ietf-httpbis-http2-11 B.5. Since draft-ietf-httpbis-http2-11
Added BLOCKED frame (at risk). Added BLOCKED frame (at risk).
Simplified priority scheme. Simplified priority scheme.
Added DATA per-frame GZIP compression. Added DATA per-frame GZIP compression.
A.5. Since draft-ietf-httpbis-http2-10 B.6. Since draft-ietf-httpbis-http2-10
Changed "connection header" to "connection preface" to avoid Changed "connection header" to "connection preface" to avoid
confusion. confusion.
Added dependency-based stream prioritization. Added dependency-based stream prioritization.
Added "h2c" identifier to distinguish between cleartext and secured Added "h2c" identifier to distinguish between cleartext and secured
HTTP/2. HTTP/2.
Adding missing padding to PUSH_PROMISE. Adding missing padding to PUSH_PROMISE.
Integrate ALTSVC frame and supporting text. Integrate ALTSVC frame and supporting text.
Dropping requirement on "deflate" Content-Encoding. Dropping requirement on "deflate" Content-Encoding.
Improving security considerations around use of compression. Improving security considerations around use of compression.
A.6. Since draft-ietf-httpbis-http2-09 B.7. Since draft-ietf-httpbis-http2-09
Adding padding for data frames. Adding padding for data frames.
Renumbering frame types, error codes, and settings. Renumbering frame types, error codes, and settings.
Adding INADEQUATE_SECURITY error code. Adding INADEQUATE_SECURITY error code.
Updating TLS usage requirements to 1.2; forbidding TLS compression. Updating TLS usage requirements to 1.2; forbidding TLS compression.
Removing extensibility for frames and settings. Removing extensibility for frames and settings.
skipping to change at page 82, line 5 skipping to change at page 88, line 43
Changing the protocol identification token to "h2". Changing the protocol identification token to "h2".
Changing the use of :authority to make it optional and to allow Changing the use of :authority to make it optional and to allow
userinfo in non-HTTP cases. userinfo in non-HTTP cases.
Allowing split on 0x0 for Cookie. Allowing split on 0x0 for Cookie.
Reserved PRI method in HTTP/1.1 to avoid possible future collisions. Reserved PRI method in HTTP/1.1 to avoid possible future collisions.
A.7. Since draft-ietf-httpbis-http2-08 B.8. Since draft-ietf-httpbis-http2-08
Added cookie crumbling for more efficient header compression. Added cookie crumbling for more efficient header compression.
Added header field ordering with the value-concatenation mechanism. Added header field ordering with the value-concatenation mechanism.
A.8. Since draft-ietf-httpbis-http2-07 B.9. Since draft-ietf-httpbis-http2-07
Marked draft for implementation. Marked draft for implementation.
A.9. Since draft-ietf-httpbis-http2-06 B.10. Since draft-ietf-httpbis-http2-06
Adding definition for CONNECT method. Adding definition for CONNECT method.
Constraining the use of push to safe, cacheable methods with no Constraining the use of push to safe, cacheable methods with no
request body. request body.
Changing from :host to :authority to remove any potential confusion. Changing from :host to :authority to remove any potential confusion.
Adding setting for header compression table size. Adding setting for header compression table size.
Adding settings acknowledgement. Adding settings acknowledgement.
Removing unnecessary and potentially problematic flags from Removing unnecessary and potentially problematic flags from
CONTINUATION. CONTINUATION.
Added denial of service considerations. Added denial of service considerations.
A.10. Since draft-ietf-httpbis-http2-05 B.11. Since draft-ietf-httpbis-http2-05
Marking the draft ready for implementation. Marking the draft ready for implementation.
Renumbering END_PUSH_PROMISE flag. Renumbering END_PUSH_PROMISE flag.
Editorial clarifications and changes. Editorial clarifications and changes.
A.11. Since draft-ietf-httpbis-http2-04 B.12. Since draft-ietf-httpbis-http2-04
Added CONTINUATION frame for HEADERS and PUSH_PROMISE. Added CONTINUATION frame for HEADERS and PUSH_PROMISE.
PUSH_PROMISE is no longer implicitly prohibited if PUSH_PROMISE is no longer implicitly prohibited if
SETTINGS_MAX_CONCURRENT_STREAMS is zero. SETTINGS_MAX_CONCURRENT_STREAMS is zero.
Push expanded to allow all safe methods without a request body. Push expanded to allow all safe methods without a request body.
Clarified the use of HTTP header fields in requests and responses. Clarified the use of HTTP header fields in requests and responses.
Prohibited HTTP/1.1 hop-by-hop header fields. Prohibited HTTP/1.1 hop-by-hop header fields.
skipping to change at page 83, line 18 skipping to change at page 90, line 12
Clarified requirements around handling different frames after stream Clarified requirements around handling different frames after stream
close, stream reset and GOAWAY. close, stream reset and GOAWAY.
Added more specific prohibitions for sending of different frame types Added more specific prohibitions for sending of different frame types
in various stream states. in various stream states.
Making the last received setting value the effective value. Making the last received setting value the effective value.
Clarified requirements on TLS version, extension and ciphers. Clarified requirements on TLS version, extension and ciphers.
A.12. Since draft-ietf-httpbis-http2-03 B.13. Since draft-ietf-httpbis-http2-03
Committed major restructuring atrocities. Committed major restructuring atrocities.
Added reference to first header compression draft. Added reference to first header compression draft.
Added more formal description of frame lifecycle. Added more formal description of frame lifecycle.
Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA. Moved END_STREAM (renamed from FINAL) back to HEADERS/DATA.
Removed HEADERS+PRIORITY, added optional priority to HEADERS frame. Removed HEADERS+PRIORITY, added optional priority to HEADERS frame.
Added PRIORITY frame. Added PRIORITY frame.
A.13. Since draft-ietf-httpbis-http2-02 B.14. Since draft-ietf-httpbis-http2-02
Added continuations to frames carrying header blocks. Added continuations to frames carrying header blocks.
Replaced use of "session" with "connection" to avoid confusion with Replaced use of "session" with "connection" to avoid confusion with
other HTTP stateful concepts, like cookies. other HTTP stateful concepts, like cookies.
Removed "message". Removed "message".
Switched to TLS ALPN from NPN. Switched to TLS ALPN from NPN.
Editorial changes. Editorial changes.
A.14. Since draft-ietf-httpbis-http2-01 B.15. Since draft-ietf-httpbis-http2-01
Added IANA considerations section for frame types, error codes and Added IANA considerations section for frame types, error codes and
settings. settings.
Removed data frame compression. Removed data frame compression.
Added PUSH_PROMISE. Added PUSH_PROMISE.
Added globally applicable flags to framing. Added globally applicable flags to framing.
skipping to change at page 84, line 29 skipping to change at page 91, line 23
Restructured frame header. Removed distinction between data and Restructured frame header. Removed distinction between data and
control frames. control frames.
Altered flow control properties to include session-level limits. Altered flow control properties to include session-level limits.
Added note on cacheability of pushed resources and multiple tenant Added note on cacheability of pushed resources and multiple tenant
servers. servers.
Changed protocol label form based on discussions. Changed protocol label form based on discussions.
A.15. Since draft-ietf-httpbis-http2-00 B.16. Since draft-ietf-httpbis-http2-00
Changed title throughout. Changed title throughout.
Removed section on Incompatibilities with SPDY draft#2. Removed section on Incompatibilities with SPDY draft#2.
Changed INTERNAL_ERROR on GOAWAY to have a value of 2 [6]. Changed INTERNAL_ERROR on GOAWAY to have a value of 2 [6].
Replaced abstract and introduction. Replaced abstract and introduction.
Added section on starting HTTP/2.0, including upgrade mechanism. Added section on starting HTTP/2.0, including upgrade mechanism.
Removed unused references. Removed unused references.
Added flow control principles (Section 5.2.1) based on [7]. Added flow control principles (Section 5.2.1) based on [7].
A.16. Since draft-mbelshe-httpbis-spdy-00 B.17. Since draft-mbelshe-httpbis-spdy-00
Adopted as base for draft-ietf-httpbis-http2. Adopted as base for draft-ietf-httpbis-http2.
Updated authors/editors list. Updated authors/editors list.
Added status note. Added status note.
Authors' Addresses Authors' Addresses
Mike Belshe Mike Belshe
 End of changes. 79 change blocks. 
310 lines changed or deleted 589 lines changed or added

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