draft-ietf-quic-http-17.txt   draft-ietf-quic-http-18.txt 
QUIC M. Bishop, Ed. QUIC M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track December 18, 2018 Intended status: Standards Track January 23, 2019
Expires: June 21, 2019 Expires: July 27, 2019
Hypertext Transfer Protocol Version 3 (HTTP/3) Hypertext Transfer Protocol Version 3 (HTTP/3)
draft-ietf-quic-http-17 draft-ietf-quic-http-18
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 June 21, 2019. This Internet-Draft will expire on July 27, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 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
skipping to change at page 2, line 34 skipping to change at page 2, line 34
2. Connection Setup and Management . . . . . . . . . . . . . . . 5 2. Connection Setup and Management . . . . . . . . . . . . . . . 5
2.1. Draft Version Identification . . . . . . . . . . . . . . 5 2.1. Draft Version Identification . . . . . . . . . . . . . . 5
2.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 5 2.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 5
2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6 2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6
2.3. Connection Establishment . . . . . . . . . . . . . . . . 6 2.3. Connection Establishment . . . . . . . . . . . . . . . . 6
2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7 2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7
3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7
3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8 3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8
3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8 3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8
3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 9 3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 9
3.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 10
3.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 10 3.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 10
4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 10
4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 10 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11
4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 11
4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 12 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 12
4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 14 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 15
4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 15 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 16
4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18
4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 18
4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 19 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 19
4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 20 4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 20
4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 21 4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 21
5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 21 5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 21
5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 21 5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 21
5.1.1. Header Formatting and Compression . . . . . . . . . . 22 5.1.1. Header Formatting and Compression . . . . . . . . . . 22
5.1.2. Request Cancellation . . . . . . . . . . . . . . . . 23 5.1.2. Request Cancellation and Rejection . . . . . . . . . 23
5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 24 5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 24
5.3. Request Prioritization . . . . . . . . . . . . . . . . . 25 5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 25
5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 26 5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 26
5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 26 5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 26
5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 27
6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 28 6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 28
6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 28 6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 28
6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 29 6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 29
6.3. Immediate Application Closure . . . . . . . . . . . . . . 30 6.3. Immediate Application Closure . . . . . . . . . . . . . . 30
6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 30 6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 30
7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 31 7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 31
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31
skipping to change at page 3, line 33 skipping to change at page 3, line 33
10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 36 10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 36
10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 37 10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 37
10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 39 10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 39
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40
11.1. Normative References . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 40
11.2. Informative References . . . . . . . . . . . . . . . . . 41 11.2. Informative References . . . . . . . . . . . . . . . . . 41
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 42 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 42
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 42
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 42 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 42
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 44 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 45
A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 45 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 45
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 46 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47
B.1. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 46 B.1. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 47
B.2. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 47 B.2. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 47
B.3. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 47 B.3. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 47
B.4. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 47 B.4. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 47
B.5. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 48 B.5. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 48
B.6. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 48 B.6. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 48
B.7. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 48 B.7. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 48
B.8. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 48 B.8. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 48
B.9. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 48 B.9. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 49
B.10. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 48 B.10. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 49
B.11. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 49 B.11. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 49
B.12. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 49 B.12. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 49
B.13. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 49 B.13. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 49
B.14. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 49 B.14. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 49
B.15. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 49 B.15. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 50
B.16. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 49 B.16. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 50
B.17. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 50 B.17. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 50
B.18. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 50 B.18. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 50
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 50 B.19. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 51
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51
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/2 introduced a framing and TCP mappings, HTTP/1.1 and HTTP/2. HTTP/2 introduced a framing and
multiplexing layer to improve latency without modifying the transport multiplexing layer to improve latency without modifying the transport
layer. However, TCP's lack of visibility into parallel requests in layer. However, TCP's lack of visibility into parallel requests in
both mappings limited the possible performance gains. both mappings limited the possible performance gains.
The QUIC transport protocol incorporates stream multiplexing and per- The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing stream flow control, similar to that provided by the HTTP/2 framing
layer. By providing reliability at the stream level and congestion layer. By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping. QUIC also improve the performance of HTTP compared to a TCP mapping. QUIC also
incorporates TLS 1.3 at the transport layer, offering comparable incorporates TLS 1.3 at the transport layer, offering comparable
security to running TLS over TCP, but with improved connection setup security to running TLS over TCP, but with improved connection setup
latency. latency (unless TCP Fast Open [RFC7413]} is used).
This document describes a mapping of HTTP semantics over the QUIC This document defines a mapping of HTTP semantics over the QUIC
transport protocol, drawing heavily on design of HTTP/2. This transport protocol, drawing heavily on the design of HTTP/2. This
document identifies HTTP/2 features that are subsumed by QUIC, and document identifies HTTP/2 features that are subsumed by QUIC, and
describes how the other features can be implemented atop QUIC. describes how the other features can be implemented atop QUIC.
QUIC is described in [QUIC-TRANSPORT]. For a full description of QUIC is described in [QUIC-TRANSPORT]. For a full description of
HTTP/2, see [RFC7540]. HTTP/2, see [RFC7540].
1.1. Notational Conventions 1.1. Notational Conventions
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
skipping to change at page 5, line 39 skipping to change at page 5, line 39
that any label MUST conform to the "token" syntax defined in that any label MUST conform to the "token" syntax defined in
Section 3.2.6 of [RFC7230]. Experimenters are encouraged to Section 3.2.6 of [RFC7230]. Experimenters are encouraged to
coordinate their experiments on the quic@ietf.org mailing list. coordinate their experiments on the quic@ietf.org mailing list.
2.2. Discovering an HTTP/3 Endpoint 2.2. Discovering an HTTP/3 Endpoint
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 2.3. ALTSVC frame ([ALTSVC]), using the ALPN token defined in Section 2.3.
For example, an origin could indicate in an HTTP/1.1 or HTTP/2 For example, an origin could indicate in an HTTP response that HTTP/3
response that HTTP/3 was available on UDP port 50781 at the same was available on UDP port 50781 at the same hostname by including the
hostname by including the following header field in any response: 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.
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
skipping to change at page 7, line 7 skipping to change at page 7, line 7
2.3. Connection Establishment 2.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
selecting the ALPN token "hq" in the TLS handshake. Support for selecting the ALPN token "h3" in the TLS handshake. Support for
other application-layer protocols MAY be offered in the same other application-layer protocols MAY be offered in the same
handshake. handshake.
While connection-level options pertaining to the core QUIC protocol While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, HTTP/3-specific settings are are set in the initial crypto handshake, HTTP/3-specific settings are
conveyed in the SETTINGS frame. After the QUIC connection is conveyed in the SETTINGS frame. After the QUIC connection is
established, a SETTINGS frame (Section 4.2.5) MUST be sent by each established, a SETTINGS frame (Section 4.2.5) MUST be sent by each
endpoint as the initial frame of their respective HTTP control stream endpoint as the initial frame of their respective HTTP control stream
(see Section 3.2.1). (see Section 3.2.1).
skipping to change at page 7, line 50 skipping to change at page 7, line 50
to the management of HTTP/3 connections. to the management of HTTP/3 connections.
3. Stream Mapping and Usage 3. Stream Mapping and Usage
A QUIC stream provides reliable in-order delivery of bytes, but makes A QUIC stream provides reliable in-order delivery of bytes, but makes
no guarantees about order of delivery with regard to bytes on other no guarantees about order of delivery with regard to bytes on other
streams. On the wire, data is framed into QUIC STREAM frames, but streams. On the wire, data is framed into QUIC STREAM frames, but
this framing is invisible to the HTTP framing layer. The transport this framing is invisible to the HTTP framing layer. The transport
layer buffers and orders received QUIC STREAM frames, exposing the layer buffers and orders received QUIC STREAM frames, exposing the
data contained within as a reliable byte stream to the application. data contained within as a reliable byte stream to the application.
Although QUIC permits out-of-order delivery within a stream HTTP/3
does not make use of this feature.
QUIC streams can be either unidirectional, carrying data only from QUIC streams can be either unidirectional, carrying data only from
initiator to receiver, or bidirectional. Streams can be initiated by initiator to receiver, or bidirectional. Streams can be initiated by
either the client or the server. For more detail on QUIC streams, either the client or the server. For more detail on QUIC streams,
see Section 2 of [QUIC-TRANSPORT]. see Section 2 of [QUIC-TRANSPORT].
When HTTP headers and data are sent over QUIC, the QUIC layer handles When HTTP headers and data are sent over QUIC, the QUIC layer handles
most of the stream management. HTTP does not need to do any separate most of the stream management. HTTP does not need to do any separate
multiplexing when using QUIC - data sent over a QUIC stream always multiplexing when using QUIC - data sent over a QUIC stream always
maps to a particular HTTP transaction or connection context. maps to a particular HTTP transaction or connection context.
skipping to change at page 9, line 25 skipping to change at page 9, line 25
the semantics are unknown. Recipients of unknown stream types MAY the semantics are unknown. Recipients of unknown stream types MAY
trigger a QUIC STOP_SENDING frame with an error code of trigger a QUIC STOP_SENDING frame with an error code of
HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an
error of any kind. error of any kind.
Implementations MAY send stream types before knowing whether the peer Implementations MAY send stream types before knowing whether the peer
supports them. However, stream types which could modify the state or supports them. However, stream types which could modify the state or
semantics of existing protocol components, including QPACK or other semantics of existing protocol components, including QPACK or other
extensions, MUST NOT be sent until the peer is known to support them. extensions, MUST NOT be sent until the peer is known to support them.
A sender can close or reset a unidirectional stream unless otherwise
specified. A receiver MUST tolerate unidirectional streams being
closed or reset prior to the reception of the unidirectional stream
header.
3.2.1. Control Streams 3.2.1. Control Streams
A control stream is indicated by a stream type of "0x43" (ASCII 'C'). A control stream is indicated by a stream type of "0x43" (ASCII 'C').
Data on this stream consists of HTTP/3 frames, as defined in Data on this stream consists of HTTP/3 frames, as defined in
Section 4.2. Section 4.2.
Each side MUST initiate a single control stream at the beginning of Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this the connection and send its SETTINGS frame as the first frame on this
stream. If the first frame of the control stream is any other frame stream. If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type type, this MUST be treated as a connection error of type
HTTP_MISSING_SETTINGS. Only one control stream per peer is HTTP_MISSING_SETTINGS. Only one control stream per peer is
permitted; receipt of a second stream which claims to be a control permitted; receipt of a second stream which claims to be a control
stream MUST be treated as a connection error of type stream MUST be treated as a connection error of type
HTTP_WRONG_STREAM_COUNT. If the control stream is closed at any HTTP_WRONG_STREAM_COUNT. The sender MUST NOT close the control
point, this MUST be treated as a connection error of type stream. If the control stream is closed at any point, this MUST be
HTTP_CLOSED_CRITICAL_STREAM. treated as a connection error of type HTTP_CLOSED_CRITICAL_STREAM.
A pair of unidirectional streams is used rather than a single A pair of unidirectional streams is used rather than a single
bidirectional stream. This allows either peer to send data as soon bidirectional stream. This allows either peer to send data as soon
they are able. Depending on whether 0-RTT is enabled on the they are able. Depending on whether 0-RTT is enabled on the
connection, either client or server might be able to send stream data connection, either client or server might be able to send stream data
first after the cryptographic handshake completes. first after the cryptographic handshake completes.
3.2.2. Push Streams 3.2.2. Push Streams
A push stream is indicated by a stream type of "0x50" (ASCII 'P'), A push stream is indicated by a stream type of "0x50" (ASCII 'P'),
skipping to change at page 10, line 38 skipping to change at page 10, line 44
semantic meaning, and can be sent when application-layer padding is semantic meaning, and can be sent when application-layer padding is
desired. They MAY also be sent on connections where no request data desired. They MAY also be sent on connections where no request data
is currently being transferred. Endpoints MUST NOT consider these is currently being transferred. Endpoints MUST NOT consider these
streams to have any meaning upon receipt. streams to have any meaning upon receipt.
The payload and length of the stream are selected in any manner the The payload and length of the stream are selected in any manner the
implementation chooses. implementation chooses.
4. HTTP Framing Layer 4. HTTP Framing Layer
Frames are used on control streams, request streams, and push As discussed above, frames are carried on QUIC streams and used on
streams. This section describes HTTP framing in QUIC. For a control streams, request streams, and push streams. This section
comparison with HTTP/2 frames, see Appendix A.2. describes HTTP framing in QUIC. For a comparison with HTTP/2 frames,
see Appendix A.2.
4.1. Frame Layout 4.1. Frame Layout
All frames have the following format: All frames have the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (i) ... | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 25 skipping to change at page 11, line 29
A frame includes the following fields: A frame includes the following fields:
Length: A variable-length integer that describes the length of the Length: A variable-length integer that describes the length of the
Frame Payload. This length does not include the Type field. Frame Payload. This length does not include the Type field.
Type: An 8-bit type for the frame. Type: An 8-bit type for the frame.
Frame Payload: A payload, the semantics of which are determined by Frame Payload: A payload, the semantics of which are determined by
the Type field. the Type field.
Each frame's payload MUST contain exactly the identified fields. A Each frame's payload MUST contain exactly the fields identified in
frame that contains additional bytes after the identified fields or a its description. A frame payload that contains additional bytes
frame that terminates before the end of the identified fields MUST be after the identified fields or a frame payload that terminates before
treated as a connection error of type HTTP_MALFORMED_FRAME. the end of the identified fields MUST be treated as a connection
error of type HTTP_MALFORMED_FRAME.
4.2. Frame Definitions 4.2. Frame Definitions
4.2.1. DATA 4.2.1. DATA
DATA frames (type=0x0) convey arbitrary, variable-length sequences of DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with an HTTP request or response payload. bytes associated with an HTTP request or response payload.
DATA frames MUST be associated with an HTTP request or response. If DATA frames MUST be associated with an HTTP request or response. If
a DATA frame is received on either control stream, the recipient MUST a DATA frame is received on either control stream, the recipient MUST
skipping to change at page 12, line 23 skipping to change at page 12, line 31
| Header Block (*) ... | Header Block (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: HEADERS frame payload Figure 5: HEADERS frame payload
HEADERS frames can only be sent on request / push streams. HEADERS frames can only be sent on request / push streams.
4.2.3. PRIORITY 4.2.3. PRIORITY
The PRIORITY (type=0x02) frame specifies the client-advised priority The PRIORITY (type=0x02) frame specifies the client-advised priority
of a stream. of a request, server push or placeholder.
When opening a new request stream, a PRIORITY frame MAY be sent as A PRIORITY frame identifies an element to prioritize, and an element
the first frame of the stream creating a dependency on an existing upon which it depends. A Prioritized ID or Dependency ID identifies
a client-initiated request using the corresponding stream ID, a
server push using a Push ID (see Section 4.2.6), or a placeholder
using a Placeholder ID (see Section 5.3.1).
When a client initiates a request, a PRIORITY frame MAY be sent as
the first frame of the stream, creating a dependency on an existing
element. In order to ensure that prioritization is processed in a element. In order to ensure that prioritization is processed in a
consistent order, any subsequent PRIORITY frames MUST be sent on the consistent order, any subsequent PRIORITY frames for that request
control stream. A PRIORITY frame received after other frames on a MUST be sent on the control stream. A PRIORITY frame received after
request stream MUST be treated as a stream error of type other frames on a request stream MUST be treated as a stream error of
HTTP_UNEXPECTED_FRAME. type HTTP_UNEXPECTED_FRAME.
If, by the time a new request stream is opened, its priority If, by the time a new request stream is opened, its priority
information has already been received via the control stream, the information has already been received via the control stream, the
PRIORITY frame sent on the request stream MUST be ignored. PRIORITY frame sent on the request stream MUST be ignored.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PT |DT | Empty | [Prioritized Element ID (i)] ... |PT |DT | Empty | [Prioritized Element ID (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| [Element Dependency ID (i)] ... | [Element Dependency ID (i)] ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight (8) | | Weight (8) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 6: PRIORITY frame payload Figure 6: PRIORITY frame payload
The PRIORITY frame payload has the following fields: The PRIORITY frame payload has the following fields:
Prioritized Type: A two-bit field indicating the type of element PT (Prioritized Element Type): A two-bit field indicating the type
being prioritized. When sent on a request stream, this MUST be of element being prioritized (see Table 1). When sent on a
set to "11". When sent on the control stream, this MUST NOT be request stream, this MUST be set to "11". When sent on the
set to "11". control stream, this MUST NOT be set to "11".
Dependency Type: A two-bit field indicating the type of element DT (Element Dependency Type): A two-bit field indicating the type of
being depended on. element being depended on (see Table 2).
Empty: A four-bit field which MUST be zero when sent and MUST be Empty: A four-bit field which MUST be zero when sent and MUST be
ignored on receipt. ignored on receipt.
Prioritized Element ID: A variable-length integer that identifies Prioritized Element ID: A variable-length integer that identifies
the element being prioritized. Depending on the value of the element being prioritized. Depending on the value of
Prioritized Type, this contains the Stream ID of a request stream, Prioritized Type, this contains the Stream ID of a request stream,
the Push ID of a promised resource, a Placeholder ID of a the Push ID of a promised resource, a Placeholder ID of a
placeholder, or is absent. placeholder, or is absent.
skipping to change at page 13, line 30 skipping to change at page 13, line 47
element on which a dependency is being expressed. Depending on element on which a dependency is being expressed. Depending on
the value of Dependency Type, this contains the Stream ID of a the value of Dependency Type, this contains the Stream ID of a
request stream, the Push ID of a promised resource, the request stream, the Push ID of a promised resource, the
Placeholder ID of a placeholder, or is absent. For details of Placeholder ID of a placeholder, or is absent. For details of
dependencies, see Section 5.3 and [RFC7540], Section 5.3. dependencies, see Section 5.3 and [RFC7540], Section 5.3.
Weight: An unsigned 8-bit integer representing a priority weight for Weight: An unsigned 8-bit integer representing a priority weight for
the prioritized element (see [RFC7540], Section 5.3). Add one to the prioritized element (see [RFC7540], Section 5.3). Add one to
the value to obtain a weight between 1 and 256. the value to obtain a weight between 1 and 256.
A PRIORITY frame identifies an element to prioritize, and an element The values for the Prioritized Element Type (Table 1) and Element
upon which it depends. A Prioritized ID or Dependency ID identifies Dependency Type (Table 2) imply the interpretation of the associated
a client-initiated request using the corresponding stream ID, a Element ID fields.
server push using a Push ID (see Section 4.2.6), or a placeholder
using a Placeholder ID (see Section 5.3.1).
The values for the Prioritized Element Type and Element Dependency +---------+------------------+---------------------------------+
Type imply the interpretation of the associated Element ID fields. | PT Bits | Type Description | Prioritized Element ID Contents |
+---------+------------------+---------------------------------+
| 00 | Request stream | Stream ID |
| | | |
| 01 | Push stream | Push ID |
| | | |
| 10 | Placeholder | Placeholder ID |
| | | |
| 11 | Current stream | Absent |
+---------+------------------+---------------------------------+
+-----------+------------------+---------------------------------+ Table 1: Prioritized Element Types
| Type Bits | Type Description | Prioritized Element ID Contents |
+-----------+------------------+---------------------------------+
| 00 | Request stream | Stream ID |
| | | |
| 01 | Push stream | Push ID |
| | | |
| 10 | Placeholder | Placeholder ID |
| | | |
| 11 | Current stream | Absent |
+-----------+------------------+---------------------------------+
+-----------+------------------+--------------------------------+
| Type Bits | Type Description | Element Dependency ID Contents |
+-----------+------------------+--------------------------------+
| 00 | Request stream | Stream ID |
| | | |
| 01 | Push stream | Push ID |
| | | |
| 10 | Placeholder | Placeholder ID |
| | | |
| 11 | Root of the tree | Absent |
+-----------+------------------+--------------------------------+
Note that the root of the tree cannot be referenced using a Stream ID +---------+------------------+--------------------------------+
of 0, as in [RFC7540]; QUIC stream 0 carries a valid HTTP request. | DT Bits | Type Description | Element Dependency ID Contents |
The root of the tree cannot be reprioritized. A PRIORITY frame sent +---------+------------------+--------------------------------+
on a request stream with the Prioritized Element Type set to any | 00 | Request stream | Stream ID |
value other than "11" or which expresses a dependency on a request | | | |
with a greater Stream ID than the current stream MUST be treated as a | 01 | Push stream | Push ID |
stream error of type HTTP_MALFORMED_FRAME. Likewise, a PRIORITY | | | |
frame sent on a control stream with the Prioritized Element Type set | 10 | Placeholder | Placeholder ID |
to "11" MUST be treated as a connection error of type | | | |
| 11 | Root of the tree | Absent |
+---------+------------------+--------------------------------+
Table 2: Element Dependency Types
Note that unlike in [RFC7540], the root of the tree cannot be
referenced using a Stream ID of 0, as in QUIC stream 0 carries a
valid HTTP request. The root of the tree cannot be reprioritized. A
PRIORITY frame sent on a request stream with the Prioritized Element
Type set to any value other than "11" or which expresses a dependency
on a request with a greater Stream ID than the current stream MUST be
treated as a stream error of type HTTP_MALFORMED_FRAME. Likewise, a
PRIORITY frame sent on a control stream with the Prioritized Element
Type set to "11" MUST be treated as a connection error of type
HTTP_MALFORMED_FRAME. HTTP_MALFORMED_FRAME.
When a PRIORITY frame claims to reference a request, the associated When a PRIORITY frame claims to reference a request, the associated
ID MUST identify a client-initiated bidirectional stream. A server ID MUST identify a client-initiated bidirectional stream. A server
MUST treat receipt of PRIORITY frame with a Stream ID of any other MUST treat receipt of a PRIORITY frame identifying a stream of any
type as a connection error of type HTTP_MALFORMED_FRAME. other type as a connection error of type HTTP_MALFORMED_FRAME.
A PRIORITY frame that references a non-existent Push ID or a A PRIORITY frame that references a non-existent Push ID, a
Placeholder ID greater than the server's limit MUST be treated as an Placeholder ID greater than the server's limit, or a Stream ID the
HTTP_MALFORMED_FRAME error. client is not yet permitted to open MUST be treated as an
HTTP_LIMIT_EXCEEDED error.
A PRIORITY frame received on any stream other than a request or A PRIORITY frame received on any stream other than a request or
control stream MUST be treated as a connection error of type control stream MUST be treated as a connection error of type
HTTP_WRONG_STREAM. HTTP_WRONG_STREAM.
PRIORITY frames received by a client MUST be treated as a stream PRIORITY frames received by a client MUST be treated as a stream
error of type HTTP_UNEXPECTED_FRAME. error of type HTTP_UNEXPECTED_FRAME.
4.2.4. CANCEL_PUSH 4.2.4. 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 created. 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 4.2.6), frame identifies a server push by Push ID (see Section 4.2.6),
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 server receives this frame, it aborts sending the response for
the identified server push. If the server has not yet started to the identified server push. If the server has not yet started to
send the server push, it can use the receipt of a CANCEL_PUSH frame send the server push, it can use the receipt of a CANCEL_PUSH frame
to avoid opening a push stream. If the push stream has been opened to avoid opening a push stream. If the push stream has been opened
by the server, the server SHOULD send a QUIC RESET_STREAM frame on by the server, the server SHOULD send a QUIC RESET_STREAM frame on
that stream and cease transmission of the response. that stream and cease transmission of the response.
A server can send this frame to indicate that it will not be A server can send the CANCEL_PUSH frame to indicate that it will not
fulfilling a promise prior to creation of a push stream. Once the be fulfilling a promise prior to creation of a push stream. Once the
push stream has been created, sending CANCEL_PUSH has no effect on push stream has been created, sending CANCEL_PUSH has no effect on
the state of the push stream. A QUIC RESET_STREAM frame SHOULD be the state of the push stream. A QUIC RESET_STREAM frame SHOULD be
used instead to abort transmission of the server push response. used instead to abort transmission of the server push response.
A CANCEL_PUSH frame is sent on the control stream. Sending 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 stream error of type HTTP_WRONG_STREAM. treated as a stream error of type HTTP_WRONG_STREAM.
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 7: CANCEL_PUSH frame payload Figure 7: 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 4.2.6). cancelled (see Section 4.2.6).
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.
An endpoint MUST treat a CANCEL_PUSH frame which does not contain
exactly one properly-formatted variable-length integer as a
connection error of type HTTP_MALFORMED_FRAME.
4.2.5. SETTINGS 4.2.5. 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".
SETTINGS frames always apply to a connection, never a single stream.
A SETTINGS frame MUST be sent as the first frame of each control
stream (see Section 3.2.1) by each peer, and MUST NOT be sent
subsequently or on any other stream. If an endpoint receives a
SETTINGS frame on a different stream, the endpoint MUST respond with
a connection error of type HTTP_WRONG_STREAM. If an endpoint
receives a second SETTINGS frame, the endpoint MUST respond with a
connection error of type HTTP_UNEXPECTED_FRAME.
SETTINGS parameters are not negotiated; they describe characteristics SETTINGS parameters are not negotiated; they describe characteristics
of the sending peer, which can be used by the receiving peer. of the sending peer, which can be used by the receiving peer.
However, a negotiation can be implied by the use of SETTINGS - each However, a negotiation can be implied by the use of SETTINGS - each
peer uses SETTINGS to advertise a set of supported values. The peer uses SETTINGS to advertise a set of supported values. The
definition of the setting would describe how each peer combines the definition of the setting would describe how each peer combines the
two sets to conclude which choice will be used. SETTINGS does not two sets to conclude which choice will be used. SETTINGS does not
provide a mechanism to identify when the choice takes effect. provide a mechanism to identify when the choice takes effect.
Different values for the same parameter can be advertised by each Different values for the same parameter can be advertised by each
peer. For example, a client might be willing to consume a very large peer. For example, a client might be willing to consume a very large
response header, while servers are more cautious about request size. response header, while servers are more cautious about request size.
Parameters MUST NOT occur more than once. A receiver MAY treat the Parameters MUST NOT occur more than once in the SETTINGS frame. A
presence of the same parameter more than once as a connection error receiver MAY treat the presence of the same parameter more than once
of type HTTP_MALFORMED_FRAME. as a connection error of type HTTP_MALFORMED_FRAME.
The payload of a SETTINGS frame consists of zero or more parameters, The payload of a SETTINGS frame consists of zero or more parameters,
each consisting of an unsigned 16-bit setting identifier and a value each consisting of an unsigned 16-bit setting identifier and a value
which uses the QUIC variable-length integer encoding. which uses the QUIC variable-length integer encoding.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (16) | Value (i) ... | Identifier (16) | Value (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SETTINGS parameter format Figure 8: SETTINGS parameter format
Each value MUST be compared against the remaining length of the
SETTINGS frame. A variable-length integer value which cannot fit
within the remaining length of the SETTINGS frame MUST cause the
SETTINGS frame to be considered malformed and trigger a connection
error of type HTTP_MALFORMED_FRAME.
An implementation MUST ignore the contents for any SETTINGS An implementation MUST ignore the contents for any SETTINGS
identifier it does not understand. identifier it does not understand.
SETTINGS frames always apply to a connection, never a single stream.
A SETTINGS frame MUST be sent as the first frame of each control
stream (see Section 3.2.1) by each peer, and MUST NOT be sent
subsequently or on any other stream. If an endpoint receives a
SETTINGS frame on a different stream, the endpoint MUST respond with
a connection error of type HTTP_WRONG_STREAM. If an endpoint
receives a second SETTINGS frame, the endpoint MUST respond with a
connection error of type HTTP_UNEXPECTED_FRAME.
The SETTINGS frame affects connection state. A badly formed or
incomplete SETTINGS frame MUST be treated as a connection error
(Section 8) of type HTTP_MALFORMED_FRAME.
4.2.5.1. Defined SETTINGS Parameters 4.2.5.1. Defined SETTINGS Parameters
The following settings are defined in HTTP/3: The following settings are defined in HTTP/3:
SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited. SETTINGS_MAX_HEADER_LIST_SIZE (0x6): The default value is unlimited.
See Section 5.1.1 for usage. See Section 5.1.1 for usage.
SETTINGS_NUM_PLACEHOLDERS (0x8): The default value is 0. However, SETTINGS_NUM_PLACEHOLDERS (0x8): The default value is 0. However,
this value SHOULD be set to a non-zero value by servers. See this value SHOULD be set to a non-zero value by servers. See
Section 5.3.1 for usage. Section 5.3.1 for usage.
skipping to change at page 18, line 8 skipping to change at page 18, line 8
settings values in determining whether to accept 0-RTT data. settings values in determining whether to accept 0-RTT data.
A server MAY accept 0-RTT and subsequently provide different settings A server MAY accept 0-RTT and subsequently provide different settings
in its SETTINGS frame. If 0-RTT data is accepted by the server, its in its SETTINGS frame. If 0-RTT data is accepted by the server, its
SETTINGS frame MUST NOT reduce any limits or alter any values that SETTINGS frame MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data. might be violated by the client with its 0-RTT data.
4.2.6. PUSH_PROMISE 4.2.6. PUSH_PROMISE
The PUSH_PROMISE frame (type=0x05) is used to carry a promised The PUSH_PROMISE frame (type=0x05) is used to carry a promised
request header set from server to client, as in HTTP/2. request header set from server to client on a request stream, as in
HTTP/2.
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) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Block (*) ... | Header Block (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: PUSH_PROMISE frame payload Figure 9: PUSH_PROMISE frame payload
skipping to change at page 18, line 37 skipping to change at page 18, line 38
Header Block: QPACK-compressed request header fields for the Header Block: QPACK-compressed request header fields for the
promised response. See [QPACK] for more details. promised response. See [QPACK] for more details.
A server MUST NOT use a Push ID that is larger than the client has A server MUST NOT use a Push ID that is larger than the client has
provided in a MAX_PUSH_ID frame (Section 4.2.8) and MUST NOT use the provided in a MAX_PUSH_ID frame (Section 4.2.8) and MUST NOT use the
same Push ID in multiple PUSH_PROMISE frames. A client MUST treat same Push ID in multiple PUSH_PROMISE frames. A client MUST treat
receipt of a PUSH_PROMISE that contains a larger Push ID than the receipt of a PUSH_PROMISE that contains a larger Push ID than the
client has advertised or a Push ID which has already been promised as client has advertised or a Push ID which has already been promised as
a connection error of type HTTP_MALFORMED_FRAME. a connection error of type HTTP_MALFORMED_FRAME.
If a PUSH_PROMISE frame is received on either control stream, the
recipient MUST respond with a connection error (Section 8) of type
HTTP_WRONG_STREAM.
See Section 5.4 for a description of the overall server push See Section 5.4 for a description of the overall server push
mechanism. mechanism.
4.2.7. GOAWAY 4.2.7. GOAWAY
The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of
a connection by a server. GOAWAY allows a server to stop accepting a connection by a server. GOAWAY allows a server to stop accepting
new requests while still finishing processing of previously received new requests while still finishing processing of previously received
requests. This enables administrative actions, like server requests. This enables administrative actions, like server
maintenance. GOAWAY by itself does not close a connection. maintenance. GOAWAY by itself does not close a connection.
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 ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: GOAWAY frame payload Figure 10: GOAWAY frame payload
The GOAWAY frame carries a QUIC Stream ID for a client-initiated The GOAWAY frame is always sent on the control stream. It carries a
bidirectional stream encoded as a variable-length integer. A client QUIC Stream ID for a client-initiated bidirectional stream encoded as
MUST treat receipt of a GOAWAY frame containing a Stream ID of any a variable-length integer. A client MUST treat receipt of a GOAWAY
other type as a connection error of type HTTP_MALFORMED_FRAME. frame containing a Stream ID of any other type as a connection error
of type HTTP_WRONG_STREAM.
Clients do not need to send GOAWAY to initiate a graceful shutdown; Clients do not need to send GOAWAY to initiate a graceful shutdown;
they simply stop making new requests. A server MUST treat receipt of they simply stop making new requests. A server MUST treat receipt of
a GOAWAY frame on any stream as a connection error (Section 8) of a GOAWAY frame on any stream as a connection error (Section 8) of
type HTTP_UNEXPECTED_FRAME. type HTTP_UNEXPECTED_FRAME.
The GOAWAY frame applies to the connection, not a specific stream. A The GOAWAY frame applies to the connection, not a specific stream. A
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_UNEXPECTED_FRAME. HTTP_UNEXPECTED_FRAME.
skipping to change at page 19, line 39 skipping to change at page 19, line 40
4.2.8. MAX_PUSH_ID 4.2.8. 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 a PUSH_PROMISE
frame. Consequently, this also limits the number of push streams frame. Consequently, this also limits the number of push streams
that the server can initiate in addition to the limit set by the QUIC that the server can initiate in addition to the limit set by the QUIC
MAX_STREAM_ID frame. MAX_STREAM_ID frame.
The MAX_PUSH_ID frame is always sent on a control stream. Receipt of The MAX_PUSH_ID frame is always sent on the control stream. Receipt
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_WRONG_STREAM. connection error of type HTTP_WRONG_STREAM.
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_MALFORMED_FRAME. HTTP_UNEXPECTED_FRAME.
The maximum Push ID is unset when a connection is created, meaning The maximum Push ID is unset when a connection is created, meaning
that a server cannot push until it receives a MAX_PUSH_ID frame. A that a server cannot push until it receives a MAX_PUSH_ID frame. A
client that wishes to manage the number of promised server pushes can client that wishes to manage the number of promised server pushes can
increase the maximum Push ID by sending MAX_PUSH_ID frames as the increase the maximum Push ID by sending MAX_PUSH_ID frames as the
server fulfills or cancels server pushes. server fulfills or cancels server pushes.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 20, line 20 skipping to change at page 20, line 20
Figure 11: MAX_PUSH_ID frame payload Figure 11: MAX_PUSH_ID frame payload
The MAX_PUSH_ID frame carries a single variable-length integer that The MAX_PUSH_ID frame carries a single variable-length integer that
identifies the maximum value for a Push ID that the server can use identifies the maximum value for a Push ID that the server can use
(see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum
Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than
previously received MUST be treated as a connection error of type previously received MUST be treated as a connection error of type
HTTP_MALFORMED_FRAME. HTTP_MALFORMED_FRAME.
A server MUST treat a MAX_PUSH_ID frame payload that does not contain
a single variable-length integer as a connection error of type
HTTP_MALFORMED_FRAME.
4.2.9. DUPLICATE_PUSH 4.2.9. DUPLICATE_PUSH
The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate The DUPLICATE_PUSH frame (type=0xE) is used by servers to indicate
that an existing pushed resource is related to multiple client that an existing pushed resource is related to multiple client
requests. requests.
The DUPLICATE_PUSH frame is always sent on a request stream. Receipt The DUPLICATE_PUSH frame is always sent on a request stream. Receipt
of a DUPLICATE_PUSH frame on any other stream MUST be treated as a of a DUPLICATE_PUSH frame on any other stream MUST be treated as a
connection error of type HTTP_WRONG_STREAM. connection error of type HTTP_WRONG_STREAM.
skipping to change at page 20, line 48 skipping to change at page 20, line 44
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 12: DUPLICATE_PUSH frame payload Figure 12: DUPLICATE_PUSH frame payload
The DUPLICATE_PUSH frame carries a single variable-length integer The DUPLICATE_PUSH frame carries a single variable-length integer
that identifies the Push ID of a resource that the server has that identifies the Push ID of a resource that the server has
previously promised (see Section 4.2.6). A server MUST treat a previously promised (see Section 4.2.6).
DUPLICATE_PUSH frame payload that does not contain a single variable-
length integer as a connection error of type HTTP_MALFORMED_FRAME.
This frame allows the server to use the same server push in response This frame allows the server to use the same server push in response
to multiple concurrent requests. Referencing the same server push to multiple concurrent requests. Referencing the same server push
ensures that a promise can be made in relation to every response in ensures that a promise can be made in relation to every response in
which server push might be needed without duplicating request headers which server push might be needed without duplicating request headers
or pushed responses. or pushed responses.
Allowing duplicate references to the same Push ID is primarily to Allowing duplicate references to the same Push ID is primarily to
reduce duplication caused by concurrent requests. A server SHOULD reduce duplication caused by concurrent requests. A server SHOULD
avoid reusing a Push ID over a long period. Clients are likely to avoid reusing a Push ID over a long period. Clients are likely to
skipping to change at page 21, line 36 skipping to change at page 21, line 30
consider these frames to have any meaning upon receipt. consider these frames to have any 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.
5. HTTP Request Lifecycle 5. HTTP Request Lifecycle
5.1. HTTP Message Exchanges 5.1. HTTP Message Exchanges
A client sends an HTTP request on a client-initiated bidirectional A client sends an HTTP request on a client-initiated bidirectional
QUIC stream. A server sends an HTTP response on the same stream as QUIC stream. A client MUST send only a single request on a given
the request. stream. A server sends one or more HTTP responses on the same stream
as the request, as detailed below.
An HTTP message (request or response) consists of: An HTTP message (request or response) consists of:
1. the message header (see [RFC7230], Section 3.2), sent as a single 1. the message header (see [RFC7230], Section 3.2), sent as a single
HEADERS frame (see Section 4.2.2), HEADERS frame (see Section 4.2.2),
2. the payload body (see [RFC7230], Section 3.3), sent as a series 2. the payload body (see [RFC7230], Section 3.3), sent as a series
of DATA frames (see Section 4.2.1), of DATA frames (see Section 4.2.1),
3. optionally, one HEADERS frame containing the trailer-part, if 3. optionally, one HEADERS frame containing the trailer-part, if
skipping to change at page 23, line 37 skipping to change at page 23, line 31
An HTTP/3 implementation MAY impose a limit on the maximum size of An HTTP/3 implementation MAY impose a limit on the maximum size of
the header it will accept on an individual HTTP message; encountering the header it will accept on an individual HTTP message; encountering
a larger message header SHOULD be treated as a stream error of type a larger message header SHOULD be treated as a stream error of type
"HTTP_EXCESSIVE_LOAD". If an implementation wishes to advise its "HTTP_EXCESSIVE_LOAD". If an implementation wishes to advise its
peer of this limit, it can be conveyed as a number of bytes in the peer of this limit, it can be conveyed as a number of bytes in the
"SETTINGS_MAX_HEADER_LIST_SIZE" parameter. The size of a header list "SETTINGS_MAX_HEADER_LIST_SIZE" parameter. The size of a header list
is calculated based on the uncompressed size of header fields, is calculated based on the uncompressed size of header fields,
including the length of the name and value in bytes plus an overhead including the length of the name and value in bytes plus an overhead
of 32 bytes for each header field. of 32 bytes for each header field.
5.1.2. Request Cancellation 5.1.2. Request Cancellation and Rejection
Either client or server can cancel requests by aborting the stream
(QUIC RESET_STREAM and/or STOP_SENDING frames, as appropriate) with
an error code of HTTP_REQUEST_CANCELLED (Section 8.1). When the
client cancels a response, it indicates that this response is no
longer of interest. Implementations SHOULD cancel requests by
aborting both directions of a stream.
When the server aborts its response stream using Clients can cancel requests by aborting the stream (QUIC RESET_STREAM
HTTP_REQUEST_CANCELLED, it indicates that no application processing and/or STOP_SENDING frames, as appropriate) with an error code of
was performed. The client can treat requests cancelled by the server HTTP_REQUEST_CANCELLED (Section 8.1). When the client cancels a
as though they had never been sent at all, thereby allowing them to response, it indicates that this response is no longer of interest.
be retried later on a new connection. Servers MUST NOT use the Implementations SHOULD cancel requests by aborting both directions of
HTTP_REQUEST_CANCELLED status for requests which were partially or a stream.
fully processed.
Note: In this context, "processed" means that some data from the When the server rejects a request without performing any application
stream was passed to some higher layer of software that might have processing, it SHOULD abort its response stream with the error code
taken some action as a result. HTTP_REQUEST_REJECTED. In this context, "processed" means that some
data from the stream was passed to some higher layer of software that
might have taken some action as a result. The client can treat
requests rejected by the server as though they had never been sent at
all, thereby allowing them to be retried later on a new connection.
Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for
requests which were partially or fully processed. When a client
sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a server MAY
indicate the error code HTTP_REQUEST_REJECTED in the corresponding
RESET_STREAM if no processing was performed. Clients MUST NOT reset
streams with the HTTP_REQUEST_REJECTED error code except in response
to a QUIC STOP_SENDING frame.
If a stream is cancelled after receiving a complete response, the If a stream is cancelled after receiving a complete response, the
client MAY ignore the cancellation and use the response. However, if client MAY ignore the cancellation and use the response. However, if
a stream is cancelled after receiving a partial response, the a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used. Automatically retrying such requests is response SHOULD NOT be used. Automatically retrying such requests is
not possible, unless this is otherwise permitted (e.g., idempotent not possible, unless this is otherwise permitted (e.g., idempotent
actions like GET, PUT, or DELETE). actions like GET, PUT, or DELETE).
5.2. The CONNECT Method 5.2. The CONNECT Method
skipping to change at page 25, line 14 skipping to change at page 25, line 12
so clients SHOULD NOT close a stream for sending while they still so clients SHOULD NOT close a stream for sending while they still
expect to receive data from the target of the CONNECT. expect to receive data from the target of the CONNECT.
A TCP connection error is signaled with QUIC RESET_STREAM frame. A A TCP connection error is signaled with QUIC RESET_STREAM frame. A
proxy treats any error in the TCP connection, which includes proxy treats any error in the TCP connection, which includes
receiving a TCP segment with the RST bit set, as a stream error of receiving a TCP segment with the RST bit set, as a stream error of
type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, a proxy MUST type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, a proxy MUST
send a TCP segment with the RST bit set if it detects an error with send a TCP segment with the RST bit set if it detects an error with
the stream or the QUIC connection. the stream or the QUIC connection.
5.3. Request Prioritization 5.3. Prioritization
HTTP/3 uses a priority scheme similar to that described in [RFC7540], HTTP/3 uses a priority scheme similar to that described in [RFC7540],
Section 5.3. In this priority scheme, a given stream can be Section 5.3. In this priority scheme, a given element can be
designated as dependent upon another request, which expresses the designated as dependent upon another element. This information is
preference that the latter stream (the "parent" request) be allocated expressed in the PRIORITY frame Section 4.2.3 which identifies the
resources before the former stream (the "dependent" request). Taken element and the dependency. The elements that can be prioritized
together, the dependencies across all requests in a connection form a are:
dependency tree.
When a client request is first sent, its parent and weight are
determined by the PRIORITY frame (see Section 4.2.3) which begins the
stream, if present. Otherwise, the element is dependent on the root
of the priority tree. Placeholders are also dependent on the root of
the priority tree when first allocated. Pushed streams are initially
dependent on the client request on which the PUSH_PROMISE frame was
sent. In all cases, elements are assigned an initial weight of 16
unless an PRIORITY frame begins the stream.
The structure of the dependency tree changes as PRIORITY frames on
the control stream modify the dependency links between requests. The
PRIORITY frame Section 4.2.3 identifies a prioritized element. The
elements which can be prioritized are:
o Requests, identified by the ID of the request stream o Requests, identified by the ID of the request stream
o Pushes, identified by the Push ID of the promised resource o Pushes, identified by the Push ID of the promised resource
(Section 4.2.6) (Section 4.2.6)
o Placeholders, identified by a Placeholder ID o Placeholders, identified by a Placeholder ID
An element can depend on another element or on the root of the tree. Taken together, the dependencies across all prioritized elements in a
A reference to an element which is no longer in the tree is treated connection form a dependency tree. An element can depend on another
as a reference to the root of the tree. element or on the root of the tree. A reference to an element which
is no longer in the tree is treated as a reference to the root of the
tree. The structure of the dependency tree changes as PRIORITY
frames modify the dependency links between prioritized elements.
Due to reordering between streams, an element can also be prioritized Due to reordering between streams, an element can also be prioritized
which is not yet in the tree. Such elements are added to the tree which is not yet in the tree. Such elements are added to the tree
with the requested priority. with the requested priority.
When a prioritized element is first created, it has a default initial
weight of 16 and a default dependency. Requests and placeholders are
dependent on the root of the priority tree; pushes are dependent on
the client request on which the PUSH_PROMISE frame was sent.
Requests may override the default intial values by including a
PRIORTIY frame (see Section 4.2.3) at the beginning of the stream.
These priorities can be updated by sending a PRIORITY frame on the
control stream.
5.3.1. Placeholders 5.3.1. Placeholders
In HTTP/2, certain implementations used closed or unused streams as In HTTP/2, certain implementations used closed or unused streams as
placeholders in describing the relative priority of requests. This placeholders in describing the relative priority of requests. This
created confusion as servers could not reliably identify which created confusion as servers could not reliably identify which
elements of the priority tree could be discarded safely. Clients elements of the priority tree could be discarded safely. Clients
could potentially reference closed streams long after the server had could potentially reference closed streams long after the server had
discarded state, leading to disparate views of the prioritization the discarded state, leading to disparate views of the prioritization the
client had attempted to express. client had attempted to express.
In HTTP/3, a number of placeholders are explicitly permitted by the In HTTP/3, a number of placeholders are explicitly permitted by the
server using the "SETTINGS_NUM_PLACEHOLDERS" setting. Because the server using the "SETTINGS_NUM_PLACEHOLDERS" setting. Because the
server commits to maintaining these IDs in the tree, clients can use server commits to maintaining these placeholders in the
them with confidence that the server will not have discarded the prioritization tree, clients can use them with confidence that the
state. Clients MUST NOT send the "SETTINGS_NUM_PLACEHOLDERS" server will not have discarded the state. Clients MUST NOT send the
setting; receipt of this setting by a server MUST be treated as a "SETTINGS_NUM_PLACEHOLDERS" setting; receipt of this setting by a
connection error of type "HTTP_WRONG_SETTING_DIRECTION". server MUST be treated as a connection error of type
"HTTP_WRONG_SETTING_DIRECTION".
Placeholders are identified by an ID between zero and one less than Placeholders are identified by an ID between zero and one less than
the number of placeholders the server has permitted. the number of placeholders the server has permitted.
Like streams, placeholders have priority information associated with Like streams, placeholders have priority information associated with
them. them.
5.3.2. Priority Tree Maintenance 5.3.2. Priority Tree Maintenance
Servers can aggressively prune inactive regions from the priority Because placeholders will be used to "root" any persistent structure
tree, because placeholders will be used to "root" any persistent of the tree which the client cares about retaining, servers can
structure of the tree which the client cares about retaining. For aggressively prune inactive regions from the priority tree. For
prioritization purposes, a node in the tree is considered "inactive" prioritization purposes, a node in the tree is considered "inactive"
when the corresponding stream has been closed for at least two round- when the corresponding stream has been closed for at least two round-
trip times (using any reasonable estimate available on the server). trip times (using any reasonable estimate available on the server).
This delay helps mitigate race conditions where the server has pruned This delay helps mitigate race conditions where the server has pruned
a node the client believed was still active and used as a Stream a node the client believed was still active and used as a Stream
Dependency. Dependency.
Specifically, the server MAY at any time: Specifically, the server MAY at any time:
o Identify and discard branches of the tree containing only inactive o Identify and discard branches of the tree containing only inactive
skipping to change at page 27, line 45 skipping to change at page 27, line 45
frames (see Section 4.2.9), then included with the push stream which frames (see Section 4.2.9), then included with the push stream which
ultimately fulfills those promises. ultimately fulfills those promises.
Server push is only enabled on a connection when a client sends a Server push is only enabled on a connection when a client sends a
MAX_PUSH_ID frame (see Section 4.2.8). A server cannot use server MAX_PUSH_ID frame (see Section 4.2.8). A server cannot use server
push until it receives a MAX_PUSH_ID frame. A client sends push until it receives a MAX_PUSH_ID frame. A client sends
additional MAX_PUSH_ID frames to control the number of pushes that a additional MAX_PUSH_ID frames to control the number of pushes that a
server can promise. A server SHOULD use Push IDs sequentially, server can promise. A server SHOULD use Push IDs sequentially,
starting at 0. A client MUST treat receipt of a push stream with a starting at 0. A client MUST treat receipt of a push stream with a
Push ID that is greater than the maximum Push ID as a connection Push ID that is greater than the maximum Push ID as a connection
error of type HTTP_PUSH_LIMIT_EXCEEDED. error of type HTTP_LIMIT_EXCEEDED.
The header of the request message is carried by a PUSH_PROMISE frame The header of the request message is carried by a PUSH_PROMISE frame
(see Section 4.2.6) on the request stream which generated the push. (see Section 4.2.6) on the request stream which generated the push.
This allows the server push to be associated with a client request. This allows the server push to be associated with a client request.
Ordering of a PUSH_PROMISE in relation to certain parts of the Ordering of a PUSH_PROMISE in relation to certain parts of the
response is important (see Section 8.2.1 of [RFC7540]). Promised response is important (see Section 8.2.1 of [RFC7540]). Promised
requests MUST conform to the requirements in Section 8.2 of requests MUST conform to the requirements in Section 8.2 of
[RFC7540]. [RFC7540].
The same server push can be associated with additional client The same server push can be associated with additional client
skipping to change at page 28, line 50 skipping to change at page 28, line 50
6.1. Idle Connections 6.1. Idle Connections
Each QUIC endpoint declares an idle timeout during the handshake. If Each QUIC endpoint declares an idle timeout during the handshake. If
the connection remains idle (no packets received) for longer than the connection remains idle (no packets received) for longer than
this duration, the peer will assume that the connection has been this duration, the peer will assume that the connection has been
closed. HTTP/3 implementations will need to open a new connection closed. HTTP/3 implementations will need to open a new connection
for new requests if the existing connection has been idle for longer for new requests if the existing connection has been idle for longer
than the server's advertised idle timeout, and SHOULD do so if than the server's advertised idle timeout, and SHOULD do so if
approaching the idle timeout. approaching the idle timeout.
HTTP clients are expected to use QUIC PING frames to keep connections HTTP clients are expected to request that the transport keep
open while there are responses outstanding for requests or server connections open while there are responses outstanding for requests
pushes. If the client is not expecting a response from the server, or server pushes, as described in Section 19.2 of [QUIC-TRANSPORT].
allowing an idle connection to time out is preferred over expending If the client is not expecting a response from the server, allowing
effort maintaining a connection that might not be needed. A gateway an idle connection to time out is preferred over expending effort
MAY use PING to maintain connections in anticipation of need rather maintaining a connection that might not be needed. A gateway MAY
than incur the latency cost of connection establishment to servers. maintain connections in anticipation of need rather than incur the
Servers SHOULD NOT use PING frames to keep a connection open. latency cost of connection establishment to servers. Servers SHOULD
NOT actively keep connections open.
6.2. Connection Shutdown 6.2. Connection Shutdown
Even when a connection is not idle, either endpoint can decide to Even when a connection is not idle, either endpoint can decide to
stop using the connection and let the connection close gracefully. stop using the connection and let the connection close gracefully.
Since clients drive request generation, clients perform a connection Since clients drive request generation, clients perform a connection
shutdown by not sending additional requests on the connection; shutdown by not sending additional requests on the connection;
responses and pushed responses associated to previous requests will responses and pushed responses associated to previous requests will
continue to completion. Servers perform the same function by continue to completion. Servers perform the same function by
communicating with clients. communicating with clients.
Servers initiate the shutdown of a connection by sending a GOAWAY Servers initiate the shutdown of a connection by sending a GOAWAY
frame (Section 4.2.7). The GOAWAY frame indicates that client- frame (Section 4.2.7). The GOAWAY frame indicates that client-
initiated requests on lower stream IDs were or might be processed in initiated requests on lower stream IDs were or might be processed in
this connection, while requests on the indicated stream ID and this connection, while requests on the indicated stream ID and
greater were not accepted. This enables client and server to agree greater were rejected. This enables client and server to agree on
on which requests were accepted prior to the connection shutdown. which requests were accepted prior to the connection shutdown. This
This identifier MAY be lower than the stream limit identified by a identifier MAY be lower than the stream limit identified by a QUIC
QUIC MAX_STREAM_ID frame, and MAY be zero if no requests were MAX_STREAM_ID frame, and MAY be zero if no requests were processed.
processed. Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after
after sending a GOAWAY frame. sending a GOAWAY frame.
Once sent, the server MUST cancel requests sent on streams with an Once GOAWAY is sent, the server MUST reject requests sent on streams
identifier higher than the indicated last Stream ID. Clients MUST with an identifier greater than or equal to the indicated last Stream
NOT send new requests on the connection after receiving GOAWAY, ID. Clients MUST NOT send new requests on the connection after
although requests might already be in transit. A new connection can receiving GOAWAY, although requests might already be in transit. A
be established for new requests. new connection can be established for new requests.
If the client has sent requests on streams with a higher Stream ID If the client has sent requests on streams with a Stream ID greater
than indicated in the GOAWAY frame, those requests are considered than or equal to that indicated in the GOAWAY frame, those requests
cancelled (Section 5.1.2). Clients SHOULD reset any streams above are considered rejected (Section 5.1.2). Clients SHOULD cancel any
this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also requests on streams above this ID. Servers MAY also reject requests
cancel requests on streams below the indicated ID if these requests on streams below the indicated ID if these requests were not
were not processed. processed.
Requests on Stream IDs less than the Stream ID in the GOAWAY frame Requests on Stream IDs less than the Stream ID in the GOAWAY frame
might have been processed; their status cannot be known until they might have been processed; their status cannot be known until they
are completed successfully, reset individually, or the connection are completed successfully, reset individually, or the connection
terminates. terminates.
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 stream has been partially processed or remote peer can know whether a request has been partially processed
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 A client that is unable to retry requests loses all requests that are
in flight when the server closes the connection. A server MAY send in flight when the server closes the connection. A server MAY send
multiple GOAWAY frames indicating different stream IDs, but MUST NOT multiple GOAWAY frames indicating different stream IDs, but MUST NOT
increase the value they send in the last Stream ID, since clients increase the value they send in the last Stream ID, since clients
might already have retried unprocessed requests on another might already have retried unprocessed requests on another
connection. A server that is attempting to gracefully shut down a connection. A server that is attempting to gracefully shut down a
skipping to change at page 32, line 49 skipping to change at page 32, line 49
HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is
exhibiting a behavior that might be generating excessive load. exhibiting a behavior that might be generating excessive load.
HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be
served over HTTP/3. The peer should retry over HTTP/1.1. served over HTTP/3. The peer should retry over HTTP/1.1.
HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it
is not permitted. is not permitted.
HTTP_PUSH_LIMIT_EXCEEDED (0x0B): A Push ID greater than the current HTTP_LIMIT_EXCEEDED (0x0B): A Stream ID, Push ID, or Placeholder ID
maximum Push ID was referenced. greater than the current maximum for that identifier was
referenced.
HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two HTTP_DUPLICATE_PUSH (0x0C): A Push ID was referenced in two
different stream headers. different stream headers.
HTTP_UNKNOWN_STREAM_TYPE (0x0D): A unidirectional stream header HTTP_UNKNOWN_STREAM_TYPE (0x0D): A unidirectional stream header
contained an unknown stream type. contained an unknown stream type.
HTTP_WRONG_STREAM_COUNT (0x0E): A unidirectional stream type was HTTP_WRONG_STREAM_COUNT (0x0E): A unidirectional stream type was
used more times than is permitted by that type. used more times than is permitted by that type.
skipping to change at page 33, line 30 skipping to change at page 33, line 30
HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request
is not needed to produce a response. For use in STOP_SENDING is not needed to produce a response. For use in STOP_SENDING
only. only.
HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at
the beginning of the control stream. the beginning of the control stream.
HTTP_UNEXPECTED_FRAME (0x0013): A frame was received which was not HTTP_UNEXPECTED_FRAME (0x0013): A frame was received which was not
permitted in the current state. permitted in the current state.
HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without
performing any application processing.
HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol HTTP_GENERAL_PROTOCOL_ERROR (0x00FF): Peer violated protocol
requirements in a way which doesn't match a more specific error requirements in a way which doesn't match a more specific error
code, or endpoint declines to use the more specific error code. code, or endpoint declines to use the more specific error code.
HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type.
The frame type is included as the last byte of the error code. The frame type is included as the last byte of the error code.
For example, an error in a MAX_PUSH_ID frame would be indicated For example, an error in a MAX_PUSH_ID frame would be indicated
with the code (0x10D). with the code (0x10D).
9. Security Considerations 9. Security Considerations
skipping to change at page 38, line 34 skipping to change at page 38, line 34
| | | excessive | | | | | excessive | |
| | | load | | | | | load | |
| | | | | | | | | |
| HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 8.1 | | HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 8.1 |
| | | HTTP/1.1 | | | | | HTTP/1.1 | |
| | | | | | | | | |
| HTTP_WRONG_STREAM | 0x000A | A frame was | Section 8.1 | | HTTP_WRONG_STREAM | 0x000A | A frame was | Section 8.1 |
| | | sent on the | | | | | sent on the | |
| | | wrong stream | | | | | wrong stream | |
| | | | | | | | | |
| HTTP_PUSH_LIMIT_EXCEEDED | 0x000B | Maximum Push | Section 8.1 | | HTTP_LIMIT_EXCEEDED | 0x000B | An identifier | Section 8.1 |
| | | ID exceeded | | | | | limit was | |
| | | exceeded | |
| | | | | | | | | |
| HTTP_DUPLICATE_PUSH | 0x000C | Push ID was | Section 8.1 | | HTTP_DUPLICATE_PUSH | 0x000C | Push ID was | Section 8.1 |
| | | fulfilled | | | | | fulfilled | |
| | | multiple | | | | | multiple | |
| | | times | | | | | times | |
| | | | | | | | | |
| HTTP_UNKNOWN_STREAM_TYPE | 0x000D | Unknown unidi | Section 8.1 | | HTTP_UNKNOWN_STREAM_TYPE | 0x000D | Unknown unidi | Section 8.1 |
| | | rectional | | | | | rectional | |
| | | stream type | | | | | stream type | |
| | | | | | | | | |
skipping to change at page 39, line 24 skipping to change at page 39, line 25
| | | | | | | | | |
| HTTP_MISSING_SETTINGS | 0x0012 | No SETTINGS | Section 8.1 | | HTTP_MISSING_SETTINGS | 0x0012 | No SETTINGS | Section 8.1 |
| | | frame | | | | | frame | |
| | | received | | | | | received | |
| | | | | | | | | |
| HTTP_UNEXPECTED_FRAME | 0x0013 | Frame not | Section 8.1 | | HTTP_UNEXPECTED_FRAME | 0x0013 | Frame not | Section 8.1 |
| | | permitted in | | | | | permitted in | |
| | | the current | | | | | the current | |
| | | state | | | | | state | |
| | | | | | | | | |
| HTTP_REQUEST_REJECTED | 0x0014 | Request not | Section 8.1 |
| | | processed | |
| | | | |
| HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 | | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 |
| | | frame | | | | | frame | |
| | | formatting | | | | | formatting | |
+---------------------------+--------+---------------+--------------+ +---------------------------+--------+---------------+--------------+
10.6. Stream Types 10.6. 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 manages an 8-bit space. types. The "HTTP/3 Stream Type" registry manages an 8-bit space.
The "HTTP/3 Stream Type" registry operates under either of the "IETF The "HTTP/3 Stream Type" registry operates under either of the "IETF
skipping to change at page 40, line 34 skipping to change at page 40, line 39
11. References 11. References
11.1. Normative References 11.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>.
[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-05 (work in progress), December 2018. qpack-06 (work in progress), January 2019.
[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-16 (work in progress), December 2018. transport-17 (work in progress), January 2019.
[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 41, line 45 skipping to change at page 41, line 50
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>.
11.2. Informative References 11.2. Informative References
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <https://www.rfc-editor.org/info/rfc7301>. July 2014, <https://www.rfc-editor.org/info/rfc7301>.
[RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>.
[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>.
11.3. URIs 11.3. URIs
[1] https://mailarchive.ietf.org/arch/search/?email_list=quic [1] https://mailarchive.ietf.org/arch/search/?email_list=quic
[2] https://github.com/quicwg [2] https://github.com/quicwg
skipping to change at page 42, line 42 skipping to change at page 42, line 47
A.1. Streams A.1. Streams
HTTP/3 permits use of a larger number of streams (2^62-1) than HTTP/3 permits use of a larger number of streams (2^62-1) than
HTTP/2. The considerations about exhaustion of stream identifier HTTP/2. The considerations about exhaustion of stream identifier
space apply, though the space is significantly larger such that it is space apply, though the space is significantly larger such that it is
likely that other limits in QUIC are reached first, such as the limit likely that other limits in QUIC are reached first, such as the limit
on the connection flow control window. on the connection flow control window.
A.2. HTTP Frame Types A.2. HTTP Frame Types
Many framing concepts from HTTP/2 can be elided away on QUIC, because Many framing concepts from HTTP/2 can be elided on QUIC, because the
the transport deals with them. Because frames are already on a transport deals with them. Because frames are already on a stream,
stream, they can omit the stream number. Because frames do not block they can omit the stream number. Because frames do not block
multiplexing (QUIC's multiplexing occurs below this layer), the multiplexing (QUIC's multiplexing occurs below this layer), the
support for variable-maximum-length packets can be removed. Because support for variable-maximum-length packets can be removed. Because
stream termination is handled by QUIC, an END_STREAM flag is not stream termination is handled by QUIC, an END_STREAM flag is not
required. This permits the removal of the Flags field from the required. This permits the removal of the Flags field from the
generic frame layout. generic frame layout.
Frame payloads are largely drawn from [RFC7540]. However, QUIC Frame payloads are largely drawn from [RFC7540]. However, QUIC
includes many features (e.g. flow control) which are also present in includes many features (e.g., flow control) which are also present in
HTTP/2. In these cases, the HTTP mapping does not re-implement them. HTTP/2. In these cases, the HTTP mapping does not re-implement them.
As a result, several HTTP/2 frame types are not required in HTTP/3. As a result, several HTTP/2 frame types are not required in HTTP/3.
Where an HTTP/2-defined frame is no longer used, the frame ID has Where an HTTP/2-defined frame is no longer used, the frame ID has
been reserved in order to maximize portability between HTTP/2 and been reserved in order to maximize portability between HTTP/2 and
HTTP/3 implementations. However, even equivalent frames between the HTTP/3 implementations. However, even equivalent frames between the
two mappings are not identical. two mappings are not identical.
Many of the differences arise from the fact that HTTP/2 provides an Many of the differences arise from the fact that HTTP/2 provides an
absolute ordering between frames across all streams, while QUIC absolute ordering between frames across all streams, while QUIC
provides this guarantee on each stream only. As a result, if a frame provides this guarantee on each stream only. As a result, if a frame
skipping to change at page 46, line 21 skipping to change at page 46, line 29
SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of
SETTINGS is defined. SETTINGS is defined.
STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream
management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION
from the QUIC layer. from the QUIC layer.
FRAME_SIZE_ERROR (0x6): HTTP_MALFORMED_FRAME error codes defined in FRAME_SIZE_ERROR (0x6): HTTP_MALFORMED_FRAME error codes defined in
Section 8.1. Section 8.1.
REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream REFUSED_STREAM (0x7): HTTP_REQUEST_REJECTED (in Section 8.1) is used
management. Would provoke a STREAM_ID_ERROR from the QUIC layer. to indicate that a request was not processed. Otherwise, not
applicable because QUIC handles stream management. A
STREAM_ID_ERROR at the QUIC layer is used for streams that are
improperly opened.
CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1. CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1.
COMPRESSION_ERROR (0x9): Multiple error codes are defined in COMPRESSION_ERROR (0x9): Multiple error codes are defined in
[QPACK]. [QPACK].
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.
skipping to change at page 46, line 46 skipping to change at page 47, line 10
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 10.5. Section 10.5.
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-16 B.1. Since draft-ietf-quic-http-17
o HTTP_REQUEST_REJECTED is used to indicate a request can be retried
(#2106, #2325)
o Changed error code for GOAWAY on the wrong stream (#2231, #2343)
B.2. Since draft-ietf-quic-http-16
o Rename "HTTP/QUIC" to "HTTP/3" (#1973) o Rename "HTTP/QUIC" to "HTTP/3" (#1973)
o Changes to PRIORITY frame (#1865, #2075) o Changes to PRIORITY frame (#1865, #2075)
* Permitted as first frame of request streams * Permitted as first frame of request streams
* Remove exclusive reprioritization * Remove exclusive reprioritization
* Changes to Prioritized Element Type bits * Changes to Prioritized Element Type bits
o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE o Define DUPLICATE_PUSH frame to refer to another PUSH_PROMISE
(#2072) (#2072)
o Set defaults for settings, allow request before receiving SETTINGS o Set defaults for settings, allow request before receiving SETTINGS
(#1809, #1846, #2038) (#1809, #1846, #2038)
o Clarify message processing rules for streams that aren't closed o Clarify message processing rules for streams that aren't closed
(#1972, #2003) (#1972, #2003)
o Removed reservation of error code 0 and moved HTTP_NO_ERROR to o Removed reservation of error code 0 and moved HTTP_NO_ERROR to
this value (#1922) this value (#1922)
o Removed prohibition of zero-length DATA frames (#2098) o Removed prohibition of zero-length DATA frames (#2098)
B.2. Since draft-ietf-quic-http-15 B.3. Since draft-ietf-quic-http-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.3. Since draft-ietf-quic-http-14 B.4. Since draft-ietf-quic-http-14
o Recommend sensible values for QUIC transport parameters o Recommend sensible values for QUIC transport parameters
(#1720,#1806) (#1720,#1806)
o Define error for missing SETTINGS frame (#1697,#1808) o Define error for missing SETTINGS frame (#1697,#1808)
o Setting values are variable-length integers (#1556,#1807) and do o Setting values are variable-length integers (#1556,#1807) and do
not have separate maximum values (#1820) not have separate maximum values (#1820)
o Expanded discussion of connection closure (#1599,#1717,#1712) o Expanded discussion of connection closure (#1599,#1717,#1712)
o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685) o HTTP_VERSION_FALLBACK falls back to HTTP/1.1 (#1677,#1685)
B.4. Since draft-ietf-quic-http-13 B.5. Since draft-ietf-quic-http-13
o Reserved some frame types for grease (#1333, #1446) o Reserved some frame types for grease (#1333, #1446)
o Unknown unidirectional stream types are tolerated, not errors; o Unknown unidirectional stream types are tolerated, not errors;
some reserved for grease (#1490, #1525) some reserved for grease (#1490, #1525)
o Require settings to be remembered for 0-RTT, prohibit reductions o Require settings to be remembered for 0-RTT, prohibit reductions
(#1541, #1641) (#1541, #1641)
o Specify behavior for truncated requests (#1596, #1643) o Specify behavior for truncated requests (#1596, #1643)
B.5. Since draft-ietf-quic-http-12 B.6. Since draft-ietf-quic-http-12
o TLS SNI extension isn't mandatory if an alternative method is used o TLS SNI extension isn't mandatory if an alternative method is used
(#1459, #1462, #1466) (#1459, #1462, #1466)
o Removed flags from HTTP/3 frames (#1388, #1398) o Removed flags from HTTP/3 frames (#1388, #1398)
o Reserved frame types and settings for use in preserving o Reserved frame types and settings for use in preserving
extensibility (#1333, #1446) extensibility (#1333, #1446)
o Added general error code (#1391, #1397) o Added general error code (#1391, #1397)
o Unidirectional streams carry a type byte and are extensible o Unidirectional streams carry a type byte and are extensible
(#910,#1359) (#910,#1359)
o Priority mechanism now uses explicit placeholders to enable o Priority mechanism now uses explicit placeholders to enable
persistent structure in the tree (#441,#1421,#1422) persistent structure in the tree (#441,#1421,#1422)
B.6. Since draft-ietf-quic-http-11 B.7. Since draft-ietf-quic-http-11
o Moved QPACK table updates and acknowledgments to dedicated streams o Moved QPACK table updates and acknowledgments to dedicated streams
(#1121, #1122, #1238) (#1121, #1122, #1238)
B.7. Since draft-ietf-quic-http-10 B.8. Since draft-ietf-quic-http-10
o Settings need to be remembered when attempting and accepting 0-RTT o Settings need to be remembered when attempting and accepting 0-RTT
(#1157, #1207) (#1157, #1207)
B.8. Since draft-ietf-quic-http-09 B.9. Since draft-ietf-quic-http-09
o Selected QCRAM for header compression (#228, #1117) o Selected QCRAM for header compression (#228, #1117)
o The server_name TLS extension is now mandatory (#296, #495) o The server_name TLS extension is now mandatory (#296, #495)
o Specified handling of unsupported versions in Alt-Svc (#1093, o Specified handling of unsupported versions in Alt-Svc (#1093,
#1097) #1097)
B.9. Since draft-ietf-quic-http-08 B.10. Since draft-ietf-quic-http-08
o Clarified connection coalescing rules (#940, #1024) o Clarified connection coalescing rules (#940, #1024)
B.10. Since draft-ietf-quic-http-07 B.11. Since draft-ietf-quic-http-07
o Changes for integer encodings in QUIC (#595,#905) o Changes for integer encodings in QUIC (#595,#905)
o Use unidirectional streams as appropriate (#515, #240, #281, #886) o Use unidirectional streams as appropriate (#515, #240, #281, #886)
o Improvement to the description of GOAWAY (#604, #898) o Improvement to the description of GOAWAY (#604, #898)
o Improve description of server push usage (#947, #950, #957) o Improve description of server push usage (#947, #950, #957)
B.11. Since draft-ietf-quic-http-06 B.12. Since draft-ietf-quic-http-06
o Track changes in QUIC error code usage (#485) o Track changes in QUIC error code usage (#485)
B.12. Since draft-ietf-quic-http-05 B.13. Since draft-ietf-quic-http-05
o Made push ID sequential, add MAX_PUSH_ID, remove o Made push ID sequential, add MAX_PUSH_ID, remove
SETTINGS_ENABLE_PUSH (#709) SETTINGS_ENABLE_PUSH (#709)
o Guidance about keep-alive and QUIC PINGs (#729) o Guidance about keep-alive and QUIC PINGs (#729)
o Expanded text on GOAWAY and cancellation (#757) o Expanded text on GOAWAY and cancellation (#757)
B.13. Since draft-ietf-quic-http-04 B.14. Since draft-ietf-quic-http-04
o Cite RFC 5234 (#404) o Cite RFC 5234 (#404)
o Return to a single stream per request (#245,#557) o Return to a single stream per request (#245,#557)
o Use separate frame type and settings registries from HTTP/2 (#81) o Use separate frame type and settings registries from HTTP/2 (#81)
o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)
o Restored GOAWAY (#696) o Restored GOAWAY (#696)
skipping to change at page 49, line 30 skipping to change at page 50, line 4
o Cite RFC 5234 (#404) o Cite RFC 5234 (#404)
o Return to a single stream per request (#245,#557) o Return to a single stream per request (#245,#557)
o Use separate frame type and settings registries from HTTP/2 (#81) o Use separate frame type and settings registries from HTTP/2 (#81)
o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477) o SETTINGS_ENABLE_PUSH instead of SETTINGS_DISABLE_PUSH (#477)
o Restored GOAWAY (#696) o Restored GOAWAY (#696)
o Identify server push using Push ID rather than a stream ID o Identify server push using Push ID rather than a stream ID
(#702,#281) (#702,#281)
o DATA frames cannot be empty (#700) o DATA frames cannot be empty (#700)
B.14. Since draft-ietf-quic-http-03 B.15. Since draft-ietf-quic-http-03
None. None.
B.15. Since draft-ietf-quic-http-02 B.16. Since draft-ietf-quic-http-02
o Track changes in transport draft o Track changes in transport draft
B.16. Since draft-ietf-quic-http-01 B.17. Since draft-ietf-quic-http-01
o SETTINGS changes (#181): o SETTINGS changes (#181):
* SETTINGS can be sent only once at the start of a connection; no * SETTINGS can be sent only once at the start of a connection; no
changes thereafter changes thereafter
* SETTINGS_ACK removed * SETTINGS_ACK removed
* Settings can only occur in the SETTINGS frame a single time * Settings can only occur in the SETTINGS frame a single time
* Boolean format updated * Boolean format updated
o Alt-Svc parameter changed from "v" to "quic"; format updated o Alt-Svc parameter changed from "v" to "quic"; format updated
(#229) (#229)
o Closing the connection control stream or any message control o Closing the connection control stream or any message control
stream is a fatal error (#176) stream is a fatal error (#176)
o HPACK Sequence counter can wrap (#173) o HPACK Sequence counter can wrap (#173)
o 0-RTT guidance added o 0-RTT guidance added
o Guide to differences from HTTP/2 and porting HTTP/2 extensions o Guide to differences from HTTP/2 and porting HTTP/2 extensions
added (#127,#242) added (#127,#242)
B.17. Since draft-ietf-quic-http-00 B.18. Since draft-ietf-quic-http-00
o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
o Changed from using HTTP/2 framing within Stream 3 to new framing o Changed from using HTTP/2 framing within Stream 3 to new framing
format and two-stream-per-request model (#71,#72,#73) format and two-stream-per-request model (#71,#72,#73)
o Adopted SETTINGS format from draft-bishop-httpbis-extended- o Adopted SETTINGS format from draft-bishop-httpbis-extended-
settings-01 settings-01
o Reworked SETTINGS_ACK to account for indeterminate inter-stream o Reworked SETTINGS_ACK to account for indeterminate inter-stream
order (#75) order (#75)
o Described CONNECT pseudo-method (#95) o Described CONNECT pseudo-method (#95)
o Updated ALPN token and Alt-Svc guidance (#13,#87) o Updated ALPN token and Alt-Svc guidance (#13,#87)
o Application-layer-defined error codes (#19,#74) o Application-layer-defined error codes (#19,#74)
B.18. Since draft-shade-quic-http2-mapping-00 B.19. Since draft-shade-quic-http2-mapping-00
o Adopted as base for draft-ietf-quic-http o Adopted as base for draft-ietf-quic-http
o Updated authors/editors list o Updated authors/editors list
Acknowledgements Acknowledgements
The original authors of this specification were Robbie Shade and Mike The original authors of this specification were Robbie Shade and Mike
Warres. Warres.
 End of changes. 95 change blocks. 
262 lines changed or deleted 292 lines changed or added

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