draft-ietf-quic-http-29.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 June 9, 2020 Intended status: Standards Track July 15, 2020
Expires: December 11, 2020 Expires: January 16, 2021
Hypertext Transfer Protocol Version 3 (HTTP/3) Hypertext Transfer Protocol Version 3 (HTTP/3)
draft-ietf-quic-http-29 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 December 11, 2020. This Internet-Draft will expire on January 16, 2021.
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 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 . . . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . 9 3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 9
3.2.1. HTTP Alternative Services . . . . . . . . . . . . . . 9 3.2.1. HTTP Alternative Services . . . . . . . . . . . . . . 9
3.2.2. Other Schemes . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Other Schemes . . . . . . . . . . . . . . . . . . . . 10
3.3. Connection Establishment . . . . . . . . . . . . . . . . 10 3.3. Connection Establishment . . . . . . . . . . . . . . . . 10
3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 11 3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 11
4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 12 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 12
4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 12 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 12
4.1.1. Field Formatting and Compression . . . . . . . . . . 13 4.1.1. Field Formatting and Compression . . . . . . . . . . 13
4.1.2. Request Cancellation and Rejection . . . . . . . . . 17 4.1.2. Request Cancellation and Rejection . . . . . . . . . 17
4.1.3. Malformed Requests and Responses . . . . . . . . . . 17 4.1.3. Malformed Requests and Responses . . . . . . . . . . 18
4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 18 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 18
4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 20 4.3. HTTP Upgrade . . . . . . . . . . . . . . . . . . . . . . 20
4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 20 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 20
5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 22 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 22
5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 22 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 22
5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 22 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 22
5.3. Immediate Application Closure . . . . . . . . . . . . . . 24 5.3. Immediate Application Closure . . . . . . . . . . . . . . 24
5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 25 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 25
6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 25 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 25
6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 25 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 25
skipping to change at page 3, line 47 skipping to change at page 3, line 47
11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 47 11.2.2. Settings Parameters . . . . . . . . . . . . . . . . 47
11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 48 11.2.3. Error Codes . . . . . . . . . . . . . . . . . . . . 48
11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 51 11.2.4. Stream Types . . . . . . . . . . . . . . . . . . . . 51
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 51 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 51
12.1. Normative References . . . . . . . . . . . . . . . . . . 51 12.1. Normative References . . . . . . . . . . . . . . . . . . 51
12.2. Informative References . . . . . . . . . . . . . . . . . 53 12.2. Informative References . . . . . . . . . . . . . . . . . 53
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 54 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 54 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 54
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 54 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 54
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 55 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 55
A.2.1. Prioritization Differences . . . . . . . . . . . . . 56 A.2.1. Prioritization Differences . . . . . . . . . . . . . 55
A.2.2. Field Compression Differences . . . . . . . . . . . . 56 A.2.2. Field Compression Differences . . . . . . . . . . . . 56
A.2.3. Guidance for New Frame Type Definitions . . . . . . . 56 A.2.3. Guidance for New Frame Type Definitions . . . . . . . 56
A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 57 A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 56
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 57 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 57
A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 59 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 58
A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors . . . . . . 60 A.4.1. Mapping Between HTTP/2 and HTTP/3 Errors . . . . . . 59
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 60 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 60
B.1. Since draft-ietf-quic-http-28 . . . . . . . . . . . . . . 60 B.1. Since draft-ietf-quic-http-28 . . . . . . . . . . . . . . 60
B.2. Since draft-ietf-quic-http-27 . . . . . . . . . . . . . . 61 B.2. Since draft-ietf-quic-http-27 . . . . . . . . . . . . . . 60
B.3. Since draft-ietf-quic-http-26 . . . . . . . . . . . . . . 61 B.3. Since draft-ietf-quic-http-26 . . . . . . . . . . . . . . 61
B.4. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 61 B.4. Since draft-ietf-quic-http-25 . . . . . . . . . . . . . . 61
B.5. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 61 B.5. Since draft-ietf-quic-http-24 . . . . . . . . . . . . . . 61
B.6. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 61 B.6. Since draft-ietf-quic-http-23 . . . . . . . . . . . . . . 61
B.7. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 61 B.7. Since draft-ietf-quic-http-22 . . . . . . . . . . . . . . 61
B.8. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 62 B.8. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 62
B.9. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 62 B.9. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 62
B.10. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 63 B.10. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 63
B.11. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 63 B.11. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 63
B.12. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 64 B.12. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 64
B.13. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 64 B.13. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 64
B.14. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 65 B.14. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 64
B.15. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 65 B.15. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 64
B.16. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 65 B.16. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 65
B.17. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 65 B.17. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 65
B.18. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 66 B.18. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 65
B.19. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 66 B.19. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 65
B.20. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 66 B.20. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 66
B.21. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 66 B.21. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 66
B.22. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 66 B.22. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 66
B.23. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 66 B.23. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 66
B.24. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 66 B.24. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 66
B.25. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 67 B.25. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 66
B.26. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 67 B.26. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 67
B.27. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 67 B.27. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 67
B.28. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 67 B.28. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 67
B.29. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 68 B.29. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 67
B.30. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 68 B.30. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 68
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 68 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 68
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 69 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 69
1. Introduction 1. Introduction
HTTP semantics [SEMANTICS] are used for a broad range of services on HTTP semantics [SEMANTICS] are used for a broad range of services on
the Internet. These semantics have most commonly been used with two the Internet. These semantics have most commonly been used with
different TCP mappings, HTTP/1.1 and HTTP/2. HTTP/3 supports the HTTP/1.1, over a variety of transport and session layers, and with
same semantics over a new transport protocol, QUIC. HTTP/2 over TLS. HTTP/3 supports the same semantics over a new
transport protocol, QUIC.
1.1. Prior versions of HTTP 1.1. Prior versions of HTTP
HTTP/1.1 [HTTP11] is a TCP mapping which uses whitespace-delimited HTTP/1.1 [HTTP11] uses whitespace-delimited text fields to convey
text fields to convey HTTP messages. While these exchanges are HTTP messages. While these exchanges are human-readable, using
human-readable, using whitespace for message formatting leads to whitespace for message formatting leads to parsing complexity and
parsing complexity and motivates tolerance of variant behavior. excessive tolerance of variant behavior. Because HTTP/1.x does not
Because each connection can transfer only a single HTTP request or include a multiplexing layer, multiple TCP connections are often used
response at a time in each direction, multiple parallel TCP to service requests in parallel. However, that has a negative impact
connections are often used, reducing the ability of the congestion on congestion control and network efficiency, since TCP does not
controller to effectively manage traffic between endpoints. share congestion control across multiple connections.
HTTP/2 [HTTP2] introduced a binary framing and multiplexing layer to HTTP/2 [HTTP2] introduced a binary framing and multiplexing layer to
improve latency without modifying the transport layer. However, improve latency without modifying the transport layer. However,
because the parallel nature of HTTP/2's multiplexing is not visible because the parallel nature of HTTP/2's multiplexing is not visible
to TCP's loss recovery mechanisms, a lost or reordered packet causes to TCP's loss recovery mechanisms, a lost or reordered packet causes
all active transactions to experience a stall regardless of whether all active transactions to experience a stall regardless of whether
that transaction was directly impacted by the lost packet. that transaction was directly impacted by the lost packet.
1.2. Delegation to QUIC 1.2. Delegation to QUIC
skipping to change at page 7, line 21 skipping to change at page 7, line 25
in Appendix A. in Appendix A.
2.2. Conventions and Terminology 2.2. Conventions and Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Field definitions are given in Augmented Backus-Naur Form (ABNF), as
defined in [RFC5234].
This document uses the variable-length integer encoding from This document uses the variable-length integer encoding from
[QUIC-TRANSPORT]. [QUIC-TRANSPORT].
The following terms are used: The following terms are used:
abort: An abrupt termination of a connection or stream, possibly due abort: An abrupt termination of a connection or stream, possibly due
to an error condition. to an error condition.
client: The endpoint that initiates an HTTP/3 connection. Clients client: The endpoint that initiates an HTTP/3 connection. Clients
send HTTP requests and receive HTTP responses. send HTTP requests and receive HTTP responses.
skipping to change at page 8, line 21 skipping to change at page 8, line 21
sender: An endpoint that is transmitting frames. sender: An endpoint that is transmitting frames.
server: The endpoint that accepts an HTTP/3 connection. Servers server: The endpoint that accepts an HTTP/3 connection. Servers
receive HTTP requests and send HTTP responses. receive HTTP requests and send HTTP responses.
stream: A bidirectional or unidirectional bytestream provided by the stream: A bidirectional or unidirectional bytestream provided by the
QUIC transport. QUIC transport.
stream error: An error on the individual HTTP/3 stream. stream error: An error on the individual HTTP/3 stream.
The term "payload body" is defined in Section 6.3.3 of [SEMANTICS]. The term "payload body" is defined in Section 7.3.3 of [SEMANTICS].
Finally, the terms "gateway", "intermediary", "proxy", and "tunnel" Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"
are defined in Section 2.2 of [SEMANTICS]. Intermediaries act as are defined in Section 2.2 of [SEMANTICS]. Intermediaries act as
both client and server at different times. both client and server at different times.
3. Connection Setup and Management 3. Connection Setup and Management
3.1. Draft Version Identification 3.1. Draft Version Identification
*RFC Editor's Note:* Please remove this section prior to *RFC Editor's Note:* Please remove this section prior to
skipping to change at page 9, line 6 skipping to change at page 9, line 6
their transport. For example, the application protocol defined in their transport. For example, the application protocol defined in
draft-ietf-quic-http-25 uses the transport defined in draft-ietf- draft-ietf-quic-http-25 uses the transport defined in draft-ietf-
quic-transport-25. 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 4.4.1.1 of [SEMANTICS]. Experimenters are encouraged to Section 5.4.1.1 of [SEMANTICS]. Experimenters are encouraged to
coordinate their experiments on the quic@ietf.org [2] mailing list. coordinate their experiments on the quic@ietf.org [2] mailing list.
3.2. Discovering an HTTP/3 Endpoint 3.2. Discovering an HTTP/3 Endpoint
HTTP relies on the notion of an authoritative response: a response HTTP relies on the notion of an authoritative response: a response
that has been determined to be the most appropriate response for that that has been determined to be the most appropriate response for that
request given the state of the target resource at the time of request given the state of the target resource at the time of
response message origination by (or at the direction of) the origin response message origination by (or at the direction of) the origin
server identified within the target URI. Locating an authoritative server identified within the target URI. Locating an authoritative
server for an HTTP URL is discussed in Section 5.4 of [SEMANTICS]. server for an HTTP URL is discussed in Section 6.4 of [SEMANTICS].
The "https" scheme associates authority with possession of a The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host certificate that the client considers to be trustworthy for the host
identified by the authority component of the URL. If a server identified by the authority component of the URL. If a server
presents a certificate and proof that it controls the corresponding presents a certificate and proof that it controls the corresponding
private key, then a client will accept a secured connection to that private key, then a client will accept a secured connection to that
server as being authoritative for all origins with the "https" scheme server as being authoritative for all origins with the "https" scheme
and a host identified in the certificate. and a host identified in the certificate.
A client MAY attempt access to a resource with an "https" URI by A client MAY attempt access to a resource with an "https" URI by
skipping to change at page 9, line 44 skipping to change at page 9, line 44
based versions of HTTP in this case. based versions of HTTP in this case.
Servers MAY serve HTTP/3 on any UDP port; an alternative service Servers MAY serve HTTP/3 on any UDP port; an alternative service
advertisement always includes an explicit port, and URLs contain advertisement always includes an explicit port, and URLs contain
either an explicit port or a default port associated with the scheme. either an explicit port or a default port associated with the scheme.
3.2.1. HTTP Alternative Services 3.2.1. HTTP Alternative Services
An HTTP origin advertises the availability of an equivalent HTTP/3 An HTTP origin advertises the availability of an equivalent HTTP/3
endpoint via the Alt-Svc HTTP response header field or the HTTP/2 endpoint via the Alt-Svc HTTP response header field or the HTTP/2
ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 3.3. ALTSVC frame ([ALTSVC]), using the Application Layer Protocol
Negotiation (ALPN) [RFC7301] token defined in Section 3.3.
For example, an origin could indicate in an HTTP response that HTTP/3 For example, an origin could indicate in an HTTP response that HTTP/3
was available on UDP port 50781 at the same hostname by including the was available on UDP port 50781 at the same hostname by including the
following header field: following header field:
Alt-Svc: h3=":50781" Alt-Svc: h3=":50781"
On receipt of an Alt-Svc record indicating HTTP/3 support, a client On receipt of an Alt-Svc record indicating HTTP/3 support, a client
MAY attempt to establish a QUIC connection to the indicated host and MAY attempt to establish a QUIC connection to the indicated host and
port and, if successful, send HTTP requests using the mapping port and, if successful, send HTTP requests using the mapping
described in this document. described in this document.
skipping to change at page 11, line 26 skipping to change at page 11, line 26
reused for requests with multiple different URI authority components. reused for requests with multiple different URI authority components.
In general, a server is considered authoritative for all URIs with In general, a server is considered authoritative for all URIs with
the "https" scheme for which the hostname in the URI is present in the "https" scheme for which the hostname in the URI is present in
the authenticated certificate provided by the server, either as the the authenticated certificate provided by the server, either as the
CN field of the certificate subject or as a dNSName in the CN field of the certificate subject or as a dNSName in the
subjectAltName field of the certificate; see [RFC6125]. For a host subjectAltName field of the certificate; see [RFC6125]. For a host
that is an IP address, the client MUST verify that the address that is an IP address, the client MUST verify that the address
appears as an iPAddress in the subjectAltName field of the appears as an iPAddress in the subjectAltName field of the
certificate. If the hostname or address is not present in the certificate. If the hostname or address is not present in the
certificate, the client MUST NOT consider the server authoritative certificate, the client MUST NOT consider the server authoritative
for origins containing that hostname or address. See Section 5.4 of for origins containing that hostname or address. See Section 6.4 of
[SEMANTICS] for more detail on authoritative access. [SEMANTICS] for more detail on authoritative access.
Clients SHOULD NOT open more than one HTTP/3 connection to a given Clients SHOULD NOT open more than one HTTP/3 connection to a given
host and port pair, where the host is derived from a URI, a selected host and port pair, where the host is derived from a URI, a selected
alternative service [ALTSVC], or a configured proxy. A client MAY alternative service [ALTSVC], or a configured proxy. A client MAY
open multiple connections to the same IP address and UDP port using open multiple connections to the same IP address and UDP port using
different transport or TLS configurations but SHOULD avoid creating different transport or TLS configurations but SHOULD avoid creating
multiple connections with the same configuration. multiple connections with the same configuration.
Servers are encouraged to maintain open connections for as long as Servers are encouraged to maintain open connections for as long as
skipping to change at page 12, line 27 skipping to change at page 12, line 27
responses, followed by a single final HTTP response, in the same responses, followed by a single final HTTP response, in the same
manner as a standard response. Push is described in more detail in manner as a standard response. Push is described in more detail in
Section 4.4. Section 4.4.
On a given stream, receipt of multiple requests or receipt of an On a given stream, receipt of multiple requests or receipt of an
additional HTTP response following a final HTTP response MUST be additional HTTP response following a final HTTP response MUST be
treated as malformed (Section 4.1.3). treated as malformed (Section 4.1.3).
An HTTP message (request or response) consists of: An HTTP message (request or response) consists of:
1. the header field section (see Section 4 of [SEMANTICS]), sent as 1. the header field section (see Section 5 of [SEMANTICS]), sent as
a single HEADERS frame (see Section 7.2.2), a single HEADERS frame (see Section 7.2.2),
2. optionally, the payload body, if present (see Section 6.3.3 of 2. optionally, the payload body, if present (see Section 7.3.3 of
[SEMANTICS]), sent as a series of DATA frames (see [SEMANTICS]), sent as a series of DATA frames (see
Section 7.2.1), Section 7.2.1),
3. optionally, the trailer field section, if present (see 3. optionally, the trailer field section, if present (see
Section 4.6 of [SEMANTICS]), sent as a single HEADERS frame. Section 5.6 of [SEMANTICS]), sent as a single HEADERS frame.
Receipt of an invalid sequence of frames MUST be treated as a Receipt of an invalid sequence of frames MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED (Section 8). In connection error of type H3_FRAME_UNEXPECTED (Section 8). In
particular, a DATA frame before any HEADERS frame, or a HEADERS or particular, a DATA frame before any HEADERS frame, or a HEADERS or
DATA frame after the trailing HEADERS frame is considered invalid. DATA frame after the trailing HEADERS frame is considered invalid.
A server MAY send one or more PUSH_PROMISE frames (see Section 7.2.5) 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. before, after, or interleaved with the frames of a response message.
These PUSH_PROMISE frames are not part of the response; see These PUSH_PROMISE frames are not part of the response; see
Section 4.4 for more details. These frames are not permitted in Section 4.4 for more details. These frames are not permitted in
skipping to change at page 13, line 14 skipping to change at page 13, line 14
The HEADERS and PUSH_PROMISE frames might reference updates to the The HEADERS and PUSH_PROMISE frames might reference updates to the
QPACK dynamic table. While these updates are not directly part of QPACK dynamic table. While these updates are not directly part of
the message exchange, they must be received and processed before the the message exchange, they must be received and processed before the
message can be consumed. See Section 4.1.1 for more details. message can be consumed. See Section 4.1.1 for more details.
The "chunked" transfer encoding defined in Section 7.1 of [HTTP11] The "chunked" transfer encoding defined in Section 7.1 of [HTTP11]
MUST NOT be used. MUST NOT be used.
A response MAY consist of multiple messages when and only when one or A response MAY consist of multiple messages when and only when one or
more informational responses (1xx; see Section 9.2 of [SEMANTICS]) more informational responses (1xx; see Section 10.2 of [SEMANTICS])
precede a final response to the same request. Interim responses do precede a final response to the same request. Interim responses do
not contain a payload body or trailers. not contain a payload body or trailers.
An HTTP request/response exchange fully consumes a client-initiated An HTTP request/response exchange fully consumes a client-initiated
bidirectional QUIC stream. After sending a request, a client MUST bidirectional QUIC stream. After sending a request, a client MUST
close the stream for sending. Unless using the CONNECT method (see close the stream for sending. Unless using the CONNECT method (see
Section 4.2), clients MUST NOT make stream closure dependent on Section 4.2), clients MUST NOT make stream closure dependent on
receiving a response to their request. After sending a final receiving a response to their request. After sending a final
response, the server MUST close the stream for sending. At this response, the server MUST close the stream for sending. At this
point, the QUIC stream is fully closed. point, the QUIC stream is fully closed.
When a stream is closed, this indicates the end of 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-initiated stream terminates
enough of the HTTP message to provide a complete response, the server without enough of the HTTP message to provide a complete response,
SHOULD abort its response with the error code H3_REQUEST_INCOMPLETE. the server 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
request that has not been sent and received. When the server does request that has not been sent and received. When the server does
not need to receive the remainder of the request, it MAY abort not need to receive the remainder of the request, it MAY abort
reading the request stream, send a complete response, and cleanly reading the request stream, send a complete response, and cleanly
close the sending part of the stream. The error code H3_NO_ERROR close the sending part of the stream. The error code H3_NO_ERROR
SHOULD be used when requesting that the client stop sending on the SHOULD be used when requesting that the client stop sending on the
request stream. Clients MUST NOT discard complete responses as a request stream. Clients MUST NOT discard complete responses as a
result of having their request terminated abruptly, though clients result of having their request terminated abruptly, though clients
can always discard responses at their discretion for other reasons. can always discard responses at their discretion for other reasons.
If the server sends a partial or complete response but does not abort If the server sends a partial or complete response but does not abort
reading, clients SHOULD continue sending the body of the request and reading the request, clients SHOULD continue sending the body of the
close the stream normally. request and close the stream normally.
4.1.1. Field Formatting and Compression 4.1.1. Field Formatting and Compression
HTTP messages carry metadata as a series of key-value pairs, called HTTP messages carry metadata as a series of key-value pairs, called
HTTP fields. For a listing of registered HTTP fields, see the HTTP fields. For a listing of registered HTTP fields, see the
"Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained "Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained
at <https://www.iana.org/assignments/http-fields/>. at <https://www.iana.org/assignments/http-fields/>.
As in previous versions of HTTP, field names are strings containing a As in previous versions of HTTP, field names are strings containing a
subset of ASCII characters that are compared in a case-insensitive subset of ASCII characters that are compared in a case-insensitive
fashion. Properties of HTTP field names and values are discussed in fashion. Properties of HTTP field names and values are discussed in
more detail in Section 4.3 of [SEMANTICS]. As in HTTP/2, characters more detail in Section 5.3 of [SEMANTICS]. As in HTTP/2, characters
in field names MUST be converted to lowercase prior to their in field names MUST be converted to lowercase prior to their
encoding. A request or response containing uppercase characters in encoding. A request or response containing uppercase characters in
field names MUST be treated as malformed (Section 4.1.3). field names MUST be treated as malformed (Section 4.1.3).
Like HTTP/2, HTTP/3 does not use the Connection header field to Like HTTP/2, HTTP/3 does not use the Connection header field to
indicate connection-specific fields; in this protocol, connection- indicate connection-specific fields; in this protocol, connection-
specific metadata is conveyed by other means. An endpoint MUST NOT specific metadata is conveyed by other means. An endpoint MUST NOT
generate an HTTP/3 field section containing connection-specific generate an HTTP/3 field section containing connection-specific
fields; any message containing connection-specific fields MUST be fields; any message containing connection-specific fields MUST be
treated as malformed (Section 4.1.3). treated as malformed (Section 4.1.3).
skipping to change at page 15, line 9 skipping to change at page 15, line 12
undefined or invalid pseudo-header fields as malformed undefined or invalid pseudo-header fields as malformed
(Section 4.1.3). (Section 4.1.3).
All pseudo-header fields MUST appear in the header field section All pseudo-header fields MUST appear in the header field section
before regular header fields. Any request or response that contains before regular header fields. Any request or response that contains
a pseudo-header field that appears in a header field section after a a pseudo-header field that appears in a header field section after a
regular header field MUST be treated as malformed (Section 4.1.3). regular header field MUST be treated as malformed (Section 4.1.3).
The following pseudo-header fields are defined for requests: The following pseudo-header fields are defined for requests:
":method": Contains the HTTP method (Section 7 of [SEMANTICS]) ":method": Contains the HTTP method (Section 8 of [SEMANTICS])
":scheme": Contains the scheme portion of the target URI ":scheme": Contains the scheme portion of the target URI
(Section 3.1 of [RFC3986]) (Section 3.1 of [RFC3986])
":scheme" is not restricted to "http" and "https" schemed URIs. A ":scheme" is not restricted to "http" and "https" schemed URIs. A
proxy or gateway can translate requests for non-HTTP schemes, proxy or gateway can translate requests for non-HTTP schemes,
enabling the use of HTTP to interact with non-HTTP services. enabling the use of HTTP to interact with non-HTTP services.
":authority": Contains the authority portion of the target URI ":authority": Contains the authority portion of the target URI
(Section 3.2 of [RFC3986]). The authority MUST NOT include the (Section 3.2 of [RFC3986]). The authority MUST NOT include the
skipping to change at page 16, line 19 skipping to change at page 16, line 22
":authority" pseudo-header and "Host" header fields. ":authority" pseudo-header and "Host" header fields.
An HTTP request that omits mandatory pseudo-header fields or contains An HTTP request that omits mandatory pseudo-header fields or contains
invalid values for those pseudo-header fields is malformed invalid values for those pseudo-header fields is malformed
(Section 4.1.3). (Section 4.1.3).
HTTP/3 does not define a way to carry the version identifier that is HTTP/3 does not define a way to carry the version identifier that is
included in the HTTP/1.1 request line. included in the HTTP/1.1 request line.
For responses, a single ":status" pseudo-header field is defined that For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see Section 9 of [SEMANTICS]. This carries the HTTP status code; see Section 10 of [SEMANTICS]. This
pseudo-header field MUST be included in all responses; otherwise, the pseudo-header field MUST be included in all responses; otherwise, the
response is malformed (Section 4.1.3). response is malformed (Section 4.1.3).
HTTP/3 does not define a way to carry the version or reason phrase HTTP/3 does not define a way to carry the version or reason phrase
that is included in an HTTP/1.1 status line. that is included in an HTTP/1.1 status line.
4.1.1.2. Field Compression 4.1.1.2. Field Compression
HTTP/3 uses QPACK field compression as described in [QPACK], a HTTP/3 uses QPACK field compression as described in [QPACK], a
variation of HPACK which allows the flexibility to avoid compression- variation of HPACK which allows the flexibility to avoid compression-
skipping to change at page 18, line 23 skipping to change at page 18, line 28
o an invalid sequence of HTTP messages, o an invalid sequence of HTTP messages,
o the inclusion of uppercase field names, or o the inclusion of uppercase field names, or
o the inclusion of invalid characters in field names or values o the inclusion of invalid characters in field names or values
A request or response that includes 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 malformed Content-Length header field. A request or response is also malformed
if the value of a content-length header field does not equal the sum if the value of a content-length header field does not equal the sum
of the DATA frame payload lengths that form the body. A response of the DATA frame payload lengths that form the body. A response
that is defined to have no payload, as described in Section 6.3.3 of that is defined to have no payload, as described in Section 7.3.3 of
[SEMANTICS] can have a non-zero content-length field, even though no [SEMANTICS] can have a non-zero content-length field, even though no
content is included in DATA frames. content is included in DATA frames.
Intermediaries that process HTTP requests or responses (i.e., any Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a malformed intermediary not acting as a tunnel) MUST NOT forward a malformed
request or response. Malformed requests or responses that are request or response. Malformed requests or responses that are
detected MUST be treated as a stream error (Section 8) of type detected MUST be treated as a stream error (Section 8) of type
H3_GENERAL_PROTOCOL_ERROR. H3_GENERAL_PROTOCOL_ERROR.
For malformed requests, a server MAY send an HTTP response prior to For malformed requests, a server MAY send an HTTP response prior to
skipping to change at page 19, line 21 skipping to change at page 19, line 27
of CONNECT requests; see Section 3.2.3 of [HTTP11]) of CONNECT requests; see Section 3.2.3 of [HTTP11])
The request stream remains open at the end of the request to carry The request stream remains open at the end of the request to carry
the data to be transferred. A CONNECT request that does not conform the data to be transferred. A CONNECT request that does not conform
to these restrictions is malformed; see Section 4.1.3. to these restrictions is malformed; see Section 4.1.3.
A proxy that supports CONNECT establishes a TCP connection A proxy that supports CONNECT establishes a TCP connection
([RFC0793]) to the server identified in the ":authority" pseudo- ([RFC0793]) to the server identified in the ":authority" pseudo-
header field. Once this connection is successfully established, the header field. Once this connection is successfully established, the
proxy sends a HEADERS frame containing a 2xx series status code to proxy sends a HEADERS frame containing a 2xx series status code to
the client, as defined in Section 9.3 of [SEMANTICS]. the client, as defined in Section 10.3 of [SEMANTICS].
All DATA frames on the stream correspond to data sent or received on All DATA frames on the stream correspond to data sent or received on
the TCP connection. Any DATA frame sent by the client is transmitted the TCP connection. Any DATA frame sent by the client is transmitted
by the proxy to the TCP server; data received from the TCP server is by the proxy to the TCP server; data received from the TCP server is
packaged into DATA frames by the proxy. Note that the size and packaged into DATA frames by the proxy. Note that the size and
number of TCP segments is not guaranteed to map predictably to the number of TCP segments is not guaranteed to map predictably to the
size and number of HTTP DATA or QUIC STREAM frames. size and number of HTTP DATA or QUIC STREAM frames.
Once the CONNECT method has completed, only DATA frames are permitted Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream. Extension frames MAY be used if to be sent on the stream. Extension frames MAY be used if
skipping to change at page 20, line 9 skipping to change at page 20, line 17
includes receiving a TCP segment with the RST bit set, as a stream includes receiving a TCP segment with the RST bit set, as a stream
error of type H3_CONNECT_ERROR (Section 8.1). Correspondingly, if a error of type H3_CONNECT_ERROR (Section 8.1). Correspondingly, if a
proxy detects an error with the stream or the QUIC connection, it proxy detects an error with the stream or the QUIC connection, it
MUST close the TCP connection. If the underlying TCP implementation MUST close the TCP connection. If the underlying TCP implementation
permits it, the proxy SHOULD send a TCP segment with the RST bit set. permits it, the proxy SHOULD send a TCP segment with the RST bit set.
4.3. HTTP Upgrade 4.3. HTTP Upgrade
HTTP/3 does not support the HTTP Upgrade mechanism (Section 9.9 of HTTP/3 does not support the HTTP Upgrade mechanism (Section 9.9 of
[HTTP11]) or 101 (Switching Protocols) informational status code [HTTP11]) or 101 (Switching Protocols) informational status code
(Section 9.2.2 of [SEMANTICS]). (Section 10.2.2 of [SEMANTICS]).
4.4. Server Push 4.4. Server Push
Server push is an interaction mode which permits a server to push a Server push is an interaction mode which permits a server to push a
request-response exchange to a client in anticipation of the client request-response exchange to a client in anticipation of the client
making the indicated request. This trades off network usage against making the indicated request. This trades off network usage against
a potential latency gain. HTTP/3 server push is similar to what is a potential latency gain. HTTP/3 server push is similar to what is
described in HTTP/2 [HTTP2], but uses different mechanisms. described in HTTP/2 [HTTP2], but uses 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
skipping to change at page 20, line 44 skipping to change at page 20, line 52
error of type H3_ID_ERROR. error of type H3_ID_ERROR.
The header section of the request message is carried by a The header section of the request message is carried by a
PUSH_PROMISE frame (see Section 7.2.5) on the request stream which PUSH_PROMISE frame (see Section 7.2.5) on the request stream which
generated the push. This allows the server push to be associated generated the push. This allows the server push to be associated
with a client request. with a client request.
Not all requests can be pushed. A server MAY push requests which Not all requests can be pushed. A server MAY push requests which
have the following properties: have the following properties:
o cacheable; see Section 7.2.3 of [SEMANTICS] o cacheable; see Section 8.2.3 of [SEMANTICS]
o safe; see Section 8.2.1 of [SEMANTICS]
o safe; see Section 7.2.1 of [SEMANTICS]
o does not include a request body or trailer section o does not include a request body or trailer section
The server MUST include a value in the ":authority" pseudo-header The server MUST include a value in the ":authority" pseudo-header
field for which the server is authoritative; see Section 3.4. field for which the server is authoritative; see Section 3.4.
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a Clients SHOULD send a CANCEL_PUSH frame upon receipt of a
PUSH_PROMISE frame carrying a request which is not cacheable, is not PUSH_PROMISE frame carrying a request which is not cacheable, is not
known to be safe, that indicates the presence of a request body, or known to be safe, that indicates the presence of a request body, or
for which it does not consider the server authoritative. for which it does not consider the server authoritative.
skipping to change at page 23, line 18 skipping to change at page 23, line 26
Endpoints MUST NOT initiate new requests or promise new pushes on the Endpoints MUST NOT initiate new requests or promise new pushes on the
connection after receipt of a GOAWAY frame from the peer. Clients connection after receipt of a GOAWAY frame from the peer. Clients
MAY establish a new connection to send additional requests. MAY establish a new connection to send additional requests.
Some requests or pushes might already be in transit: Some requests or pushes might already be in transit:
o Upon receipt of a GOAWAY frame, if the client has already sent o Upon receipt of a GOAWAY frame, if the client has already sent
requests with a Stream ID greater than or equal to the identifier requests with a Stream ID greater than or equal to the identifier
received in a GOAWAY frame, those requests will not be processed. received in a GOAWAY frame, those requests will not be processed.
Clients can safely retry unprocessed requests on a different Clients can safely retry unprocessed requests on a different
connection. connection. A client that is unable to retry requests loses all
requests that are in flight when the server closes the connection.
Requests on Stream IDs less than the Stream ID in a GOAWAY frame Requests on Stream IDs less than the Stream ID in a GOAWAY frame
from the server might have been processed; their status cannot be from the server might have been processed; their status cannot be
known until a response is received, the stream is reset known until a response is received, the stream is reset
individually, another GOAWAY is received, or the connection individually, another GOAWAY is received, or the connection
terminates. terminates.
Servers MAY reject individual requests on streams below the Servers MAY reject individual requests on streams below the
indicated ID if these requests were not processed. indicated ID if these requests were not processed.
skipping to change at page 23, line 41 skipping to change at page 23, line 50
a GOAWAY frame, those pushes will not be accepted. a GOAWAY frame, those pushes will not be accepted.
Servers SHOULD send a GOAWAY frame when the closing of a connection Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the is known in advance, even if the advance notice is small, so that the
remote peer can know whether a request has been partially processed remote peer can know whether a request has been partially processed
or not. For example, if an HTTP client sends a POST at the same time or not. For example, if an HTTP client sends a POST at the same time
that a server closes a QUIC connection, the client cannot know if the that a server closes a QUIC connection, the client cannot know if the
server started to process that POST request if the server does not server started to process that POST request if the server does not
send a GOAWAY frame to indicate what streams it might have acted on. send a GOAWAY frame to indicate what streams it might have acted on.
A client that is unable to retry requests loses all requests that are An endpoint MAY send multiple GOAWAY frames indicating different
in flight when the server closes the connection. An endpoint MAY identifiers, but the identifier in each frame MUST NOT be greater
send multiple GOAWAY frames indicating different identifiers, but the than the identifier in any previous frame, since clients might
identifier in each frame MUST NOT be greater than the identifier in already have retried unprocessed requests on another connection.
any previous frame, since clients might already have retried Receiving a GOAWAY containing a larger identifier than previously
unprocessed requests on another connection. Receiving a GOAWAY received MUST be treated as a connection error of type H3_ID_ERROR.
containing a larger identifier than previously received MUST be
treated as a connection error of type H3_ID_ERROR.
An endpoint that is attempting to gracefully shut down a connection An endpoint that is attempting to gracefully shut down a connection
can send a GOAWAY frame with a value set to the maximum possible can send a GOAWAY frame with a value set to the maximum possible
value (2^62-4 for servers, 2^62-1 for clients). This ensures that value (2^62-4 for servers, 2^62-1 for clients). This ensures that
the peer stops creating new requests or pushes. After allowing time the peer stops creating new requests or pushes. After allowing time
for any in-flight requests or pushes to arrive, the endpoint can send for any in-flight requests or pushes to arrive, the endpoint can send
another GOAWAY frame indicating which requests or pushes it might another GOAWAY frame indicating which requests or pushes it might
accept before the end of the connection. This ensures that a accept before the end of the connection. This ensures that a
connection can be cleanly shut down without losing requests. connection can be cleanly shut down without losing requests.
A client has more flexibility in the value it chooses for the Push ID A client has more flexibility in the value it chooses for the Push ID
in a GOAWAY that it sends. A value of 2^62 - 1 indicates that the in a GOAWAY that it sends. A value of 2^62 - 1 indicates that the
server can continue fulfilling pushes which have already been server can continue fulfilling pushes which have already been
promised, and the client can continue granting push credit as needed; promised, and the client can continue granting push credit as needed;
see Section 7.2.7. A smaller value indicates the client will reject see Section 7.2.7. A smaller value indicates the client will reject
pushes with Push IDs greater than or equal to this value. Like the pushes with Push IDs greater than or equal to this value. Like the
server, the client MAY send subsequent GOAWAY frames so long as the server, the client MAY send subsequent GOAWAY frames so long as the
specified Push ID is strictly smaller than all previously sent specified Push ID is no greater than any previously sent value.
values.
Even when a GOAWAY indicates that a given request or push will not be Even when a GOAWAY indicates that a given request or push will not be
processed or accepted upon receipt, the underlying transport processed or accepted upon receipt, the underlying transport
resources still exist. The endpoint that initiated these requests resources still exist. The endpoint that initiated these requests
can cancel them to clean up transport state. can cancel them to clean up transport state.
Once all accepted requests and pushes have been processed, the Once all accepted requests and pushes have been processed, the
endpoint can permit the connection to become idle, or MAY initiate an endpoint can permit the connection to become idle, or MAY initiate an
immediate closure of the connection. An endpoint that completes a immediate closure of the connection. An endpoint that completes a
graceful shutdown SHOULD use the H3_NO_ERROR code when closing the graceful shutdown SHOULD use the H3_NO_ERROR code when closing the
skipping to change at page 41, line 18 skipping to change at page 41, line 18
The security considerations of HTTP/3 should be comparable to those The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS. However, many of the considerations from of HTTP/2 with TLS. However, many of the considerations from
Section 10 of [HTTP2] apply to [QUIC-TRANSPORT] and are discussed in Section 10 of [HTTP2] apply to [QUIC-TRANSPORT] and are discussed in
that document. that document.
10.1. Server Authority 10.1. Server Authority
HTTP/3 relies on the HTTP definition of authority. The security HTTP/3 relies on the HTTP definition of authority. The security
considerations of establishing authority are discussed in considerations of establishing authority are discussed in
Section 11.1 of [SEMANTICS]. Section 12.1 of [SEMANTICS].
10.2. Cross-Protocol Attacks 10.2. Cross-Protocol Attacks
The use of ALPN in the TLS and QUIC handshakes establishes the target The use of ALPN in the TLS and QUIC handshakes establishes the target
application protocol before application-layer bytes are processed. application protocol before application-layer bytes are processed.
Because all QUIC packets are encrypted, it is difficult for an Because all QUIC packets are encrypted, it is difficult for an
attacker to control the plaintext bytes of an HTTP/3 connection which attacker to control the plaintext bytes of an HTTP/3 connection which
could be used in a cross-protocol attack on a plaintext protocol. could be used in a cross-protocol attack on a plaintext protocol.
10.3. Intermediary Encapsulation Attacks 10.3. Intermediary Encapsulation Attacks
The HTTP/3 field encoding allows the expression of names that are not The HTTP/3 field encoding allows the expression of names that are not
valid field names in the syntax used by HTTP (Section 4.3 of valid field names in the syntax used by HTTP (Section 5.3 of
[SEMANTICS]). Requests or responses containing invalid field names [SEMANTICS]). Requests or responses containing invalid field names
MUST be treated as malformed (Section 4.1.3). An intermediary MUST be treated as malformed (Section 4.1.3). An intermediary
therefore cannot translate an HTTP/3 request or response containing therefore cannot translate an HTTP/3 request or response containing
an invalid field name into an HTTP/1.1 message. an invalid field name into an HTTP/1.1 message.
Similarly, HTTP/3 allows field values that are not valid. While most Similarly, HTTP/3 allows field values that are not valid. While most
of the values that can be encoded will not alter field parsing, of the values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the
zero character (NUL, ASCII 0x0) might be exploited by an attacker if zero character (NUL, ASCII 0x0) might be exploited by an attacker if
they are translated verbatim. Any request or response that contains they are translated verbatim. Any request or response that contains
a character not permitted in a field value MUST be treated as a character not permitted in a field value MUST be treated as
malformed (Section 4.1.3). Valid characters are defined by the malformed (Section 4.1.3). Valid characters are defined by the
"field-content" ABNF rule in Section 4.4 of [SEMANTICS]. "field-content" ABNF rule in Section 5.4 of [SEMANTICS].
10.4. Cacheability of Pushed Responses 10.4. Cacheability of Pushed Responses
Pushed responses do not have an explicit request from the client; the Pushed responses do not have an explicit request from the client; the
request is provided by the server in the PUSH_PROMISE frame. request is provided by the server in the PUSH_PROMISE frame.
Caching responses that are pushed is possible based on the guidance Caching responses that are pushed is possible based on the guidance
provided by the origin server in the Cache-Control header field. provided by the origin server in the Cache-Control header field.
However, this can cause issues if a single server hosts more than one However, this can cause issues if a single server hosts more than one
tenant. For example, a server might offer multiple users each a tenant. For example, a server might offer multiple users each a
skipping to change at page 43, line 24 skipping to change at page 43, line 24
A large field section (Section 4.1) can cause an implementation to A large field section (Section 4.1) can cause an implementation to
commit a large amount of state. Header fields that are critical for commit a large amount of state. Header fields that are critical for
routing can appear toward the end of a header field section, which routing can appear toward the end of a header field section, which
prevents streaming of the header field section to its ultimate prevents streaming of the header field section to its ultimate
destination. This ordering and other reasons, such as ensuring cache destination. This ordering and other reasons, such as ensuring cache
correctness, mean that an endpoint likely needs to buffer the entire correctness, mean that an endpoint likely needs to buffer the entire
header field section. Since there is no hard limit to the size of a header field section. Since there is no hard limit to the size of a
field section, some endpoints could be forced to commit a large field section, some endpoints could be forced to commit a large
amount of available memory for header fields. amount of available memory for header fields.
An endpoint can use the SETTINGS_MAX_HEADER_LIST_SIZE An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE
(Section 7.2.4.1) setting to advise peers of limits that might apply (Section 7.2.4.1) setting to advise peers of limits that might apply
on the size of field sections. This setting is only advisory, so on the size of field sections. This setting is only advisory, so
endpoints MAY choose to send field sections that exceed this limit endpoints MAY choose to send field sections that exceed this limit
and risk having the request or response being treated as malformed. and risk having the request or response being treated as malformed.
This setting is specific to a connection, so any request or response This setting is specific to a connection, so any request or response
could encounter a hop with a lower, unknown limit. An intermediary could encounter a hop with a lower, unknown limit. An intermediary
can attempt to avoid this problem by passing on values presented by can attempt to avoid this problem by passing on values presented by
different peers, but they are not obligated to do so. different peers, but they are not obligated to do so.
A server that receives a larger field section than it is willing to A server that receives a larger field section than it is willing to
skipping to change at page 44, line 11 skipping to change at page 44, line 11
TCP connection remains in the TIME_WAIT state. Therefore, a proxy TCP connection remains in the TIME_WAIT state. Therefore, a proxy
cannot rely on QUIC stream limits alone to control the resources cannot rely on QUIC stream limits alone to control the resources
consumed by CONNECT requests. consumed by CONNECT requests.
10.6. Use of Compression 10.6. Use of Compression
Compression can allow an attacker to recover secret data when it is Compression can allow an attacker to recover secret data when it is
compressed in the same context as data under attacker control. compressed in the same context as data under attacker control.
HTTP/3 enables compression of fields (Section 4.1.1); the following HTTP/3 enables compression of fields (Section 4.1.1); the following
concerns also apply to the use of HTTP compressed content-codings; concerns also apply to the use of HTTP compressed content-codings;
see Section 6.1.2 of [SEMANTICS]. see Section 7.1.2 of [SEMANTICS].
There are demonstrable attacks on compression that exploit the There are demonstrable attacks on compression that exploit the
characteristics of the web (e.g., [BREACH]). The attacker induces characteristics of the web (e.g., [BREACH]). The attacker induces
multiple requests containing varying plaintext, observing the length multiple requests containing varying plaintext, observing the length
of the resulting ciphertext in each, which reveals a shorter length of the resulting ciphertext in each, which reveals a shorter length
when a guess about the secret is correct. when a guess about the secret is correct.
Implementations communicating on a secure channel MUST NOT compress Implementations communicating on a secure channel MUST NOT compress
content that includes both confidential and attacker-controlled data content that includes both confidential and attacker-controlled data
unless separate compression dictionaries are used for each source of unless separate compression dictionaries are used for each source of
skipping to change at page 51, line 51 skipping to change at page 51, line 51
12. References 12. References
12.1. Normative References 12.1. Normative References
[ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP [ALTSVC] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[CACHING] Fielding, R., Nottingham, M., and J. Reschke, "HTTP [CACHING] Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Caching", draft-ietf-httpbis-cache-08 (work in progress), Caching", draft-ietf-httpbis-cache-10 (work in progress),
May 2020. July 2020.
[HTTP-REPLAY] [HTTP-REPLAY]
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Header Compression for HTTP over QUIC", draft-ietf-quic- Header Compression for HTTP over QUIC", draft-ietf-quic-
qpack-16 (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-29 (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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<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>.
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March Security (TLS)", RFC 6125, DOI 10.17487/RFC6125, March
2011, <https://www.rfc-editor.org/info/rfc6125>. 2011, <https://www.rfc-editor.org/info/rfc6125>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011, DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>. <https://www.rfc-editor.org/info/rfc6265>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for [RFC8164] Nottingham, M. and M. Thomson, "Opportunistic Security for
HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017, HTTP/2", RFC 8164, DOI 10.17487/RFC8164, May 2017,
<https://www.rfc-editor.org/info/rfc8164>. <https://www.rfc-editor.org/info/rfc8164>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SEMANTICS] [SEMANTICS]
Fielding, R., Nottingham, M., and J. Reschke, "HTTP Fielding, R., Nottingham, M., and J. Reschke, "HTTP
Semantics", draft-ietf-httpbis-semantics-08 (work in Semantics", draft-ietf-httpbis-semantics-10 (work in
progress), May 2020. progress), July 2020.
12.2. Informative References 12.2. Informative References
[BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the [BREACH] Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the
CRIME Attack", July 2013, CRIME Attack", July 2013,
<http://breachattack.com/resources/ <http://breachattack.com/resources/
BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>. BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf>.
[HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>. <https://www.rfc-editor.org/info/rfc7541>.
[HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1 [HTTP11] Fielding, R., Nottingham, M., and J. Reschke, "HTTP/1.1
Messaging", draft-ietf-httpbis-messaging-08 (work in Messaging", draft-ietf-httpbis-messaging-10 (work in
progress), May 2020. progress), July 2020.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>. <https://www.rfc-editor.org/info/rfc6585>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP [TFO] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol [TLS13] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>. <https://www.rfc-editor.org/info/rfc8446>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
skipping to change at page 58, line 31 skipping to change at page 58, line 22
SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error. SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error.
SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and SETTINGS_INITIAL_WINDOW_SIZE: QUIC requires both stream and
connection flow control window sizes to be specified in the connection flow control window sizes to be specified in the
initial transport handshake. Specifying 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_FIELD_SECTION_SIZE: See Section 7.2.4.1. SETTINGS_MAX_HEADER_LIST_SIZE: This setting identifier has been
renamed SETTINGS_MAX_FIELD_SECTION_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 their value to limit it ported from HTTP/2 might choose to redefine their value to limit it
to 30 bits for more efficient encoding, or to make use of the 62-bit to 30 bits for more efficient encoding, or to make use of the 62-bit
space if more than 30 bits are required. space if more than 30 bits are required.
Settings need to be defined separately for HTTP/2 and HTTP/3. The Settings need to be defined separately for HTTP/2 and HTTP/3. The
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.2.2. equivalent HTTP/2 code point. See Section 11.2.2.
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, the differences between HTTP/2 and HTTP/3 HTTP/2 provides. However, the differences between HTTP/2 and HTTP/3
mean that error codes are not directly portable between versions. mean that error codes are not directly portable between versions.
The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map
 End of changes. 52 change blocks. 
90 lines changed or deleted 83 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/