draft-ietf-quic-http-23.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 September 12, 2019 Intended status: Standards Track October 19, 2019
Expires: March 15, 2020 Expires: April 21, 2020
Hypertext Transfer Protocol Version 3 (HTTP/3) Hypertext Transfer Protocol Version 3 (HTTP/3)
draft-ietf-quic-http-23 draft-ietf-quic-http-latest
Abstract Abstract
The QUIC transport protocol has several features that are desirable The QUIC transport protocol has several features that are desirable
in a transport for HTTP, such as stream multiplexing, per-stream flow in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC. This document also describes a mapping of HTTP semantics over QUIC. This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to HTTP/3. how HTTP/2 extensions can be ported to HTTP/3.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
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 March 15, 2020. This Internet-Draft will expire on April 21, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 4 1.1. Prior versions of HTTP . . . . . . . . . . . . . . . . . 4
1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 5 1.2. Delegation to QUIC . . . . . . . . . . . . . . . . . . . 4
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 . . . . . . . . . . . . . . . 6 2.2. Conventions and Terminology . . . . . . . . . . . . . . . 6
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 . . . . . . . . . . . . . 8
3.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 9 3.3. Connection Establishment . . . . . . . . . . . . . . . . 9
3.3. Connection Establishment . . . . . . . . . . . . . . . . 10 3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 9
3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 10 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 10
4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 11 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 10
4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 11 4.1.1. Header Formatting and Compression . . . . . . . . . . 11
4.1.1. Header Formatting and Compression . . . . . . . . . . 12
4.1.2. Request Cancellation and Rejection . . . . . . . . . 13 4.1.2. Request Cancellation and Rejection . . . . . . . . . 13
4.1.3. Malformed Requests and Responses . . . . . . . . . . 14 4.1.3. Malformed Requests and Responses . . . . . . . . . . 13
4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 15 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 14
4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 16 4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 15
4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 16 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 15
5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 17 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 17
5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 18 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 17
5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 18 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 17
5.3. Immediate Application Closure . . . . . . . . . . . . . . 19 5.3. Immediate Application Closure . . . . . . . . . . . . . . 19
5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 20 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 19
6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 20 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 19
6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 20 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 20
6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 21 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 20
6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 22 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 21
6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 23 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 22
6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 23 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 22
7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 23
7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 24
7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 24
7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 25 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 25
7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 26 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 26 7.2.3. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 25
7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 27 7.2.4. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 26
7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 30 7.2.5. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 29
7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 31 7.2.6. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 30
7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 31 7.2.7. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 31
7.2.8. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 32 7.2.8. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 32
7.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 33 7.2.9. Reserved Frame Types . . . . . . . . . . . . . . . . 33
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 34 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 33
9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 35 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 35
10. Security Considerations . . . . . . . . . . . . . . . . . . . 36 10. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 36 10.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 36
10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 36 10.2. Frame Parsing . . . . . . . . . . . . . . . . . . . . . 36
10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 36 10.3. Early Data . . . . . . . . . . . . . . . . . . . . . . . 36
10.4. Migration . . . . . . . . . . . . . . . . . . . . . . . 37 10.4. Migration . . . . . . . . . . . . . . . . . . . . . . . 36
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
11.1. Registration of HTTP/3 Identification String . . . . . . 37 11.1. Registration of HTTP/3 Identification String . . . . . . 36
11.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 37 11.2. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37
11.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37 11.3. Settings Parameters . . . . . . . . . . . . . . . . . . 38
11.4. Settings Parameters . . . . . . . . . . . . . . . . . . 39 11.4. Error Codes . . . . . . . . . . . . . . . . . . . . . . 39
11.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 40 11.5. Stream Types . . . . . . . . . . . . . . . . . . . . . . 41
11.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 42 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 12.1. Normative References . . . . . . . . . . . . . . . . . . 42
12.1. Normative References . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 44 12.2. Informative References . . . . . . . . . . . . . . . . . 44
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45
A.2.1. Prioritization Differences . . . . . . . . . . . . . 46 A.2.1. Prioritization Differences . . . . . . . . . . . . . 46
A.2.2. Header Compression Differences . . . . . . . . . . . 46 A.2.2. Header Compression Differences . . . . . . . . . . . 46
A.2.3. Guidance for New Frame Type Definitions . . . . . . . 47 A.2.3. Guidance for New Frame Type Definitions . . . . . . . 46
A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 47 A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 47
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48
A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50
B.1. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 50 B.1. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 50
B.2. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 51 B.2. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 51
B.3. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 51 B.3. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 51
B.4. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 52 B.4. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 52
B.5. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 52 B.5. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 52
B.6. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 53 B.6. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 52
B.7. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 53 B.7. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 52
B.8. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 53 B.8. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 53
B.9. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 53 B.9. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 53
B.10. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 54 B.10. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 53
B.11. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 54 B.11. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 54
B.12. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 54 B.12. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 54
B.13. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 54 B.13. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 54
B.14. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 54 B.14. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 54
B.15. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 55 B.15. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 54
B.16. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 55 B.16. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 54
B.17. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 55 B.17. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 55
B.18. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 55 B.18. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 55
B.19. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 55 B.19. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 55
B.20. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 56 B.20. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 55
B.21. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 56 B.21. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 55
B.22. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 56 B.22. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 55
B.23. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 56 B.23. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 56
B.24. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 57 B.24. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 56
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 57 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 56
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 57
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 9, line 15 skipping to change at page 9, line 13
described in this document. described in this document.
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.2.1. QUIC Version Hints
This document defines the "quic" parameter for Alt-Svc, which MAY be
used to provide version-negotiation hints to HTTP/3 clients. QUIC
versions are four-byte sequences with no additional constraints on
format. Leading zeros SHOULD be omitted for brevity.
Syntax:
quic = DQUOTE version-number [ "," version-number ] * DQUOTE
version-number = 1*8HEXDIG; hex-encoded QUIC version
Where multiple versions are listed, the order of the values reflects
the server's preference (with the first value being the most
preferred version). Reserved versions MAY be listed, but unreserved
versions which are not supported by the alternative SHOULD NOT be
present in the list. Origins MAY omit supported versions for any
reason.
Clients MUST ignore any included versions which they do not support.
The "quic" parameter MUST NOT occur more than once; clients SHOULD
process only the first occurrence.
For example, suppose a server supported both version 0x00000001 and
the version rendered in ASCII as "Q034". If it also opted to include
the reserved version (from Section 15 of [QUIC-TRANSPORT])
0x1abadaba, it could specify the following header field:
Alt-Svc: h3=":49288";quic="1,1abadaba,51303334"
A client acting on this header field would drop the reserved version
(not supported), then attempt to connect to the alternative using the
first version in the list which it does support, if any.
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 as the underlying transport. The QUIC version
being used MUST use TLS version 1.3 or greater as its handshake being used MUST use TLS version 1.3 or greater as its handshake
protocol. HTTP/3 clients MUST indicate the target domain name during protocol. HTTP/3 clients MUST indicate the target domain name during
the TLS handshake. This may be done using the Server Name Indication the TLS handshake. This may be done using the Server Name Indication
(SNI) [RFC6066] extension to TLS or using some other mechanism. (SNI) [RFC6066] extension to TLS or using some other mechanism.
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
skipping to change at page 13, line 11 skipping to change at page 12, line 20
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).
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. These pseudo-
header fields are defined in Section 8.1.2.3 and 8.1.2.4 of [HTTP2]. 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 [HTTP2].
The restrictions on the use of pseudo-header fields in The restrictions on the use of pseudo-header fields in Section 8.1.2
Section 8.1.2.1 of [HTTP2] also apply to HTTP/3. of [HTTP2] also apply to HTTP/3. Messages which are considered
malformed under these restrictions are handled as described in
Section 4.1.3.
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
skipping to change at page 21, line 29 skipping to change at page 20, line 41
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Type (i) ... | Stream Type (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Unidirectional Stream Header Figure 1: Unidirectional Stream Header
Some stream types are reserved (Section 6.2.3). Two stream types are Some stream types are reserved (Section 6.2.3). Two stream types are
defined in this document: control streams (Section 6.2.1) and push defined in this document: control streams (Section 6.2.1) and push
streams (Section 6.2.2). Other stream types can be defined by streams (Section 6.2.2). [QPACK] defines two additional stream
extensions to HTTP/3; see Section 9 for more details. types. Other stream types can be defined by extensions to HTTP/3;
see Section 9 for more details.
The performance of HTTP/3 connections in the early phase of their The performance of HTTP/3 connections in the early phase of their
lifetime is sensitive to the creation and exchange of data on lifetime is sensitive to the creation and exchange of data on
unidirectional streams. Endpoints that excessively restrict the unidirectional streams. Endpoints that excessively restrict the
number of streams or the flow control window of these streams will number of streams or the flow control window of these streams will
increase the chance that the remote peer reaches the limit early and increase the chance that the remote peer reaches the limit early and
becomes blocked. In particular, implementations should consider that becomes blocked. In particular, implementations should consider that
remote peers may wish to exercise reserved stream behavior remote peers may wish to exercise reserved stream behavior
(Section 6.2.3) with some of the unidirectional streams they are (Section 6.2.3) with some of the unidirectional streams they are
permitted to use. To avoid blocking, the transport parameters sent permitted to use. To avoid blocking, the transport parameters sent
skipping to change at page 24, line 14 skipping to change at page 23, line 19
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 | Request | Push | Section | | Frame | Control | Request | Push | Section |
| | Stream | Stream | Stream | | | | Stream | Stream | Stream | |
+----------------+---------+----------+---------+-------------------+ +----------------+------------+------------+-----------+------------+
| DATA | No | Yes | Yes | Section 7.2.1 | | DATA | No | Yes | Yes | Section 7. |
| | | | | | | | | | | 2.1 |
| HEADERS | No | Yes | Yes | Section 7.2.2 | | | | | | |
| | | | | | | HEADERS | No | Yes | Yes | Section 7. |
| CANCEL_PUSH | Yes | No | No | Section 7.2.3 | | | | | | 2.2 |
| | | | | | | | | | | |
| SETTINGS | Yes (1) | No | No | Section 7.2.4 | | CANCEL_PUSH | Yes | No | No | Section 7. |
| | | | | | | | | | | 2.3 |
| PUSH_PROMISE | No | Yes | No | Section 7.2.5 | | | | | | |
| | | | | | | SETTINGS | Yes (1) | No | No | Section 7. |
| GOAWAY | Yes | No | No | Section 7.2.6 | | | | | | 2.4 |
| | | | | | | | | | | |
| MAX_PUSH_ID | Yes | No | No | Section 7.2.7 | | PUSH_PROMISE | No | Yes | No | Section 7. |
| | | | | | | | | | | 2.5 |
| DUPLICATE_PUSH | No | Yes | No | Section 7.2.8 | | | | | | |
| | | | | | | GOAWAY | Yes | No | No | Section 7. |
| Reserved | Yes | Yes | Yes | {{frame-reserved} | | | | | | 2.6 |
+----------------+---------+----------+---------+-------------------+ | | | | | |
| MAX_PUSH_ID | Yes | No | No | Section 7. |
| | | | | 2.7 |
| | | | | |
| DUPLICATE_PUSH | No | Yes | No | Section 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.
skipping to change at page 26, line 38 skipping to change at page 25, line 50
respond with a connection error (Section 8) of type respond with a connection error (Section 8) of type
HTTP_FRAME_UNEXPECTED. HTTP_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=0x3) is used to request cancellation of a
server push prior to the push stream being received. The CANCEL_PUSH server push prior to the push stream being received. The CANCEL_PUSH
frame identifies a server push by Push ID (see Section 7.2.5), frame identifies a server push by Push ID (see Section 7.2.5),
encoded as a variable-length integer. encoded as a variable-length integer.
When a server receives this frame, it aborts sending the response for When a client sends CANCEL_PUSH, it is indicating that it does not
the identified server push. If the server has not yet started to wish to receive the promised resource. The server SHOULD abort
send the server push, it can use the receipt of a CANCEL_PUSH frame sending the resource, but the mechanism to do so depends on the state
to avoid opening a push stream. If the push stream has been opened of the corresponding push stream. If the server has not yet created
by the server, the server SHOULD abruptly terminate that stream. 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
has already ended, the server MAY still abruptly terminate the stream
or MAY take no action.
A server can send the CANCEL_PUSH frame to indicate that it will not When a server sends CANCEL_PUSH, it is indicating that it will not be
be fulfilling a promise prior to creation of a push stream. Once the fulfilling a promise and has not created a push stream. The client
push stream has been created, sending CANCEL_PUSH has no effect on should not expect the corresponding promise to be fulfilled.
the state of the push stream. The server SHOULD abruptly terminate
the push stream instead. Sending CANCEL_PUSH has no direct effect on the state of existing
push streams. A server SHOULD NOT send a CANCEL_PUSH when it has
already created a corresponding push stream, and a client SHOULD NOT
send a CANCEL_PUSH when it has already received a corresponding push
stream.
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 HTTP_FRAME_UNEXPECTED. treated as a connection error of type HTTP_FRAME_UNEXPECTED.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ... | Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: CANCEL_PUSH frame payload Figure 6: CANCEL_PUSH frame payload
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 7.2.5). cancelled (see Section 7.2.5). If a CANCEL_PUSH frame is received
which references a Push ID greater than currently allowed on the
connection, this MUST be treated as a connection error of type
HTTP_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. 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
ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST
be treated as a connection error of type HTTP_ID_ERROR.
7.2.4. SETTINGS 7.2.4. SETTINGS
The SETTINGS frame (type=0x4) conveys configuration parameters that The SETTINGS frame (type=0x4) 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".
skipping to change at page 31, line 43 skipping to change at page 31, line 21
client MUST treat a GOAWAY frame on a stream other than the control client MUST treat a GOAWAY frame on a stream other than the control
stream as a connection error (Section 8) of type stream as a connection error (Section 8) of type
HTTP_FRAME_UNEXPECTED. HTTP_FRAME_UNEXPECTED.
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=0xD) 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 a PUSH_PROMISE maximum value for a Push ID that the server can use in PUSH_PROMISE
frame. Consequently, this also limits the number of push streams and CANCEL_PUSH frames. Consequently, this also limits the number of
that the server can initiate in addition to the limit maintained by push streams that the server can initiate in addition to the limit
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 HTTP_FRAME_UNEXPECTED. connection error of type HTTP_FRAME_UNEXPECTED.
A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the
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
HTTP_FRAME_UNEXPECTED. HTTP_FRAME_UNEXPECTED.
The maximum Push ID is unset when a connection is created, meaning The maximum Push ID is unset when a connection is created, meaning
skipping to change at page 33, line 42 skipping to change at page 33, line 19
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
implementation chooses. implementation chooses.
Frame types which were used in HTTP/2 where there is no corresponding Frame types which were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (Section 11.3). These frame HTTP/3 frame have also been reserved (Section 11.2). These frame
types MUST NOT be sent, and receipt MAY be treated as an error of types MUST NOT be sent, and receipt MAY be treated as an error of
type HTTP_UNEXPECTED_FRAME. type HTTP_FRAME_UNEXPECTED.
8. Error Handling 8. Error Handling
QUIC allows the application to abruptly terminate (reset) individual QUIC allows the application to abruptly terminate (reset) individual
streams or the entire connection when an error is encountered. These streams or the entire connection when an error is encountered. These
are referred to as "stream errors" or "connection errors" and are are referred to as "stream errors" or "connection errors" and are
described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose
to treat a stream error as a connection error. to treat a stream error as a connection error.
Because new error codes can be defined without negotiation (see Because new error codes can be defined without negotiation (see
skipping to change at page 35, line 39 skipping to change at page 35, line 20
are effective only within the scope of a single HTTP/3 connection. are effective only within the scope of a single HTTP/3 connection.
This applies to the protocol elements defined in this document. This This applies to the protocol elements defined in this document. This
does not affect the existing options for extending HTTP, such as does not affect the existing options for extending HTTP, such as
defining new methods, status codes, or header fields. defining new methods, status codes, or header fields.
Extensions are permitted to use new frame types (Section 7.2), new Extensions are permitted to use new frame types (Section 7.2), new
settings (Section 7.2.4.1), new error codes (Section 8), or new settings (Section 7.2.4.1), new error codes (Section 8), or new
unidirectional stream types (Section 6.2). Registries are unidirectional stream types (Section 6.2). Registries are
established for managing these extension points: frame types established for managing these extension points: frame types
(Section 11.3), settings (Section 11.4), error codes (Section 11.5), (Section 11.2), settings (Section 11.3), error codes (Section 11.4),
and stream types (Section 11.6). and stream types (Section 11.5).
Implementations MUST ignore unknown or unsupported values in all Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements. Implementations MUST discard frames extensible protocol elements. Implementations MUST discard frames
and unidirectional streams that have unknown or unsupported types. and unidirectional streams that have unknown or unsupported types.
This means that any of these extension points can be safely used by This means that any of these extension points can be safely used by
extensions without prior arrangement or negotiation. However, where extensions without prior arrangement or negotiation. However, where
a known frame type is required to be in a specific location, such as a known frame type is required to be in a specific location, such as
the SETTINGS frame as the first frame of the control stream (see the SETTINGS frame as the first frame of the control stream (see
Section 6.2.1), an unknown frame type does not satisfy that Section 6.2.1), an unknown frame type does not satisfy that
requirement and SHOULD be treated as an error. requirement and SHOULD be treated as an error.
skipping to change at page 37, line 26 skipping to change at page 37, line 4
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
11.2. Registration of QUIC Version Hint Alt-Svc Parameter 11.2. Frame Types
This document creates a new registration for version-negotiation
hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter"
registry established in [RFC7838].
Parameter: "quic"
Specification: This document, Section 3.2.1
11.3. Frame Types
This document establishes a registry for HTTP/3 frame type codes. This document establishes a registry for HTTP/3 frame type codes.
The "HTTP/3 Frame Type" registry governs a 62-bit space. This space The "HTTP/3 Frame Type" registry governs a 62-bit space. This space
is split into three spaces that are governed by different policies. is split into three spaces that are governed by different policies.
Values between "0x00" and "0x3f" (in hexadecimal) are assigned via Values between "0x00" and "0x3f" (in hexadecimal) are assigned via
the Standards Action or IESG Review policies [RFC8126]. Values from the Standards Action or IESG Review policies [RFC8126]. Values from
"0x40" to "0x3fff" operate on the Specification Required policy "0x40" to "0x3fff" operate on the Specification Required policy
[RFC8126]. All other values are assigned to Private Use [RFC8126]. [RFC8126]. All other values are assigned to Private Use [RFC8126].
While this registry is separate from the "HTTP/2 Frame Type" registry While this registry is separate from the "HTTP/2 Frame Type" registry
skipping to change at page 39, line 5 skipping to change at page 38, line 37
| | | | | | | |
| MAX_PUSH_ID | 0xD | Section 7.2.7 | | MAX_PUSH_ID | 0xD | Section 7.2.7 |
| | | | | | | |
| DUPLICATE_PUSH | 0xE | Section 7.2.8 | | DUPLICATE_PUSH | 0xE | Section 7.2.8 |
+----------------+------+----------------+ +----------------+------+----------------+
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.4. Settings Parameters 11.3. Settings Parameters
This document establishes a registry for HTTP/3 settings. The This document establishes a registry for HTTP/3 settings. The
"HTTP/3 Settings" registry governs a 62-bit space. This space is "HTTP/3 Settings" registry governs a 62-bit space. This space is
split into three spaces that are governed by different policies. split into three spaces that are governed by different policies.
Values between "0x00" and "0x3f" (in hexadecimal) are assigned via Values between "0x00" and "0x3f" (in hexadecimal) are assigned via
the Standards Action or IESG Review policies [RFC8126]. Values from the Standards Action or IESG Review policies [RFC8126]. Values from
"0x40" to "0x3fff" operate on the Specification Required policy "0x40" to "0x3fff" operate on the Specification Required policy
[RFC8126]. All other values are assigned to Private Use [RFC8126]. [RFC8126]. All other values are assigned to Private Use [RFC8126].
The designated experts are the same as those for the "HTTP/2 The designated experts are the same as those for the "HTTP/2
Settings" registry defined in [HTTP2]. Settings" registry defined in [HTTP2].
skipping to change at page 40, line 9 skipping to change at page 39, line 40
| | | | | | | | | |
| Reserved | 0x5 | N/A | N/A | | Reserved | 0x5 | N/A | N/A |
| | | | | | | | | |
| MAX_HEADER_LIST_SIZE | 0x6 | Section 7.2.4.1 | Unlimited | | MAX_HEADER_LIST_SIZE | 0x6 | Section 7.2.4.1 | Unlimited |
+----------------------+------+------------------+-----------+ +----------------------+------+------------------+-----------+
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.5. Error Codes 11.4. Error Codes
This document establishes a registry for HTTP/3 error codes. The This document establishes a registry for HTTP/3 error codes. The
"HTTP/3 Error Code" registry manages a 62-bit space. The "HTTP/3 "HTTP/3 Error Code" registry manages a 62-bit space. The "HTTP/3
Error Code" registry operates under the "Expert Review" policy Error Code" registry operates under the "Expert Review" policy
[RFC8126]. [RFC8126].
Registrations for error codes are required to include a description Registrations for error codes are required to include a description
of the error code. An expert reviewer is advised to examine new of the error code. An expert reviewer is advised to examine new
registrations for possible duplication with existing error codes. registrations for possible duplication with existing error codes.
Use of existing registrations is to be encouraged, but not mandated. Use of existing registrations is to be encouraged, but not mandated.
skipping to change at page 42, line 14 skipping to change at page 41, line 46
| | | | | | | | | |
| HTTP_CONNECT_ERROR | 0x010F | TCP reset | Section 8.1 | | HTTP_CONNECT_ERROR | 0x010F | TCP reset | Section 8.1 |
| | | or error on | | | | | or error on | |
| | | CONNECT | | | | | CONNECT | |
| | | request | | | | | request | |
| | | | | | | | | |
| HTTP_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 | | HTTP_VERSION_FALLBACK | 0x0110 | Retry over | Section 8.1 |
| | | HTTP/1.1 | | | | | HTTP/1.1 | |
+----------------------------+--------+-------------+---------------+ +----------------------------+--------+-------------+---------------+
11.6. Stream Types 11.5. Stream Types
This document establishes a registry for HTTP/3 unidirectional stream This document establishes a registry for HTTP/3 unidirectional stream
types. The "HTTP/3 Stream Type" registry governs a 62-bit space. types. The "HTTP/3 Stream Type" registry governs a 62-bit space.
This space is split into three spaces that are governed by different This space is split into three spaces that are governed by different
policies. Values between "0x00" and 0x3f (in hexadecimal) are policies. Values between "0x00" and 0x3f (in hexadecimal) are
assigned via the Standards Action or IESG Review policies [RFC8126]. assigned via the Standards Action or IESG Review policies [RFC8126].
Values from "0x40" to "0x3fff" operate on the Specification Required Values from "0x40" to "0x3fff" operate on the Specification Required
policy [RFC8126]. All other values are assigned to Private Use policy [RFC8126]. All other values are assigned to Private Use
[RFC8126]. [RFC8126].
skipping to change at page 43, line 25 skipping to change at page 43, line 12
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", draft-ietf-quic- Header Compression for HTTP over QUIC", draft-ietf-quic-
qpack-10 (work in progress). qpack-latest (work in progress).
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-23 (work in progress). transport-latest (work in progress).
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 48, line 16 skipping to change at page 47, line 51
provides flow control. provides flow control.
CONTINUATION (0x9): CONTINUATION frames do not exist; instead, CONTINUATION (0x9): CONTINUATION frames do not exist; instead,
larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted. larger HEADERS/PUSH_PROMISE frames than HTTP/2 are 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.3. See Section 11.2.
A.3. HTTP/2 SETTINGS Parameters A.3. HTTP/2 SETTINGS Parameters
An important difference from HTTP/2 is that settings are sent once, An important difference from HTTP/2 is that settings are sent once,
as the first frame of the control stream, and thereafter cannot as the first frame of the control stream, and thereafter cannot
change. This eliminates many corner cases around synchronization of change. This eliminates many corner cases around synchronization of
changes. changes.
Some transport-level options that HTTP/2 specifies via the SETTINGS Some transport-level options that HTTP/2 specifies via the SETTINGS
frame are superseded by QUIC transport parameters in HTTP/3. The frame are superseded by QUIC transport parameters in HTTP/3. The
skipping to change at page 49, line 4 skipping to change at page 48, line 40
initial transport handshake. Specifying initial transport handshake. Specifying
SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error. SETTINGS_INITIAL_WINDOW_SIZE in the SETTINGS frame is an error.
SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3. SETTINGS_MAX_FRAME_SIZE: This setting has no equivalent in HTTP/3.
Specifying it in the SETTINGS frame is an error. Specifying it in the SETTINGS frame is an error.
SETTINGS_MAX_HEADER_LIST_SIZE: See Section 7.2.4.1. SETTINGS_MAX_HEADER_LIST_SIZE: See Section 7.2.4.1.
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 which use the full 32-bit space. Settings encoding for settings which use the full 32-bit space. Settings
ported from HTTP/2 might choose to redefine the format of their ported from HTTP/2 might choose to redefine the format of their
settings to avoid using the 62-bit encoding. settings to avoid using the 62-bit encoding.
Settings need to be defined separately for HTTP/2 and HTTP/3. The Settings need to be defined separately for HTTP/2 and HTTP/3. The
IDs of settings defined in [HTTP2] have been reserved for simplicity. IDs of settings defined in [HTTP2] have been reserved for simplicity.
Note that the settings identifier space in HTTP/3 is substantially Note that the settings identifier space in HTTP/3 is substantially
larger (62 bits versus 16 bits), so many HTTP/3 settings have no larger (62 bits versus 16 bits), so many HTTP/3 settings have no
equivalent HTTP/2 code point. See Section 11.4. equivalent HTTP/2 code point. See Section 11.3.
As QUIC streams might arrive out-of-order, endpoints are advised to As QUIC streams might arrive out-of-order, endpoints are advised to
not wait for the peers' settings to arrive before responding to other not wait for the peers' settings to arrive before responding to other
streams. See Section 7.2.4.2. streams. See Section 7.2.4.2.
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, there is no direct portability of HTTP/2 HTTP/2 provides. However, there is no direct portability of HTTP/2
error codes to HTTP/3 error codes; the values are shifted in order to error codes to HTTP/3 error codes; the values are shifted in order to
skipping to change at page 50, line 24 skipping to change at page 50, line 11
CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1. CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1.
ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1. ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1.
INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to INADEQUATE_SECURITY (0xc): Not applicable, since QUIC is assumed to
provide sufficient security on all connections. provide sufficient security on all connections.
HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 8.1. HTTP_1_1_REQUIRED (0xd): HTTP_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.5. Section 11.4.
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-22 B.1. Since draft-ietf-quic-http-22
o Removed priority signaling (#2922,#2924) o Removed priority signaling (#2922,#2924)
 End of changes. 43 change blocks. 
155 lines changed or deleted 131 lines changed or added

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