draft-ietf-quic-http-33.txt | draft-ietf-quic-http-latest.txt | |||
---|---|---|---|---|
QUIC Working Group M. Bishop, Ed. | QUIC Working Group M. Bishop, Ed. | |||
Internet-Draft Akamai | Internet-Draft Akamai | |||
Intended status: Standards Track December 15, 2020 | Intended status: Standards Track January 27, 2021 | |||
Expires: June 18, 2021 | Expires: July 31, 2021 | |||
Hypertext Transfer Protocol Version 3 (HTTP/3) | Hypertext Transfer Protocol Version 3 (HTTP/3) | |||
draft-ietf-quic-http-33 | draft-ietf-quic-http-latest | |||
Abstract | Abstract | |||
The QUIC transport protocol has several features that are desirable | The QUIC transport protocol has several features that are desirable | |||
in a transport for HTTP, such as stream multiplexing, per-stream flow | in a transport for HTTP, such as stream multiplexing, per-stream flow | |||
control, and low-latency connection establishment. This document | control, and low-latency connection establishment. This document | |||
describes a mapping of HTTP semantics over QUIC. This document also | describes a mapping of HTTP semantics over QUIC. This document also | |||
identifies HTTP/2 features that are subsumed by QUIC, and describes | identifies HTTP/2 features that are subsumed by QUIC, and describes | |||
how HTTP/2 extensions can be ported to HTTP/3. | how HTTP/2 extensions can be ported to HTTP/3. | |||
skipping to change at page 2, line 4 ¶ | skipping to change at page 2, line 4 ¶ | |||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF). Note that other groups may also distribute | Task Force (IETF). Note that other groups may also distribute | |||
working documents as Internet-Drafts. The list of current Internet- | working documents as Internet-Drafts. The list of current Internet- | |||
Drafts is at https://datatracker.ietf.org/drafts/current/. | Drafts is at https://datatracker.ietf.org/drafts/current/. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
and may be updated, replaced, or obsoleted by other documents at any | and may be updated, replaced, or obsoleted by other documents at any | |||
time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
This Internet-Draft will expire on June 18, 2021. | This Internet-Draft will expire on July 31, 2021. | |||
Copyright Notice | Copyright Notice | |||
Copyright (c) 2020 IETF Trust and the persons identified as the | Copyright (c) 2021 IETF Trust and the persons identified as the | |||
document authors. All rights reserved. | document authors. All rights reserved. | |||
This document is subject to BCP 78 and the IETF Trust's Legal | This document is subject to BCP 78 and the IETF Trust's Legal | |||
Provisions Relating to IETF Documents | Provisions Relating to IETF Documents | |||
(https://trustee.ietf.org/license-info) in effect on the date of | (https://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 | |||
carefully, as they describe your rights and restrictions with respect | carefully, as they describe your rights and restrictions with respect | |||
to this document. Code Components extracted from this document must | to this document. Code Components extracted from this document must | |||
include Simplified BSD License text as described in Section 4.e of | include Simplified BSD License text as described in Section 4.e of | |||
the Trust Legal Provisions and are provided without warranty as | the Trust Legal Provisions and are provided without warranty as | |||
described in the Simplified BSD License. | described in the Simplified BSD License. | |||
Table of Contents | Table of Contents | |||
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 | |||
1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 5 | 1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 5 | |||
1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5 | 1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5 | |||
2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 5 | 2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 6 | |||
2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 | 2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 | |||
2.2. Conventions and Terminology . . . . . . . . . . . . . . . 7 | 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 7 | |||
3. Connection Setup and Management . . . . . . . . . . . . . . . 8 | 3. Connection Setup and Management . . . . . . . . . . . . . . . 8 | |||
3.1. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 8 | 3.1. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 9 | |||
3.1.1. HTTP Alternative Services . . . . . . . . . . . . . . 9 | 3.1.1. HTTP Alternative Services . . . . . . . . . . . . . . 9 | |||
3.1.2. Other Schemes . . . . . . . . . . . . . . . . . . . . 10 | 3.1.2. Other Schemes . . . . . . . . . . . . . . . . . . . . 10 | |||
3.2. Connection Establishment . . . . . . . . . . . . . . . . 10 | 3.2. Connection Establishment . . . . . . . . . . . . . . . . 10 | |||
3.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 11 | 3.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 11 | |||
4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 11 | 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 12 | |||
4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 11 | 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 12 | |||
4.1.1. Field Formatting and Compression . . . . . . . . . . 13 | 4.1.1. Field Formatting and Compression . . . . . . . . . . 14 | |||
4.1.2. Request Cancellation and Rejection . . . . . . . . . 17 | 4.1.2. Request Cancellation and Rejection . . . . . . . . . 17 | |||
4.1.3. Malformed Requests and Responses . . . . . . . . . . 18 | 4.1.3. Malformed Requests and Responses . . . . . . . . . . 18 | |||
4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 19 | 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 19 | |||
4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 20 | 4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 20 | |||
4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 20 | 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21 | |||
5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 22 | 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 23 | |||
5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 22 | 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 23 | |||
5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 23 | 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 23 | |||
5.3. Immediate Application Closure . . . . . . . . . . . . . . 25 | 5.3. Immediate Application Closure . . . . . . . . . . . . . . 25 | |||
5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 25 | 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 26 | |||
6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 25 | 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 26 | |||
6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 26 | 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 26 | |||
6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 26 | 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 27 | |||
6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 27 | 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 28 | |||
6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 28 | 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 29 | |||
6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 28 | 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 29 | |||
7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 29 | 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 30 | |||
7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 30 | 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 31 | |||
7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 30 | 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 31 | |||
7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 30 | 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 31 | 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 32 | |||
7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 31 | 7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 32 | |||
7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 32 | 7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 34 | |||
7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 35 | 7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 37 | |||
7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 37 | 7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 38 | |||
7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 37 | 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 39 | |||
7.2.8. Reserved Frame Types . . . . . . . . . . . . . . . . 38 | 7.2.8. Reserved Frame Types . . . . . . . . . . . . . . . . 39 | |||
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 39 | 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 40 | |||
8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 39 | 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 41 | |||
9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 41 | 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 42 | |||
10. Security Considerations . . . . . . . . . . . . . . . . . . . 42 | 10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 | |||
10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 42 | 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 43 | |||
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 42 | 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 43 | |||
10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 42 | 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 43 | |||
10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 43 | 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 44 | |||
10.5. Denial-of-Service Considerations . . . . . . . . . . . . 43 | 10.5. Denial-of-Service Considerations . . . . . . . . . . . . 44 | |||
10.5.1. Limits on Field Section Size . . . . . . . . . . . . 44 | 10.5.1. Limits on Field Section Size . . . . . . . . . . . . 45 | |||
10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 44 | 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 46 | |||
10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 45 | 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 46 | |||
10.7. Padding and Traffic Analysis . . . . . . . . . . . . . . 45 | 10.7. Padding and Traffic Analysis . . . . . . . . . . . . . . 46 | |||
10.8. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 46 | 10.8. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 47 | |||
10.9. Early Data . . . . . . . . . . . . . . . . . . . . . . . 46 | 10.9. Early Data . . . . . . . . . . . . . . . . . . . . . . . 47 | |||
10.10. Migration . . . . . . . . . . . . . . . . . . . . . . . 46 | 10.10. Migration . . . . . . . . . . . . . . . . . . . . . . . 48 | |||
10.11. Privacy Considerations . . . . . . . . . . . . . . . . . 46 | 10.11. Privacy Considerations . . . . . . . . . . . . . . . . . 48 | |||
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47 | 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 | |||
11.1. Registration of HTTP/3 Identification String . . . . . . 47 | 11.1. Registration of HTTP/3 Identification String . . . . . . 48 | |||
11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 47 | 11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 49 | |||
11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 47 | 11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 49 | |||
11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 49 | 11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 50 | |||
11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 50 | 11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 51 | |||
11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 53 | 11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 54 | |||
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 | 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 | |||
12.1. Normative References . . . . . . . . . . . . . . . . . . 53 | 12.1. Normative References . . . . . . . . . . . . . . . . . . 54 | |||
12.2. Informative References . . . . . . . . . . . . . . . . . 55 | 12.2. Informative References . . . . . . . . . . . . . . . . . 56 | |||
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 56 | Appendix A. Considerations for Transitioning from HTTP/2 . . . . 57 | |||
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 56 | A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 57 | |||
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 57 | A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 58 | |||
A.2.1. Prioritization Differences . . . . . . . . . . . . . 57 | A.2.1. Prioritization Differences . . . . . . . . . . . . . 58 | |||
A.2.2. Field Compression Differences . . . . . . . . . . . . 57 | A.2.2. Field Compression Differences . . . . . . . . . . . . 59 | |||
A.2.3. Flow Control Differences . . . . . . . . . . . . . . 58 | A.2.3. Flow Control Differences . . . . . . . . . . . . . . 59 | |||
A.2.4. Guidance for New Frame Type Definitions . . . . . . . 58 | A.2.4. Guidance for New Frame Type Definitions . . . . . . . 59 | |||
A.2.5. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 58 | A.2.5. Comparison Between HTTP/2 and HTTP/3 Frame Types . . 60 | |||
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 59 | A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 61 | |||
A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 61 | A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 62 | |||
A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors . . . . . . 62 | A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors . . . . . . 63 | |||
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 62 | Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 64 | |||
B.1. Since draft-ietf-quic-http-32 . . . . . . . . . . . . . . 63 | B.1. Since draft-ietf-quic-http-32 . . . . . . . . . . . . . . 64 | |||
B.2. Since draft-ietf-quic-http-31 . . . . . . . . . . . . . . 63 | B.2. Since draft-ietf-quic-http-31 . . . . . . . . . . . . . . 64 | |||
B.3. Since draft-ietf-quic-http-30 . . . . . . . . . . . . . . 63 | B.3. Since draft-ietf-quic-http-30 . . . . . . . . . . . . . . 64 | |||
B.4. Since draft-ietf-quic-http-29 . . . . . . . . . . . . . . 63 | B.4. Since draft-ietf-quic-http-29 . . . . . . . . . . . . . . 64 | |||
B.5. Since draft-ietf-quic-http-28 . . . . . . . . . . . . . . 63 | B.5. Since draft-ietf-quic-http-28 . . . . . . . . . . . . . . 64 | |||
B.6. Since draft-ietf-quic-http-27 . . . . . . . . . . . . . . 63 | B.6. Since draft-ietf-quic-http-27 . . . . . . . . . . . . . . 64 | |||
B.7. Since draft-ietf-quic-http-26 . . . . . . . . . . . . . . 63 | B.7. Since draft-ietf-quic-http-26 . . . . . . . . . . . . . . 65 | |||
B.8. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 64 | B.8. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 65 | |||
B.9. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 64 | B.9. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 65 | |||
B.10. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 64 | B.10. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 65 | |||
B.11. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 64 | B.11. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 65 | |||
B.12. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 65 | B.12. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 66 | |||
B.13. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 65 | B.13. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 66 | |||
B.14. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 66 | B.14. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 67 | |||
B.15. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 66 | B.15. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 67 | |||
B.16. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 67 | B.16. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 68 | |||
B.17. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 67 | B.17. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 68 | |||
B.18. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 67 | B.18. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 68 | |||
B.19. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 67 | B.19. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 68 | |||
B.20. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 68 | B.20. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 69 | |||
B.21. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 68 | B.21. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 69 | |||
B.22. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 68 | B.22. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 69 | |||
B.23. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 68 | B.23. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 69 | |||
B.24. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 68 | B.24. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 70 | |||
B.25. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 69 | B.25. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 70 | |||
B.26. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 69 | B.26. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 70 | |||
B.27. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 69 | B.27. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 70 | |||
B.28. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 69 | B.28. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 70 | |||
B.29. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 69 | B.29. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 70 | |||
B.30. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 70 | B.30. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 71 | |||
B.31. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 70 | B.31. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 71 | |||
B.32. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 70 | B.32. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 71 | |||
B.33. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 70 | B.33. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 71 | |||
B.34. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 71 | B.34. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 72 | |||
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 71 | Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 72 | |||
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 72 | Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 73 | |||
1. Introduction | 1. Introduction | |||
HTTP semantics ([SEMANTICS]) are used for a broad range of services | HTTP semantics ([SEMANTICS]) are used for a broad range of services | |||
on the Internet. These semantics have most commonly been used with | on the Internet. These semantics have most commonly been used with | |||
HTTP/1.1, over a variety of transport and session layers, and with | HTTP/1.1 and HTTP/2. HTTP/1.1 has been used over a variety of | |||
HTTP/2 over TLS. HTTP/3 supports the same semantics over a new | transport and session layers, while HTTP/2 has been used primarily | |||
with TLS over TCP. HTTP/3 supports the same semantics over a new | ||||
transport protocol, QUIC. | transport protocol, QUIC. | |||
1.1. Prior versions of HTTP | 1.1. Prior versions of HTTP | |||
HTTP/1.1 ([HTTP11]) uses whitespace-delimited text fields to convey | HTTP/1.1 ([HTTP11]) uses whitespace-delimited text fields to convey | |||
HTTP messages. While these exchanges are human-readable, using | HTTP messages. While these exchanges are human-readable, using | |||
whitespace for message formatting leads to parsing complexity and | whitespace for message formatting leads to parsing complexity and | |||
excessive tolerance of variant behavior. Because HTTP/1.x does not | excessive tolerance of variant behavior. | |||
include a multiplexing layer, multiple TCP connections are often used | ||||
to service requests in parallel. However, that has a negative impact | Because HTTP/1.1 does not include a multiplexing layer, multiple TCP | |||
on congestion control and network efficiency, since TCP does not | connections are often used to service requests in parallel. However, | |||
share congestion control across multiple connections. | that has a negative impact on congestion control and network | |||
efficiency, since TCP does not share congestion control across | ||||
multiple connections. | ||||
HTTP/2 ([HTTP2]) introduced a binary framing and multiplexing layer | HTTP/2 ([HTTP2]) introduced a binary framing and multiplexing layer | |||
to improve latency without modifying the transport layer. However, | to improve latency without modifying the transport layer. However, | |||
because the parallel nature of HTTP/2's multiplexing is not visible | because the parallel nature of HTTP/2's multiplexing is not visible | |||
to TCP's loss recovery mechanisms, a lost or reordered packet causes | to TCP's loss recovery mechanisms, a lost or reordered packet causes | |||
all active transactions to experience a stall regardless of whether | all active transactions to experience a stall regardless of whether | |||
that transaction was directly impacted by the lost packet. | that transaction was directly impacted by the lost packet. | |||
1.2. Delegation to QUIC | 1.2. Delegation to QUIC | |||
The QUIC transport protocol incorporates stream multiplexing and per- | The QUIC transport protocol incorporates stream multiplexing and per- | |||
stream flow control, similar to that provided by the HTTP/2 framing | stream flow control, similar to that provided by the HTTP/2 framing | |||
layer. By providing reliability at the stream level and congestion | layer. By providing reliability at the stream level and congestion | |||
control across the entire connection, QUIC has the capability to | control across the entire connection, QUIC has the capability to | |||
improve the performance of HTTP compared to a TCP mapping. QUIC also | improve the performance of HTTP compared to a TCP mapping. QUIC also | |||
incorporates TLS 1.3 ([TLS13]) at the transport layer, offering | incorporates TLS 1.3 ([TLS13]) at the transport layer, offering | |||
comparable confidentiality and integrity to running TLS over TCP, | comparable confidentiality and integrity to running TLS over TCP, | |||
with the improved connection setup latency of TCP Fast Open ([TFO]). | with the improved connection setup latency of TCP Fast Open ([TFO]). | |||
This document defines a mapping of HTTP semantics over the QUIC | This document defines HTTP/3, a mapping of HTTP semantics over the | |||
transport protocol, drawing heavily on the design of HTTP/2. While | QUIC transport protocol, drawing heavily on the design of HTTP/2. | |||
delegating stream lifetime and flow control issues to QUIC, a similar | HTTP/3 relies on QUIC to provide confidentiality and integrity | |||
binary framing is used on each stream. Some HTTP/2 features are | protection of data; peer authentication; and reliable, in-order, per- | |||
subsumed by QUIC, while other features are implemented atop QUIC. | stream delivery. While delegating stream lifetime and flow control | |||
issues to QUIC, a binary framing similar to the HTTP/2 framing is | ||||
used on each stream. Some HTTP/2 features are subsumed by QUIC, | ||||
while other features are implemented atop QUIC. | ||||
QUIC is described in [QUIC-TRANSPORT]. For a full description of | QUIC is described in [QUIC-TRANSPORT]. For a full description of | |||
HTTP/2, see [HTTP2]. | HTTP/2, see [HTTP2]. | |||
2. HTTP/3 Protocol Overview | 2. HTTP/3 Protocol Overview | |||
HTTP/3 provides a transport for HTTP semantics using the QUIC | HTTP/3 provides a transport for HTTP semantics using the QUIC | |||
transport protocol and an internal framing layer similar to HTTP/2. | transport protocol and an internal framing layer similar to HTTP/2. | |||
Once a client knows that an HTTP/3 server exists at a certain | Once a client knows that an HTTP/3 server exists at a certain | |||
endpoint, it opens a QUIC connection. QUIC provides protocol | endpoint, it opens a QUIC connection. QUIC provides protocol | |||
negotiation, stream-based multiplexing, and flow control. Discovery | negotiation, stream-based multiplexing, and flow control. Discovery | |||
of an HTTP/3 endpoint is described in Section 3.1. | of an HTTP/3 endpoint is described in Section 3.1. | |||
Within each stream, the basic unit of HTTP/3 communication is a frame | Within each stream, the basic unit of HTTP/3 communication is a frame | |||
(Section 7.2). Each frame type serves a different purpose. For | (Section 7.2). Each frame type serves a different purpose. For | |||
example, HEADERS and DATA frames form the basis of HTTP requests and | example, HEADERS and DATA frames form the basis of HTTP requests and | |||
responses (Section 4.1). | responses (Section 4.1). Frames that apply to the entire connection | |||
are conveyed on a dedicated control stream. | ||||
Multiplexing of requests is performed using the QUIC stream | Multiplexing of requests is performed using the QUIC stream | |||
abstraction, described in Section 2 of [QUIC-TRANSPORT]. Each | abstraction, described in Section 2 of [QUIC-TRANSPORT]. Each | |||
request-response pair consumes a single QUIC stream. Streams are | request-response pair consumes a single QUIC stream. Streams are | |||
independent of each other, so one stream that is blocked or suffers | independent of each other, so one stream that is blocked or suffers | |||
packet loss does not prevent progress on other streams. | packet loss does not prevent progress on other streams. | |||
Server push is an interaction mode introduced in HTTP/2 ([HTTP2]) | Server push is an interaction mode introduced in HTTP/2 ([HTTP2]) | |||
that permits a server to push a request-response exchange to a client | that permits a server to push a request-response exchange to a client | |||
in anticipation of the client making the indicated request. This | in anticipation of the client making the indicated request. This | |||
skipping to change at page 8, line 26 ¶ | skipping to change at page 8, line 37 ¶ | |||
server: The endpoint that accepts an HTTP/3 connection. Servers | server: The endpoint that accepts an HTTP/3 connection. Servers | |||
receive HTTP requests and send HTTP responses. | receive HTTP requests and send HTTP responses. | |||
stream: A bidirectional or unidirectional bytestream provided by the | stream: A bidirectional or unidirectional bytestream provided by the | |||
QUIC transport. All streams within an HTTP/3 connection can be | QUIC transport. All streams within an HTTP/3 connection can be | |||
considered "HTTP/3 streams," but multiple stream types are defined | considered "HTTP/3 streams," but multiple stream types are defined | |||
within HTTP/3. | within HTTP/3. | |||
stream error: An application-level error on the individual stream. | stream error: An application-level error on the individual stream. | |||
The term "payload data" is defined in Section 6.4 of [SEMANTICS]. | The term "content" is defined in Section 6.4 of [SEMANTICS]. | |||
Finally, the terms "resource", "message", "user agent", "origin | Finally, the terms "resource", "message", "user agent", "origin | |||
server", "gateway", "intermediary", "proxy", and "tunnel" are defined | server", "gateway", "intermediary", "proxy", and "tunnel" are defined | |||
in Section 3 of [SEMANTICS]. | in Section 3 of [SEMANTICS]. | |||
Packet diagrams in this document use the format defined in | Packet diagrams in this document use the format defined in | |||
Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of | Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of | |||
fields. | fields. | |||
3. Connection Setup and Management | 3. Connection Setup and Management | |||
skipping to change at page 8, line 37 ¶ | skipping to change at page 9, line 4 ¶ | |||
Finally, the terms "resource", "message", "user agent", "origin | Finally, the terms "resource", "message", "user agent", "origin | |||
server", "gateway", "intermediary", "proxy", and "tunnel" are defined | server", "gateway", "intermediary", "proxy", and "tunnel" are defined | |||
in Section 3 of [SEMANTICS]. | in Section 3 of [SEMANTICS]. | |||
Packet diagrams in this document use the format defined in | Packet diagrams in this document use the format defined in | |||
Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of | Section 1.3 of [QUIC-TRANSPORT] to illustrate the order and size of | |||
fields. | fields. | |||
3. Connection Setup and Management | 3. Connection Setup and Management | |||
3.1. Discovering an HTTP/3 Endpoint | 3.1. Discovering an HTTP/3 Endpoint | |||
HTTP relies on the notion of an authoritative response: a response | HTTP relies on the notion of an authoritative response: a response | |||
that has been determined to be the most appropriate response for that | that has been determined to be the most appropriate response for that | |||
request given the state of the target resource at the time of | request given the state of the target resource at the time of | |||
response message origination by (or at the direction of) the origin | response message origination by (or at the direction of) the origin | |||
server identified within the target URI. Locating an authoritative | server identified within the target URI. Locating an authoritative | |||
server for an HTTP URL is discussed in Section 4.3 of [SEMANTICS]. | server for an HTTP URI is discussed in Section 4.3 of [SEMANTICS]. | |||
The "https" scheme associates authority with possession of a | The "https" scheme associates authority with possession of a | |||
certificate that the client considers to be trustworthy for the host | certificate that the client considers to be trustworthy for the host | |||
identified by the authority component of the URL. | identified by the authority component of the URI. Upon receiving a | |||
server certificate in the TLS handshake, the client MUST verify that | ||||
If a server presents a valid certificate and proof that it controls | the certificate is an acceptable match for the URI's origin server | |||
the corresponding private key, then a client will accept a secured | using the process described in Section 4.3.4 of [SEMANTICS]. If the | |||
TLS session with that server as being authoritative for all origins | certificate cannot be verified with respect to the URI's origin | |||
with the "https" scheme and a host identified in the certificate. | server, the client MUST NOT consider the server authoritative for | |||
The host must be listed either as the CN field of the certificate | that origin. | |||
subject or as a dNSName in the subjectAltName field of the | ||||
certificate; see [RFC6125]. For a host that is an IP address, the | ||||
client MUST verify that the address appears as an iPAddress in the | ||||
subjectAltName field of the certificate. | ||||
If the hostname or address is not present in the certificate, the | ||||
client MUST NOT consider the server authoritative for origins | ||||
containing that hostname or address. See Section 4.3 of [SEMANTICS] | ||||
for more detail on authoritative access. | ||||
A client MAY attempt access to a resource with an "https" URI by | A client MAY attempt access to a resource with an "https" URI by | |||
resolving the host identifier to an IP address, establishing a QUIC | resolving the host identifier to an IP address, establishing a QUIC | |||
connection to that address on the indicated port, and sending an | connection to that address on the indicated port (including | |||
HTTP/3 request message targeting the URI to the server over that | validation of the server certificate as described above), and sending | |||
an HTTP/3 request message targeting the URI to the server over that | ||||
secured connection. Unless some other mechanism is used to select | secured connection. Unless some other mechanism is used to select | |||
HTTP/3, the token "h3" is used in the Application Layer Protocol | HTTP/3, the token "h3" is used in the Application Layer Protocol | |||
Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake. | Negotiation (ALPN; see [RFC7301]) extension during the TLS handshake. | |||
Connectivity problems (e.g., blocking UDP) can result in QUIC | Connectivity problems (e.g., blocking UDP) can result in QUIC | |||
connection establishment failure; clients SHOULD attempt to use TCP- | connection establishment failure; clients SHOULD attempt to use TCP- | |||
based versions of HTTP in this case. | based versions of HTTP in this case. | |||
Servers MAY serve HTTP/3 on any UDP port; an alternative service | Servers MAY serve HTTP/3 on any UDP port; an alternative service | |||
advertisement always includes an explicit port, and URLs contain | advertisement always includes an explicit port, and URIs contain | |||
either an explicit port or a default port associated with the scheme. | either an explicit port or a default port associated with the scheme. | |||
3.1.1. HTTP Alternative Services | 3.1.1. HTTP Alternative Services | |||
An HTTP origin advertises the availability of an equivalent HTTP/3 | An HTTP origin can advertise the availability of an equivalent HTTP/3 | |||
endpoint via the Alt-Svc HTTP response header field or the HTTP/2 | endpoint via the Alt-Svc HTTP response header field or the HTTP/2 | |||
ALTSVC frame ([ALTSVC]), using the "h3" ALPN token. | ALTSVC frame ([ALTSVC]), using the "h3" ALPN token. | |||
For example, an origin could indicate in an HTTP response that HTTP/3 | For example, an origin could indicate in an HTTP response that HTTP/3 | |||
was available on UDP port 50781 at the same hostname by including the | was available on UDP port 50781 at the same hostname by including the | |||
following header field: | following header field: | |||
Alt-Svc: h3=":50781" | Alt-Svc: h3=":50781" | |||
On receipt of an Alt-Svc record indicating HTTP/3 support, a client | On receipt of an Alt-Svc record indicating HTTP/3 support, a client | |||
MAY attempt to establish a QUIC connection to the indicated host and | MAY attempt to establish a QUIC connection to the indicated host and | |||
port; if this connection is successful, the client can send HTTP | port; if this connection is successful, the client can send HTTP | |||
requests using the mapping described in this document. | requests using the mapping described in this document. | |||
3.1.2. Other Schemes | 3.1.2. Other Schemes | |||
Although HTTP is independent of the transport protocol, the "http" | Although HTTP is independent of the transport protocol, the "http" | |||
scheme associates authority with the ability to receive TCP | scheme associates authority with the ability to receive TCP | |||
connections on the indicated port of whatever host is identified | connections on the indicated port of whatever host is identified | |||
skipping to change at page 10, line 32 ¶ | skipping to change at page 10, line 36 ¶ | |||
3.2. Connection Establishment | 3.2. Connection Establishment | |||
HTTP/3 relies on QUIC version 1 as the underlying transport. The use | HTTP/3 relies on QUIC version 1 as the underlying transport. The use | |||
of other QUIC transport versions with HTTP/3 MAY be defined by future | of other QUIC transport versions with HTTP/3 MAY be defined by future | |||
specifications. | specifications. | |||
QUIC version 1 uses TLS version 1.3 or greater as its handshake | QUIC version 1 uses TLS version 1.3 or greater as its handshake | |||
protocol. HTTP/3 clients MUST support a mechanism to indicate the | protocol. HTTP/3 clients MUST support a mechanism to indicate the | |||
target host to the server during the TLS handshake. If the server is | target host to the server during the TLS handshake. If the server is | |||
identified by a DNS name, clients MUST send the Server Name | identified by a domain name ([DNS-TERMS]), clients MUST send the | |||
Indication (SNI; [RFC6066]) TLS extension unless an alternative | Server Name Indication (SNI; [RFC6066]) TLS extension unless an | |||
mechanism to indicate the target host is used. | alternative mechanism to indicate the target host is used. | |||
QUIC connections are established as described in [QUIC-TRANSPORT]. | QUIC connections are established as described in [QUIC-TRANSPORT]. | |||
During connection establishment, HTTP/3 support is indicated by | During connection establishment, HTTP/3 support is indicated by | |||
selecting the ALPN token "h3" in the TLS handshake. Support for | selecting the ALPN token "h3" in the TLS handshake. Support for | |||
other application-layer protocols MAY be offered in the same | other application-layer protocols MAY be offered in the same | |||
handshake. | handshake. | |||
While connection-level options pertaining to the core QUIC protocol | While connection-level options pertaining to the core QUIC protocol | |||
are set in the initial crypto handshake, HTTP/3-specific settings are | are set in the initial crypto handshake, HTTP/3-specific settings are | |||
conveyed in the SETTINGS frame. After the QUIC connection is | conveyed in the SETTINGS frame. After the QUIC connection is | |||
skipping to change at page 11, line 15 ¶ | skipping to change at page 11, line 15 ¶ | |||
3.3. Connection Reuse | 3.3. Connection Reuse | |||
HTTP/3 connections are persistent across multiple requests. For best | HTTP/3 connections are persistent across multiple requests. For best | |||
performance, it is expected that clients will not close connections | performance, it is expected that clients will not close connections | |||
until it is determined that no further communication with a server is | until it is determined that no further communication with a server is | |||
necessary (for example, when a user navigates away from a particular | necessary (for example, when a user navigates away from a particular | |||
web page) or until the server closes the connection. | web page) or until the server closes the connection. | |||
Once a connection exists to a server endpoint, this connection MAY be | Once a connection exists to a server endpoint, this connection MAY be | |||
reused for requests with multiple different URI authority components. | reused for requests with multiple different URI authority components. | |||
Clients SHOULD NOT open more than one HTTP/3 connection to a given | To use an existing connection for a new origin, clients MUST validate | |||
host and port pair, where the host is derived from a URI, a selected | the certificate presented by the server for the new origin server | |||
alternative service ([ALTSVC]), or a configured proxy. A client MAY | using the process described in Section 4.3.4 of [SEMANTICS]. This | |||
open multiple HTTP/3 connections to the same IP address and UDP port | implies that clients will need to retain the server certificate and | |||
using different transport or TLS configurations but SHOULD avoid | any additional information needed to verify that certificate; clients | |||
creating multiple connections with the same configuration. | which do not do so will be unable to reuse the connection for | |||
additional origins. | ||||
If the certificate is not acceptable with regard to the new origin | ||||
for any reason, the connection MUST NOT be reused and a new | ||||
connection SHOULD be established for the new origin. If the reason | ||||
the certificate cannot be verified might apply to other origins | ||||
already associated with the connection, the client SHOULD re-validate | ||||
the server certificate for those origins. For instance, if | ||||
validation of a certificate fails because the certificate has expired | ||||
or been revoked, this might be used to invalidate all other origins | ||||
for which that certificate was used to establish authority. | ||||
Clients SHOULD NOT open more than one HTTP/3 connection to a given IP | ||||
address and UDP port, where the IP address and port might be derived | ||||
from a URI, a selected alternative service ([ALTSVC]), a configured | ||||
proxy, or name resolution of any of these. A client MAY open | ||||
multiple HTTP/3 connections to the same IP address and UDP port using | ||||
different transport or TLS configurations but SHOULD avoid creating | ||||
multiple connections with the same configuration. | ||||
Servers are encouraged to maintain open HTTP/3 connections for as | Servers are encouraged to maintain open HTTP/3 connections for as | |||
long as possible but are permitted to terminate idle connections if | long as possible but are permitted to terminate idle connections if | |||
necessary. When either endpoint chooses to close the HTTP/3 | necessary. When either endpoint chooses to close the HTTP/3 | |||
connection, the terminating endpoint SHOULD first send a GOAWAY frame | connection, the terminating endpoint SHOULD first send a GOAWAY frame | |||
(Section 5.2) so that both endpoints can reliably determine whether | (Section 5.2) so that both endpoints can reliably determine whether | |||
previously sent frames have been processed and gracefully complete or | previously sent frames have been processed and gracefully complete or | |||
terminate any necessary remaining tasks. | terminate any necessary remaining tasks. | |||
A server that does not wish clients to reuse HTTP/3 connections for a | A server that does not wish clients to reuse HTTP/3 connections for a | |||
particular origin can indicate that it is not authoritative for a | particular origin can indicate that it is not authoritative for a | |||
request by sending a 421 (Misdirected Request) status code in | request by sending a 421 (Misdirected Request) status code in | |||
response to the request; see Section 9.1.2 of [HTTP2]. | response to the request; see Section 7.4 of [SEMANTICS]. | |||
4. HTTP Request Lifecycle | 4. HTTP Request Lifecycle | |||
4.1. HTTP Message Exchanges | 4.1. HTTP Message Exchanges | |||
A client sends an HTTP request on a request stream, which is a | A client sends an HTTP request on a request stream, which is a | |||
client-initiated bidirectional QUIC stream; see Section 6.1. A | client-initiated bidirectional QUIC stream; see Section 6.1. A | |||
client MUST send only a single request on a given stream. A server | client MUST send only a single request on a given stream. A server | |||
sends zero or more interim HTTP responses on the same stream as the | sends zero or more interim HTTP responses on the same stream as the | |||
request, followed by a single final HTTP response, as detailed below. | request, followed by a single final HTTP response, as detailed below. | |||
skipping to change at page 12, line 11 ¶ | skipping to change at page 12, line 29 ¶ | |||
responses, followed by a single final HTTP response, in the same | responses, followed by a single final HTTP response, in the same | |||
manner as a standard response. Push is described in more detail in | manner as a standard response. Push is described in more detail in | |||
Section 4.4. | Section 4.4. | |||
On a given stream, receipt of multiple requests or receipt of an | On a given stream, receipt of multiple requests or receipt of an | |||
additional HTTP response following a final HTTP response MUST be | additional HTTP response following a final HTTP response MUST be | |||
treated as malformed (Section 4.1.3). | treated as malformed (Section 4.1.3). | |||
An HTTP message (request or response) consists of: | An HTTP message (request or response) consists of: | |||
1. the header field section, sent as a single HEADERS frame (see | 1. the header section, sent as a single HEADERS frame (see | |||
Section 7.2.2), | Section 7.2.2), | |||
2. optionally, the payload data, if present, sent as a series of | 2. optionally, the content, if present, sent as a series of DATA | |||
DATA frames (see Section 7.2.1), and | frames (see Section 7.2.1), and | |||
3. optionally, the trailer field section, if present, sent as a | 3. optionally, the trailer section, if present, sent as a single | |||
single HEADERS frame. | HEADERS frame. | |||
Header and trailer field sections are described in Sections 6.3 and | Header and trailer sections are described in Sections 6.3 and 6.5 of | |||
6.5 of [SEMANTICS]; the payload data is described in Section 6.4 of | [SEMANTICS]; the content is described in Section 6.4 of [SEMANTICS]. | |||
[SEMANTICS]. | ||||
Receipt of an invalid sequence of frames MUST be treated as a | Receipt of an invalid sequence of frames MUST be treated as a | |||
connection error of type H3_FRAME_UNEXPECTED; see Section 8. In | connection error of type H3_FRAME_UNEXPECTED; see Section 8. In | |||
particular, a DATA frame before any HEADERS frame, or a HEADERS or | particular, a DATA frame before any HEADERS frame, or a HEADERS or | |||
DATA frame after the trailing HEADERS frame is considered invalid. | DATA frame after the trailing HEADERS frame, is considered invalid. | |||
Other frame types, especially unknown frame types, might be permitted | Other frame types, especially unknown frame types, might be permitted | |||
subject to their own rules; see Section 9. | subject to their own rules; see Section 9. | |||
A server MAY send one or more PUSH_PROMISE frames (Section 7.2.5) | A server MAY send one or more PUSH_PROMISE frames (Section 7.2.5) | |||
before, after, or interleaved with the frames of a response message. | before, after, or interleaved with the frames of a response message. | |||
These PUSH_PROMISE frames are not part of the response; see | These PUSH_PROMISE frames are not part of the response; see | |||
Section 4.4 for more details. PUSH_PROMISE frames are not permitted | Section 4.4 for more details. PUSH_PROMISE frames are not permitted | |||
on push streams; a pushed response that includes PUSH_PROMISE frames | on push streams; a pushed response that includes PUSH_PROMISE frames | |||
MUST be treated as a connection error of type H3_FRAME_UNEXPECTED; | MUST be treated as a connection error of type H3_FRAME_UNEXPECTED; | |||
see Section 8. | see Section 8. | |||
Frames of unknown types (Section 9), including reserved frames | Frames of unknown types (Section 9), including reserved frames | |||
(Section 7.2.8) MAY be sent on a request or push stream before, | (Section 7.2.8) MAY be sent on a request or push stream before, | |||
after, or interleaved with other frames described in this section. | after, or interleaved with other frames described in this section. | |||
The HEADERS and PUSH_PROMISE frames might reference updates to the | The HEADERS and PUSH_PROMISE frames might reference updates to the | |||
QPACK dynamic table. While these updates are not directly part of | QPACK dynamic table. While these updates are not directly part of | |||
the message exchange, they must be received and processed before the | the message exchange, they must be received and processed before the | |||
message can be consumed. See Section 4.1.1 for more details. | message can be consumed. See Section 4.1.1 for more details. | |||
The "chunked" transfer encoding defined in Section 7.1 of [HTTP11] | Transfer codings (see Section 6.1 of [HTTP11]) are not defined for | |||
MUST NOT be used. | HTTP/3; the Transfer-Encoding header field MUST NOT be used. | |||
A response MAY consist of multiple messages when and only when one or | A response MAY consist of multiple messages when and only when one or | |||
more interim responses (1xx; see Section 15.2 of [SEMANTICS]) precede | more interim responses (1xx; see Section 15.2 of [SEMANTICS]) precede | |||
a final response to the same request. Interim responses do not | a final response to the same request. Interim responses do not | |||
contain payload data or trailers. | contain content or trailer sections. | |||
An HTTP request/response exchange fully consumes a client-initiated | An HTTP request/response exchange fully consumes a client-initiated | |||
bidirectional QUIC stream. After sending a request, a client MUST | bidirectional QUIC stream. After sending a request, a client MUST | |||
close the stream for sending. Unless using the CONNECT method (see | close the stream for sending. Unless using the CONNECT method (see | |||
Section 4.2), clients MUST NOT make stream closure dependent on | Section 4.2), clients MUST NOT make stream closure dependent on | |||
receiving a response to their request. After sending a final | receiving a response to their request. After sending a final | |||
response, the server MUST close the stream for sending. At this | response, the server MUST close the stream for sending. At this | |||
point, the QUIC stream is fully closed. | point, the QUIC stream is fully closed. | |||
When a stream is closed, this indicates the end of the final HTTP | When a stream is closed, this indicates the end of the final HTTP | |||
message. Because some messages are large or unbounded, endpoints | message. Because some messages are large or unbounded, endpoints | |||
SHOULD begin processing partial HTTP messages once enough of the | SHOULD begin processing partial HTTP messages once enough of the | |||
message has been received to make progress. If a client-initiated | message has been received to make progress. If a client-initiated | |||
stream terminates without enough of the HTTP message to provide a | stream terminates without enough of the HTTP message to provide a | |||
complete response, the server SHOULD abort its response with the | complete response, the server SHOULD abort its response stream with | |||
error code H3_REQUEST_INCOMPLETE; see Section 8. | the error code H3_REQUEST_INCOMPLETE; see Section 8. | |||
A server can send a complete response prior to the client sending an | A server can send a complete response prior to the client sending an | |||
entire request if the response does not depend on any portion of the | entire request if the response does not depend on any portion of the | |||
request that has not been sent and received. When the server does | request that has not been sent and received. When the server does | |||
not need to receive the remainder of the request, it MAY abort | not need to receive the remainder of the request, it MAY abort | |||
reading the request stream, send a complete response, and cleanly | reading the request stream, send a complete response, and cleanly | |||
close the sending part of the stream. The error code H3_NO_ERROR | close the sending part of the stream. The error code H3_NO_ERROR | |||
SHOULD be used when requesting that the client stop sending on the | SHOULD be used when requesting that the client stop sending on the | |||
request stream. Clients MUST NOT discard complete responses as a | request stream. Clients MUST NOT discard complete responses as a | |||
result of having their request terminated abruptly, though clients | result of having their request terminated abruptly, though clients | |||
skipping to change at page 13, line 49 ¶ | skipping to change at page 14, line 19 ¶ | |||
HTTP messages carry metadata as a series of key-value pairs called | HTTP messages carry metadata as a series of key-value pairs called | |||
HTTP fields; see Sections 6.3 and 6.5 of [SEMANTICS]. For a listing | HTTP fields; see Sections 6.3 and 6.5 of [SEMANTICS]. For a listing | |||
of registered HTTP fields, see the "Hypertext Transfer Protocol | of registered HTTP fields, see the "Hypertext Transfer Protocol | |||
(HTTP) Field Name Registry" maintained at | (HTTP) Field Name Registry" maintained at | |||
<https://www.iana.org/assignments/http-fields/>. | <https://www.iana.org/assignments/http-fields/>. | |||
*Note:* This registry will not exist until [SEMANTICS] is | *Note:* This registry will not exist until [SEMANTICS] is | |||
approved. *RFC Editor*, please remove this note prior to | approved. *RFC Editor*, please remove this note prior to | |||
publication. | publication. | |||
As in previous versions of HTTP, field names are strings containing a | Field names are strings containing a subset of ASCII characters. | |||
subset of ASCII characters that are compared in a case-insensitive | Properties of HTTP field names and values are discussed in more | |||
fashion. Properties of HTTP field names and values are discussed in | detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters in | |||
more detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters | field names MUST be converted to lowercase prior to their encoding. | |||
in field names MUST be converted to lowercase prior to their | A request or response containing uppercase characters in field names | |||
encoding. A request or response containing uppercase characters in | MUST be treated as malformed (Section 4.1.3). | |||
field names MUST be treated as malformed (Section 4.1.3). | ||||
Like HTTP/2, HTTP/3 does not use the Connection header field to | Like HTTP/2, HTTP/3 does not use the Connection header field to | |||
indicate connection-specific fields; in this protocol, connection- | indicate connection-specific 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/3 field section containing connection-specific | generate an HTTP/3 field section containing connection-specific | |||
fields; any message containing connection-specific fields MUST be | fields; any message containing connection-specific fields MUST be | |||
treated as malformed (Section 4.1.3). | treated as malformed (Section 4.1.3). | |||
The only exception to this is the TE header field, which MAY be | The only exception to this is the TE header field, which MAY be | |||
present in an HTTP/3 request header; when it is, it MUST NOT contain | present in an HTTP/3 request header; when it is, it MUST NOT contain | |||
any value other than "trailers". | any value other than "trailers". | |||
This means that an intermediary transforming an HTTP/1.x message to | An intermediary transforming an HTTP/1.x message to HTTP/3 MUST | |||
HTTP/3 will need to remove any fields nominated by the Connection | remove connection-specific header fields as discussed in | |||
field, along with the Connection field itself. Such intermediaries | Section 7.6.1 of [SEMANTICS], or their messages will be treated by | |||
SHOULD also remove other connection-specific fields, such as Keep- | other HTTP/3 endpoints as malformed (Section 4.1.3). | |||
Alive, Proxy-Connection, Transfer-Encoding, and Upgrade, even if they | ||||
are not nominated by the Connection field. | ||||
4.1.1.1. Pseudo-Header Fields | 4.1.1.1. Pseudo-Header Fields | |||
Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where | Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where | |||
the field name begins with the ':' character (ASCII 0x3a). These | the field name begins with the ':' character (ASCII 0x3a). These | |||
pseudo-header fields convey the target URI, the method of the | pseudo-header fields convey the target URI, the method of the | |||
request, and the status code for the response. | request, and the status code for the response. | |||
Pseudo-header fields are not HTTP fields. Endpoints MUST NOT | Pseudo-header fields are not HTTP 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; however, an extension could negotiate a modification of | document; however, an extension could negotiate a modification of | |||
this restriction; see Section 9. | this restriction; see Section 9. | |||
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 trailer | |||
trailers. Endpoints MUST treat a request or response that contains | sections. 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 4.1.3). | (Section 4.1.3). | |||
All pseudo-header fields MUST appear in the header field section | All pseudo-header fields MUST appear in the header section before | |||
before regular header fields. Any request or response that contains | regular header fields. Any request or response that contains a | |||
a pseudo-header field that appears in a header field section after a | pseudo-header field that appears in a header section after a regular | |||
regular header field MUST be treated as malformed (Section 4.1.3). | header field MUST be treated as malformed (Section 4.1.3). | |||
The following pseudo-header fields are defined for requests: | The following pseudo-header fields are defined for requests: | |||
":method": Contains the HTTP method (Section 9 of [SEMANTICS]) | ":method": Contains the HTTP method (Section 9 of [SEMANTICS]) | |||
":scheme": Contains the scheme portion of the target URI | ":scheme": Contains the scheme portion of the target URI | |||
(Section 3.1 of [URI]) | (Section 3.1 of [URI]) | |||
":scheme" is not restricted to "http" and "https" schemed URIs. A | ":scheme" is not restricted to URIs with scheme "http" and | |||
proxy or gateway can translate requests for non-HTTP schemes, | "https". A proxy or gateway can translate requests for non-HTTP | |||
enabling the use of HTTP to interact with non-HTTP services. | schemes, enabling the use of HTTP to interact with non-HTTP | |||
services. | ||||
See Section 3.1.2 for guidance on using a scheme other than | ||||
"https". | ||||
":authority": Contains the authority portion of the target URI | ":authority": Contains the authority portion of the target URI | |||
(Section 3.2 of [URI]). The authority MUST NOT include the | (Section 3.2 of [URI]). The authority MUST NOT include the | |||
deprecated "userinfo" subcomponent for "http" or "https" schemed | deprecated "userinfo" subcomponent for URIs of scheme "http" or | |||
URIs. | "https". | |||
To ensure that the HTTP/1.1 request line can be reproduced | To ensure that the HTTP/1.1 request line can be reproduced | |||
accurately, this pseudo-header field MUST be omitted when | accurately, this pseudo-header field MUST be omitted when | |||
translating from an HTTP/1.1 request that has a request target in | translating from an HTTP/1.1 request that has a request target in | |||
origin or asterisk form; see Section 3.2 of [HTTP11]. Clients | origin or asterisk form; see Section 7.1 of [SEMANTICS]. Clients | |||
that generate HTTP/3 requests directly SHOULD use the ":authority" | that generate HTTP/3 requests directly SHOULD use the ":authority" | |||
pseudo-header field instead of the Host field. An intermediary | pseudo-header field instead of the Host field. An intermediary | |||
that converts an HTTP/3 request to HTTP/1.1 MUST create a Host | that converts an HTTP/3 request to HTTP/1.1 MUST create a Host | |||
field if one is not present in a request by copying the value of | field if one is not present in a request by copying the value of | |||
the ":authority" pseudo-header field. | the ":authority" pseudo-header field. | |||
":path": Contains the path and query parts of the target URI (the | ":path": Contains the path and query parts of the target URI (the | |||
"path-absolute" production and optionally a '?' character followed | "path-absolute" production and optionally a '?' character followed | |||
by the "query" production; see Sections 3.3 and 3.4 of [URI]. A | by the "query" production; see Sections 3.3 and 3.4 of [URI]. A | |||
request in asterisk form includes the value '*' for the ":path" | request in asterisk form includes the value '*' for the ":path" | |||
pseudo-header field. | pseudo-header field. | |||
This pseudo-header field MUST NOT be empty for "http" or "https" | This pseudo-header field MUST NOT be empty for "http" or "https" | |||
URIs; "http" or "https" URIs that do not contain a path component | URIs; "http" or "https" URIs that do not contain a path component | |||
MUST include a value of '/'. The exception to this rule is an | MUST include a value of '/'. The exception to this rule is an | |||
OPTIONS request for an "http" or "https" URI that does not include | OPTIONS request for an "http" or "https" URI that does not include | |||
a path component; these MUST include a ":path" pseudo-header field | a path component; these MUST include a ":path" pseudo-header field | |||
with a value of '*'; see Section 3.2.4 of [HTTP11]. | with a value of '*'; see Section 7.1 of [SEMANTICS]. | |||
All HTTP/3 requests MUST include exactly one value for the ":method", | All HTTP/3 requests MUST include exactly one value for the ":method", | |||
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT | ":scheme", and ":path" pseudo-header fields, unless it is a CONNECT | |||
request; see Section 4.2. | request; see Section 4.2. | |||
If the ":scheme" pseudo-header field identifies a scheme that has a | If the ":scheme" pseudo-header field identifies a scheme that has a | |||
mandatory authority component (including "http" and "https"), the | mandatory authority component (including "http" and "https"), the | |||
request MUST contain either an ":authority" pseudo-header field or a | request MUST contain either an ":authority" pseudo-header field or a | |||
"Host" header field. If these fields are present, they MUST NOT be | "Host" header field. If these fields are present, they MUST NOT be | |||
empty. If both fields are present, they MUST contain the same value. | empty. If both fields are present, they MUST contain the same value. | |||
skipping to change at page 16, line 26 ¶ | skipping to change at page 16, line 45 ¶ | |||
For responses, a single ":status" pseudo-header field is defined that | For responses, a single ":status" pseudo-header field is defined that | |||
carries the HTTP status code; see Section 15 of [SEMANTICS]. This | carries the HTTP status code; see Section 15 of [SEMANTICS]. This | |||
pseudo-header field MUST be included in all responses; otherwise, the | pseudo-header field MUST be included in all responses; otherwise, the | |||
response is malformed (Section 4.1.3). | response is malformed (Section 4.1.3). | |||
HTTP/3 does not define a way to carry the version or reason phrase | HTTP/3 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. | |||
4.1.1.2. Field Compression | 4.1.1.2. Field Compression | |||
HTTP/3 uses QPACK field compression as described in [QPACK], a | [QPACK] describes a variation of HPACK that gives an encoder some | |||
variation of HPACK that allows the flexibility to avoid compression- | control over how much head-of-line blocking can be caused by | |||
induced head-of-line blocking. See that document for additional | compression. This allows an encoder to balance compression | |||
details. | efficiency with latency. HTTP/3 uses QPACK to compress header and | |||
trailer sections, including the pseudo-header fields present in the | ||||
header section. | ||||
To allow for better compression efficiency, the "Cookie" field | To allow for better compression efficiency, the "Cookie" field | |||
([RFC6265]) MAY be split into separate field lines, each with one or | ([RFC6265]) MAY be split into separate field lines, each with one or | |||
more cookie-pairs, before compression. If a decompressed field | more cookie-pairs, before compression. If a decompressed field | |||
section contains multiple cookie field lines, these MUST be | section contains multiple cookie field lines, these MUST be | |||
concatenated into a single octet string using the two-octet delimiter | concatenated into a single byte string using the two-byte delimiter | |||
of 0x3b, 0x20 (the ASCII string "; ") before being passed into a | of 0x3b, 0x20 (the ASCII string "; ") before being passed into a | |||
context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, | context other than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, | |||
or a generic HTTP server application. | or a generic HTTP server application. | |||
4.1.1.3. Header Size Constraints | 4.1.1.3. Header Size Constraints | |||
An HTTP/3 implementation MAY impose a limit on the maximum size of | An HTTP/3 implementation MAY impose a limit on the maximum size of | |||
the message header it will accept on an individual HTTP message. A | the message header it will accept on an individual HTTP message. A | |||
server that receives a larger header section than it is willing to | server that receives a larger header section than it is willing to | |||
handle can send an HTTP 431 (Request Header Fields Too Large) status | handle can send an HTTP 431 (Request Header Fields Too Large) status | |||
skipping to change at page 17, line 8 ¶ | skipping to change at page 17, line 31 ¶ | |||
process. The size of a field list is calculated based on the | process. The size of a field list is calculated based on the | |||
uncompressed size of fields, including the length of the name and | uncompressed size of fields, including the length of the name and | |||
value in bytes plus an overhead of 32 bytes for each field. | value in bytes plus an overhead of 32 bytes for each field. | |||
If an implementation wishes to advise its peer of this limit, it can | If an implementation wishes to advise its peer of this limit, it can | |||
be conveyed as a number of bytes in the | be conveyed as a number of bytes in the | |||
SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An implementation that | SETTINGS_MAX_FIELD_SECTION_SIZE parameter. An implementation that | |||
has received this parameter SHOULD NOT send an HTTP message header | has received this parameter SHOULD NOT send an HTTP message header | |||
that exceeds the indicated size, as the peer will likely refuse to | that exceeds the indicated size, as the peer will likely refuse to | |||
process it. However, an HTTP message can traverse one or more | process it. However, an HTTP message can traverse one or more | |||
intermediaries before reaching the origin server; see Section 3.6 of | intermediaries before reaching the origin server; see Section 3.7 of | |||
[SEMANTICS]. Because this limit is applied separately by each | [SEMANTICS]. Because this limit is applied separately by each | |||
implementation which processes the message, messages below this limit | implementation which processes the message, messages below this limit | |||
are not guaranteed to be accepted. | are not guaranteed to be accepted. | |||
4.1.2. Request Cancellation and Rejection | 4.1.2. Request Cancellation and Rejection | |||
Once a request stream has been opened, the request MAY be cancelled | Once a request stream has been opened, the request MAY be cancelled | |||
by either endpoint. Clients cancel requests if the response is no | by either endpoint. Clients cancel requests if the response is no | |||
longer of interest; servers cancel requests if they are unable to or | longer of interest; servers cancel requests if they are unable to or | |||
choose not to respond. When possible, it is RECOMMENDED that servers | choose not to respond. When possible, it is RECOMMENDED that servers | |||
skipping to change at page 18, line 30 ¶ | skipping to change at page 19, line 5 ¶ | |||
o invalid values for pseudo-header fields, | o invalid values for pseudo-header fields, | |||
o pseudo-header fields after fields, | o pseudo-header fields after fields, | |||
o an invalid sequence of HTTP messages, | o an invalid sequence of HTTP messages, | |||
o the inclusion of uppercase field names, or | o the inclusion of uppercase field names, or | |||
o the inclusion of invalid characters in field names or values. | o the inclusion of invalid characters in field names or values. | |||
A request or response that includes payload data can include a | A request or response that is defined as having content when it | |||
Content-Length header field. A request or response is also malformed | contains a Content-Length header field (Section 6.4.1 of | |||
if the value of a Content-Length header field does not equal the sum | [SEMANTICS]), is malformed if the value of a Content-Length header | |||
of the DATA frame lengths that form the payload data. A response | field does not equal the sum of the DATA frame lengths received. A | |||
that is defined to have no payload, as described in Section 6.4 of | response that is defined as never having content, even when a | |||
[SEMANTICS], can have a non-zero Content-Length field, even though no | Content-Length is present, can have a non-zero Content-Length field | |||
content is included in DATA frames. | even though no content is included in DATA frames. | |||
Intermediaries that process HTTP requests or responses (i.e., any | Intermediaries that process HTTP requests or responses (i.e., any | |||
intermediary not acting as a tunnel) MUST NOT forward a malformed | intermediary not acting as a tunnel) MUST NOT forward a malformed | |||
request or response. Malformed requests or responses that are | request or response. Malformed requests or responses that are | |||
detected MUST be treated as a stream error (Section 8) of type | detected MUST be treated as a stream error (Section 8) of type | |||
H3_MESSAGE_ERROR. | H3_MESSAGE_ERROR. | |||
For malformed requests, a server MAY send an HTTP response indicating | For malformed requests, a server MAY send an HTTP response indicating | |||
the error prior to closing or resetting the stream. Clients MUST NOT | the error prior to closing or resetting the stream. Clients MUST NOT | |||
accept a malformed response. Note that these requirements are | accept a malformed response. Note that these requirements are | |||
skipping to change at page 19, line 25 ¶ | skipping to change at page 19, line 46 ¶ | |||
method is used to establish a tunnel over a single stream. | method is used to establish a tunnel over a single stream. | |||
A CONNECT request MUST be constructed as follows: | A CONNECT request MUST be constructed as follows: | |||
o The ":method" pseudo-header field is set to "CONNECT" | o The ":method" pseudo-header field is set to "CONNECT" | |||
o The ":scheme" and ":path" pseudo-header fields are omitted | o The ":scheme" and ":path" pseudo-header fields are omitted | |||
o The ":authority" pseudo-header field contains the host and port to | o The ":authority" pseudo-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 Section 3.2.3 of [HTTP11]) | of CONNECT requests; see Section 7.1 of [SEMANTICS]) | |||
The request stream remains open at the end of the request to carry | The request stream remains open at the end of the request to carry | |||
the data to be transferred. A CONNECT request that does not conform | the data to be transferred. A CONNECT request that does not conform | |||
to these restrictions is malformed; see Section 4.1.3. | to these restrictions is malformed; see Section 4.1.3. | |||
A proxy that supports CONNECT establishes a TCP connection | A proxy that supports CONNECT establishes a TCP connection | |||
([RFC0793]) to the server identified in the ":authority" pseudo- | ([RFC0793]) to the server identified in the ":authority" pseudo- | |||
header field. Once this connection is successfully established, the | header field. Once this connection is successfully established, the | |||
proxy sends a HEADERS frame containing a 2xx series status code to | proxy sends a HEADERS frame containing a 2xx series status code to | |||
the client, as defined in Section 15.3 of [SEMANTICS]. | the client, as defined in Section 15.3 of [SEMANTICS]. | |||
skipping to change at page 20, line 19 ¶ | skipping to change at page 20, line 42 ¶ | |||
expect to receive data from the target of the CONNECT. | expect to receive data from the target of the CONNECT. | |||
A TCP connection error is signaled by abruptly terminating the | A TCP connection error is signaled by abruptly terminating the | |||
stream. A proxy treats any error in the TCP connection, which | stream. A proxy treats any error in the TCP connection, which | |||
includes receiving a TCP segment with the RST bit set, as a stream | includes receiving a TCP segment with the RST bit set, as a stream | |||
error of type H3_CONNECT_ERROR; see Section 8. Correspondingly, if a | error of type H3_CONNECT_ERROR; see Section 8. Correspondingly, if a | |||
proxy detects an error with the stream or the QUIC connection, it | proxy detects an error with the stream or the QUIC connection, it | |||
MUST close the TCP connection. If the underlying TCP implementation | MUST close the TCP connection. If the underlying TCP implementation | |||
permits it, the proxy SHOULD send a TCP segment with the RST bit set. | permits it, the proxy SHOULD send a TCP segment with the RST bit set. | |||
Since CONNECT creates a tunnel to an arbitrary server, proxies that | ||||
support CONNECT SHOULD restrict its use to a set of known ports or a | ||||
list of safe request targets; see Section 9.3.6 of [SEMANTICS] for | ||||
more detail. | ||||
4.3. HTTP Upgrade | 4.3. HTTP Upgrade | |||
HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of | HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of | |||
[SEMANTICS]) or 101 (Switching Protocols) informational status code | [SEMANTICS]) or 101 (Switching Protocols) informational status code | |||
(Section 15.2.2 of [SEMANTICS]). | (Section 15.2.2 of [SEMANTICS]). | |||
4.4. Server Push | 4.4. Server Push | |||
Server push is an interaction mode that permits a server to push a | Server push is an interaction mode that permits a server to push a | |||
request-response exchange to a client in anticipation of the client | request-response exchange to a client in anticipation of the client | |||
skipping to change at page 21, line 24 ¶ | skipping to change at page 22, line 4 ¶ | |||
Section 7.2.3. Clients use this frame to indicate they do not wish | Section 7.2.3. Clients use this frame to indicate they do not wish | |||
to receive a promised resource. Servers use this frame to indicate | to receive a promised resource. Servers use this frame to indicate | |||
they will not be fulfilling a previous promise. | they will not be fulfilling a previous promise. | |||
Not all requests can be pushed. A server MAY push requests that have | Not all requests can be pushed. A server MAY push requests that have | |||
the following properties: | the following properties: | |||
o cacheable; see Section 9.2.3 of [SEMANTICS] | o cacheable; see Section 9.2.3 of [SEMANTICS] | |||
o safe; see Section 9.2.1 of [SEMANTICS] | o safe; see Section 9.2.1 of [SEMANTICS] | |||
o does not include a request body or trailer section | o does not include a request body or trailer section | |||
The server MUST include a value in the ":authority" pseudo-header | The server MUST include a value in the ":authority" pseudo-header | |||
field for which the server is authoritative; see Section 3.3. | field for which the server is authoritative. If the client has not | |||
yet validated the connection for the origin indicated by the pushed | ||||
request, it MUST perform the same verification process it would do | ||||
before sending a request for that origin on the connection; see | ||||
Section 3.3. If this verification fails, the client MUST NOT | ||||
consider the server authoritative for that origin. | ||||
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a | Clients SHOULD send a CANCEL_PUSH frame upon receipt of a | |||
PUSH_PROMISE frame carrying a request that is not cacheable, is not | PUSH_PROMISE frame carrying a request that is not cacheable, is not | |||
known to be safe, that indicates the presence of a request body, or | known to be safe, that indicates the presence of a request body, or | |||
for which it does not consider the server authoritative. Any | for which it does not consider the server authoritative. Any | |||
corresponding responses MUST NOT be used or cached. | corresponding responses MUST NOT be used or cached. | |||
Each pushed response is associated with one or more client requests. | Each pushed response is associated with one or more client requests. | |||
The push is associated with the request stream on which the | The push is associated with the request stream on which the | |||
PUSH_PROMISE frame was received. The same server push can be | PUSH_PROMISE frame was received. The same server push can be | |||
skipping to change at page 23, line 47 ¶ | skipping to change at page 24, line 31 ¶ | |||
requests with a Stream ID greater than or equal to the identifier | requests with a Stream ID greater than or equal to the identifier | |||
contained in the GOAWAY frame, those requests will not be | contained in the GOAWAY frame, those requests will not be | |||
processed. Clients can safely retry unprocessed requests on a | processed. Clients can safely retry unprocessed requests on a | |||
different HTTP connection. A client that is unable to retry | different HTTP connection. A client that is unable to retry | |||
requests loses all requests that are in flight when the server | requests loses all requests that are in flight when the server | |||
closes the connection. | closes the connection. | |||
Requests on Stream IDs less than the Stream ID in a GOAWAY frame | Requests on Stream IDs less than the Stream ID in a GOAWAY frame | |||
from the server might have been processed; their status cannot be | from the server might have been processed; their status cannot be | |||
known until a response is received, the stream is reset | known until a response is received, the stream is reset | |||
individually, another GOAWAY is received, or the connection | individually, another GOAWAY is received with a lower Stream ID | |||
than that of the request in question, or the connection | ||||
terminates. | terminates. | |||
Servers MAY reject individual requests on streams below the | Servers MAY reject individual requests on streams below the | |||
indicated ID if these requests were not processed. | indicated ID if these requests were not processed. | |||
o If a server receives a GOAWAY frame after having promised pushes | o If a server receives a GOAWAY frame after having promised pushes | |||
with a Push ID greater than or equal to the identifier contained | with a Push ID greater than or equal to the identifier contained | |||
in the GOAWAY frame, those pushes will not be accepted. | in the GOAWAY frame, those pushes will not be accepted. | |||
Servers SHOULD send a GOAWAY frame when the closing of a connection | Servers SHOULD send a GOAWAY frame when the closing of a connection | |||
skipping to change at page 25, line 23 ¶ | skipping to change at page 26, line 7 ¶ | |||
the peer indicating that the application layer has terminated the | the peer indicating that the application layer has terminated the | |||
connection. The application error code in this frame indicates to | connection. The application error code in this frame indicates to | |||
the peer why the connection is being closed. See Section 8 for error | the peer why the connection is being closed. See Section 8 for error | |||
codes that can be used when closing a connection in HTTP/3. | codes that can be used when closing a connection in HTTP/3. | |||
Before closing the connection, a GOAWAY frame MAY be sent to allow | Before closing the connection, a GOAWAY frame MAY be sent to allow | |||
the client to retry some requests. Including the GOAWAY frame in the | the client to retry some requests. Including the GOAWAY frame in the | |||
same packet as the QUIC CONNECTION_CLOSE frame improves the chances | same packet as the QUIC CONNECTION_CLOSE frame improves the chances | |||
of the frame being received by clients. | of the frame being received by clients. | |||
If there are open streams that have not been explicitly closed, they | ||||
are implicitly closed when the connection is closed; see Section 10.2 | ||||
of [QUIC-TRANSPORT]. | ||||
5.4. Transport Closure | 5.4. Transport Closure | |||
For various reasons, the QUIC transport could indicate to the | For various reasons, the QUIC transport could indicate to the | |||
application layer that the connection has terminated. This might be | application layer that the connection has terminated. This might be | |||
due to an explicit closure by the peer, a transport-level error, or a | due to an explicit closure by the peer, a transport-level error, or a | |||
change in network topology that interrupts connectivity. | change in network topology that interrupts connectivity. | |||
If a connection terminates without a GOAWAY frame, clients MUST | If a connection terminates without a GOAWAY frame, clients MUST | |||
assume that any request that was sent, whether in whole or in part, | assume that any request that was sent, whether in whole or in part, | |||
might have been processed. | might have been processed. | |||
6. Stream Mapping and Usage | 6. Stream Mapping and Usage | |||
A QUIC stream provides reliable in-order delivery of bytes, but makes | A QUIC stream provides reliable in-order delivery of bytes, but makes | |||
no guarantees about order of delivery with regard to bytes on other | no guarantees about order of delivery with regard to bytes on other | |||
streams. On the wire, data is framed into QUIC STREAM frames, but | streams. On the wire, the stream data containing HTTP frames is | |||
this framing is invisible to the HTTP framing layer. The transport | carried by QUIC STREAM frames, but this framing is invisible to the | |||
layer buffers and orders received QUIC STREAM frames, exposing the | HTTP framing layer. The transport layer buffers and orders received | |||
data contained within as a reliable byte stream to the application. | QUIC STREAM frames, exposing the data contained within as a reliable | |||
Although QUIC permits out-of-order delivery within a stream, HTTP/3 | byte stream to the application. Although QUIC permits out-of-order | |||
does not make use of this feature. | delivery within a stream, HTTP/3 does not make use of this feature. | |||
QUIC streams can be either unidirectional, carrying data only from | QUIC streams can be either unidirectional, carrying data only from | |||
initiator to receiver, or bidirectional. Streams can be initiated by | initiator to receiver, or bidirectional. Streams can be initiated by | |||
either the client or the server. For more detail on QUIC streams, | either the client or the server. For more detail on QUIC streams, | |||
see Section 2 of [QUIC-TRANSPORT]. | see Section 2 of [QUIC-TRANSPORT]. | |||
When HTTP fields and data are sent over QUIC, the QUIC layer handles | When HTTP fields and data are sent over QUIC, the QUIC layer handles | |||
most of the stream management. HTTP does not need to do any separate | most of the stream management. HTTP does not need to do any separate | |||
multiplexing when using QUIC - data sent over a QUIC stream always | multiplexing when using QUIC - data sent over a QUIC stream always | |||
maps to a particular HTTP transaction or to the entire HTTP/3 | maps to a particular HTTP transaction or to the entire HTTP/3 | |||
skipping to change at page 26, line 19 ¶ | skipping to change at page 27, line 10 ¶ | |||
All client-initiated bidirectional streams are used for HTTP requests | All client-initiated bidirectional streams are used for HTTP requests | |||
and responses. A bidirectional stream ensures that the response can | and responses. A bidirectional stream ensures that the response can | |||
be readily correlated with the request. These streams are referred | be readily correlated with the request. These streams are referred | |||
to as request streams. | to as request streams. | |||
This means that the client's first request occurs on QUIC stream 0, | This means that the client's first request occurs on QUIC stream 0, | |||
with subsequent requests on stream 4, 8, and so on. In order to | with subsequent requests on stream 4, 8, and so on. In order to | |||
permit these streams to open, an HTTP/3 server SHOULD configure non- | permit these streams to open, an HTTP/3 server SHOULD configure non- | |||
zero minimum values for the number of permitted streams and the | zero minimum values for the number of permitted streams and the | |||
initial stream flow control window. So as to not unnecessarily limit | initial stream flow control window. So as to not unnecessarily limit | |||
parallelism, at least 100 requests SHOULD be permitted at a time. | parallelism, at least 100 request streams SHOULD be permitted at a | |||
time. | ||||
HTTP/3 does not use server-initiated bidirectional streams, though an | HTTP/3 does not use server-initiated bidirectional streams, though an | |||
extension could define a use for these streams. Clients MUST treat | extension could define a use for these streams. Clients MUST treat | |||
receipt of a server-initiated bidirectional stream as a connection | receipt of a server-initiated bidirectional stream as a connection | |||
error of type H3_STREAM_CREATION_ERROR (Section 8) unless such an | error of type H3_STREAM_CREATION_ERROR (Section 8) unless such an | |||
extension has been negotiated. | extension has been negotiated. | |||
6.2. Unidirectional Streams | 6.2. Unidirectional Streams | |||
Unidirectional streams, in either direction, are used for a range of | Unidirectional streams, in either direction, are used for a range of | |||
skipping to change at page 28, line 10 ¶ | skipping to change at page 28, line 50 ¶ | |||
type, this MUST be treated as a connection error of type | type, this MUST be treated as a connection error of type | |||
H3_MISSING_SETTINGS. Only one control stream per peer is permitted; | H3_MISSING_SETTINGS. Only one control stream per peer is permitted; | |||
receipt of a second stream claiming to be a control stream MUST be | receipt of a second stream claiming to be a control stream MUST be | |||
treated as a connection error of type H3_STREAM_CREATION_ERROR. The | treated as a connection error of type H3_STREAM_CREATION_ERROR. The | |||
sender MUST NOT close the control stream, and the receiver MUST NOT | sender MUST NOT close the control stream, and the receiver MUST NOT | |||
request that the sender close the control stream. If either control | request that the sender close the control stream. If either control | |||
stream is closed at any point, this MUST be treated as a connection | stream is closed at any point, this MUST be treated as a connection | |||
error of type H3_CLOSED_CRITICAL_STREAM. Connection errors are | error of type H3_CLOSED_CRITICAL_STREAM. Connection errors are | |||
described in Section 8. | described in Section 8. | |||
Because the contents of the control stream are used to manage the | ||||
behavior of other streams, endpoints SHOULD provide enough flow | ||||
control credit to keep the peer's control stream from becoming | ||||
blocked. | ||||
A pair of unidirectional streams is used rather than a single | A pair of unidirectional streams is used rather than a single | |||
bidirectional stream. This allows either peer to send data as soon | bidirectional stream. This allows either peer to send data as soon | |||
as it is able. Depending on whether 0-RTT is enabled on the QUIC | as it is able. Depending on whether 0-RTT is available on the QUIC | |||
connection, either client or server might be able to send stream data | connection, either client or server might be able to send stream data | |||
first after the cryptographic handshake completes. | first. | |||
6.2.2. Push Streams | 6.2.2. Push Streams | |||
Server push is an optional feature introduced in HTTP/2 that allows a | Server push is an optional feature introduced in HTTP/2 that allows a | |||
server to initiate a response before a request has been made. See | server to initiate a response before a request has been made. See | |||
Section 4.4 for more details. | Section 4.4 for more details. | |||
A push stream is indicated by a stream type of 0x01, followed by the | A push stream is indicated by a stream type of 0x01, followed by the | |||
Push ID of the promise that it fulfills, encoded as a variable-length | Push ID of the promise that it fulfills, encoded as a variable-length | |||
integer. The remaining data on this stream consists of HTTP/3 | integer. The remaining data on this stream consists of HTTP/3 | |||
skipping to change at page 30, line 5 ¶ | skipping to change at page 31, line 5 ¶ | |||
| | | | | | | | | | | | | | |||
| MAX_PUSH_ID | Yes | No | No | Section 7.2 | | | MAX_PUSH_ID | Yes | No | No | Section 7.2 | | |||
| | | | | .7 | | | | | | | .7 | | |||
| | | | | | | | | | | | | | |||
| Reserved | Yes | Yes | Yes | Section 7.2 | | | Reserved | Yes | Yes | Yes | Section 7.2 | | |||
| | | | | .8 | | | | | | | .8 | | |||
+--------------+------------+-------------+-----------+-------------+ | +--------------+------------+-------------+-----------+-------------+ | |||
Table 1: HTTP/3 Frames and Stream Type Overview | Table 1: HTTP/3 Frames and Stream Type Overview | |||
Certain frames can only occur as the first frame of a particular | The SETTINGS frame can only occur as the first frame of a Control | |||
stream type; these are indicated in Table 1 with a (1). Specific | stream; this is indicated in Table 1 with a (1). Specific guidance | |||
guidance is provided in the relevant section. | is provided in the relevant section. | |||
Note that, unlike QUIC frames, HTTP/3 frames can span multiple | Note that, unlike QUIC frames, HTTP/3 frames can span multiple | |||
packets. | packets. | |||
7.1. Frame Layout | 7.1. Frame Layout | |||
All frames have the following format: | All frames have the following format: | |||
HTTP/3 Frame Format { | HTTP/3 Frame Format { | |||
Type (i), | Type (i), | |||
skipping to change at page 30, line 38 ¶ | skipping to change at page 31, line 38 ¶ | |||
Length: A variable-length integer that describes the length in bytes | Length: A variable-length integer that describes the length in bytes | |||
of the Frame Payload. | of the Frame Payload. | |||
Frame Payload: A payload, the semantics of which are determined by | Frame Payload: A payload, the semantics of which are determined by | |||
the Type field. | the Type field. | |||
Each frame's payload MUST contain exactly the fields identified in | Each frame's payload MUST contain exactly the fields identified in | |||
its description. A frame payload that contains additional bytes | its description. A frame payload that contains additional bytes | |||
after the identified fields or a frame payload that terminates before | after the identified fields or a frame payload that terminates before | |||
the end of the identified fields MUST be treated as a connection | the end of the identified fields MUST be treated as a connection | |||
error of type H3_FRAME_ERROR; see Section 8. | error of type H3_FRAME_ERROR; see Section 8. In particular, | |||
redundant length encodings MUST be verified to be self-consistent; | ||||
see Section 10.8. | ||||
When a stream terminates cleanly, if the last frame on the stream was | When a stream terminates cleanly, if the last frame on the stream was | |||
truncated, this MUST be treated as a connection error of type | truncated, this MUST be treated as a connection error of type | |||
H3_FRAME_ERROR; see Section 8. Streams that terminate abruptly may | H3_FRAME_ERROR; see Section 8. Streams that terminate abruptly may | |||
be reset at any point in a frame. | be reset at any point in a frame. | |||
7.2. Frame Definitions | 7.2. Frame Definitions | |||
7.2.1. DATA | 7.2.1. DATA | |||
DATA frames (type=0x0) convey arbitrary, variable-length sequences of | DATA frames (type=0x0) convey arbitrary, variable-length sequences of | |||
bytes associated with HTTP request or response payload data. | bytes associated with HTTP request or response content. | |||
DATA frames MUST be associated with an HTTP request or response. If | DATA frames MUST be associated with an HTTP request or response. If | |||
a DATA frame is received on a control stream, the recipient MUST | a DATA frame is received on a control stream, the recipient MUST | |||
respond with a connection error of type H3_FRAME_UNEXPECTED; see | respond with a connection error of type H3_FRAME_UNEXPECTED; see | |||
Section 8. | Section 8. | |||
DATA Frame { | DATA Frame { | |||
Type (i) = 0x0, | Type (i) = 0x0, | |||
Length (i), | Length (i), | |||
Data (..), | Data (..), | |||
skipping to change at page 32, line 29 ¶ | skipping to change at page 33, line 32 ¶ | |||
client SHOULD abort reading the stream with an error code of | client SHOULD abort reading the stream with an error code of | |||
H3_REQUEST_CANCELLED. | H3_REQUEST_CANCELLED. | |||
A CANCEL_PUSH frame is sent on the control stream. Receiving a | A CANCEL_PUSH frame is sent on the control stream. Receiving a | |||
CANCEL_PUSH frame on a stream other than the control stream MUST be | CANCEL_PUSH frame on a stream other than the control stream MUST be | |||
treated as a connection error of type H3_FRAME_UNEXPECTED. | treated as a connection error of type H3_FRAME_UNEXPECTED. | |||
CANCEL_PUSH Frame { | CANCEL_PUSH Frame { | |||
Type (i) = 0x3, | Type (i) = 0x3, | |||
Length (i), | Length (i), | |||
Push ID (..), | Push ID (i), | |||
} | } | |||
Figure 6: CANCEL_PUSH Frame | Figure 6: CANCEL_PUSH Frame | |||
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length | The CANCEL_PUSH frame carries a Push ID encoded as a variable-length | |||
integer. The Push ID identifies the server push that is being | integer. The Push ID identifies the server push that is being | |||
cancelled; see Section 4.4. If a CANCEL_PUSH frame is received that | cancelled; see Section 4.4. If a CANCEL_PUSH frame is received that | |||
references a Push ID greater than currently allowed on the | references a Push ID greater than currently allowed on the | |||
connection, this MUST be treated as a connection error of type | connection, this MUST be treated as a connection error of type | |||
H3_ID_ERROR. | H3_ID_ERROR. | |||
skipping to change at page 34, line 5 ¶ | skipping to change at page 35, line 18 ¶ | |||
} | } | |||
SETTINGS Frame { | SETTINGS Frame { | |||
Type (i) = 0x4, | Type (i) = 0x4, | |||
Length (i), | Length (i), | |||
Setting (..) ..., | Setting (..) ..., | |||
} | } | |||
Figure 7: SETTINGS Frame | Figure 7: SETTINGS Frame | |||
An implementation MUST ignore the contents for any SETTINGS | An implementation MUST ignore any parameter with an identifier it | |||
identifier it does not understand. | does not understand. | |||
7.2.4.1. Defined SETTINGS Parameters | 7.2.4.1. Defined SETTINGS Parameters | |||
The following settings are defined in HTTP/3: | The following settings are defined in HTTP/3: | |||
SETTINGS_MAX_FIELD_SECTION_SIZE (0x6): The default value is | SETTINGS_MAX_FIELD_SECTION_SIZE (0x6): The default value is | |||
unlimited. See Section 4.1.1.3 for usage. | unlimited. See Section 4.1.1.3 for usage. | |||
Setting identifiers of the format "0x1f * N + 0x21" for non-negative | Setting identifiers of the format "0x1f * N + 0x21" for non-negative | |||
integer values of N are reserved to exercise the requirement that | integer values of N are reserved to exercise the requirement that | |||
unknown identifiers be ignored. Such settings have no defined | unknown identifiers be ignored. Such settings have no defined | |||
meaning. Endpoints SHOULD include at least one such setting in their | meaning. Endpoints SHOULD include at least one such setting in their | |||
SETTINGS frame. Endpoints MUST NOT consider such settings to have | SETTINGS frame. Endpoints MUST NOT consider such settings to have | |||
any meaning upon receipt. | any meaning upon receipt. | |||
Because the setting has no defined meaning, the value of the setting | Because the setting has no defined meaning, the value of the setting | |||
can be any value the implementation selects. | can be any value the implementation selects. | |||
Setting identifiers which were used in HTTP/2 where there is no | Setting identifiers which were defined in [HTTP2] where there is no | |||
corresponding HTTP/3 setting have also been reserved | corresponding HTTP/3 setting have also been reserved | |||
(Section 11.2.2). These settings MUST NOT be sent, and their receipt | (Section 11.2.2). These reserved settings MUST NOT be sent, and | |||
MUST be treated as a connection error of type H3_SETTINGS_ERROR. | their receipt MUST be treated as a connection error of type | |||
H3_SETTINGS_ERROR. | ||||
Additional settings can be defined by extensions to HTTP/3; see | Additional settings can be defined by extensions to HTTP/3; see | |||
Section 9 for more details. | Section 9 for more details. | |||
7.2.4.2. Initialization | 7.2.4.2. Initialization | |||
An HTTP implementation MUST NOT send frames or requests that would be | An HTTP implementation MUST NOT send frames or requests that would be | |||
invalid based on its current understanding of the peer's settings. | invalid based on its current understanding of the peer's settings. | |||
All settings begin at an initial value. Each endpoint SHOULD use | All settings begin at an initial value. Each endpoint SHOULD use | |||
skipping to change at page 35, line 48 ¶ | skipping to change at page 37, line 13 ¶ | |||
with the previously specified settings, this MUST be treated as a | with the previously specified settings, this MUST be treated as a | |||
connection error of type H3_SETTINGS_ERROR. If a server accepts | connection error of type H3_SETTINGS_ERROR. If a server accepts | |||
0-RTT but then sends a SETTINGS frame that omits a setting value that | 0-RTT but then sends a SETTINGS frame that omits a setting value that | |||
the client understands (apart from reserved setting identifiers) that | the client understands (apart from reserved setting identifiers) that | |||
was previously specified to have a non-default value, this MUST be | was previously specified to have a non-default value, this MUST be | |||
treated as a connection error of type H3_SETTINGS_ERROR. | treated as a connection error of type H3_SETTINGS_ERROR. | |||
7.2.5. PUSH_PROMISE | 7.2.5. PUSH_PROMISE | |||
The PUSH_PROMISE frame (type=0x5) is used to carry a promised request | The PUSH_PROMISE frame (type=0x5) is used to carry a promised request | |||
header field section from server to client on a request stream, as in | header section from server to client on a request stream, as in | |||
HTTP/2. | HTTP/2. | |||
PUSH_PROMISE Frame { | PUSH_PROMISE Frame { | |||
Type (i) = 0x5, | Type (i) = 0x5, | |||
Length (i), | Length (i), | |||
Push ID (i), | Push ID (i), | |||
Encoded Field Section (..), | Encoded Field Section (..), | |||
} | } | |||
Figure 8: PUSH_PROMISE Frame | Figure 8: PUSH_PROMISE Frame | |||
skipping to change at page 41, line 31 ¶ | skipping to change at page 42, line 40 ¶ | |||
Extensions are permitted to use new frame types (Section 7.2), new | Extensions are permitted to use new frame types (Section 7.2), new | |||
settings (Section 7.2.4.1), new error codes (Section 8), or new | settings (Section 7.2.4.1), new error codes (Section 8), or new | |||
unidirectional stream types (Section 6.2). Registries are | unidirectional stream types (Section 6.2). Registries are | |||
established for managing these extension points: frame types | established for managing these extension points: frame types | |||
(Section 11.2.1), settings (Section 11.2.2), error codes | (Section 11.2.1), settings (Section 11.2.2), error codes | |||
(Section 11.2.3), and stream types (Section 11.2.4). | (Section 11.2.3), and stream types (Section 11.2.4). | |||
Implementations MUST ignore unknown or unsupported values in all | Implementations MUST ignore unknown or unsupported values in all | |||
extensible protocol elements. Implementations MUST discard frames | extensible protocol elements. Implementations MUST discard frames | |||
and unidirectional streams that have unknown or unsupported types. | and abort reading on unidirectional streams that have unknown or | |||
This means that any of these extension points can be safely used by | unsupported types. This means that any of these extension points can | |||
extensions without prior arrangement or negotiation. However, where | be safely used by extensions without prior arrangement or | |||
a known frame type is required to be in a specific location, such as | negotiation. However, where a known frame type is required to be in | |||
the SETTINGS frame as the first frame of the control stream (see | a specific location, such as the SETTINGS frame as the first frame of | |||
Section 6.2.1), an unknown frame type does not satisfy that | the control stream (see Section 6.2.1), an unknown frame type does | |||
requirement and SHOULD be treated as an error. | not satisfy that requirement and SHOULD be treated as an error. | |||
Extensions that could change the semantics of existing protocol | Extensions that could change the semantics of existing protocol | |||
components MUST be negotiated before being used. For example, an | components MUST be negotiated before being used. For example, an | |||
extension that changes the layout of the HEADERS frame cannot be used | extension that changes the layout of the HEADERS frame cannot be used | |||
until the peer has given a positive signal that this is acceptable. | until the peer has given a positive signal that this is acceptable. | |||
Coordinating when such a revised layout comes into effect could prove | Coordinating when such a revised layout comes into effect could prove | |||
complex. As such, allocating new identifiers for new definitions of | complex. As such, allocating new identifiers for new definitions of | |||
existing protocol elements is likely to be more effective. | existing protocol elements is likely to be more effective. | |||
This document does not mandate a specific method for negotiating the | This document does not mandate a specific method for negotiating the | |||
skipping to change at page 44, line 9 ¶ | skipping to change at page 45, line 15 ¶ | |||
to traffic analysis. | to traffic analysis. | |||
Compression of field sections also offers some opportunities to waste | Compression of field sections also offers some opportunities to waste | |||
processing resources; see Section 7 of [QPACK] for more details on | processing resources; see Section 7 of [QPACK] for more details on | |||
potential abuses. | potential abuses. | |||
All these features - i.e., server push, unknown protocol elements, | All these features - i.e., server push, unknown protocol elements, | |||
field compression - have legitimate uses. These features become a | field compression - have legitimate uses. These features become a | |||
burden only when they are used unnecessarily or to excess. | burden only when they are used unnecessarily or to excess. | |||
An endpoint that does not monitor this behavior exposes itself to a | An endpoint that does not monitor such behavior exposes itself to a | |||
risk of denial-of-service attack. Implementations SHOULD track the | risk of denial-of-service attack. Implementations SHOULD track the | |||
use of these features and set limits on their use. An endpoint MAY | use of these features and set limits on their use. An endpoint MAY | |||
treat activity that is suspicious as a connection error of type | treat activity that is suspicious as a connection error of type | |||
H3_EXCESSIVE_LOAD (Section 8), but false positives will result in | H3_EXCESSIVE_LOAD (Section 8), but false positives will result in | |||
disrupting valid connections and requests. | disrupting valid connections and requests. | |||
10.5.1. Limits on Field Section Size | 10.5.1. Limits on Field Section Size | |||
A large field section (Section 4.1) can cause an implementation to | A large field section (Section 4.1) can cause an implementation to | |||
commit a large amount of state. Header fields that are critical for | commit a large amount of state. Header fields that are critical for | |||
routing can appear toward the end of a header field section, which | routing can appear toward the end of a header section, which prevents | |||
prevents streaming of the header field section to its ultimate | streaming of the header section to its ultimate destination. This | |||
destination. This ordering and other reasons, such as ensuring cache | ordering and other reasons, such as ensuring cache correctness, mean | |||
correctness, mean that an endpoint likely needs to buffer the entire | that an endpoint likely needs to buffer the entire header section. | |||
header field section. Since there is no hard limit to the size of a | Since there is no hard limit to the size of a field section, some | |||
field section, some endpoints could be forced to commit a large | endpoints could be forced to commit a large amount of available | |||
amount of available memory for header fields. | memory for header fields. | |||
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE | An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE | |||
(Section 4.1.1.3) setting to advise peers of limits that might apply | (Section 4.1.1.3) setting to advise peers of limits that might apply | |||
on the size of field sections. This setting is only advisory, so | on the size of field sections. This setting is only advisory, so | |||
endpoints MAY choose to send field sections that exceed this limit | endpoints MAY choose to send field sections that exceed this limit | |||
and risk having the request or response being treated as malformed. | and risk having the request or response being treated as malformed. | |||
This setting is specific to an HTTP/3 connection, so any request or | This setting is specific to an HTTP/3 connection, so any request or | |||
response could encounter a hop with a lower, unknown limit. An | response could encounter a hop with a lower, unknown limit. An | |||
intermediary can attempt to avoid this problem by passing on values | intermediary can attempt to avoid this problem by passing on values | |||
presented by different peers, but they are not obligated to do so. | presented by different peers, but they are not obligated to do so. | |||
A server that receives a larger field section than it is willing to | A server that receives a larger field section than it is willing to | |||
handle can send an HTTP 431 (Request Header Fields Too Large) status | handle can send an HTTP 431 (Request Header Fields Too Large) status | |||
code ([RFC6585]). A client can discard responses that it cannot | code ([RFC6585]). A client can discard responses that it cannot | |||
process. | process. | |||
10.5.2. CONNECT Issues | 10.5.2. CONNECT Issues | |||
The CONNECT method can be used to create disproportionate load on a | The CONNECT method can be used to create disproportionate load on a | |||
proxy, since stream creation is relatively inexpensive when compared | proxy, since stream creation is relatively inexpensive when compared | |||
to the creation and maintenance of a TCP connection. A proxy might | to the creation and maintenance of a TCP connection. Therefore, a | |||
also maintain some resources for a TCP connection beyond the closing | proxy that supports CONNECT might be more conservative in the number | |||
of the stream that carries the CONNECT request, since the outgoing | of simultaneous requests it accepts. | |||
TCP connection remains in the TIME_WAIT state. Therefore, a proxy | ||||
cannot rely on QUIC stream limits alone to control the resources | A proxy might also maintain some resources for a TCP connection | |||
consumed by CONNECT requests. | beyond the closing of the stream that carries the CONNECT request, | |||
since the outgoing TCP connection remains in the TIME_WAIT state. To | ||||
account for this, a proxy might delay increasing the QUIC stream | ||||
limits for some time after a TCP connection terminates. | ||||
10.6. Use of Compression | 10.6. Use of Compression | |||
Compression can allow an attacker to recover secret data when it is | Compression can allow an attacker to recover secret data when it is | |||
compressed in the same context as data under attacker control. | compressed in the same context as data under attacker control. | |||
HTTP/3 enables compression of fields (Section 4.1.1); the following | HTTP/3 enables compression of fields (Section 4.1.1); the following | |||
concerns also apply to the use of HTTP compressed content-codings; | concerns also apply to the use of HTTP compressed content-codings; | |||
see Section 8.5.1 of [SEMANTICS]. | see Section 8.4.1 of [SEMANTICS]. | |||
There are demonstrable attacks on compression that exploit the | There are demonstrable attacks on compression that exploit the | |||
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 contexts are used for each source of | unless separate compression contexts 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. | reliably determined. | |||
Further considerations regarding the compression of fields sections | Further considerations regarding the compression of field sections | |||
are described in [QPACK]. | are described in [QPACK]. | |||
10.7. Padding and Traffic Analysis | 10.7. Padding and Traffic Analysis | |||
Padding can be used to obscure the exact size of frame content and is | Padding can be used to obscure the exact size of frame content and is | |||
provided to mitigate specific attacks within HTTP, for example, | provided to mitigate specific attacks within HTTP, for example, | |||
attacks where compressed content includes both attacker-controlled | attacks where compressed content includes both attacker-controlled | |||
plaintext and secret data (e.g., [BREACH]). | plaintext and secret data (e.g., [BREACH]). | |||
Where HTTP/2 employs PADDING frames and Padding fields in other | Where HTTP/2 employs PADDING frames and Padding fields in other | |||
skipping to change at page 46, line 31 ¶ | skipping to change at page 47, line 45 ¶ | |||
Several protocol elements contain nested length elements, typically | Several protocol elements contain nested length elements, typically | |||
in the form of frames with an explicit length containing variable- | in the form of frames with an explicit length containing variable- | |||
length integers. This could pose a security risk to an incautious | length integers. This could pose a security risk to an incautious | |||
implementer. An implementation MUST ensure that the length of a | implementer. An implementation MUST ensure that the length of a | |||
frame exactly matches the length of the fields it contains. | frame exactly matches the length of the fields it contains. | |||
10.9. Early Data | 10.9. Early Data | |||
The use of 0-RTT with HTTP/3 creates an exposure to replay attack. | The use of 0-RTT with HTTP/3 creates an exposure to replay attack. | |||
The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when | The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when | |||
using HTTP/3 with 0-RTT. | using HTTP/3 with 0-RTT. When applying [HTTP-REPLAY] to HTTP/3, | |||
references to the TLS layer refer to the handshake performed within | ||||
QUIC, while all references to application data refer to the contents | ||||
of streams. | ||||
10.10. Migration | 10.10. Migration | |||
Certain HTTP implementations use the client address for logging or | Certain HTTP implementations use the client address for logging or | |||
access-control purposes. Since a QUIC client's address might change | access-control purposes. Since a QUIC client's address might change | |||
during a connection (and future versions might support simultaneous | during a connection (and future versions might support simultaneous | |||
use of multiple addresses), such implementations will need to either | use of multiple addresses), such implementations will need to either | |||
actively retrieve the client's current address or addresses when they | actively retrieve the client's current address or addresses when they | |||
are relevant or explicitly accept that the original address might | are relevant or explicitly accept that the original address might | |||
change. | change. | |||
skipping to change at page 48, line 13 ¶ | skipping to change at page 49, line 33 ¶ | |||
Permanent registrations in this registry are assigned using the | Permanent registrations in this registry are assigned using the | |||
Specification Required policy ([RFC8126]), except for values between | Specification Required policy ([RFC8126]), except for values between | |||
0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using | 0x00 and 0x3f (in hexadecimal; inclusive), which are assigned using | |||
Standards Action or IESG Approval as defined in Section 4.9 and 4.10 | Standards Action or IESG Approval as defined in Section 4.9 and 4.10 | |||
of [RFC8126]. | of [RFC8126]. | |||
While this registry is separate from the "HTTP/2 Frame Type" registry | While this registry is separate from the "HTTP/2 Frame Type" registry | |||
defined in [HTTP2], it is preferable that the assignments parallel | defined in [HTTP2], it is preferable that the assignments parallel | |||
each other where the code spaces overlap. If an entry is present in | each other where the code spaces overlap. If an entry is present in | |||
only one registry, every effort SHOULD be made to avoid assigning the | only one registry, every effort SHOULD be made to avoid assigning the | |||
corresponding value to an unrelated operation. | corresponding value to an unrelated operation. Expert reviewers MAY | |||
reject unrelated registrations which would conflict with the same | ||||
value in the corresponding registry. | ||||
In addition to common fields as described in Section 11.2, permanent | In addition to common fields as described in Section 11.2, permanent | |||
registrations in this registry MUST include the following field: | registrations in this registry MUST include the following field: | |||
Frame Type: A name or label for the frame type. | Frame Type: A name or label for the frame type. | |||
Specifications of frame types MUST include a description of the frame | Specifications of frame types MUST include a description of the frame | |||
layout and its semantics, including any parts of the frame that are | layout and its semantics, including any parts of the frame that are | |||
conditionally present. | conditionally present. | |||
skipping to change at page 50, line 5 ¶ | skipping to change at page 51, line 4 ¶ | |||
registrations in this registry are assigned using the Specification | registrations in this registry are assigned using the Specification | |||
Required policy ([RFC8126]), except for values between 0x00 and 0x3f | Required policy ([RFC8126]), except for values between 0x00 and 0x3f | |||
(in hexadecimal; inclusive), which are assigned using Standards | (in hexadecimal; inclusive), which are assigned using Standards | |||
Action or IESG Approval as defined in Section 4.9 and 4.10 of | Action or IESG Approval as defined in Section 4.9 and 4.10 of | |||
[RFC8126]. | [RFC8126]. | |||
While this registry is separate from the "HTTP/2 Settings" registry | While this registry is separate from the "HTTP/2 Settings" registry | |||
defined in [HTTP2], it is preferable that the assignments parallel | defined in [HTTP2], it is preferable that the assignments parallel | |||
each other. If an entry is present in only one registry, every | each other. If an entry is present in only one registry, every | |||
effort SHOULD be made to avoid assigning the corresponding value to | effort SHOULD be made to avoid assigning the corresponding value to | |||
an unrelated operation. | an unrelated operation. Expert reviewers MAY reject unrelated | |||
registrations which would conflict with the same value in the | ||||
corresponding registry. | ||||
In addition to common fields as described in Section 11.2, permanent | In addition to common fields as described in Section 11.2, permanent | |||
registrations in this registry MUST include the following fields: | registrations in this registry MUST include the following fields: | |||
Setting Name: A symbolic name for the setting. Specifying a setting | Setting Name: A symbolic name for the setting. Specifying a setting | |||
name is optional. | name is optional. | |||
Default: The value of the setting unless otherwise indicated. A | Default: The value of the setting unless otherwise indicated. A | |||
default SHOULD be the most restrictive possible value. | default SHOULD be the most restrictive possible value. | |||
The entries in Table 3 are registered by this document. | The entries in Table 3 are registered by this document. | |||
+------------------------+-------+------------------+-----------+ | +------------------------+-------+------------------+-----------+ | |||
| Setting Name | Value | Specification | Default | | | Setting Name | Value | Specification | Default | | |||
+------------------------+-------+------------------+-----------+ | +------------------------+-------+------------------+-----------+ | |||
| Reserved | 0x0 | N/A | N/A | | ||||
| | | | | | ||||
| Reserved | 0x2 | N/A | N/A | | | Reserved | 0x2 | N/A | N/A | | |||
| | | | | | | | | | | | |||
| Reserved | 0x3 | N/A | N/A | | | Reserved | 0x3 | N/A | N/A | | |||
| | | | | | | | | | | | |||
| Reserved | 0x4 | N/A | N/A | | | Reserved | 0x4 | N/A | N/A | | |||
| | | | | | | | | | | | |||
| Reserved | 0x5 | N/A | N/A | | | Reserved | 0x5 | N/A | N/A | | |||
| | | | | | | | | | | | |||
| MAX_FIELD_SECTION_SIZE | 0x6 | Section 7.2.4.1 | Unlimited | | | MAX_FIELD_SECTION_SIZE | 0x6 | Section 7.2.4.1 | Unlimited | | |||
+------------------------+-------+------------------+-----------+ | +------------------------+-------+------------------+-----------+ | |||
skipping to change at page 51, line 7 ¶ | skipping to change at page 52, line 10 ¶ | |||
Required policy ([RFC8126]), except for values between 0x00 and 0x3f | Required policy ([RFC8126]), except for values between 0x00 and 0x3f | |||
(in hexadecimal; inclusive), which are assigned using Standards | (in hexadecimal; inclusive), which are assigned using Standards | |||
Action or IESG Approval as defined in Section 4.9 and 4.10 of | Action or IESG Approval as defined in Section 4.9 and 4.10 of | |||
[RFC8126]. | [RFC8126]. | |||
Registrations for error codes are required to include a description | Registrations for error codes are required to include a description | |||
of the error code. An expert reviewer is advised to examine new | of the error code. An expert reviewer is advised to examine new | |||
registrations for possible duplication with existing error codes. | registrations for possible duplication with existing error codes. | |||
Use of existing registrations is to be encouraged, but not mandated. | Use of existing registrations is to be encouraged, but not mandated. | |||
Use of values that are registered in the "HTTP/2 Error Code" registry | Use of values that are registered in the "HTTP/2 Error Code" registry | |||
is discouraged. | is discouraged, and expert reviewers MAY reject such registrations. | |||
In addition to common fields as described in Section 11.2, this | In addition to common fields as described in Section 11.2, this | |||
registry includes two additional fields. Permanent registrations in | registry includes two additional fields. Permanent registrations in | |||
this registry MUST include the following field: | this registry MUST include the following field: | |||
Name: A name for the error code. | Name: A name for the error code. | |||
Description: A brief description of the error code semantics. | Description: A brief description of the error code semantics. | |||
The entries in Table 4 are registered by this document. These error | The entries in Table 4 are registered by this document. These error | |||
codes were selected from the range that operates on a Specification | codes were selected from the range that operates on a Specification | |||
Required policy to avoid collisions with HTTP/2 error codes. | Required policy to avoid collisions with HTTP/2 error codes. | |||
+---------------------------+--------+--------------+---------------+ | +---------------------------+-------+---------------+---------------+ | |||
| Name | Value | Description | Specification | | | Name | Value | Description | Specification | | |||
+---------------------------+--------+--------------+---------------+ | +---------------------------+-------+---------------+---------------+ | |||
| H3_NO_ERROR | 0x0100 | No error | Section 8.1 | | | H3_NO_ERROR | 0x100 | No error | Section 8.1 | | |||
| | | | | | | | | | | | |||
| H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General | Section 8.1 | | | H3_GENERAL_PROTOCOL_ERROR | 0x101 | General | Section 8.1 | | |||
| | | protocol | | | | | | protocol | | | |||
| | | error | | | | | | error | | | |||
| | | | | | | | | | | | |||
| H3_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 | | | H3_INTERNAL_ERROR | 0x102 | Internal | Section 8.1 | | |||
| | | error | | | | | | error | | | |||
| | | | | | | | | | | | |||
| H3_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 | | | H3_STREAM_CREATION_ERROR | 0x103 | Stream | Section 8.1 | | |||
| | | creation | | | | | | creation | | | |||
| | | error | | | | | | error | | | |||
| | | | | | | | | | | | |||
| H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical | Section 8.1 | | | H3_CLOSED_CRITICAL_STREAM | 0x104 | Critical | Section 8.1 | | |||
| | | stream was | | | | | | stream was | | | |||
| | | closed | | | | | | closed | | | |||
| | | | | | | | | | | | |||
| H3_FRAME_UNEXPECTED | 0x0105 | Frame not | Section 8.1 | | | H3_FRAME_UNEXPECTED | 0x105 | Frame not | Section 8.1 | | |||
| | | permitted in | | | | | | permitted in | | | |||
| | | the current | | | | | | the current | | | |||
| | | state | | | | | | state | | | |||
| | | | | | | | | | | | |||
| H3_FRAME_ERROR | 0x0106 | Frame | Section 8.1 | | | H3_FRAME_ERROR | 0x106 | Frame | Section 8.1 | | |||
| | | violated | | | | | | violated | | | |||
| | | layout or | | | | | | layout or | | | |||
| | | size rules | | | | | | size rules | | | |||
| | | | | | | | | | | | |||
| H3_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 | | | H3_EXCESSIVE_LOAD | 0x107 | Peer | Section 8.1 | | |||
| | | generating | | | | | | generating | | | |||
| | | excessive | | | | | | excessive | | | |||
| | | load | | | | | | load | | | |||
| | | | | | | | | | | | |||
| H3_ID_ERROR | 0x0108 | An | Section 8.1 | | | H3_ID_ERROR | 0x108 | An identifier | Section 8.1 | | |||
| | | identifier | | | | | | was used | | | |||
| | | was used | | | | | | incorrectly | | | |||
| | | incorrectly | | | | | | | | | |||
| | | | | | | H3_SETTINGS_ERROR | 0x109 | SETTINGS | Section 8.1 | | |||
| H3_SETTINGS_ERROR | 0x0109 | SETTINGS | Section 8.1 | | | | | frame | | | |||
| | | frame | | | | | | contained | | | |||
| | | contained | | | | | | invalid | | | |||
| | | invalid | | | | | | values | | | |||
| | | values | | | | | | | | | |||
| | | | | | | H3_MISSING_SETTINGS | 0x10a | No SETTINGS | Section 8.1 | | |||
| H3_MISSING_SETTINGS | 0x010a | No SETTINGS | Section 8.1 | | | | | frame | | | |||
| | | frame | | | | | | received | | | |||
| | | received | | | | | | | | | |||
| | | | | | | H3_REQUEST_REJECTED | 0x10b | Request not | Section 8.1 | | |||
| H3_REQUEST_REJECTED | 0x010b | Request not | Section 8.1 | | | | | processed | | | |||
| | | processed | | | | | | | | | |||
| | | | | | | H3_REQUEST_CANCELLED | 0x10c | Data no | Section 8.1 | | |||
| H3_REQUEST_CANCELLED | 0x010c | Data no | Section 8.1 | | | | | longer needed | | | |||
| | | longer | | | | | | | | | |||
| | | needed | | | | H3_REQUEST_INCOMPLETE | 0x10d | Stream | Section 8.1 | | |||
| | | | | | | | | terminated | | | |||
| H3_REQUEST_INCOMPLETE | 0x010d | Stream | Section 8.1 | | | | | early | | | |||
| | | terminated | | | | | | | | | |||
| | | early | | | | H3_MESSAGE_ERROR | 0x10e | Malformed | Section 8.1 | | |||
| | | | | | | | | message | | | |||
| H3_MESSAGE_ERROR | 0x010e | Malformed | Section 8.1 | | | | | | | | |||
| | | message | | | | H3_CONNECT_ERROR | 0x10f | TCP reset or | Section 8.1 | | |||
| | | | | | | | | error on | | | |||
| H3_CONNECT_ERROR | 0x010f | TCP reset or | Section 8.1 | | | | | CONNECT | | | |||
| | | error on | | | | | | request | | | |||
| | | CONNECT | | | | | | | | | |||
| | | request | | | | H3_VERSION_FALLBACK | 0x110 | Retry over | Section 8.1 | | |||
| | | | | | | | | HTTP/1.1 | | | |||
| H3_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 | | +---------------------------+-------+---------------+---------------+ | |||
| | | HTTP/1.1 | | | ||||
+---------------------------+--------+--------------+---------------+ | ||||
Table 4: Initial HTTP/3 Error Codes | Table 4: Initial HTTP/3 Error Codes | |||
Each code of the format "0x1f * N + 0x21" for non-negative integer | Each code of the format "0x1f * N + 0x21" for non-negative integer | |||
values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) | values of N (that is, 0x21, 0x40, ..., through 0x3ffffffffffffffe) | |||
MUST NOT be assigned by IANA and MUST NOT appear in the listing of | MUST NOT be assigned by IANA and MUST NOT appear in the listing of | |||
assigned values. | assigned values. | |||
11.2.4. Stream Types | 11.2.4. Stream Types | |||
skipping to change at page 54, line 6 ¶ | skipping to change at page 55, line 6 ¶ | |||
12. References | 12. References | |||
12.1. Normative References | 12.1. Normative References | |||
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP | [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP | |||
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, | Alternative Services", RFC 7838, DOI 10.17487/RFC7838, | |||
April 2016, <https://www.rfc-editor.org/info/rfc7838>. | April 2016, <https://www.rfc-editor.org/info/rfc7838>. | |||
[CACHING] Fielding, R., Nottingham, M., and J. Reschke, "HTTP | [CACHING] Fielding, R., Nottingham, M., and J. Reschke, "HTTP | |||
Caching", draft-ietf-httpbis-cache-13 (work in progress), | Caching", draft-ietf-httpbis-cache-14 (work in progress), | |||
December 2020. | January 2021. | |||
[HTTP-REPLAY] | [HTTP-REPLAY] | |||
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early | Thomson, M., Nottingham, M., and W. Tarreau, "Using Early | |||
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September | Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September | |||
2018, <https://www.rfc-editor.org/info/rfc8470>. | 2018, <https://www.rfc-editor.org/info/rfc8470>. | |||
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: | [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: | |||
Header Compression for HTTP over QUIC", draft-ietf-quic- | Header Compression for HTTP over QUIC", draft-ietf-quic- | |||
qpack-20 (work in progress). | qpack-latest (work in progress). | |||
[QUIC-TRANSPORT] | [QUIC-TRANSPORT] | |||
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based | |||
Multiplexed and Secure Transport", draft-ietf-quic- | Multiplexed and Secure Transport", draft-ietf-quic- | |||
transport-33 (work in progress). | transport-latest (work in progress). | |||
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, | |||
RFC 793, DOI 10.17487/RFC0793, September 1981, | RFC 793, DOI 10.17487/RFC0793, September 1981, | |||
<https://www.rfc-editor.org/info/rfc793>. | <https://www.rfc-editor.org/info/rfc793>. | |||
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
<https://www.rfc-editor.org/info/rfc2119>. | <https://www.rfc-editor.org/info/rfc2119>. | |||
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) | |||
Extensions: Extension Definitions", RFC 6066, | Extensions: Extension Definitions", RFC 6066, | |||
DOI 10.17487/RFC6066, January 2011, | DOI 10.17487/RFC6066, January 2011, | |||
<https://www.rfc-editor.org/info/rfc6066>. | <https://www.rfc-editor.org/info/rfc6066>. | |||
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and | ||||
Verification of Domain-Based Application Service Identity | ||||
within Internet Public Key Infrastructure Using X.509 | ||||
(PKIX) Certificates in the Context of Transport Layer | ||||
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March | ||||
2011, <https://www.rfc-editor.org/info/rfc6125>. | ||||
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, | [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, | |||
DOI 10.17487/RFC6265, April 2011, | DOI 10.17487/RFC6265, April 2011, | |||
<https://www.rfc-editor.org/info/rfc6265>. | <https://www.rfc-editor.org/info/rfc6265>. | |||
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, | [RFC7301] 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, DOI 10.17487/RFC7301, | Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, | |||
July 2014, <https://www.rfc-editor.org/info/rfc7301>. | July 2014, <https://www.rfc-editor.org/info/rfc7301>. | |||
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for | |||
Writing an IANA Considerations Section in RFCs", BCP 26, | Writing an IANA Considerations Section in RFCs", BCP 26, | |||
RFC 8126, DOI 10.17487/RFC8126, June 2017, | RFC 8126, DOI 10.17487/RFC8126, June 2017, | |||
<https://www.rfc-editor.org/info/rfc8126>. | <https://www.rfc-editor.org/info/rfc8126>. | |||
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC | |||
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, | |||
May 2017, <https://www.rfc-editor.org/info/rfc8174>. | May 2017, <https://www.rfc-editor.org/info/rfc8174>. | |||
[SEMANTICS] | [SEMANTICS] | |||
Fielding, R., Nottingham, M., and J. Reschke, "HTTP | Fielding, R., Nottingham, M., and J. Reschke, "HTTP | |||
Semantics", draft-ietf-httpbis-semantics-13 (work in | Semantics", draft-ietf-httpbis-semantics-14 (work in | |||
progress), December 2020. | progress), January 2021. | |||
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform | |||
Resource Identifier (URI): Generic Syntax", STD 66, | Resource Identifier (URI): Generic Syntax", STD 66, | |||
RFC 3986, DOI 10.17487/RFC3986, January 2005, | RFC 3986, DOI 10.17487/RFC3986, January 2005, | |||
<https://www.rfc-editor.org/info/rfc3986>. | <https://www.rfc-editor.org/info/rfc3986>. | |||
12.2. Informative References | 12.2. Informative References | |||
[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, | CRIME Attack", July 2013, | |||
<http://breachattack.com/resources/ | <http://breachattack.com/resources/ | |||
BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>. | BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>. | |||
[DNS-TERMS] | ||||
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS | ||||
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, | ||||
January 2019, <https://www.rfc-editor.org/info/rfc8499>. | ||||
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for | [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for | |||
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, | HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, | |||
<https://www.rfc-editor.org/info/rfc7541>. | <https://www.rfc-editor.org/info/rfc7541>. | |||
[HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1", | [HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1", | |||
draft-ietf-httpbis-messaging-13 (work in progress), | draft-ietf-httpbis-messaging-14 (work in progress), | |||
December 2020. | January 2021. | |||
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext | |||
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | Transfer Protocol Version 2 (HTTP/2)", RFC 7540, | |||
DOI 10.17487/RFC7540, May 2015, | DOI 10.17487/RFC7540, May 2015, | |||
<https://www.rfc-editor.org/info/rfc7540>. | <https://www.rfc-editor.org/info/rfc7540>. | |||
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status | [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status | |||
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, | Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, | |||
<https://www.rfc-editor.org/info/rfc6585>. | <https://www.rfc-editor.org/info/rfc6585>. | |||
skipping to change at page 56, line 29 ¶ | skipping to change at page 57, line 29 ¶ | |||
HTTP/3 begins from the premise that similarity to HTTP/2 is | HTTP/3 begins from the premise that similarity to HTTP/2 is | |||
preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 | preferable, but not a hard requirement. HTTP/3 departs from HTTP/2 | |||
where QUIC differs from TCP, either to take advantage of QUIC | where QUIC differs from TCP, either to take advantage of QUIC | |||
features (like streams) or to accommodate important shortcomings | features (like streams) or to accommodate important shortcomings | |||
(such as a lack of total ordering). These differences make HTTP/3 | (such as a lack of total ordering). These differences make HTTP/3 | |||
similar to HTTP/2 in key aspects, such as the relationship of | similar to HTTP/2 in key aspects, such as the relationship of | |||
requests and responses to streams. However, the details of the | requests and responses to streams. However, the details of the | |||
HTTP/3 design are substantially different from HTTP/2. | HTTP/3 design are substantially different from HTTP/2. | |||
These departures are noted in this section. | Some important departures are noted in this section. | |||
A.1. Streams | A.1. Streams | |||
HTTP/3 permits use of a larger number of streams (2^62-1) than | HTTP/3 permits use of a larger number of streams (2^62-1) than | |||
HTTP/2. The same considerations about exhaustion of stream | HTTP/2. The same considerations about exhaustion of stream | |||
identifier space apply, though the space is significantly larger such | identifier space apply, though the space is significantly larger such | |||
that it is likely that other limits in QUIC are reached first, such | that it is likely that other limits in QUIC are reached first, such | |||
as the limit on the connection flow control window. | as the limit on the connection flow control window. | |||
In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by | In contrast to HTTP/2, stream concurrency in HTTP/3 is managed by | |||
QUIC. QUIC considers a stream closed when all data has been received | QUIC. QUIC considers a stream closed when all data has been received | |||
and sent data has been acknowledged by the peer. HTTP/2 considers a | and sent data has been acknowledged by the peer. HTTP/2 considers a | |||
stream closed when the frame containing the END_STREAM bit has been | stream closed when the frame containing the END_STREAM bit has been | |||
committed to the transport. As a result, the stream for an | committed to the transport. As a result, the stream for an | |||
equivalent exchange could remain "active" for a longer period of | equivalent exchange could remain "active" for a longer period of | |||
time. HTTP/3 servers might choose to permit a larger number of | time. HTTP/3 servers might choose to permit a larger number of | |||
concurrent client-initiated bidirectional streams to achieve | concurrent client-initiated bidirectional streams to achieve | |||
equivalent concurrency to HTTP/2, depending on the expected usage | equivalent concurrency to HTTP/2, depending on the expected usage | |||
patterns. | patterns. | |||
In HTTP/2, only request and response bodies (the frame payload of | ||||
DATA frames) are subject to flow control. All HTTP/3 frames are sent | ||||
on QUIC streams, so all frames on all streams are flow-controlled in | ||||
HTTP/3. | ||||
Due to the presence of other unidirectional stream types, HTTP/3 does | Due to the presence of other unidirectional stream types, HTTP/3 does | |||
not rely exclusively on the number of concurrent unidirectional | not rely exclusively on the number of concurrent unidirectional | |||
streams to control the number of concurrent in-flight pushes. | streams to control the number of concurrent in-flight pushes. | |||
Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the | Instead, HTTP/3 clients use the MAX_PUSH_ID frame to control the | |||
number of pushes received from an HTTP/3 server. | number of pushes received from an HTTP/3 server. | |||
A.2. HTTP Frame Types | A.2. HTTP Frame Types | |||
Many framing concepts from HTTP/2 can be elided on QUIC, because the | Many framing concepts from HTTP/2 can be elided on QUIC, because the | |||
transport deals with them. Because frames are already on a stream, | transport deals with them. Because frames are already on a stream, | |||
they can omit the stream number. Because frames do not block | they can omit the stream number. Because frames do not block | |||
multiplexing (QUIC's multiplexing occurs below this layer), the | multiplexing (QUIC's multiplexing occurs below this layer), the | |||
support for variable-maximum-length packets can be removed. Because | support for variable-maximum-length packets can be removed. Because | |||
stream termination is handled by QUIC, an END_STREAM flag is not | stream termination is handled by QUIC, an END_STREAM flag is not | |||
required. This permits the removal of the Flags field from the | required. This permits the removal of the Flags field from the | |||
generic frame layout. | generic frame layout. | |||
Frame payloads are largely drawn from [HTTP2]. However, QUIC | Frame payloads are largely drawn from [HTTP2]. However, QUIC | |||
includes many features (e.g., flow control) that are also present in | includes many features (e.g., flow control) that are also present in | |||
HTTP/2. In these cases, the HTTP mapping does not re-implement them. | HTTP/2. In these cases, the HTTP mapping does not re-implement them. | |||
As a result, several HTTP/2 frame types are not required in HTTP/3. | As a result, several HTTP/2 frame types are not required in HTTP/3. | |||
Where an HTTP/2-defined frame is no longer used, the frame ID has | Where an HTTP/2-defined frame is no longer used, the frame ID has | |||
been reserved in order to maximize portability between HTTP/2 and | been reserved in order to maximize portability between HTTP/2 and | |||
HTTP/3 implementations. However, even equivalent frames between the | HTTP/3 implementations. However, even frame types that appear in | |||
two mappings are not identical. | both mappings do not have identical semantics. | |||
Many of the differences arise from the fact that HTTP/2 provides an | Many of the differences arise from the fact that HTTP/2 provides an | |||
absolute ordering between frames across all streams, while QUIC | absolute ordering between frames across all streams, while QUIC | |||
provides this guarantee on each stream only. As a result, if a frame | provides this guarantee on each stream only. As a result, if a frame | |||
type makes assumptions that frames from different streams will still | type makes assumptions that frames from different streams will still | |||
be received in the order sent, HTTP/3 will break them. | be received in the order sent, HTTP/3 will break them. | |||
Some examples of feature adaptations are described below, as well as | Some examples of feature adaptations are described below, as well as | |||
general guidance to extension frame implementors converting an HTTP/2 | general guidance to extension frame implementors converting an HTTP/2 | |||
extension to HTTP/3. | extension to HTTP/3. | |||
skipping to change at page 58, line 30 ¶ | skipping to change at page 59, line 35 ¶ | |||
is subject to flow control. QUIC provides flow control for stream | is subject to flow control. QUIC provides flow control for stream | |||
data and all HTTP/3 frame types defined in this document are sent on | data and all HTTP/3 frame types defined in this document are sent on | |||
streams. Therefore, all frame headers and payload are subject to | streams. Therefore, all frame headers and payload are subject to | |||
flow control. | flow control. | |||
A.2.4. Guidance for New Frame Type Definitions | A.2.4. Guidance for New Frame Type Definitions | |||
Frame type definitions in HTTP/3 often use the QUIC variable-length | Frame type definitions in HTTP/3 often use the QUIC variable-length | |||
integer encoding. In particular, Stream IDs use this encoding, which | integer encoding. In particular, Stream IDs use this encoding, which | |||
allows for a larger range of possible values than the encoding used | allows for a larger range of possible values than the encoding used | |||
in HTTP/2. Some frames in HTTP/3 use an identifier rather than a | in HTTP/2. Some frames in HTTP/3 use an identifier other than a | |||
Stream ID (e.g., Push IDs). Redefinition of the encoding of | Stream ID (e.g., Push IDs). Redefinition of the encoding of | |||
extension frame types might be necessary if the encoding includes a | extension frame types might be necessary if the encoding includes a | |||
Stream ID. | Stream ID. | |||
Because the Flags field is not present in generic HTTP/3 frames, | Because the Flags field is not present in generic HTTP/3 frames, | |||
those frames that depend on the presence of flags need to allocate | those frames that depend on the presence of flags need to allocate | |||
space for flags as part of their frame payload. | space for flags as part of their frame payload. | |||
Other than these issues, frame type HTTP/2 extensions are typically | Other than these issues, frame type HTTP/2 extensions are typically | |||
portable to QUIC simply by replacing Stream 0 in HTTP/2 with a | portable to QUIC simply by replacing Stream 0 in HTTP/2 with a | |||
control stream in HTTP/3. HTTP/3 extensions will not assume | control stream in HTTP/3. HTTP/3 extensions will not assume | |||
ordering, but would not be harmed by ordering, and would be portable | ordering, but would not be harmed by ordering, and are expected to be | |||
to HTTP/2 in the same manner. | portable to HTTP/2. | |||
A.2.5. Mapping Between HTTP/2 and HTTP/3 Frame Types | A.2.5. Comparison Between HTTP/2 and HTTP/3 Frame Types | |||
DATA (0x0): Padding is not defined in HTTP/3 frames. See | DATA (0x0): Padding is not defined in HTTP/3 frames. See | |||
Section 7.2.1. | Section 7.2.1. | |||
HEADERS (0x1): The PRIORITY region of HEADERS is not defined in | HEADERS (0x1): The PRIORITY region of HEADERS is not defined in | |||
HTTP/3 frames. Padding is not defined in HTTP/3 frames. See | HTTP/3 frames. Padding is not defined in HTTP/3 frames. See | |||
Section 7.2.2. | Section 7.2.2. | |||
PRIORITY (0x2): As described in Appendix A.2.1, HTTP/3 does not | PRIORITY (0x2): As described in Appendix A.2.1, HTTP/3 does not | |||
provide a means of signaling priority. | provide a means of signaling priority. | |||
skipping to change at page 60, line 4 ¶ | skipping to change at page 61, line 14 ¶ | |||
A.3. HTTP/2 SETTINGS Parameters | A.3. HTTP/2 SETTINGS Parameters | |||
An important difference from HTTP/2 is that settings are sent once, | An important difference from HTTP/2 is that settings are sent once, | |||
as the first frame of the control stream, and thereafter cannot | as the first frame of the control stream, and thereafter cannot | |||
change. This eliminates many corner cases around synchronization of | change. This eliminates many corner cases around synchronization of | |||
changes. | changes. | |||
Some transport-level options that HTTP/2 specifies via the SETTINGS | Some transport-level options that HTTP/2 specifies via the SETTINGS | |||
frame are superseded by QUIC transport parameters in HTTP/3. The | frame are superseded by QUIC transport parameters in HTTP/3. The | |||
HTTP-level options that are retained in HTTP/3 have the same value as | HTTP-level setting that is retained in HTTP/3 has the same value as | |||
in HTTP/2. The superseded settings are reserved, and their receipt | in HTTP/2. The superseded settings are reserved, and their receipt | |||
is an error. See Section 7.2.4.1 for discussion of both the retained | is an error. See Section 7.2.4.1 for discussion of both the retained | |||
and reserved values. | and reserved values. | |||
Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: | Below is a listing of how each HTTP/2 SETTINGS parameter is mapped: | |||
SETTINGS_HEADER_TABLE_SIZE: See [QPACK]. | SETTINGS_HEADER_TABLE_SIZE (0x1): See [QPACK]. | |||
SETTINGS_ENABLE_PUSH: This is removed in favor of the MAX_PUSH_ID | SETTINGS_ENABLE_PUSH (0x2): This is removed in favor of the | |||
frame, which provides a more granular control over server push. | MAX_PUSH_ID frame, which provides a more granular control over | |||
Specifying a setting with the identifier 0x2 (corresponding to the | server push. Specifying a setting with the identifier 0x2 | |||
SETTINGS_ENABLE_PUSH parameter) in the HTTP/3 SETTINGS frame is an | (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the | |||
error. | HTTP/3 SETTINGS frame is an error. | |||
SETTINGS_MAX_CONCURRENT_STREAMS: QUIC controls the largest open | SETTINGS_MAX_CONCURRENT_STREAMS (0x3): QUIC controls the largest | |||
Stream ID as part of its flow control logic. Specifying a setting | open Stream ID as part of its flow control logic. Specifying a | |||
with the identifier 0x3 (corresponding to the | setting with the identifier 0x3 (corresponding to the | |||
SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS | SETTINGS_MAX_CONCURRENT_STREAMS parameter) in the HTTP/3 SETTINGS | |||
frame is an error. | frame is an error. | |||
SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and | SETTINGS_INITIAL_WINDOW_SIZE (0x4): QUIC requires both stream and | |||
connection flow control window sizes to be specified in the | connection flow control window sizes to be specified in the | |||
initial transport handshake. Specifying a setting with the | initial transport handshake. Specifying a setting with the | |||
identifier 0x4 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE | identifier 0x4 (corresponding to the SETTINGS_INITIAL_WINDOW_SIZE | |||
parameter) in the HTTP/3 SETTINGS frame is an error. | parameter) in the HTTP/3 SETTINGS frame is an error. | |||
SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. | SETTINGS_MAX_FRAME_SIZE (0x5): This setting has no equivalent in | |||
Specifying a setting with the identifier 0x5 (corresponding to the | HTTP/3. Specifying a setting with the identifier 0x5 | |||
SETTINGS_MAX_FRAME_SIZE parameter) in the HTTP/3 SETTINGS frame is | (corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) in the | |||
an error. | HTTP/3 SETTINGS frame is an error. | |||
SETTINGS_MAX_HEADER_LIST_SIZE: This setting identifier has been | SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This setting identifier has | |||
renamed SETTINGS_MAX_FIELD_SECTION_SIZE. | been renamed SETTINGS_MAX_FIELD_SECTION_SIZE. | |||
In HTTP/3, setting values are variable-length integers (6, 14, 30, or | In HTTP/3, setting values are variable-length integers (6, 14, 30, or | |||
62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. | 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. | |||
This will often produce a shorter encoding, but can produce a longer | This will often produce a shorter encoding, but can produce a longer | |||
encoding for settings that use the full 32-bit space. Settings | encoding for settings that use the full 32-bit space. Settings | |||
ported from HTTP/2 might choose to redefine their value to limit it | ported from HTTP/2 might choose to redefine their value to limit it | |||
to 30 bits for more efficient encoding, or to make use of the 62-bit | to 30 bits for more efficient encoding, or to make use of the 62-bit | |||
space if more than 30 bits are required. | space if more than 30 bits are required. | |||
Settings need to be defined separately for HTTP/2 and HTTP/3. The | Settings need to be defined separately for HTTP/2 and HTTP/3. The | |||
skipping to change at page 61, line 30 ¶ | skipping to change at page 62, line 39 ¶ | |||
PROTOCOL_ERROR (0x1): This is mapped to H3_GENERAL_PROTOCOL_ERROR | PROTOCOL_ERROR (0x1): This is mapped to H3_GENERAL_PROTOCOL_ERROR | |||
except in cases where more specific error codes have been defined. | except in cases where more specific error codes have been defined. | |||
Such cases include H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, and | Such cases include H3_FRAME_UNEXPECTED, H3_MESSAGE_ERROR, and | |||
H3_CLOSED_CRITICAL_STREAM defined in Section 8.1. | H3_CLOSED_CRITICAL_STREAM defined in Section 8.1. | |||
INTERNAL_ERROR (0x2): H3_INTERNAL_ERROR in Section 8.1. | INTERNAL_ERROR (0x2): H3_INTERNAL_ERROR in Section 8.1. | |||
FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow | FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow | |||
control. | control. | |||
SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of | SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgment of | |||
SETTINGS is defined. | SETTINGS is defined. | |||
STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream | STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream | |||
management. | management. | |||
FRAME_SIZE_ERROR (0x6): H3_FRAME_ERROR error code defined in | FRAME_SIZE_ERROR (0x6): H3_FRAME_ERROR error code defined in | |||
Section 8.1. | Section 8.1. | |||
REFUSED_STREAM (0x7): H3_REQUEST_REJECTED (in Section 8.1) is used | REFUSED_STREAM (0x7): H3_REQUEST_REJECTED (in Section 8.1) is used | |||
to indicate that a request was not processed. Otherwise, not | to indicate that a request was not processed. Otherwise, not | |||
skipping to change at page 71, line 4 ¶ | skipping to change at page 72, line 9 ¶ | |||
o Changed from using HTTP/2 framing within Stream 3 to new framing | o Changed from using HTTP/2 framing within Stream 3 to new framing | |||
format and two-stream-per-request model (#71,#72,#73) | format and two-stream-per-request model (#71,#72,#73) | |||
o Adopted SETTINGS format from draft-bishop-httpbis-extended- | o Adopted SETTINGS format from draft-bishop-httpbis-extended- | |||
settings-01 | settings-01 | |||
o Reworked SETTINGS_ACK to account for indeterminate inter-stream | o Reworked SETTINGS_ACK to account for indeterminate inter-stream | |||
order (#75) | order (#75) | |||
o Described CONNECT pseudo-method (#95) | o Described CONNECT pseudo-method (#95) | |||
o Updated ALPN token and Alt-Svc guidance (#13,#87) | o Updated ALPN token and Alt-Svc guidance (#13,#87) | |||
o Application-layer-defined error codes (#19,#74) | o Application-layer-defined error codes (#19,#74) | |||
B.34. Since draft-shade-quic-http2-mapping-00 | B.34. Since draft-shade-quic-http2-mapping-00 | |||
o Adopted as base for draft-ietf-quic-http | o Adopted as base for draft-ietf-quic-http | |||
o Updated authors/editors list | o Updated authors/editors list | |||
Acknowledgements | Acknowledgments | |||
The original authors of this specification were Robbie Shade and Mike | The original authors of this specification were Robbie Shade and Mike | |||
Warres. | Warres. | |||
The IETF QUIC Working Group received an enormous amount of support | The IETF QUIC Working Group received an enormous amount of support | |||
from many people. Among others, the following people provided | from many people. Among others, the following people provided | |||
substantial contributions to this document: | substantial contributions to this document: | |||
o Bence Beky | o Bence Beky | |||
End of changes. 102 change blocks. | ||||
372 lines changed or deleted | 425 lines changed or added | |||
This html diff was produced by rfcdiff 1.44jr. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ |