draft-ietf-quic-http-25.txt   draft-ietf-quic-http-26.txt 
QUIC M. Bishop, Ed. QUIC M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track 22 January 2020 Intended status: Standards Track 21 February 2020
Expires: 25 July 2020 Expires: 24 August 2020
Hypertext Transfer Protocol Version 3 (HTTP/3) Hypertext Transfer Protocol Version 3 (HTTP/3)
draft-ietf-quic-http-25 draft-ietf-quic-http-26
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 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 25 July 2020. This Internet-Draft will expire on 24 August 2020.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 29 skipping to change at page 2, line 29
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 4 1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 4
1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5 1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5
2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 5 2. HTTP/3 Protocol Overview . . . . . . . . . . . . . . . . . . 5
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. Draft Version Identification . . . . . . . . . . . . . . 8 3.1. Draft Version Identification . . . . . . . . . . . . . . 8
3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 8 3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 9
3.3. Connection Establishment . . . . . . . . . . . . . . . . 9 3.3. Connection Establishment . . . . . . . . . . . . . . . . 9
3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 9 3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 10
4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 10 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 10
4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 10 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 10
4.1.1. Header Formatting and Compression . . . . . . . . . . 12 4.1.1. Header Formatting and Compression . . . . . . . . . . 12
4.1.2. Request Cancellation and Rejection . . . . . . . . . 13 4.1.2. Request Cancellation and Rejection . . . . . . . . . 15
4.1.3. Malformed Requests and Responses . . . . . . . . . . 14 4.1.3. Malformed Requests and Responses . . . . . . . . . . 16
4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 14 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 17
4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 15 4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 18
4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 15 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 18
5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 17 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 20
5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 17 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 20
5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 17 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 20
5.3. Immediate Application Closure . . . . . . . . . . . . . . 19 5.3. Immediate Application Closure . . . . . . . . . . . . . . 22
5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 19 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 22
6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 19 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 22
6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 20 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 23
6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 20 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 23
6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 22 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 24
6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 22 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 25
6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 23 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 26
7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 23 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 26
7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 25 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 28
7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 26 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 29
7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 26 7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 29
7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 27 7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 30
7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 30 7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 33
7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 31 7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 34
7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 32 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 35
7.2.8. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 32 7.2.8. Reserved Frame Types . . . . . . . . . . . . . . . . 36
7.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 33 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 36
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 34 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 36
8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 34 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 38
9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 35 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 39
10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 37 10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 39
10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 37 10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 39
10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 37 10.4. Migration . . . . . . . . . . . . . . . . . . . . . . . 39
10.4. Migration . . . . . . . . . . . . . . . . . . . . . . . 37 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 11.1. Registration of HTTP/3 Identification String . . . . . . 40
11.1. Registration of HTTP/3 Identification String . . . . . . 37 11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 40
11.2. New Registries . . . . . . . . . . . . . . . . . . . . . 38 11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 40
11.2.1. Frame Types . . . . . . . . . . . . . . . . . . . . 38 11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 42
11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 39 11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 43
11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 40 11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 45
11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 43 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 12.1. Normative References . . . . . . . . . . . . . . . . . . 45
12.1. Normative References . . . . . . . . . . . . . . . . . . 43 12.2. Informative References . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . 45 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 48
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 46 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 48
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 46 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 49
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 47 A.2.1. Prioritization Differences . . . . . . . . . . . . . 49
A.2.1. Prioritization Differences . . . . . . . . . . . . . 47 A.2.2. Header Compression Differences . . . . . . . . . . . 49
A.2.2. Header Compression Differences . . . . . . . . . . . 47 A.2.3. Guidance for New Frame Type Definitions . . . . . . . 50
A.2.3. Guidance for New Frame Type Definitions . . . . . . . 48 A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 50
A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 48 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 51
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 49 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 52
A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 50 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 53
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 51 B.1. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 53
B.1. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 51 B.2. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 53
B.2. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 51 B.3. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 54
B.3. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 52 B.4. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 54
B.4. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 53 B.5. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 55
B.5. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 53 B.6. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 55
B.6. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 54 B.7. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 56
B.7. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 54 B.8. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 56
B.8. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 54 B.9. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 56
B.9. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 54 B.10. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 56
B.10. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 55 B.11. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 57
B.11. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 55 B.12. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 57
B.12. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 55 B.13. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 57
B.13. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 55 B.14. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 57
B.14. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 56 B.15. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 58
B.15. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 56 B.16. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 58
B.16. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 56 B.17. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 58
B.17. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 56 B.18. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 58
B.18. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 56 B.19. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 58
B.19. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 56 B.20. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 59
B.20. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 57 B.21. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 59
B.21. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 57 B.22. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 59
B.22. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 57 B.23. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 59
B.23. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 57 B.24. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 59
B.24. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 57 B.25. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 59
B.25. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 58 B.26. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 60
B.26. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 58 B.27. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 60
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 58 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 60
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
HTTP semantics are used for a broad range of services on the HTTP semantics are used for a broad range of services on the
Internet. These semantics have commonly been used with two different Internet. These semantics have commonly been used with two different
TCP mappings, HTTP/1.1 and HTTP/2. HTTP/3 supports the same TCP mappings, HTTP/1.1 and HTTP/2. HTTP/3 supports the same
semantics over a new transport protocol, QUIC. semantics over a new transport protocol, QUIC.
1.1. Prior versions of HTTP 1.1. Prior versions of HTTP
skipping to change at page 5, line 52 skipping to change at page 5, line 52
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] which Server push is an interaction mode introduced in HTTP/2 [HTTP2] which
permits a server to push a request-response exchange to a client in permits a server to push a request-response exchange to a client in
anticipation of the client making the indicated request. This trades anticipation of the client making the indicated request. This trades
off network usage against a potential latency gain. Several HTTP/3 off network usage against a potential latency gain. Several HTTP/3
frames are used to manage server push, such as PUSH_PROMISE, frames are used to manage server push, such as PUSH_PROMISE,
DUPLICATE_PUSH, MAX_PUSH_ID, and CANCEL_PUSH. MAX_PUSH_ID, and CANCEL_PUSH.
As in HTTP/2, request and response headers are compressed for As in HTTP/2, request and response headers are compressed for
transmission. Because HPACK [HPACK] relies on in-order transmission transmission. Because HPACK [HPACK] relies on in-order transmission
of compressed header blocks (a guarantee not provided by QUIC), of compressed header blocks (a guarantee not provided by QUIC),
HTTP/3 replaces HPACK with QPACK [QPACK]. QPACK uses separate HTTP/3 replaces HPACK with QPACK [QPACK]. QPACK uses separate
unidirectional streams to modify and track header table state, while unidirectional streams to modify and track header table state, while
header blocks refer to the state of the table without modifying it. header blocks refer to the state of the table without modifying it.
2.1. Document Organization 2.1. Document Organization
skipping to change at page 8, line 36 skipping to change at page 8, line 36
HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc. HTTP/3 uses the token "h3" to identify itself in ALPN and Alt-Svc.
Only implementations of the final, published RFC can identify Only implementations of the final, published RFC can identify
themselves as "h3". Until such an RFC exists, implementations MUST themselves as "h3". Until such an RFC exists, implementations MUST
NOT identify themselves using this string. NOT identify themselves using this string.
Implementations of draft versions of the protocol MUST add the string Implementations of draft versions of the protocol MUST add the string
"-" and the corresponding draft number to the identifier. For "-" and the corresponding draft number to the identifier. For
example, draft-ietf-quic-http-01 is identified using the string example, draft-ietf-quic-http-01 is identified using the string
"h3-01". "h3-01".
Draft versions MUST use the corresponding draft transport version as
their transport. For example, the application protocol defined in
draft-ietf-quic-http-25 uses the transport defined in draft-ietf-
quic-transport-25.
Non-compatible experiments that are based on these draft versions Non-compatible experiments that are based on these draft versions
MUST append the string "-" and an experiment name to the identifier. MUST append the string "-" and an experiment name to the identifier.
For example, an experimental implementation based on draft-ietf-quic- For example, an experimental implementation based on draft-ietf-quic-
http-09 which reserves an extra stream for unsolicited transmission http-09 which reserves an extra stream for unsolicited transmission
of 1980s pop music might identify itself as "h3-09-rickroll". Note of 1980s pop music might identify itself as "h3-09-rickroll". Note
that any label MUST conform to the "token" syntax defined in that any label MUST conform to the "token" syntax defined in
Section 3.2.6 of [RFC7230]. Experimenters are encouraged to Section 3.2.6 of [RFC7230]. Experimenters are encouraged to
coordinate their experiments on the quic@ietf.org mailing list. coordinate their experiments on the quic@ietf.org mailing list.
3.2. Discovering an HTTP/3 Endpoint 3.2. Discovering an HTTP/3 Endpoint
skipping to change at page 9, line 24 skipping to change at page 9, line 32
Connectivity problems (e.g. firewall blocking UDP) can result in QUIC Connectivity problems (e.g. firewall blocking UDP) can result in QUIC
connection establishment failure, in which case the client SHOULD connection establishment failure, in which case the client SHOULD
continue using the existing connection or try another alternative continue using the existing connection or try another alternative
endpoint offered by the origin. endpoint offered by the origin.
Servers MAY serve HTTP/3 on any UDP port, since an alternative always Servers MAY serve HTTP/3 on any UDP port, since an alternative always
includes an explicit port. includes an explicit port.
3.3. Connection Establishment 3.3. Connection Establishment
HTTP/3 relies on QUIC as the underlying transport. The QUIC version HTTP/3 relies on QUIC version 1 as the underlying transport. The use
being used MUST use TLS version 1.3 or greater as its handshake of other QUIC transport versions with HTTP/3 MAY be defined by future
protocol. HTTP/3 clients MUST indicate the target domain name during specifications.
the TLS handshake. This may be done using the Server Name Indication
(SNI) [RFC6066] extension to TLS or using some other mechanism. QUIC version 1 uses TLS version 1.3 or greater as its handshake
protocol. HTTP/3 clients MUST support a mechanism to indicate the
target host to the server during the TLS handshake. If the server is
identified by a DNS name, clients MUST send the Server Name
Indication (SNI) [RFC6066] TLS extension unless an 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 10, line 36 skipping to change at page 10, line 48
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 client-initiated bidirectional A client sends an HTTP request on a client-initiated bidirectional
QUIC stream. A client MUST send only a single request on a given QUIC stream. A client MUST send only a single request on a given
stream. A server sends zero or more non-final HTTP responses on the stream. A server sends zero or more non-final HTTP responses on the
same stream as the request, followed by a single final HTTP response, same stream as the request, followed by a single final HTTP response,
as detailed below. as detailed below.
Pushed responses are sent on a server-initiated unidirectional QUIC
stream (see Section 6.2.2). A server sends zero or more non-final
HTTP responses, followed by a single final HTTP response, in the same
manner as a standard response. Push is described in more detail in
Section 4.4.
On a given stream, receipt of multiple requests or receipt of an
additional HTTP response following a final HTTP response MUST be
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 message header (see Section 3.2 of [RFC7230]), sent as a 1. the message header (see Section 3.2 of [RFC7230]), sent as a
single HEADERS frame (see Section 7.2.2), single HEADERS frame (see Section 7.2.2),
2. optionally, the payload body, if present (see Section 3.3 of 2. optionally, the payload body, if present (see Section 3.3 of
[RFC7230]), sent as a series of DATA frames (see Section 7.2.1), [RFC7230]), sent as a series of DATA frames (see Section 7.2.1),
3. optionally, trailing headers, if present (see Section 4.1.2 of 3. optionally, trailing headers, if present (see Section 4.1.2 of
[RFC7230]), sent as a single HEADERS frame. [RFC7230]), sent as a single HEADERS frame.
A server MAY send one or more PUSH_PROMISE (see Section 7.2.5) or Receipt of DATA and HEADERS frames in any other sequence MUST be
DUPLICATE_PUSH (see Section 7.2.8) frames before, after, or treated as a connection error of type H3_FRAME_UNEXPECTED
interleaved with the frames of a response message. These (Section 8).
PUSH_PROMISE and DUPLICATE_PUSH frames are not part of the response;
see Section 4.4 for more details. A server MAY send one or more PUSH_PROMISE frames (see Section 7.2.5)
before, after, or interleaved with the frames of a response message.
These PUSH_PROMISE frames are not part of the response; see
Section 4.4 for more details. These frames are not permitted in
pushed responses; a pushed response which includes PUSH_PROMISE
frames MUST be treated as a connection error of type
H3_FRAME_UNEXPECTED.
Frames of unknown types (Section 9), including reserved frames Frames of unknown types (Section 9), including reserved frames
(Section 7.2.9) 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 4.1 of [RFC7230] The "chunked" transfer encoding defined in Section 4.1 of [RFC7230]
MUST NOT be used. MUST NOT be used.
skipping to change at page 11, line 28 skipping to change at page 12, line 11
more informational responses (1xx; see Section 6.2 of [RFC7231]) more informational responses (1xx; see Section 6.2 of [RFC7231])
precede a final response to the same request. Non-final responses do precede a final response to the same request. Non-final responses do
not contain a payload body or trailers. not contain a payload body or trailers.
If an endpoint receives an invalid sequence of frames on either a If an endpoint receives an invalid sequence of frames on either a
request or a push stream, it MUST respond with a connection error of request or a push stream, it MUST respond with a connection error of
type H3_FRAME_UNEXPECTED (Section 8). In particular, a DATA frame type H3_FRAME_UNEXPECTED (Section 8). In particular, a DATA frame
before any HEADERS frame, or a HEADERS or DATA frame after the before any HEADERS frame, or a HEADERS or DATA frame after the
trailing HEADERS frame is considered invalid. trailing HEADERS frame is considered invalid.
An HTTP request/response exchange fully consumes a bidirectional QUIC An HTTP request/response exchange fully consumes a client-initiated
stream. After sending a request, a client MUST close the stream for bidirectional QUIC stream. After sending a request, a client MUST
sending. Unless using the CONNECT method (see Section 4.2), clients close the stream for sending. Unless using the CONNECT method (see
MUST NOT make stream closure dependent on receiving a response to Section 4.2), clients MUST NOT make stream closure dependent on
their request. After sending a final response, the server MUST close receiving a response to their request. After sending a final
the stream for sending. At this point, the QUIC stream is fully response, the server MUST close the stream for sending. At this
closed. point, the QUIC stream is fully closed.
When a stream is closed, this indicates the end of an HTTP message. When a stream is closed, this indicates the end of an HTTP message.
Because some messages are large or unbounded, endpoints SHOULD begin Because some messages are large or unbounded, endpoints SHOULD begin
processing partial HTTP messages once enough of the message has been processing partial HTTP messages once enough of the message has been
received to make progress. If a client stream terminates without received to make progress. If a client stream terminates without
enough of the HTTP message to provide a complete response, the server enough of the HTTP message to provide a complete response, the server
SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE. SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE.
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
skipping to change at page 12, line 26 skipping to change at page 13, line 8
Just as in previous versions of HTTP, header field names are strings Just as in previous versions of HTTP, header field names are strings
of ASCII characters that are compared in a case-insensitive fashion. of ASCII characters that are compared in a case-insensitive fashion.
Properties of HTTP header field names and values are discussed in Properties of HTTP header field names and values are discussed in
more detail in Section 3.2 of [RFC7230], though the wire rendering in more detail in Section 3.2 of [RFC7230], though the wire rendering in
HTTP/3 differs. As in HTTP/2, header field names MUST be converted HTTP/3 differs. As in HTTP/2, header field names MUST be converted
to lowercase prior to their encoding. A request or response to lowercase prior to their encoding. A request or response
containing uppercase header field names MUST be treated as malformed containing uppercase header field names MUST be treated as malformed
(Section 4.1.3). (Section 4.1.3).
Like HTTP/2, HTTP/3 does not use the Connection header field to
indicate connection-specific header fields; in this protocol,
connection-specific metadata is conveyed by other means. An endpoint
MUST NOT generate an HTTP/3 message containing connection-specific
header fields; any message containing connection-specific header
fields MUST be treated as malformed (Section 4.1.3).
The only exception to this is the TE header field, which MAY be
present in an HTTP/3 request; when it is, it MUST NOT contain any
value other than "trailers".
This means that an intermediary transforming an HTTP/1.x message to
HTTP/3 will need to remove any header fields nominated by the
Connection header field, along with the Connection header field
itself. Such intermediaries SHOULD also remove other connection-
specific header fields, such as Keep-Alive, Proxy-Connection,
Transfer-Encoding, and Upgrade, even if they are not nominated by the
Connection header field.
4.1.1.1. Pseudo-Header Fields
As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with
the ':' character (ASCII 0x3a) to convey the target URI, the method the ':' character (ASCII 0x3a) to convey the target URI, the method
of the request, and the status code for the response. These pseudo- of the request, and the status code for the response.
header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2].
Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT
generate pseudo-header fields other than those defined in [HTTP2]. generate pseudo-header fields other than those defined in this
The restrictions on the use of pseudo-header fields in Section 8.1.2 document, except as negotiated via an extension; see Section 9.
of [HTTP2] also apply to HTTP/3. Messages which are considered
malformed under these restrictions are handled as described in Pseudo-header fields are only valid in the context in which they are
Section 4.1.3. defined. Pseudo-header fields defined for requests MUST NOT appear
in responses; pseudo-header fields defined for responses MUST NOT
appear in requests. Pseudo-header fields MUST NOT appear in
trailers. Endpoints MUST treat a request or response that contains
undefined or invalid pseudo-header fields as malformed
(Section 4.1.3).
All pseudo-header fields MUST appear in the header block before
regular header fields. Any request or response that contains a
pseudo-header field that appears in a header block after a regular
header field MUST be treated as malformed (Section 4.1.3).
The following pseudo-header fields are defined for requests:
":method": Contains the HTTP method ([RFC7231], Section 4)
":scheme": Contains the scheme portion of the target URI ([RFC3986],
Section 3.1)
":scheme" is not restricted to "http" and "https" schemed URIs. A
proxy or gateway can translate requests for non-HTTP schemes,
enabling the use of HTTP to interact with non-HTTP services.
":authority": Contains the authority portion of the target URI
(Section 3.2 of [RFC3986]). The authority MUST NOT include the
deprecated "userinfo" subcomponent for "http" or "https" schemed
URIs.
To ensure that the HTTP/1.1 request line can be reproduced
accurately, this pseudo-header field MUST be omitted when
translating from an HTTP/1.1 request that has a request target in
origin or asterisk form (see Section 5.3 of [RFC7230]). Clients
that generate HTTP/3 requests directly SHOULD use the ":authority"
pseudo-header field instead of the Host header field. An
intermediary that converts an HTTP/3 request to HTTP/1.1 MUST
create a Host header field if one is not present in a request by
copying the value of the ":authority" pseudo-header field.
":path": Contains the path and query parts of the target URI (the
"path-absolute" production and optionally a '?' character followed
by the "query" production (see Sections 3.3 and 3.4 of [RFC3986]).
A request in asterisk form includes the value '*' for the ":path"
pseudo-header field.
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'. The exception to this rule is an
OPTIONS request for an "http" or "https" URI that does not include
a path component; these MUST include a ":path" pseudo-header field
with a value of '*' (see Section 5.3.4 of [RFC7230]).
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
request (Section 4.2). An HTTP request that omits mandatory pseudo-
header fields or contains invalid values for those fields is
malformed (Section 4.1.3).
HTTP/3 does not define a way to carry the version identifier that is
included in the HTTP/1.1 request line.
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code field (see Section 6 of [RFC7231]).
This pseudo-header field MUST be included in all responses;
otherwise, the response is malformed (Section 4.1.3).
HTTP/3 does not define a way to carry the version or reason phrase
that is included in an HTTP/1.1 status line.
4.1.1.2. Header Compression
HTTP/3 uses QPACK header compression as described in [QPACK], a HTTP/3 uses QPACK header compression as described in [QPACK], a
variation of HPACK which allows the flexibility to avoid header- variation of HPACK which allows the flexibility to avoid header-
compression-induced head-of-line blocking. See that document for compression-induced head-of-line blocking. See that document for
additional details. additional details.
To allow for better compression efficiency, the cookie header field To allow for better compression efficiency, the cookie header field
[RFC6265] MAY be split into separate header fields, each with one or [RFC6265] MAY be split into separate header fields, each with one or
more cookie-pairs, before compression. If a decompressed header list more cookie-pairs, before compression. If a decompressed header list
contains multiple cookie header fields, these MUST be concatenated contains multiple cookie header fields, these MUST be concatenated
before being passed into a non-HTTP/2, non-HTTP/3 context, as before being passed into a non-HTTP/2, non-HTTP/3 context, as
described in Section 8.1.2.5 of [HTTP2]. described in Section 8.1.2.5 of [HTTP2].
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 field list than it is willing to server that receives a larger header field list than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status handle can send an HTTP 431 (Request Header Fields Too Large) status
code [RFC6585]. A client can discard responses that it cannot code [RFC6585]. A client can discard responses that it cannot
process. The size of a header field list is calculated based on the process. The size of a header field list is calculated based on the
uncompressed size of header fields, including the length of the name uncompressed size of header fields, including the length of the name
and value in bytes plus an overhead of 32 bytes for each header and value in bytes plus an overhead of 32 bytes for each header
field. field.
skipping to change at page 14, line 8 skipping to change at page 16, line 34
If a stream is cancelled after receiving a complete response, the If a stream is cancelled after receiving a complete response, the
client MAY ignore the cancellation and use the response. However, if client MAY ignore the cancellation and use the response. However, if
a stream is cancelled after receiving a partial response, the a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used. Automatically retrying such requests is response SHOULD NOT be used. Automatically retrying such requests is
not possible, unless this is otherwise permitted (e.g., idempotent not possible, unless this is otherwise permitted (e.g., idempotent
actions like GET, PUT, or DELETE). actions like GET, PUT, or DELETE).
4.1.3. Malformed Requests and Responses 4.1.3. Malformed Requests and Responses
A malformed request or response is one that is an otherwise valid A malformed request or response is one that is an otherwise valid
sequence of frames but is invalid due to the presence of extraneous sequence of frames but is invalid due to:
frames, prohibited header fields, the absence of mandatory header
fields, or the inclusion of uppercase header field names. * the presence of prohibited header fields or pseudo-header fields,
* the absence of mandatory pseudo-header fields,
* invalid values for pseudo-header fields,
* pseudo-header fields after header fields,
* an invalid sequence of HTTP messages, or
* the inclusion of uppercase header field names.
A request or response that includes a payload body can include a A request or response that includes a payload body can include a
"content-length" header field. A request or response is also "content-length" header field. A request or response is also
malformed if the value of a content-length header field does not malformed if the value of a content-length header field does not
equal the sum of the DATA frame payload lengths that form the body. equal the sum of the DATA frame payload lengths that form the body.
A response that is defined to have no payload, as described in A response that is defined to have no payload, as described in
Section 3.3.2 of [RFC7230] can have a non-zero content-length header Section 3.3.2 of [RFC7230] can have a non-zero content-length header
field, even though no content is included in DATA frames. field, even though no content is included in DATA frames.
Intermediaries that process HTTP requests or responses (i.e., any Intermediaries that process HTTP requests or responses (i.e., any
skipping to change at page 16, line 6 skipping to change at page 18, line 41
4.4. Server Push 4.4. Server Push
Server push is an interaction mode introduced in HTTP/2 [HTTP2] which Server push is an interaction mode introduced in HTTP/2 [HTTP2] which
permits a server to push a request-response exchange to a client in permits a server to push a request-response exchange to a client in
anticipation of the client making the indicated request. This trades anticipation of the client making the indicated request. This trades
off network usage against a potential latency gain. HTTP/3 server off network usage against a potential latency gain. HTTP/3 server
push is similar to what is described in HTTP/2 [HTTP2], but uses push is similar to what is described in HTTP/2 [HTTP2], but uses
different mechanisms. different mechanisms.
Each server push is identified by a unique Push ID. This Push ID is Each server push is identified by a unique Push ID. This Push ID is
used in a single PUSH_PROMISE frame (see Section 7.2.5) which carries used in one or more PUSH_PROMISE frames (see Section 7.2.5) that
the request headers, possibly included in one or more DUPLICATE_PUSH carry the request headers, then included with the push stream which
frames (see Section 7.2.8), then included with the push stream which ultimately fulfills those promises. When the same Push ID is
ultimately fulfills those promises. promised on multiple request streams, the decompressed request header
sets MUST contain the same fields in the same order, and both the
name and the value in each field MUST be exact matches.
Server push is only enabled on a connection when a client sends a Server push is only enabled on a connection when a client sends a
MAX_PUSH_ID frame (see Section 7.2.7). A server cannot use server MAX_PUSH_ID frame (see Section 7.2.7). A server cannot use server
push until it receives a MAX_PUSH_ID frame. A client sends push until it receives a MAX_PUSH_ID frame. A client sends
additional MAX_PUSH_ID frames to control the number of pushes that a additional MAX_PUSH_ID frames to control the number of pushes that a
server can promise. A server SHOULD use Push IDs sequentially, server can promise. A server SHOULD use Push IDs sequentially,
starting at 0. A client MUST treat receipt of a push stream with a starting at 0. A client MUST treat receipt of a push stream with a
Push ID that is greater than the maximum Push ID as a connection Push ID that is greater than the maximum Push ID as a connection
error of type H3_ID_ERROR. error of type H3_ID_ERROR.
The header of the request message is carried by a PUSH_PROMISE frame The header of the request message is carried by a PUSH_PROMISE frame
(see Section 7.2.5) on the request stream which generated the push. (see Section 7.2.5) on the request stream which generated the push.
Promised requests MUST conform to the requirements in Section 8.2 of Promised requests MUST conform to the requirements in Section 8.2 of
[HTTP2]. [HTTP2].
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
associated with additional client requests using a DUPLICATE_PUSH associated with additional client requests using a PUSH_PROMISE frame
frame (see Section 7.2.8). These associations do not affect the with the same Push ID on multiple request streams. These
operation of the protocol, but MAY be used by user agents when associations do not affect the operation of the protocol, but MAY be
deciding how to use pushed resources. considered by user agents when deciding how to use pushed resources.
Ordering of a PUSH_PROMISE or DUPLICATE_PUSH in relation to certain Ordering of a PUSH_PROMISE in relation to certain parts of the
parts of the response is important. The server SHOULD send response is important. The server SHOULD send PUSH_PROMISE frames
PUSH_PROMISE or DUPLICATE_PUSH frames prior to sending HEADERS or prior to sending HEADERS or DATA frames that reference the promised
DATA frames that reference the promised responses. This reduces the responses. This reduces the chance that a client requests a resource
chance that a client requests a resource that will be pushed by the that will be pushed by the server.
server.
When a server later fulfills a promise, the server push response is When a server later fulfills a promise, the server push response is
conveyed on a push stream (see Section 6.2.2). The push stream conveyed on a push stream (see Section 6.2.2). The push stream
identifies the Push ID of the promise that it fulfills, then contains identifies the Push ID of the promise that it fulfills, then contains
a response to the promised request using the same format described a response to the promised request using the same format described
for responses in Section 4.1. for responses in Section 4.1.
Due to reordering, DUPLICATE_PUSH frames or push stream data can Due to reordering, push stream data can arrive before the
arrive before the corresponding PUSH_PROMISE frame. When a client corresponding PUSH_PROMISE frame. When a client receives a new push
receives a DUPLICATE_PUSH frame for an as-yet-unknown Push ID, the stream with an as-yet-unknown Push ID, both the associated client
request headers of the push are not immediately available. The request and the pushed request headers are unknown. The client can
client can either delay generating new requests for content buffer the stream data in expectation of the matching PUSH_PROMISE.
referenced following the DUPLICATE_PUSH frame until the request The client can use stream flow control (see section 4.1 of
headers become available, or can initiate requests for discovered [QUIC-TRANSPORT]) to limit the amount of data a server may commit to
resources and cancel the requests if the requested resource is the pushed stream.
already being pushed. When a client receives a new push stream with
an as-yet-unknown Push ID, both the associated client request and the
pushed request headers are unknown. The client can buffer the stream
data in expectation of the matching PUSH_PROMISE. The client can use
stream flow control (see section 4.1 of [QUIC-TRANSPORT]) to limit
the amount of data a server may commit to the pushed stream.
If a promised server push is not needed by the client, the client If a promised server push is not needed by the client, the client
SHOULD send a CANCEL_PUSH frame. If the push stream is already open SHOULD send a CANCEL_PUSH frame. If the push stream is already open
or opens after sending the CANCEL_PUSH frame, the client can abort or opens after sending the CANCEL_PUSH frame, the client can abort
reading the stream with an error code of H3_REQUEST_CANCELLED. This reading the stream with an error code of H3_REQUEST_CANCELLED. This
asks the server not to transfer additional data and indicates that it asks the server not to transfer additional data and indicates that it
will be discarded upon receipt. will be discarded upon receipt.
5. Connection Closure 5. Connection Closure
skipping to change at page 24, line 5 skipping to change at page 27, line 5
7. HTTP Framing Layer 7. HTTP Framing Layer
HTTP frames are carried on QUIC streams, as described in Section 6. HTTP frames are carried on QUIC streams, as described in Section 6.
HTTP/3 defines three stream types: control stream, request stream, HTTP/3 defines three stream types: control stream, request stream,
and push stream. This section describes HTTP/3 frame formats and the and push stream. This section describes HTTP/3 frame formats and the
streams types on which they are permitted; see Table 1 for an streams types on which they are permitted; see Table 1 for an
overview. A comparison between HTTP/2 and HTTP/3 frames is provided overview. A comparison between HTTP/2 and HTTP/3 frames is provided
in Appendix A.2. in Appendix A.2.
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| Frame | Control Stream | Request | Push | Section | | Frame | Control Stream | Request | Push | Section |
| | | Stream | Stream | | | | | Stream | Stream | |
+================+================+=========+========+=========+ +==============+================+================+========+=========+
| DATA | No | Yes | Yes | Section | | DATA | No | Yes | Yes | Section |
| | | | | 7.2.1 | | | | | | 7.2.1 |
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| HEADERS | No | Yes | Yes | Section | | HEADERS | No | Yes | Yes | Section |
| | | | | 7.2.2 | | | | | | 7.2.2 |
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| CANCEL_PUSH | Yes | No | No | Section | | CANCEL_PUSH | Yes | No | No | Section |
| | | | | 7.2.3 | | | | | | 7.2.3 |
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| SETTINGS | Yes (1) | No | No | Section | | SETTINGS | Yes (1) | No | No | Section |
| | | | | 7.2.4 | | | | | | 7.2.4 |
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| PUSH_PROMISE | No | Yes | No | Section | | PUSH_PROMISE | No | Yes | No | Section |
| | | | | 7.2.5 | | | | | | 7.2.5 |
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| GOAWAY | Yes | No | No | Section | | GOAWAY | Yes | No | No | Section |
| | | | | 7.2.6 | | | | | | 7.2.6 |
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| MAX_PUSH_ID | Yes | No | No | Section | | MAX_PUSH_ID | Yes | No | No | Section |
| | | | | 7.2.7 | | | | | | 7.2.7 |
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| DUPLICATE_PUSH | No | Yes | No | Section | | Reserved | Yes | Yes | Yes | Section |
| | | | | 7.2.8 | | | | | | 7.2.8 |
+----------------+----------------+---------+--------+---------+ +--------------+----------------+----------------+--------+---------+
| Reserved | Yes | Yes | Yes | Section |
| | | | | 7.2.9 |
+----------------+----------------+---------+--------+---------+
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 Certain frames can only occur as the first frame of a particular
stream type; these are indicated in Table 1 with a (1). Specific stream type; these are indicated in Table 1 with a (1). Specific
guidance is provided in the relevant section. guidance 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
skipping to change at page 30, line 43 skipping to change at page 33, line 43
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Block (*) ... | Header Block (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: PUSH_PROMISE Frame Payload Figure 8: PUSH_PROMISE Frame Payload
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
operation. A Push ID is used in push stream headers operation. A Push ID is used in push stream headers
(Section 4.4), CANCEL_PUSH frames (Section 7.2.3), and (Section 4.4), CANCEL_PUSH frames (Section 7.2.3).
DUPLICATE_PUSH frames (Section 7.2.8).
Header Block: QPACK-compressed request header fields for the Header Block: QPACK-compressed request header fields for the
promised response. See [QPACK] for more details. promised response. See [QPACK] for more details.
A server MUST NOT use a Push ID that is larger than the client has A server MUST NOT use a Push ID that is larger than the client has
provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat provided in a MAX_PUSH_ID frame (Section 7.2.7). A client MUST treat
receipt of a PUSH_PROMISE frame that contains a larger Push ID than receipt of a PUSH_PROMISE frame that contains a larger Push ID than
the client has advertised as a connection error of H3_ID_ERROR. the client has advertised as a connection error of H3_ID_ERROR.
A server MUST NOT use the same Push ID in multiple PUSH_PROMISE A server MAY use the same Push ID in multiple PUSH_PROMISE frames.
frames. A client MUST treat receipt of a Push ID which has already If so, the decompressed request header sets MUST contain the same
been promised as a connection error of type H3_ID_ERROR. fields in the same order, and both the name and and value in each
field MUST be exact matches. Clients SHOULD compare the request
header sets for resources promised multiple times. If a client
receives a Push ID that has already been promised and detects a
mismatch, it MUST respond with a connection error of type
H3_GENERAL_PROTOCOL_ERROR. If the decompressed header sets match
exactly, the client SHOULD associate the pushed content with each
stream on which a PUSH_PROMISE was received.
Allowing duplicate references to the same Push ID is primarily to
reduce duplication caused by concurrent requests. A server SHOULD
avoid reusing a Push ID over a long period. Clients are likely to
consume server push responses and not retain them for reuse over
time. Clients that see a PUSH_PROMISE that uses a Push ID that they
have already consumed and discarded are forced to ignore the
PUSH_PROMISE.
If a PUSH_PROMISE frame is received on the control stream, the client If a PUSH_PROMISE frame is received on the control stream, the client
MUST respond with a connection error (Section 8) of type MUST respond with a connection error (Section 8) of type
H3_FRAME_UNEXPECTED. H3_FRAME_UNEXPECTED.
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. H3_FRAME_UNEXPECTED.
See Section 4.4 for a description of the overall server push See Section 4.4 for a description of the overall server push
skipping to change at page 32, line 45 skipping to change at page 36, line 9
Figure 10: MAX_PUSH_ID Frame Payload Figure 10: MAX_PUSH_ID Frame Payload
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 7.2.5). A MAX_PUSH_ID frame cannot reduce the maximum (see Section 7.2.5). A MAX_PUSH_ID frame cannot reduce the maximum
Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than
previously received MUST be treated as a connection error of type previously received MUST be treated as a connection error of type
H3_ID_ERROR. H3_ID_ERROR.
7.2.8. DUPLICATE_PUSH 7.2.8. Reserved Frame Types
The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate
that an existing pushed resource is related to multiple client
requests.
The DUPLICATE_PUSH frame is always sent on a request stream. Receipt
of a DUPLICATE_PUSH frame on any other stream MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED.
A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat
the receipt of a DUPLICATE_PUSH frame as a connection error of type
H3_FRAME_UNEXPECTED.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: DUPLICATE_PUSH Frame Payload
The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has
previously promised (see Section 7.2.5), though that promise might
not be received before this frame. A server MUST NOT use a Push ID
that is larger than the client has provided in a MAX_PUSH_ID frame
(Section 7.2.7). A client MUST treat receipt of a DUPLICATE_PUSH
that contains a larger Push ID than the client has advertised as a
connection error of type H3_ID_ERROR.
This frame allows the server to use the same server push in response
to multiple concurrent requests. Referencing the same server push
ensures that a promise can be made in relation to every response in
which server push might be needed without duplicating request headers
or pushed responses.
Allowing duplicate references to the same Push ID is primarily to
reduce duplication caused by concurrent requests. A server SHOULD
avoid reusing a Push ID over a long period. Clients are likely to
consume server push responses and not retain them for reuse over
time. Clients that see a DUPLICATE_PUSH that uses a Push ID that
they have since consumed and discarded are forced to ignore the
DUPLICATE_PUSH.
7.2.9. Reserved Frame Types
Frame types of the format "0x1f * N + 0x21" for integer values of N Frame types of the format "0x1f * N + 0x21" for integer values of N
are reserved to exercise the requirement that unknown types be are reserved to exercise the requirement that unknown types be
ignored (Section 9). These frames have no semantics, and can be sent ignored (Section 9). These frames have no semantics, and can be sent
on any open stream when application-layer padding is desired. They on any open stream when application-layer padding is desired. They
MAY also be sent on connections where no data is currently being MAY also be sent on connections where no data is currently being
transferred. Endpoints MUST NOT consider these frames to have any transferred. Endpoints MUST NOT consider these frames to have any
meaning upon receipt. meaning upon receipt.
The payload and length of the frames are selected in any manner the The payload and length of the frames are selected in any manner the
skipping to change at page 37, line 10 skipping to change at page 39, line 21
apply in addition to those listed here. apply in addition to those listed here.
When HTTP Alternative Services is used for discovery for HTTP/3 When HTTP Alternative Services is used for discovery for HTTP/3
endpoints, the security considerations of [ALTSVC] also apply. endpoints, the security considerations of [ALTSVC] also apply.
10.1. Traffic Analysis 10.1. Traffic Analysis
Where HTTP/2 employs PADDING frames and Padding fields in other Where HTTP/2 employs PADDING frames and Padding fields in other
frames to make a connection more resistant to traffic analysis, frames to make a connection more resistant to traffic analysis,
HTTP/3 can either rely on transport-layer padding or employ the HTTP/3 can either rely on transport-layer padding or employ the
reserved frame and stream types discussed in Section 7.2.9 and reserved frame and stream types discussed in Section 7.2.8 and
Section 6.2.3. These methods of padding produce different results in Section 6.2.3. These methods of padding produce different results in
terms of the granularity of padding, the effect of packet loss and terms of the granularity of padding, how padding is arranged in
recovery, and how an implementation might control padding. relation to the information that is being protected, whether padding
is applied in the case of packet loss, and how an implementation
might control padding.
10.2. Frame Parsing 10.2. Frame Parsing
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.3. Early Data 10.3. Early Data
skipping to change at page 39, line 5 skipping to change at page 41, line 16
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.
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 | 0x0 | Section 7.2.1 |
+----------------+-------+---------------+ +--------------+-------+---------------+
| HEADERS | 0x1 | Section 7.2.2 | | HEADERS | 0x1 | Section 7.2.2 |
+----------------+-------+---------------+ +--------------+-------+---------------+
| Reserved | 0x2 | N/A | | Reserved | 0x2 | N/A |
+----------------+-------+---------------+ +--------------+-------+---------------+
| CANCEL_PUSH | 0x3 | Section 7.2.3 | | CANCEL_PUSH | 0x3 | Section 7.2.3 |
+----------------+-------+---------------+ +--------------+-------+---------------+
| SETTINGS | 0x4 | Section 7.2.4 | | SETTINGS | 0x4 | Section 7.2.4 |
+----------------+-------+---------------+ +--------------+-------+---------------+
| PUSH_PROMISE | 0x5 | Section 7.2.5 | | PUSH_PROMISE | 0x5 | Section 7.2.5 |
+----------------+-------+---------------+ +--------------+-------+---------------+
| Reserved | 0x6 | N/A | | Reserved | 0x6 | N/A |
+----------------+-------+---------------+ +--------------+-------+---------------+
| GOAWAY | 0x7 | Section 7.2.6 | | GOAWAY | 0x7 | Section 7.2.6 |
+----------------+-------+---------------+ +--------------+-------+---------------+
| Reserved | 0x8 | N/A | | Reserved | 0x8 | N/A |
+----------------+-------+---------------+ +--------------+-------+---------------+
| Reserved | 0x9 | N/A | | Reserved | 0x9 | N/A |
+----------------+-------+---------------+ +--------------+-------+---------------+
| MAX_PUSH_ID | 0xD | Section 7.2.7 | | MAX_PUSH_ID | 0xD | Section 7.2.7 |
+----------------+-------+---------------+ +--------------+-------+---------------+
| DUPLICATE_PUSH | 0xE | Section 7.2.8 |
+----------------+-------+---------------+
Table 2: Initial HTTP/3 Frame Types Table 2: Initial HTTP/3 Frame Types
Additionally, each code of the format "0x1f * N + 0x21" for integer Additionally, each code of the format "0x1f * N + 0x21" for integer
values of N (that is, "0x21", "0x40", ..., through values of N (that is, "0x21", "0x40", ..., through
"0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA. "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
11.2.2. Settings Parameters 11.2.2. Settings Parameters
This document establishes a registry for HTTP/3 settings. The This document establishes a registry for HTTP/3 settings. The
skipping to change at page 44, line 17 skipping to change at page 46, line 21
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>.
[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>.
[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", Work in Progress, Header Compression for HTTP over QUIC", Work in Progress,
Internet-Draft, draft-ietf-quic-qpack-12, 22 January 2020, Internet-Draft, draft-ietf-quic-qpack-13, 21 February
<https://tools.ietf.org/html/draft-ietf-quic-qpack-12>. 2020,
<https://tools.ietf.org/html/draft-ietf-quic-qpack-13>.
[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", Work in Progress, Multiplexed and Secure Transport", Work in Progress,
Internet-Draft, draft-ietf-quic-transport-25, 22 January Internet-Draft, draft-ietf-quic-transport-26, 21 February
2020, <https://tools.ietf.org/html/draft-ietf-quic- 2020, <https://tools.ietf.org/html/draft-ietf-quic-
transport-25>. transport-26>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[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>.
skipping to change at page 51, line 40 skipping to change at page 53, line 40
H3_1_1_REQUIRED (0xd): H3_VERSION_FALLBACK in Section 8.1. H3_1_1_REQUIRED (0xd): 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.
Appendix B. Change Log Appendix B. Change Log
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
publication of a final version of this document. publication of a final version of this document.
B.1. Since draft-ietf-quic-http-24 B.1. Since draft-ietf-quic-http-25
* Require QUICv1 for HTTP/3 (#3117, #3323)
* Remove DUPLICATE_PUSH and allow duplicate PUSH_PROMISE (#3275,
#3309)
* Clarify the definition of "malformed" (#3352, #3345)
B.2. Since draft-ietf-quic-http-24
* Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended * Removed H3_EARLY_RESPONSE error code; H3_NO_ERROR is recommended
instead (#3130,#3208) instead (#3130,#3208)
* Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331) * Unknown error codes are equivalent to H3_NO_ERROR (#3276,#3331)
* Some error codes are reserved for greasing (#3325,#3360) * Some error codes are reserved for greasing (#3325,#3360)
B.2. Since draft-ietf-quic-http-23 B.3. Since draft-ietf-quic-http-23
* Removed "quic" Alt-Svc parameter (#3061,#3118) * Removed "quic" Alt-Svc parameter (#3061,#3118)
* Clients need not persist unknown settings for use in 0-RTT * Clients need not persist unknown settings for use in 0-RTT
(#3110,#3113) (#3110,#3113)
* Clarify error cases around CANCEL_PUSH (#2819,#3083) * Clarify error cases around CANCEL_PUSH (#2819,#3083)
B.3. Since draft-ietf-quic-http-22 B.4. Since draft-ietf-quic-http-22
* Removed priority signaling (#2922,#2924) * Removed priority signaling (#2922,#2924)
* Further changes to error codes (#2662,#2551): * Further changes to error codes (#2662,#2551):
- Error codes renumbered - Error codes renumbered
- HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR, - HTTP_MALFORMED_FRAME replaced by HTTP_FRAME_ERROR,
HTTP_ID_ERROR, and others HTTP_ID_ERROR, and others
skipping to change at page 53, line 5 skipping to change at page 55, line 11
* Clarify that Upgrade and the 101 status code are prohibited * Clarify that Upgrade and the 101 status code are prohibited
(#2898,#2889) (#2898,#2889)
* Clarify that frame types reserved for greasing can occur on any * Clarify that frame types reserved for greasing can occur on any
stream, but frame types reserved due to HTTP/2 correspondence are stream, but frame types reserved due to HTTP/2 correspondence are
prohibited (#2997,#2692,#2693) prohibited (#2997,#2692,#2693)
* Unknown error codes cannot be treated as errors (#2998,#2816) * Unknown error codes cannot be treated as errors (#2998,#2816)
B.4. Since draft-ietf-quic-http-21 B.5. Since draft-ietf-quic-http-21
No changes No changes
B.5. Since draft-ietf-quic-http-20 B.6. Since draft-ietf-quic-http-20
* Prohibit closing the control stream (#2509, #2666) * Prohibit closing the control stream (#2509, #2666)
* Change default priority to use an orphan node (#2502, #2690) * Change default priority to use an orphan node (#2502, #2690)
* Exclusive priorities are restored (#2754, #2781) * Exclusive priorities are restored (#2754, #2781)
* Restrict use of frames when using CONNECT (#2229, #2702) * Restrict use of frames when using CONNECT (#2229, #2702)
* Close and maybe reset streams if a connection error occurs for * Close and maybe reset streams if a connection error occurs for
skipping to change at page 53, line 47 skipping to change at page 56, line 4
- Specified error code for HEADERS on control stream (#2708) - Specified error code for HEADERS on control stream (#2708)
- Specified error code for servers receiving PUSH_PROMISE (#2709) - Specified error code for servers receiving PUSH_PROMISE (#2709)
- Specified error code for receiving DATA before HEADERS (#2715) - Specified error code for receiving DATA before HEADERS (#2715)
- Describe malformed messages and their handling (#2410, #2764) - Describe malformed messages and their handling (#2410, #2764)
- Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813) - Remove HTTP_PUSH_ALREADY_IN_CACHE error (#2812, #2813)
- Refactor Push ID related errors (#2818, #2820) - Refactor Push ID related errors (#2818, #2820)
- Rationalize HTTP/3 stream creation errors (#2821, #2822) - Rationalize HTTP/3 stream creation errors (#2821, #2822)
B.6. Since draft-ietf-quic-http-19 B.7. Since draft-ietf-quic-http-19
* SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530) * SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530)
* Non-zero bits in the Empty field of the PRIORITY frame MAY be * Non-zero bits in the Empty field of the PRIORITY frame MAY be
treated as an error (#2501) treated as an error (#2501)
B.7. Since draft-ietf-quic-http-18 B.8. Since draft-ietf-quic-http-18
* Resetting streams following a GOAWAY is recommended, but not * Resetting streams following a GOAWAY is recommended, but not
required (#2256,#2457) required (#2256,#2457)
* Use variable-length integers throughout (#2437,#2233,#2253,#2275) * Use variable-length integers throughout (#2437,#2233,#2253,#2275)
- Variable-length frame types, stream types, and settings - Variable-length frame types, stream types, and settings
identifiers identifiers
- Renumbered stream type assignments - Renumbered stream type assignments
- Modified associated reserved values - Modified associated reserved values
* Frame layout switched from Length-Type-Value to Type-Length-Value * Frame layout switched from Length-Type-Value to Type-Length-Value
(#2395,#2235) (#2395,#2235)
* Specified error code for servers receiving DUPLICATE_PUSH (#2497) * Specified error code for servers receiving DUPLICATE_PUSH (#2497)
* Use connection error for invalid PRIORITY (#2507, #2508) * Use connection error for invalid PRIORITY (#2507, #2508)
B.8. Since draft-ietf-quic-http-17 B.9. Since draft-ietf-quic-http-17
* HTTP_REQUEST_REJECTED is used to indicate a request can be retried * HTTP_REQUEST_REJECTED is used to indicate a request can be retried
(#2106, #2325) (#2106, #2325)
* Changed error code for GOAWAY on the wrong stream (#2231, #2343) * Changed error code for GOAWAY on the wrong stream (#2231, #2343)
B.9. Since draft-ietf-quic-http-16 B.10. Since draft-ietf-quic-http-16
* Rename "HTTP/QUIC" to "HTTP/3" (#1973) * Rename "HTTP/QUIC" to "HTTP/3" (#1973)
* Changes to PRIORITY frame (#1865, #2075) * Changes to PRIORITY frame (#1865, #2075)
- Permitted as first frame of request streams - Permitted as first frame of request streams
- Remove exclusive reprioritization - Remove exclusive reprioritization
- Changes to Prioritized Element Type bits - Changes to Prioritized Element Type bits
* Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE * Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE
(#2072) (#2072)
* Set defaults for settings, allow request before receiving SETTINGS * Set defaults for settings, allow request before receiving SETTINGS
(#1809, #1846, #2038) (#1809, #1846, #2038)
* Clarify message processing rules for streams that aren't closed * Clarify message processing rules for streams that aren't closed
(#1972, #2003) (#1972, #2003)
* Removed reservation of error code 0 and moved HTTP_NO_ERROR to * Removed reservation of error code 0 and moved HTTP_NO_ERROR to
this value (#1922) this value (#1922)
* Removed prohibition of zero-length DATA frames (#2098) * Removed prohibition of zero-length DATA frames (#2098)
B.10. Since draft-ietf-quic-http-15 B.11. Since draft-ietf-quic-http-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.11. Since draft-ietf-quic-http-14 B.12. Since draft-ietf-quic-http-14
* Recommend sensible values for QUIC transport parameters * Recommend sensible values for QUIC transport parameters
(#1720,#1806) (#1720,#1806)
* Define error for missing SETTINGS frame (#1697,#1808) * Define error for missing SETTINGS frame (#1697,#1808)
* Setting values are variable-length integers (#1556,#1807) and do * Setting values are variable-length integers (#1556,#1807) and do
not have separate maximum values (#1820) not have separate maximum values (#1820)
* Expanded discussion of connection closure (#1599,#1717,#1712) * Expanded discussion of connection closure (#1599,#1717,#1712)
* HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) * HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)
B.12. Since draft-ietf-quic-http-13 B.13. Since draft-ietf-quic-http-13
* Reserved some frame types for grease (#1333, #1446) * Reserved some frame types for grease (#1333, #1446)
* Unknown unidirectional stream types are tolerated, not errors; * Unknown unidirectional stream types are tolerated, not errors;
some reserved for grease (#1490, #1525) some reserved for grease (#1490, #1525)
* Require settings to be remembered for 0-RTT, prohibit reductions * Require settings to be remembered for 0-RTT, prohibit reductions
(#1541, #1641) (#1541, #1641)
* Specify behavior for truncated requests (#1596, #1643) * Specify behavior for truncated requests (#1596, #1643)
B.13. Since draft-ietf-quic-http-12 B.14. Since draft-ietf-quic-http-12
* TLS SNI extension isn't mandatory if an alternative method is used * TLS SNI extension isn't mandatory if an alternative method is used
(#1459, #1462, #1466) (#1459, #1462, #1466)
* Removed flags from HTTP/3 frames (#1388, #1398) * Removed flags from HTTP/3 frames (#1388, #1398)
* Reserved frame types and settings for use in preserving * Reserved frame types and settings for use in preserving
extensibility (#1333, #1446) extensibility (#1333, #1446)
* Added general error code (#1391, #1397) * Added general error code (#1391, #1397)
* Unidirectional streams carry a type byte and are extensible * Unidirectional streams carry a type byte and are extensible
(#910,#1359) (#910,#1359)
* Priority mechanism now uses explicit placeholders to enable * Priority mechanism now uses explicit placeholders to enable
persistent structure in the tree (#441,#1421,#1422) persistent structure in the tree (#441,#1421,#1422)
B.14. Since draft-ietf-quic-http-11 B.15. Since draft-ietf-quic-http-11
* Moved QPACK table updates and acknowledgments to dedicated streams * Moved QPACK table updates and acknowledgments to dedicated streams
(#1121, #1122, #1238) (#1121, #1122, #1238)
B.15. Since draft-ietf-quic-http-10 B.16. Since draft-ietf-quic-http-10
* Settings need to be remembered when attempting and accepting 0-RTT * Settings need to be remembered when attempting and accepting 0-RTT
(#1157, #1207) (#1157, #1207)
B.16. Since draft-ietf-quic-http-09 B.17. Since draft-ietf-quic-http-09
* Selected QCRAM for header compression (#228, #1117) * Selected QCRAM for header compression (#228, #1117)
* The server_name TLS extension is now mandatory (#296, #495) * The server_name TLS extension is now mandatory (#296, #495)
* Specified handling of unsupported versions in Alt-Svc (#1093, * Specified handling of unsupported versions in Alt-Svc (#1093,
#1097) #1097)
B.17. Since draft-ietf-quic-http-08 B.18. Since draft-ietf-quic-http-08
* Clarified connection coalescing rules (#940, #1024) * Clarified connection coalescing rules (#940, #1024)
B.18. Since draft-ietf-quic-http-07 B.19. Since draft-ietf-quic-http-07
* Changes for integer encodings in QUIC (#595,#905) * Changes for integer encodings in QUIC (#595,#905)
* Use unidirectional streams as appropriate (#515, #240, #281, #886) * Use unidirectional streams as appropriate (#515, #240, #281, #886)
* Improvement to the description of GOAWAY (#604, #898) * Improvement to the description of GOAWAY (#604, #898)
* Improve description of server push usage (#947, #950, #957) * Improve description of server push usage (#947, #950, #957)
B.19. Since draft-ietf-quic-http-06 B.20. Since draft-ietf-quic-http-06
* Track changes in QUIC error code usage (#485) * Track changes in QUIC error code usage (#485)
B.20. Since draft-ietf-quic-http-05 B.21. Since draft-ietf-quic-http-05
* Made push ID sequential, add MAX_PUSH_ID, remove * Made push ID sequential, add MAX_PUSH_ID, remove
SETTINGS_ENABLE_PUSH (#709) SETTINGS_ENABLE_PUSH (#709)
* Guidance about keep-alive and QUIC PINGs (#729) * Guidance about keep-alive and QUIC PINGs (#729)
* Expanded text on GOAWAY and cancellation (#757) * Expanded text on GOAWAY and cancellation (#757)
B.21. Since draft-ietf-quic-http-04 B.22. Since draft-ietf-quic-http-04
* Cite RFC 5234 (#404) * Cite RFC 5234 (#404)
* Return to a single stream per request (#245,#557) * Return to a single stream per request (#245,#557)
* Use separate frame type and settings registries from HTTP/2 (#81) * Use separate frame type and settings registries from HTTP/2 (#81)
* SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) * SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)
* Restored GOAWAY (#696) * Restored GOAWAY (#696)
* Identify server push using Push ID rather than a stream ID * Identify server push using Push ID rather than a stream ID
(#702,#281) (#702,#281)
* DATA frames cannot be empty (#700) * DATA frames cannot be empty (#700)
B.22. Since draft-ietf-quic-http-03 B.23. Since draft-ietf-quic-http-03
None. None.
B.23. Since draft-ietf-quic-http-02 B.24. Since draft-ietf-quic-http-02
* Track changes in transport draft * Track changes in transport draft
B.24. Since draft-ietf-quic-http-01 B.25. Since draft-ietf-quic-http-01
* SETTINGS changes (#181): * SETTINGS changes (#181):
- SETTINGS can be sent only once at the start of a connection; no - SETTINGS can be sent only once at the start of a connection; no
changes thereafter changes thereafter
- SETTINGS_ACK removed - SETTINGS_ACK removed
- Settings can only occur in the SETTINGS frame a single time - Settings can only occur in the SETTINGS frame a single time
- Boolean format updated - Boolean format updated
* Alt-Svc parameter changed from "v" to "quic"; format updated * Alt-Svc parameter changed from "v" to "quic"; format updated
(#229) (#229)
* Closing the connection control stream or any message control * Closing the connection control stream or any message control
stream is a fatal error (#176) stream is a fatal error (#176)
* HPACK Sequence counter can wrap (#173) * HPACK Sequence counter can wrap (#173)
* 0-RTT guidance added * 0-RTT guidance added
* Guide to differences from HTTP/2 and porting HTTP/2 extensions * Guide to differences from HTTP/2 and porting HTTP/2 extensions
added (#127,#242) added (#127,#242)
B.25. Since draft-ietf-quic-http-00 B.26. Since draft-ietf-quic-http-00
* Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) * Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
* Changed from using HTTP/2 framing within Stream 3 to new framing * 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)
* Adopted SETTINGS format from draft-bishop-httpbis-extended- * Adopted SETTINGS format from draft-bishop-httpbis-extended-
settings-01 settings-01
* Reworked SETTINGS_ACK to account for indeterminate inter-stream * Reworked SETTINGS_ACK to account for indeterminate inter-stream
order (#75) order (#75)
* Described CONNECT pseudo-method (#95) * Described CONNECT pseudo-method (#95)
* Updated ALPN token and Alt-Svc guidance (#13,#87) * Updated ALPN token and Alt-Svc guidance (#13,#87)
* Application-layer-defined error codes (#19,#74) * Application-layer-defined error codes (#19,#74)
B.26. Since draft-shade-quic-http2-mapping-00 B.27. Since draft-shade-quic-http2-mapping-00
* Adopted as base for draft-ietf-quic-http * Adopted as base for draft-ietf-quic-http
* Updated authors/editors list * Updated authors/editors list
Acknowledgements Acknowledgements
The original authors of this specification were Robbie Shade and Mike The original authors of this specification were Robbie Shade and Mike
Warres. Warres.
 End of changes. 64 change blocks. 
294 lines changed or deleted 396 lines changed or added

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