draft-ietf-quic-http-34.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 February 2, 2021 Intended status: Standards Track March 8, 2023
Expires: August 6, 2021 Expires: September 9, 2023
Hypertext Transfer Protocol Version 3 (HTTP/3) Hypertext Transfer Protocol Version 3 (HTTP/3)
draft-ietf-quic-http-34 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.
DO NOT DEPLOY THIS VERSION OF HTTP
DO NOT DEPLOY THIS VERSION OF HTTP/3 UNTIL IT IS IN AN RFC. This
version is still a work in progress. For trial deployments, please
use earlier versions.
Note to Readers
Discussion of this draft takes place on the QUIC working group
mailing list (quic@ietf.org), which is archived at
<https://mailarchive.ietf.org/arch/search/?email_list=quic>.
Working Group information can be found at <https://github.com/
quicwg>; source code and issues list for this draft can be found at
<https://github.com/quicwg/base-drafts/labels/-http>.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at 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 August 6, 2021.
This Internet-Draft will expire on September 9, 2023.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2023 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 5 1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 4
1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5 1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 4
2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 6 2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 4
2.1. Document Organization . . . . . . . . . . . . . . . . . . 6 2.1. Document Organization . . . . . . . . . . . . . . . . . . 5
2.2. Conventions and Terminology . . . . . . . . . . . . . . . 7 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6
3. Connection Setup and Management . . . . . . . . . . . . . . . 8 3. Connection Setup and Management . . . . . . . . . . . . . . . 7
3.1. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 9 3.1. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 7
3.1.1. HTTP Alternative Services . . . . . . . . . . . . . . 9 3.1.1. HTTP Alternative Services . . . . . . . . . . . . . . 8
3.1.2. Other Schemes . . . . . . . . . . . . . . . . . . . . 10 3.1.2. Other Schemes . . . . . . . . . . . . . . . . . . . . 9
3.2. Connection Establishment . . . . . . . . . . . . . . . . 10 3.2. Connection Establishment . . . . . . . . . . . . . . . . 9
3.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 11 3.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 10
4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 12 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 11
4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 12 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 11
4.1.1. Field Formatting and Compression . . . . . . . . . . 14 4.1.1. Field Formatting and Compression . . . . . . . . . . 13
4.1.2. Request Cancellation and Rejection . . . . . . . . . 17 4.1.2. Request Cancellation and Rejection . . . . . . . . . 16
4.1.3. Malformed Requests and Responses . . . . . . . . . . 18 4.1.3. Malformed Requests and Responses . . . . . . . . . . 17
4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 19 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 18
4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 20 4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 19
4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 20
5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 23 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 22
5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 23 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 22
5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 23 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 22
5.3. Immediate Application Closure . . . . . . . . . . . . . . 25 5.3. Immediate Application Closure . . . . . . . . . . . . . . 24
5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 26 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 25
6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 26 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 25
6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 26 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 25
6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 27 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 26
6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 28 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 27
6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 29 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 28
6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 29 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 28
7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 30 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 29
7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 31 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 31 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 30
7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 32 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 32 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 31
7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 32 7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 31
7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 34 7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 33
7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 37 7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 36
7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 38 7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 37
7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 39 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 38
7.2.8. Reserved Frame Types . . . . . . . . . . . . . . . . 39 7.2.8. Reserved Frame Types . . . . . . . . . . . . . . . . 38
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 40 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 39
8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 41 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 40
9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 42 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 41
10. Security Considerations . . . . . . . . . . . . . . . . . . . 43 10. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 43 10.1. Server Authority . . . . . . . . . . . . . . . . . . . . 42
10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 43 10.2. Cross-Protocol Attacks . . . . . . . . . . . . . . . . . 42
10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 43 10.3. Intermediary Encapsulation Attacks . . . . . . . . . . . 42
10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 44 10.4. Cacheability of Pushed Responses . . . . . . . . . . . . 43
10.5. Denial-of-Service Considerations . . . . . . . . . . . . 44 10.5. Denial-of-Service Considerations . . . . . . . . . . . . 43
10.5.1. Limits on Field Section Size . . . . . . . . . . . . 45 10.5.1. Limits on Field Section Size . . . . . . . . . . . . 44
10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 46 10.5.2. CONNECT Issues . . . . . . . . . . . . . . . . . . . 45
10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 46 10.6. Use of Compression . . . . . . . . . . . . . . . . . . . 45
10.7. Padding and Traffic Analysis . . . . . . . . . . . . . . 46 10.7. Padding and Traffic Analysis . . . . . . . . . . . . . . 45
10.8. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 47 10.8. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 46
10.9. Early Data . . . . . . . . . . . . . . . . . . . . . . . 47 10.9. Early Data . . . . . . . . . . . . . . . . . . . . . . . 46
10.10. Migration . . . . . . . . . . . . . . . . . . . . . . . 48 10.10. Migration . . . . . . . . . . . . . . . . . . . . . . . 47
10.11. Privacy Considerations . . . . . . . . . . . . . . . . . 48 10.11. Privacy Considerations . . . . . . . . . . . . . . . . . 47
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 47
11.1. Registration of HTTP/3 Identification String . . . . . . 48 11.1. Registration of HTTP/3 Identification String . . . . . . 47
11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 49 11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 48
11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 49 11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 48
11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 50 11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 49
11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 51 11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 50
11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 54 11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 53
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
12.1. Normative References . . . . . . . . . . . . . . . . . . 54 12.1. Normative References . . . . . . . . . . . . . . . . . . 53
12.2. Informative References . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . 55
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 57 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 56
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 57 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 56
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 58 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 57
A.2.1. Prioritization Differences . . . . . . . . . . . . . 58 A.2.1. Prioritization Differences . . . . . . . . . . . . . 57
A.2.2. Field Compression Differences . . . . . . . . . . . . 59 A.2.2. Field Compression Differences . . . . . . . . . . . . 58
A.2.3. Flow Control Differences . . . . . . . . . . . . . . 59 A.2.3. Flow Control Differences . . . . . . . . . . . . . . 58
A.2.4. Guidance for New Frame Type Definitions . . . . . . . 59 A.2.4. Guidance for New Frame Type Definitions . . . . . . . 58
A.2.5. Comparison Between HTTP/2 and HTTP/3 Frame Types . . 60 A.2.5. Comparison Between HTTP/2 and HTTP/3 Frame Types . . 59
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 60
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 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 63
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 64
B.1. Since draft-ietf-quic-http-32 . . . . . . . . . . . . . . 64
B.2. Since draft-ietf-quic-http-31 . . . . . . . . . . . . . . 64
B.3. Since draft-ietf-quic-http-30 . . . . . . . . . . . . . . 64
B.4. Since draft-ietf-quic-http-29 . . . . . . . . . . . . . . 64
B.5. Since draft-ietf-quic-http-28 . . . . . . . . . . . . . . 64
B.6. Since draft-ietf-quic-http-27 . . . . . . . . . . . . . . 64
B.7. Since draft-ietf-quic-http-26 . . . . . . . . . . . . . . 65
B.8. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 65
B.9. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 65
B.10. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 65
B.11. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 65
B.12. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 66
B.13. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 66
B.14. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 67
B.15. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 67
B.16. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 68
B.17. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 68
B.18. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 68
B.19. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 68
B.20. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 69
B.21. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 69
B.22. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 69
B.23. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 69
B.24. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 70
B.25. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 70
B.26. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 70
B.27. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 70
B.28. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 70
B.29. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 70
B.30. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 71
B.31. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 71
B.32. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 71
B.33. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 71
B.34. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 72
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 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 and HTTP/2. HTTP/1.1 has been used over a variety of HTTP/1.1 and HTTP/2. HTTP/1.1 has been used over a variety of
transport and session layers, while HTTP/2 has been used primarily transport and session layers, while HTTP/2 has been used primarily
with TLS over TCP. HTTP/3 supports the same semantics over a new with TLS over TCP. HTTP/3 supports the same semantics over a new
transport protocol, QUIC. transport protocol, QUIC.
skipping to change at page 7, line 33 skipping to change at page 6, line 27
o Extensions to HTTP/3 (Section 9) describes how new capabilities o Extensions to HTTP/3 (Section 9) describes how new capabilities
can be added in future documents. can be added in future documents.
o A more detailed comparison between HTTP/2 and HTTP/3 can be found o A more detailed comparison between HTTP/2 and HTTP/3 can be found
in Appendix A. in Appendix A.
2.2. Conventions and Terminology 2.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in BCP
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This document uses the variable-length integer encoding from This document uses the variable-length integer encoding from
[QUIC-TRANSPORT]. [QUIC-TRANSPORT].
The following terms are used: The following terms are used:
abort: An abrupt termination of a connection or stream, possibly due abort: An abrupt termination of a connection or stream, possibly due
to an error condition. to an error condition.
skipping to change at page 9, line 29 skipping to change at page 8, line 21
certificate cannot be verified with respect to the URI's origin certificate cannot be verified with respect to the URI's origin
server, the client MUST NOT consider the server authoritative for server, the client MUST NOT consider the server authoritative for
that origin. that origin.
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 (including connection to that address on the indicated port (including
validation of the server certificate as described above), and sending validation of the server certificate as described above), and sending
an HTTP/3 request message targeting the URI to the server over that 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 URIs 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.
skipping to change at page 14, line 15 skipping to change at page 13, line 15
request and close the stream normally. request and close the stream normally.
4.1.1. Field Formatting and Compression 4.1.1. Field Formatting and Compression
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
approved. *RFC Editor*, please remove this note prior to
publication.
Field names are strings containing a subset of ASCII characters. Field names are strings containing a subset of ASCII characters.
Properties of HTTP field names and values are discussed in more Properties of HTTP field names and values are discussed in more
detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters in detail in Section 5.1 of [SEMANTICS]. As in HTTP/2, characters in
field names MUST be converted to lowercase prior to their encoding. field names MUST be converted to lowercase prior to their encoding.
A request or response containing uppercase characters in field names A request or response containing uppercase characters in field names
MUST be treated as malformed (Section 4.1.3). 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
skipping to change at page 29, line 39 skipping to change at page 28, line 39
H3_STREAM_CREATION_ERROR; see Section 8. H3_STREAM_CREATION_ERROR; see Section 8.
Push Stream Header { Push Stream Header {
Stream Type (i) = 0x01, Stream Type (i) = 0x01,
Push ID (i), Push ID (i),
} }
Figure 2: Push Stream Header Figure 2: Push Stream Header
Each Push ID MUST only be used once in a push stream header. If a Each Push ID MUST only be used once in a push stream header. If a
push stream header includes a Push ID that was used in another push client detects that a push stream header includes a Push ID that was
stream header, the client MUST treat this as a connection error of used in another push stream header, the client MUST treat this as a
type H3_ID_ERROR; see Section 8. connection error of type H3_ID_ERROR; see Section 8.
6.2.3. Reserved Stream Types 6.2.3. Reserved Stream Types
Stream types of the format "0x1f * N + 0x21" for non-negative integer Stream types of the format "0x1f * N + 0x21" for non-negative integer
values of N are reserved to exercise the requirement that unknown values of N are reserved to exercise the requirement that unknown
types be ignored. These streams have no semantics, and can be sent types be ignored. These streams have no semantics, and can be sent
when application-layer padding is desired. They MAY also be sent on when application-layer padding is desired. They MAY also be sent on
connections where no data is currently being transferred. Endpoints connections where no data is currently being transferred. Endpoints
MUST NOT consider these streams to have any meaning upon receipt. MUST NOT consider these streams to have any meaning upon receipt.
skipping to change at page 32, line 6 skipping to change at page 31, line 6
see Section 10.8. 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=0x00) convey arbitrary, variable-length sequences
bytes associated with HTTP request or response content. of 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) = 0x00,
Length (i), Length (i),
Data (..), Data (..),
} }
Figure 4: DATA Frame Figure 4: DATA Frame
7.2.2. HEADERS 7.2.2. HEADERS
The HEADERS frame (type=0x1) is used to carry an HTTP field section, The HEADERS frame (type=0x01) is used to carry an HTTP field section,
encoded using QPACK. See [QPACK] for more details. encoded using QPACK. See [QPACK] for more details.
HEADERS Frame { HEADERS Frame {
Type (i) = 0x1, Type (i) = 0x01,
Length (i), Length (i),
Encoded Field Section (..), Encoded Field Section (..),
} }
Figure 5: HEADERS Frame Figure 5: HEADERS Frame
HEADERS frames can only be sent on request or push streams. If a HEADERS frames can only be sent on request or push streams. If a
HEADERS frame is received on a control stream, the recipient MUST HEADERS frame is received on a control stream, the recipient MUST
respond with a connection error (Section 8) of type respond with a connection error (Section 8) of type
H3_FRAME_UNEXPECTED. H3_FRAME_UNEXPECTED.
7.2.3. CANCEL_PUSH 7.2.3. CANCEL_PUSH
The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a The CANCEL_PUSH frame (type=0x03) is used to request cancellation of
server push prior to the push stream being received. The CANCEL_PUSH a server push prior to the push stream being received. The
frame identifies a server push by Push ID (see Section 4.4), encoded CANCEL_PUSH frame identifies a server push by Push ID (see
as a variable-length integer. Section 4.4), encoded as a variable-length integer.
When a client sends CANCEL_PUSH, it is indicating that it does not When a client sends CANCEL_PUSH, it is indicating that it does not
wish to receive the promised resource. The server SHOULD abort wish to receive the promised resource. The server SHOULD abort
sending the resource, but the mechanism to do so depends on the state sending the resource, but the mechanism to do so depends on the state
of the corresponding push stream. If the server has not yet created of the corresponding push stream. If the server has not yet created
a push stream, it does not create one. If the push stream is open, a push stream, it does not create one. If the push stream is open,
the server SHOULD abruptly terminate that stream. If the push stream the server SHOULD abruptly terminate that stream. If the push stream
has already ended, the server MAY still abruptly terminate the stream has already ended, the server MAY still abruptly terminate the stream
or MAY take no action. or MAY take no action.
skipping to change at page 33, line 30 skipping to change at page 32, line 30
stream could arrive after a client has sent a CANCEL_PUSH frame, stream could arrive after a client has sent a CANCEL_PUSH frame,
because a server might not have processed the CANCEL_PUSH. The because a server might not have processed the CANCEL_PUSH. The
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) = 0x03,
Length (i), Length (i),
Push ID (i), 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
skipping to change at page 34, line 7 skipping to change at page 33, line 7
H3_ID_ERROR. H3_ID_ERROR.
If the client receives a CANCEL_PUSH frame, that frame might identify If the client receives a CANCEL_PUSH frame, that frame might identify
a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due a Push ID that has not yet been mentioned by a PUSH_PROMISE frame due
to reordering. If a server receives a CANCEL_PUSH frame for a Push to reordering. If a server receives a CANCEL_PUSH frame for a Push
ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST
be treated as a connection error of type H3_ID_ERROR. be treated as a connection error of type H3_ID_ERROR.
7.2.4. SETTINGS 7.2.4. SETTINGS
The SETTINGS frame (type=0x4) conveys configuration parameters that The SETTINGS frame (type=0x04) conveys configuration parameters that
affect how endpoints communicate, such as preferences and constraints affect how endpoints communicate, such as preferences and constraints
on peer behavior. Individually, a SETTINGS parameter can also be on peer behavior. Individually, a SETTINGS parameter can also be
referred to as a "setting"; the identifier and value of each setting referred to as a "setting"; the identifier and value of each setting
parameter can be referred to as a "setting identifier" and a "setting parameter can be referred to as a "setting identifier" and a "setting
value". value".
SETTINGS frames always apply to an entire HTTP/3 connection, never a SETTINGS frames always apply to an entire HTTP/3 connection, never a
single stream. A SETTINGS frame MUST be sent as the first frame of single stream. A SETTINGS frame MUST be sent as the first frame of
each control stream (see Section 6.2.1) by each peer, and MUST NOT be each control stream (see Section 6.2.1) by each peer, and MUST NOT be
sent subsequently. If an endpoint receives a second SETTINGS frame sent subsequently. If an endpoint receives a second SETTINGS frame
skipping to change at page 35, line 11 skipping to change at page 34, line 11
The payload of a SETTINGS frame consists of zero or more parameters. The payload of a SETTINGS frame consists of zero or more parameters.
Each parameter consists of a setting identifier and a value, both Each parameter consists of a setting identifier and a value, both
encoded as QUIC variable-length integers. encoded as QUIC variable-length integers.
Setting { Setting {
Identifier (i), Identifier (i),
Value (i), Value (i),
} }
SETTINGS Frame { SETTINGS Frame {
Type (i) = 0x4, Type (i) = 0x04,
Length (i), Length (i),
Setting (..) ..., Setting (..) ...,
} }
Figure 7: SETTINGS Frame Figure 7: SETTINGS Frame
An implementation MUST ignore any parameter with an identifier it An implementation MUST ignore any parameter with an 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 (0x06): 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
skipping to change at page 37, line 12 skipping to change at page 36, line 12
server accepts 0-RTT but then sends settings that are not compatible server accepts 0-RTT but then sends settings that are not compatible
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=0x05) is used to carry a promised
header section from server to client on a request stream, as in request header section from server to client on a request stream, as
HTTP/2. in HTTP/2.
PUSH_PROMISE Frame { PUSH_PROMISE Frame {
Type (i) = 0x5, Type (i) = 0x05,
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
The payload consists of: The payload consists of:
Push ID: A variable-length integer that identifies the server push Push ID: A variable-length integer that identifies the server push
skipping to change at page 38, line 23 skipping to change at page 37, line 23
A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the A client MUST NOT send a PUSH_PROMISE frame. A server MUST treat the
receipt of a PUSH_PROMISE frame as a connection error of type receipt of a PUSH_PROMISE frame as a connection error of type
H3_FRAME_UNEXPECTED; see Section 8. H3_FRAME_UNEXPECTED; see Section 8.
See Section 4.4 for a description of the overall server push See Section 4.4 for a description of the overall server push
mechanism. mechanism.
7.2.6. GOAWAY 7.2.6. GOAWAY
The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of The GOAWAY frame (type=0x07) is used to initiate graceful shutdown of
an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint an HTTP/3 connection by either endpoint. GOAWAY allows an endpoint
to stop accepting new requests or pushes while still finishing to stop accepting new requests or pushes while still finishing
processing of previously received requests and pushes. This enables processing of previously received requests and pushes. This enables
administrative actions, like server maintenance. GOAWAY by itself administrative actions, like server maintenance. GOAWAY by itself
does not close a connection. does not close a connection.
GOAWAY Frame { GOAWAY Frame {
Type (i) = 0x7, Type (i) = 0x07,
Length (i), Length (i),
Stream ID/Push ID (..), Stream ID/Push ID (..),
} }
Figure 9: GOAWAY Frame Figure 9: GOAWAY Frame
The GOAWAY frame is always sent on the control stream. In the server The GOAWAY frame is always sent on the control stream. In the server
to client direction, it carries a QUIC Stream ID for a client- to client direction, it carries a QUIC Stream ID for a client-
initiated bidirectional stream encoded as a variable-length integer. initiated bidirectional stream encoded as a variable-length integer.
A client MUST treat receipt of a GOAWAY frame containing a Stream ID A client MUST treat receipt of a GOAWAY frame containing a Stream ID
skipping to change at page 39, line 9 skipping to change at page 38, line 9
The GOAWAY frame applies to the entire connection, not a specific The GOAWAY frame applies to the entire connection, not a specific
stream. A client MUST treat a GOAWAY frame on a stream other than stream. A client MUST treat a GOAWAY frame on a stream other than
the control stream as a connection error of type H3_FRAME_UNEXPECTED; the control stream as a connection error of type H3_FRAME_UNEXPECTED;
see Section 8. see Section 8.
See Section 5.2 for more information on the use of the GOAWAY frame. See Section 5.2 for more information on the use of the GOAWAY frame.
7.2.7. MAX_PUSH_ID 7.2.7. MAX_PUSH_ID
The MAX_PUSH_ID frame (type=0xd) is used by clients to control the The MAX_PUSH_ID frame (type=0x0d) is used by clients to control the
number of server pushes that the server can initiate. This sets the number of server pushes that the server can initiate. This sets the
maximum value for a Push ID that the server can use in PUSH_PROMISE maximum value for a Push ID that the server can use in PUSH_PROMISE
and CANCEL_PUSH frames. Consequently, this also limits the number of and CANCEL_PUSH frames. Consequently, this also limits the number of
push streams that the server can initiate in addition to the limit push streams that the server can initiate in addition to the limit
maintained by the QUIC transport. maintained by the QUIC transport.
The MAX_PUSH_ID frame is always sent on the control stream. Receipt The MAX_PUSH_ID frame is always sent on the control stream. Receipt
of a MAX_PUSH_ID frame on any other stream MUST be treated as a of a MAX_PUSH_ID frame on any other stream MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED. connection error of type H3_FRAME_UNEXPECTED.
skipping to change at page 39, line 31 skipping to change at page 38, line 31
receipt of a MAX_PUSH_ID frame as a connection error of type receipt of a MAX_PUSH_ID frame as a connection error of type
H3_FRAME_UNEXPECTED. H3_FRAME_UNEXPECTED.
The maximum Push ID is unset when an HTTP/3 connection is created, The maximum Push ID is unset when an HTTP/3 connection is created,
meaning that a server cannot push until it receives a MAX_PUSH_ID meaning that a server cannot push until it receives a MAX_PUSH_ID
frame. A client that wishes to manage the number of promised server frame. A client that wishes to manage the number of promised server
pushes can increase the maximum Push ID by sending MAX_PUSH_ID frames pushes can increase the maximum Push ID by sending MAX_PUSH_ID frames
as the server fulfills or cancels server pushes. as the server fulfills or cancels server pushes.
MAX_PUSH_ID Frame { MAX_PUSH_ID Frame {
Type (i) = 0xd, Type (i) = 0x0d,
Length (i), Length (i),
Push ID (i), Push ID (i),
} }
Figure 10: MAX_PUSH_ID Frame Figure 10: MAX_PUSH_ID Frame
The MAX_PUSH_ID frame carries a single variable-length integer that The MAX_PUSH_ID frame carries a single variable-length integer that
identifies the maximum value for a Push ID that the server can use; identifies the maximum value for a Push ID that the server can use;
see Section 4.4. A MAX_PUSH_ID frame cannot reduce the maximum Push see Section 4.4. A MAX_PUSH_ID frame cannot reduce the maximum Push
ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than
skipping to change at page 41, line 11 skipping to change at page 40, line 11
of an unknown error code MUST be treated as equivalent to of an unknown error code MUST be treated as equivalent to
H3_NO_ERROR. However, closing a stream can have other effects H3_NO_ERROR. However, closing a stream can have other effects
regardless of the error code; for example, see Section 4.1. regardless of the error code; for example, see Section 4.1.
8.1. HTTP/3 Error Codes 8.1. HTTP/3 Error Codes
The following error codes are defined for use when abruptly The following error codes are defined for use when abruptly
terminating streams, aborting reading of streams, or immediately terminating streams, aborting reading of streams, or immediately
closing HTTP/3 connections. closing HTTP/3 connections.
H3_NO_ERROR (0x100): No error. This is used when the connection or H3_NO_ERROR (0x0100): No error. This is used when the connection or
stream needs to be closed, but there is no error to signal. stream needs to be closed, but there is no error to signal.
H3_GENERAL_PROTOCOL_ERROR (0x101): Peer violated protocol H3_GENERAL_PROTOCOL_ERROR (0x0101): Peer violated protocol
requirements in a way that does not match a more specific error requirements in a way that does not match a more specific error
code, or endpoint declines to use the more specific error code. code, or endpoint declines to use the more specific error code.
H3_INTERNAL_ERROR (0x102): An internal error has occurred in the H3_INTERNAL_ERROR (0x0102): An internal error has occurred in the
HTTP stack. HTTP stack.
H3_STREAM_CREATION_ERROR (0x103): The endpoint detected that its H3_STREAM_CREATION_ERROR (0x0103): The endpoint detected that its
peer created a stream that it will not accept. peer created a stream that it will not accept.
H3_CLOSED_CRITICAL_STREAM (0x104): A stream required by the HTTP/3 H3_CLOSED_CRITICAL_STREAM (0x0104): A stream required by the HTTP/3
connection was closed or reset. connection was closed or reset.
H3_FRAME_UNEXPECTED (0x105): A frame was received that was not H3_FRAME_UNEXPECTED (0x0105): A frame was received that was not
permitted in the current state or on the current stream. permitted in the current state or on the current stream.
H3_FRAME_ERROR (0x106): A frame that fails to satisfy layout H3_FRAME_ERROR (0x0106): A frame that fails to satisfy layout
requirements or with an invalid size was received. requirements or with an invalid size was received.
H3_EXCESSIVE_LOAD (0x107): The endpoint detected that its peer is H3_EXCESSIVE_LOAD (0x0107): The endpoint detected that its peer is
exhibiting a behavior that might be generating excessive load. exhibiting a behavior that might be generating excessive load.
H3_ID_ERROR (0x108): A Stream ID or Push ID was used incorrectly, H3_ID_ERROR (0x0108): A Stream ID or Push ID was used incorrectly,
such as exceeding a limit, reducing a limit, or being reused. such as exceeding a limit, reducing a limit, or being reused.
H3_SETTINGS_ERROR (0x109): An endpoint detected an error in the H3_SETTINGS_ERROR (0x0109): An endpoint detected an error in the
payload of a SETTINGS frame. payload of a SETTINGS frame.
H3_MISSING_SETTINGS (0x10a): No SETTINGS frame was received at the H3_MISSING_SETTINGS (0x010a): No SETTINGS frame was received at the
beginning of the control stream. beginning of the control stream.
H3_REQUEST_REJECTED (0x10b): A server rejected a request without H3_REQUEST_REJECTED (0x010b): A server rejected a request without
performing any application processing. performing any application processing.
H3_REQUEST_CANCELLED (0x10c): The request or its response (including H3_REQUEST_CANCELLED (0x010c): The request or its response
pushed response) is cancelled. (including pushed response) is cancelled.
H3_REQUEST_INCOMPLETE (0x10d): The client's stream terminated H3_REQUEST_INCOMPLETE (0x010d): The client's stream terminated
without containing a fully-formed request. without containing a fully-formed request.
H3_MESSAGE_ERROR (0x10e): An HTTP message was malformed and cannot H3_MESSAGE_ERROR (0x010e): An HTTP message was malformed and cannot
be processed. be processed.
H3_CONNECT_ERROR (0x10f): The TCP connection established in response H3_CONNECT_ERROR (0x010f): The TCP connection established in
to a CONNECT request was reset or abnormally closed. response to a CONNECT request was reset or abnormally closed.
H3_VERSION_FALLBACK (0x110): The requested operation cannot be H3_VERSION_FALLBACK (0x0110): The requested operation cannot be
served over HTTP/3. The peer should retry over HTTP/1.1. served over HTTP/3. The peer should retry over HTTP/1.1.
Error codes of the format "0x1f * N + 0x21" for non-negative integer Error codes of the format "0x1f * N + 0x21" for non-negative integer
values of N are reserved to exercise the requirement that unknown values of N are reserved to exercise the requirement that unknown
error codes be treated as equivalent to H3_NO_ERROR (Section 9). error codes be treated as equivalent to H3_NO_ERROR (Section 9).
Implementations SHOULD select an error code from this space with some Implementations SHOULD select an error code from this space with some
probability when they would have sent H3_NO_ERROR. probability when they would have sent H3_NO_ERROR.
9. Extensions to HTTP/3 9. Extensions to HTTP/3
skipping to change at page 43, line 51 skipping to change at page 42, line 51
The HTTP/3 field encoding allows the expression of names that are not The HTTP/3 field encoding allows the expression of names that are not
valid field names in the syntax used by HTTP (Section 5.1 of valid field names in the syntax used by HTTP (Section 5.1 of
[SEMANTICS]). Requests or responses containing invalid field names [SEMANTICS]). Requests or responses containing invalid field names
MUST be treated as malformed (Section 4.1.3). An intermediary MUST be treated as malformed (Section 4.1.3). An intermediary
therefore cannot translate an HTTP/3 request or response containing therefore cannot translate an HTTP/3 request or response containing
an invalid field name into an HTTP/1.1 message. an invalid field name into an HTTP/1.1 message.
Similarly, HTTP/3 can transport field values that are not valid. Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing, While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the carriage return (CR, ASCII 0x0d), line feed (LF, ASCII 0x0d), and the
zero character (NUL, ASCII 0x0) might be exploited by an attacker if zero character (NUL, ASCII 0x0d) might be exploited by an attacker if
they are translated verbatim. Any request or response that contains they are translated verbatim. Any request or response that contains
a character not permitted in a field value MUST be treated as a character not permitted in a field value MUST be treated as
malformed (Section 4.1.3). Valid characters are defined by the malformed (Section 4.1.3). Valid characters are defined by the
"field-content" ABNF rule in Section 5.5 of [SEMANTICS]. "field-content" ABNF rule in Section 5.5 of [SEMANTICS].
10.4. Cacheability of Pushed Responses 10.4. Cacheability of Pushed Responses
Pushed responses do not have an explicit request from the client; the Pushed responses do not have an explicit request from the client; the
request is provided by the server in the PUSH_PROMISE frame. request is provided by the server in the PUSH_PROMISE frame.
skipping to change at page 48, line 43 skipping to change at page 47, line 43
11. IANA Considerations 11. IANA Considerations
This document registers a new ALPN protocol ID (Section 11.1) and This document registers a new ALPN protocol ID (Section 11.1) and
creates new registries that manage the assignment of codepoints in creates new registries that manage the assignment of codepoints in
HTTP/3. HTTP/3.
11.1. Registration of HTTP/3 Identification String 11.1. Registration of HTTP/3 Identification String
This document creates a new registration for the identification of This document creates a new registration for the identification of
HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol HTTP/3 in the "Application-Layer Protocol Negotiation (ALPN) Protocol
IDs" registry established in [RFC7301]. IDs" registry established in [RFC7301].
The "h3" string identifies HTTP/3: The "h3" string identifies HTTP/3:
Protocol: HTTP/3 Protocol: HTTP/3
Identification Sequence: 0x68 0x33 ("h3") Identification Sequence: 0x68 0x33 ("h3")
Specification: This document Specification: This document
skipping to change at page 50, line 8 skipping to change at page 49, line 8
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.
The entries in Table 2 are registered by this document. The entries in Table 2 are registered by this document.
+--------------+-------+----------------+ +--------------+-------+----------------+
| Frame Type | Value | Specification | | Frame Type | Value | Specification |
+--------------+-------+----------------+ +--------------+-------+----------------+
| DATA | 0x0 | Section 7.2.1 | | DATA | 0x00 | Section 7.2.1 |
| | | | | | | |
| HEADERS | 0x1 | Section 7.2.2 | | HEADERS | 0x01 | Section 7.2.2 |
| | | | | | | |
| Reserved | 0x2 | N/A | | Reserved | 0x02 | N/A |
| | | | | | | |
| CANCEL_PUSH | 0x3 | Section 7.2.3 | | CANCEL_PUSH | 0x03 | Section 7.2.3 |
| | | | | | | |
| SETTINGS | 0x4 | Section 7.2.4 | | SETTINGS | 0x04 | Section 7.2.4 |
| | | | | | | |
| PUSH_PROMISE | 0x5 | Section 7.2.5 | | PUSH_PROMISE | 0x05 | Section 7.2.5 |
| | | | | | | |
| Reserved | 0x6 | N/A | | Reserved | 0x06 | N/A |
| | | | | | | |
| GOAWAY | 0x7 | Section 7.2.6 | | GOAWAY | 0x07 | Section 7.2.6 |
| | | | | | | |
| Reserved | 0x8 | N/A | | Reserved | 0x08 | N/A |
| | | | | | | |
| Reserved | 0x9 | N/A | | Reserved | 0x09 | N/A |
| | | | | | | |
| MAX_PUSH_ID | 0xd | Section 7.2.7 | | MAX_PUSH_ID | 0x0d | Section 7.2.7 |
+--------------+-------+----------------+ +--------------+-------+----------------+
Table 2: Initial HTTP/3 Frame Types Table 2: Initial HTTP/3 Frame Types
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.2. Settings Parameters 11.2.2. Settings Parameters
skipping to change at page 51, line 22 skipping to change at page 50, line 22
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 | 0x00 | N/A | N/A |
| | | | | | | | | |
| Reserved | 0x2 | N/A | N/A | | Reserved | 0x02 | N/A | N/A |
| | | | | | | | | |
| Reserved | 0x3 | N/A | N/A | | Reserved | 0x03 | N/A | N/A |
| | | | | | | | | |
| Reserved | 0x4 | N/A | N/A | | Reserved | 0x04 | N/A | N/A |
| | | | | | | | | |
| Reserved | 0x5 | N/A | N/A | | Reserved | 0x05 | N/A | N/A |
| | | | | | | | | |
| MAX_FIELD_SECTION_SIZE | 0x6 | Section 7.2.4.1 | Unlimited | | MAX_FIELD_SECTION_SIZE | 0x06 | Section 7.2.4.1 | Unlimited |
+------------------------+-------+------------------+-----------+ +------------------------+-------+------------------+-----------+
Table 3: Initial HTTP/3 Settings Table 3: Initial HTTP/3 Settings
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.3. Error Codes 11.2.3. Error Codes
skipping to change at page 52, line 24 skipping to change at page 51, line 24
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 | 0x100 | No error | Section 8.1 | | H3_NO_ERROR | 0x0100 | No error | Section 8.1 |
| | | | | | | | | |
| H3_GENERAL_PROTOCOL_ERROR | 0x101 | General | Section 8.1 | | H3_GENERAL_PROTOCOL_ERROR | 0x0101 | General | Section 8.1 |
| | | protocol | | | | | protocol | |
| | | error | | | | | error | |
| | | | | | | | | |
| H3_INTERNAL_ERROR | 0x102 | Internal | Section 8.1 | | H3_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 |
| | | error | | | | | error | |
| | | | | | | | | |
| H3_STREAM_CREATION_ERROR | 0x103 | Stream | Section 8.1 | | H3_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 |
| | | creation | | | | | creation | |
| | | error | | | | | error | |
| | | | | | | | | |
| H3_CLOSED_CRITICAL_STREAM | 0x104 | Critical | Section 8.1 | | H3_CLOSED_CRITICAL_STREAM | 0x0104 | Critical | Section 8.1 |
| | | stream was | | | | | stream was | |
| | | closed | | | | | closed | |
| | | | | | | | | |
| H3_FRAME_UNEXPECTED | 0x105 | Frame not | Section 8.1 | | H3_FRAME_UNEXPECTED | 0x0105 | Frame not | Section 8.1 |
| | | permitted in | | | | | permitted in | |
| | | the current | | | | | the current | |
| | | state | | | | | state | |
| | | | | | | | | |
| H3_FRAME_ERROR | 0x106 | Frame | Section 8.1 | | H3_FRAME_ERROR | 0x0106 | Frame | Section 8.1 |
| | | violated | | | | | violated | |
| | | layout or | | | | | layout or | |
| | | size rules | | | | | size rules | |
| | | | | | | | | |
| H3_EXCESSIVE_LOAD | 0x107 | Peer | Section 8.1 | | H3_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 |
| | | generating | | | | | generating | |
| | | excessive | | | | | excessive | |
| | | load | | | | | load | |
| | | | | | | | | |
| H3_ID_ERROR | 0x108 | An identifier | Section 8.1 | | H3_ID_ERROR | 0x0108 | An | Section 8.1 |
| | | was used | | | | | identifier | |
| | | incorrectly | | | | | was used | |
| | | | | | | | incorrectly | |
| H3_SETTINGS_ERROR | 0x109 | SETTINGS | Section 8.1 | | | | | |
| | | frame | | | H3_SETTINGS_ERROR | 0x0109 | SETTINGS | Section 8.1 |
| | | contained | | | | | frame | |
| | | invalid | | | | | contained | |
| | | values | | | | | invalid | |
| | | | | | | | values | |
| H3_MISSING_SETTINGS | 0x10a | No SETTINGS | Section 8.1 | | | | | |
| | | frame | | | H3_MISSING_SETTINGS | 0x010a | No SETTINGS | Section 8.1 |
| | | received | | | | | frame | |
| | | | | | | | received | |
| H3_REQUEST_REJECTED | 0x10b | Request not | Section 8.1 | | | | | |
| | | processed | | | H3_REQUEST_REJECTED | 0x010b | Request not | Section 8.1 |
| | | | | | | | processed | |
| H3_REQUEST_CANCELLED | 0x10c | Data no | Section 8.1 | | | | | |
| | | longer needed | | | H3_REQUEST_CANCELLED | 0x010c | Data no | Section 8.1 |
| | | | | | | | longer | |
| H3_REQUEST_INCOMPLETE | 0x10d | Stream | Section 8.1 | | | | needed | |
| | | terminated | | | | | | |
| | | early | | | H3_REQUEST_INCOMPLETE | 0x010d | Stream | Section 8.1 |
| | | | | | | | terminated | |
| H3_MESSAGE_ERROR | 0x10e | Malformed | Section 8.1 | | | | early | |
| | | message | | | | | | |
| | | | | | H3_MESSAGE_ERROR | 0x010e | Malformed | Section 8.1 |
| H3_CONNECT_ERROR | 0x10f | TCP reset or | Section 8.1 | | | | message | |
| | | error on | | | | | | |
| | | CONNECT | | | H3_CONNECT_ERROR | 0x010f | TCP reset or | Section 8.1 |
| | | request | | | | | error on | |
| | | | | | | | CONNECT | |
| H3_VERSION_FALLBACK | 0x110 | Retry over | Section 8.1 | | | | request | |
| | | 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 55, line 6 skipping to change at page 54, 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-14 (work in progress), Caching", draft-ietf-httpbis-cache-19 (work in progress),
January 2021. September 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-21 (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", RFC 9000,
transport-34 (work in progress). DOI 10.17487/RFC9000,
<https://www.rfc-editor.org/info/rfc9000>.
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", RFC 793,
RFC 793, DOI 10.17487/RFC0793, September 1981, 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,
skipping to change at page 56, line 11 skipping to change at page 55, line 11
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-14 (work in Semantics", draft-ietf-httpbis-semantics-19 (work in
progress), January 2021. progress), September 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,
skipping to change at page 56, line 36 skipping to change at page 55, line 36
[DNS-TERMS] [DNS-TERMS]
Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
January 2019, <https://www.rfc-editor.org/info/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-14 (work in progress), draft-ietf-httpbis-messaging-19 (work in progress),
January 2021. September 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 60, line 7 skipping to change at page 59, line 7
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 are expected to be ordering, but would not be harmed by ordering, and are expected to be
portable to HTTP/2. portable to HTTP/2.
A.2.5. Comparison 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 (0x00): 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 (0x01): 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 (0x02): As described in Appendix A.2.1, HTTP/3 does not
provide a means of signaling priority. provide a means of signaling priority.
RST_STREAM (0x3): RST_STREAM frames do not exist in HTTP/3, since RST_STREAM (0x03): RST_STREAM frames do not exist in HTTP/3, since
QUIC provides stream lifecycle management. The same code point is QUIC provides stream lifecycle management. The same code point is
used for the CANCEL_PUSH frame (Section 7.2.3). used for the CANCEL_PUSH frame (Section 7.2.3).
SETTINGS (0x4): SETTINGS frames are sent only at the beginning of SETTINGS (0x04): SETTINGS frames are sent only at the beginning of
the connection. See Section 7.2.4 and Appendix A.3. the connection. See Section 7.2.4 and Appendix A.3.
PUSH_PROMISE (0x5): The PUSH_PROMISE frame does not reference a PUSH_PROMISE (0x05): The PUSH_PROMISE frame does not reference a
stream; instead the push stream references the PUSH_PROMISE frame stream; instead the push stream references the PUSH_PROMISE frame
using a Push ID. See Section 7.2.5. using a Push ID. See Section 7.2.5.
PING (0x6): PING frames do not exist in HTTP/3, as QUIC provides PING (0x06): PING frames do not exist in HTTP/3, as QUIC provides
equivalent functionality. equivalent functionality.
GOAWAY (0x7): GOAWAY does not contain an error code. In the client GOAWAY (0x07): GOAWAY does not contain an error code. In the client
to server direction, it carries a Push ID instead of a server to server direction, it carries a Push ID instead of a server
initiated stream ID. See Section 7.2.6. initiated stream ID. See Section 7.2.6.
WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist in HTTP/3, WINDOW_UPDATE (0x08): WINDOW_UPDATE frames do not exist in HTTP/3,
since QUIC provides flow control. since QUIC provides flow control.
CONTINUATION (0x9): CONTINUATION frames do not exist in HTTP/3; CONTINUATION (0x09): CONTINUATION frames do not exist in HTTP/3;
instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are instead, larger HEADERS/PUSH_PROMISE frames than HTTP/2 are
permitted. permitted.
Frame types defined by extensions to HTTP/2 need to be separately Frame types defined by extensions to HTTP/2 need to be separately
registered for HTTP/3 if still applicable. The IDs of frames defined registered for HTTP/3 if still applicable. The IDs of frames defined
in [HTTP2] have been reserved for simplicity. Note that the frame in [HTTP2] have been reserved for simplicity. Note that the frame
type space in HTTP/3 is substantially larger (62 bits versus 8 bits), type space in HTTP/3 is substantially larger (62 bits versus 8 bits),
so many HTTP/3 frame types have no equivalent HTTP/2 code points. so many HTTP/3 frame types have no equivalent HTTP/2 code points.
See Section 11.2.1. See Section 11.2.1.
skipping to change at page 61, line 21 skipping to change at page 60, line 21
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 setting that is retained in HTTP/3 has 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 (0x1): See [QPACK]. SETTINGS_HEADER_TABLE_SIZE (0x01): See [QPACK].
SETTINGS_ENABLE_PUSH (0x2): This is removed in favor of the SETTINGS_ENABLE_PUSH (0x02): This is removed in favor of the
MAX_PUSH_ID frame, which provides a more granular control over MAX_PUSH_ID frame, which provides a more granular control over
server push. Specifying a setting with the identifier 0x2 server push. Specifying a setting with the identifier 0x02
(corresponding to the SETTINGS_ENABLE_PUSH parameter) in the (corresponding to the SETTINGS_ENABLE_PUSH parameter) in the
HTTP/3 SETTINGS frame is an error. HTTP/3 SETTINGS frame is an error.
SETTINGS_MAX_CONCURRENT_STREAMS (0x3): QUIC controls the largest SETTINGS_MAX_CONCURRENT_STREAMS (0x03): QUIC controls the largest
open Stream ID as part of its flow control logic. Specifying a open Stream ID as part of its flow control logic. Specifying a
setting with the identifier 0x3 (corresponding to the setting with the identifier 0x03 (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 (0x4): QUIC requires both stream and SETTINGS_INITIAL_WINDOW_SIZE (0x04): 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 0x04 (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 (0x5): This setting has no equivalent in SETTINGS_MAX_FRAME_SIZE (0x05): This setting has no equivalent in
HTTP/3. Specifying a setting with the identifier 0x5 HTTP/3. Specifying a setting with the identifier 0x05
(corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) in the (corresponding to the SETTINGS_MAX_FRAME_SIZE parameter) in the
HTTP/3 SETTINGS frame is an error. HTTP/3 SETTINGS frame is an error.
SETTINGS_MAX_HEADER_LIST_SIZE (0x6): This setting identifier has SETTINGS_MAX_HEADER_LIST_SIZE (0x06): This setting identifier has
been 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.
skipping to change at page 62, line 27 skipping to change at page 61, line 27
A.4. HTTP/2 Error Codes A.4. HTTP/2 Error Codes
QUIC has the same concepts of "stream" and "connection" errors that QUIC has the same concepts of "stream" and "connection" errors that
HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3 HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3
mean that error codes are not directly portable between versions. mean that error codes are not directly portable between versions.
The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map
to the HTTP/3 error codes as follows: to the HTTP/3 error codes as follows:
NO_ERROR (0x0): H3_NO_ERROR in Section 8.1. NO_ERROR (0x00): H3_NO_ERROR in Section 8.1.
PROTOCOL_ERROR (0x1): This is mapped to H3_GENERAL_PROTOCOL_ERROR PROTOCOL_ERROR (0x01): 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 (0x02): H3_INTERNAL_ERROR in Section 8.1.
FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow FLOW_CONTROL_ERROR (0x03): Not applicable, since QUIC handles flow
control. control.
SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgment of SETTINGS_TIMEOUT (0x04): Not applicable, since no acknowledgment of
SETTINGS is defined. SETTINGS is defined.
STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream STREAM_CLOSED (0x05): Not applicable, since QUIC handles stream
management. management.
FRAME_SIZE_ERROR (0x6): H3_FRAME_ERROR error code defined in FRAME_SIZE_ERROR (0x06): 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 (0x07): 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
applicable because QUIC handles stream management. applicable because QUIC handles stream management.
CANCEL (0x8): H3_REQUEST_CANCELLED in Section 8.1. CANCEL (0x08): H3_REQUEST_CANCELLED in Section 8.1.
COMPRESSION_ERROR (0x9): Multiple error codes are defined in COMPRESSION_ERROR (0x09): Multiple error codes are defined in
[QPACK]. [QPACK].
CONNECT_ERROR (0xa): H3_CONNECT_ERROR in Section 8.1. CONNECT_ERROR (0x0a): H3_CONNECT_ERROR in Section 8.1.
ENHANCE_YOUR_CALM (0xb): H3_EXCESSIVE_LOAD in Section 8.1. ENHANCE_YOUR_CALM (0x0b): H3_EXCESSIVE_LOAD in Section 8.1.
INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to INADEQUATE_SECURITY (0x0c): Not applicable, since QUIC is assumed to
provide sufficient security on all connections. provide sufficient security on all connections.
HTTP_1_1_REQUIRED (0xd): H3_VERSION_FALLBACK in Section 8.1. HTTP_1_1_REQUIRED (0x0d): H3_VERSION_FALLBACK in Section 8.1.
Error codes need to be defined for HTTP/2 and HTTP/3 separately. See Error codes need to be defined for HTTP/2 and HTTP/3 separately. See
Section 11.2.3. Section 11.2.3.
A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors
An intermediary that converts between HTTP/2 and HTTP/3 may encounter An intermediary that converts between HTTP/2 and HTTP/3 may encounter
error conditions from either upstream. It is useful to communicate error conditions from either upstream. It is useful to communicate
the occurrence of error to the downstream but error codes largely the occurrence of error to the downstream but error codes largely
reflect connection-local problems that generally do not make sense to reflect connection-local problems that generally do not make sense to
skipping to change at page 64, line 5 skipping to change at page 63, line 5
H3_REQUEST_CANCELLED; see Section 4.1.2. H3_REQUEST_CANCELLED; see Section 4.1.2.
Conversion between errors is described in the logical mapping. The Conversion between errors is described in the logical mapping. The
error codes are defined in non-overlapping spaces in order to protect error codes are defined in non-overlapping spaces in order to protect
against accidental conversion that could result in the use of against accidental conversion that could result in the use of
inappropriate or unknown error codes for the target version. An inappropriate or unknown error codes for the target version. An
intermediary is permitted to promote stream errors to connection intermediary is permitted to promote stream errors to connection
errors but they should be aware of the cost to the HTTP/3 connection errors but they should be aware of the cost to the HTTP/3 connection
for what might be a temporary or intermittent error. for what might be a temporary or intermittent error.
Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document.
B.1. Since draft-ietf-quic-http-32
o Removed draft version guidance; added final version string
o Added H3_MESSAGE_ERROR for malformed messages
B.2. Since draft-ietf-quic-http-31
Editorial changes only.
B.3. Since draft-ietf-quic-http-30
Editorial changes only.
B.4. Since draft-ietf-quic-http-29
o Require a connection error if a reserved frame type that
corresponds to a frame in HTTP/2 is received (#3991, #3993)
o Require a connection error if a reserved setting that corresponds
to a setting in HTTP/2 is received (#3954, #3955)
B.5. Since draft-ietf-quic-http-28
o CANCEL_PUSH is recommended even when the stream is reset (#3698,
#3700)
o Use H3_ID_ERROR when GOAWAY contains a larger identifier (#3631,
#3634)
B.6. Since draft-ietf-quic-http-27
o Updated text to refer to latest HTTP revisions
o Use the HTTP definition of authority for establishing and
coalescing connections (#253, #2223, #3558)
o Define use of GOAWAY from both endpoints (#2632, #3129)
o Require either :authority or Host if the URI scheme has a
mandatory authority component (#3408, #3475)
B.7. Since draft-ietf-quic-http-26
o No changes
B.8. Since draft-ietf-quic-http-25
o Require QUICv1 for HTTP/3 (#3117, #3323)
o Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3275,
#3309)
o Clarify the definition of "malformed" (#3352, #3345)
B.9. Since draft-ietf-quic-http-24
o Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended
instead (#3130,#3208)
o Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331)
o Some error codes are reserved for greasing (#3325,#3360)
B.10. Since draft-ietf-quic-http-23
o Removed "quic" Alt-Svc parameter (#3061,#3118)
o Clients need not persist unknown settings for use in 0-RTT
(#3110,#3113)
o Clarify error cases around CANCEL_PUSH (#2819,#3083)
B.11. Since draft-ietf-quic-http-22
o Removed priority signaling (#2922,#2924)
o Further changes to error codes (#2662,#2551):
* Error codes renumbered
* HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR,
HTTP_ID_ERROR, and others
o Clarify how unknown frame types interact with required frame
sequence (#2867,#2858)
o Describe interactions with the transport in terms of defined
interface terms (#2857,#2805)
o Require the use of the "http-opportunistic" resource (RFC 8164)
when scheme is "http" (#2439,#2973)
o Settings identifiers cannot be duplicated (#2979)
o Changes to SETTINGS frames in 0-RTT (#2972,#2790,#2945):
* Servers must send all settings with non-default values in their
SETTINGS frame, even when resuming
* If a client doesn't have settings associated with a 0-RTT
ticket, it uses the defaults
* Servers can't accept early data if they cannot recover the
settings the client will have remembered
o Clarify that Upgrade and the 101 status code are prohibited
(#2898,#2889)
o Clarify that frame types reserved for greasing can occur on any
stream, but frame types reserved due to HTTP/2 correspondence are
prohibited (#2997,#2692,#2693)
o Unknown error codes cannot be treated as errors (#2998,#2816)
B.12. Since draft-ietf-quic-http-21
No changes
B.13. Since draft-ietf-quic-http-20
o Prohibit closing the control stream (#2509, #2666)
o Change default priority to use an orphan node (#2502, #2690)
o Exclusive priorities are restored (#2754, #2781)
o Restrict use of frames when using CONNECT (#2229, #2702)
o Close and maybe reset streams if a connection error occurs for
CONNECT (#2228, #2703)
o Encourage provision of sufficient unidirectional streams for QPACK
(#2100, #2529, #2762)
o Allow extensions to use server-initiated bidirectional streams
(#2711, #2773)
o Clarify use of maximum header list size setting (#2516, #2774)
o Extensive changes to error codes and conditions of their sending
* Require connection errors for more error conditions (#2511,
#2510)
* Updated the error codes for illegal GOAWAY frames (#2714,
#2707)
* Specified error code for HEADERS on control stream (#2708)
* Specified error code for servers receiving PUSH_PROMISE (#2709)
* Specified error code for receiving DATA before HEADERS (#2715)
* Describe malformed messages and their handling (#2410, #2764)
* Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813)
* Refactor Push ID related errors (#2818, #2820)
* Rationalize HTTP/3 stream creation errors (#2821, #2822)
B.14. Since draft-ietf-quic-http-19
o SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530)
o Non-zero bits in the Empty field of the PRIORITY frame MAY be
treated as an error (#2501)
B.15. Since draft-ietf-quic-http-18
o Resetting streams following a GOAWAY is recommended, but not
required (#2256,#2457)
o Use variable-length integers throughout (#2437,#2233,#2253,#2275)
* Variable-length frame types, stream types, and settings
identifiers
* Renumbered stream type assignments
* Modified associated reserved values
o Frame layout switched from Length-Type-Value to Type-Length-Value
(#2395,#2235)
o Specified error code for servers receiving DUPLICATE_PUSH (#2497)
o Use connection error for invalid PRIORITY (#2507, #2508)
B.16. Since draft-ietf-quic-http-17
o HTTP_REQUEST_REJECTED is used to indicate a request can be retried
(#2106, #2325)
o Changed error code for GOAWAY on the wrong stream (#2231, #2343)
B.17. Since draft-ietf-quic-http-16
o Rename "HTTP/QUIC" to "HTTP/3" (#1973)
o Changes to PRIORITY frame (#1865, #2075)
* Permitted as first frame of request streams
* Remove exclusive reprioritization
* Changes to Prioritized Element Type bits
o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE
(#2072)
o Set defaults for settings, allow request before receiving SETTINGS
(#1809, #1846, #2038)
o Clarify message processing rules for streams that aren't closed
(#1972, #2003)
o Removed reservation of error code 0 and moved HTTP_NO_ERROR to
this value (#1922)
o Removed prohibition of zero-length DATA frames (#2098)
B.18. Since draft-ietf-quic-http-15
Substantial editorial reorganization; no technical changes.
B.19. Since draft-ietf-quic-http-14
o Recommend sensible values for QUIC transport parameters
(#1720,#1806)
o Define error for missing SETTINGS frame (#1697,#1808)
o Setting values are variable-length integers (#1556,#1807) and do
not have separate maximum values (#1820)
o Expanded discussion of connection closure (#1599,#1717,#1712)
o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)
B.20. Since draft-ietf-quic-http-13
o Reserved some frame types for grease (#1333, #1446)
o Unknown unidirectional stream types are tolerated, not errors;
some reserved for grease (#1490, #1525)
o Require settings to be remembered for 0-RTT, prohibit reductions
(#1541, #1641)
o Specify behavior for truncated requests (#1596, #1643)
B.21. Since draft-ietf-quic-http-12
o TLS SNI extension isn't mandatory if an alternative method is used
(#1459, #1462, #1466)
o Removed flags from HTTP/3 frames (#1388, #1398)
o Reserved frame types and settings for use in preserving
extensibility (#1333, #1446)
o Added general error code (#1391, #1397)
o Unidirectional streams carry a type byte and are extensible
(#910,#1359)
o Priority mechanism now uses explicit placeholders to enable
persistent structure in the tree (#441,#1421,#1422)
B.22. Since draft-ietf-quic-http-11
o Moved QPACK table updates and acknowledgments to dedicated streams
(#1121, #1122, #1238)
B.23. Since draft-ietf-quic-http-10
o Settings need to be remembered when attempting and accepting 0-RTT
(#1157, #1207)
B.24. Since draft-ietf-quic-http-09
o Selected QCRAM for header compression (#228, #1117)
o The server_name TLS extension is now mandatory (#296, #495)
o Specified handling of unsupported versions in Alt-Svc (#1093,
#1097)
B.25. Since draft-ietf-quic-http-08
o Clarified connection coalescing rules (#940, #1024)
B.26. Since draft-ietf-quic-http-07
o Changes for integer encodings in QUIC (#595,#905)
o Use unidirectional streams as appropriate (#515, #240, #281, #886)
o Improvement to the description of GOAWAY (#604, #898)
o Improve description of server push usage (#947, #950, #957)
B.27. Since draft-ietf-quic-http-06
o Track changes in QUIC error code usage (#485)
B.28. Since draft-ietf-quic-http-05
o Made push ID sequential, add MAX_PUSH_ID, remove
SETTINGS_ENABLE_PUSH (#709)
o Guidance about keep-alive and QUIC PINGs (#729)
o Expanded text on GOAWAY and cancellation (#757)
B.29. Since draft-ietf-quic-http-04
o Cite RFC 5234 (#404)
o Return to a single stream per request (#245,#557)
o Use separate frame type and settings registries from HTTP/2 (#81)
o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)
o Restored GOAWAY (#696)
o Identify server push using Push ID rather than a stream ID
(#702,#281)
o DATA frames cannot be empty (#700)
B.30. Since draft-ietf-quic-http-03
None.
B.31. Since draft-ietf-quic-http-02
o Track changes in transport draft
B.32. Since draft-ietf-quic-http-01
o SETTINGS changes (#181):
* SETTINGS can be sent only once at the start of a connection; no
changes thereafter
* SETTINGS_ACK removed
* Settings can only occur in the SETTINGS frame a single time
* Boolean format updated
o Alt-Svc parameter changed from "v" to "quic"; format updated
(#229)
o Closing the connection control stream or any message control
stream is a fatal error (#176)
o HPACK Sequence counter can wrap (#173)
o 0-RTT guidance added
o Guide to differences from HTTP/2 and porting HTTP/2 extensions
added (#127,#242)
B.33. Since draft-ietf-quic-http-00
o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
o Changed from using HTTP/2 framing within Stream 3 to new framing
format and two-stream-per-request model (#71,#72,#73)
o Adopted SETTINGS format from draft-bishop-httpbis-extended-
settings-01
o Reworked SETTINGS_ACK to account for indeterminate inter-stream
order (#75)
o Described CONNECT pseudo-method (#95)
o Updated ALPN token and Alt-Svc guidance (#13,#87)
o Application-layer-defined error codes (#19,#74)
B.34. Since draft-shade-quic-http2-mapping-00
o Adopted as base for draft-ietf-quic-http
o Updated authors/editors list
Acknowledgments 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. 
720 lines changed or deleted 272 lines changed or added

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