| 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.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ | ||||