draft-ietf-quic-http-18.txt   draft-ietf-quic-http-19.txt 
QUIC M. Bishop, Ed. QUIC M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track January 23, 2019 Intended status: Standards Track March 11, 2019
Expires: July 27, 2019 Expires: September 12, 2019
Hypertext Transfer Protocol Version 3 (HTTP/3) Hypertext Transfer Protocol Version 3 (HTTP/3)
draft-ietf-quic-http-18 draft-ietf-quic-http-19
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 July 27, 2019. This Internet-Draft will expire on September 12, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 36 skipping to change at page 2, line 36
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 . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . 11
4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 11 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 12
4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 11 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 12 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 13
4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 15 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16
4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 16 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19
4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 19 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 20
4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 20 4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 21
4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 21 4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 22
5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 21 5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 22
5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 21 5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 22
5.1.1. Header Formatting and Compression . . . . . . . . . . 22 5.1.1. Header Formatting and Compression . . . . . . . . . . 24
5.1.2. Request Cancellation and Rejection . . . . . . . . . 23 5.1.2. Request Cancellation and Rejection . . . . . . . . . 24
5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 24 5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 25
5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 25 5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 26
5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 26 5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 27
5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 26 5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 27
5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 27 5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 28
6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 28 6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 29
6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 28 6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 30
6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 29 6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 30
6.3. Immediate Application Closure . . . . . . . . . . . . . . 30 6.3. Immediate Application Closure . . . . . . . . . . . . . . 31
6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 30 6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 32
7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 31 7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 32
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 31 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33
8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 32 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 33
9. Security Considerations . . . . . . . . . . . . . . . . . . . 33 9. Security Considerations . . . . . . . . . . . . . . . . . . . 35
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35
10.1. Registration of HTTP/3 Identification String . . . . . . 34 10.1. Registration of HTTP/3 Identification String . . . . . . 35
10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 34 10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 36
10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 34 10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 36
10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 36 10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 37
10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 37 10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 38
10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 39 10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 41
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42
11.1. Normative References . . . . . . . . . . . . . . . . . . 40 11.1. Normative References . . . . . . . . . . . . . . . . . . 42
11.2. Informative References . . . . . . . . . . . . . . . . . 41 11.2. Informative References . . . . . . . . . . . . . . . . . 43
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 42 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 42 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 44
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 42 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 44
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 42 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 44
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 45 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 46
A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 45 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 47
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 47 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 48
B.1. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 47 B.1. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 48
B.2. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 47 B.2. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 49
B.3. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 47 B.3. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 49
B.4. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 47 B.4. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 50
B.5. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 48 B.5. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 50
B.6. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 48 B.6. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 50
B.7. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 48 B.7. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 50
B.8. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 48 B.8. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 51
B.9. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 49 B.9. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 51
B.10. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 49 B.10. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 51
B.11. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 49 B.11. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 51
B.12. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 49 B.12. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 51
B.13. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 49 B.13. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 51
B.14. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 49 B.14. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 51
B.15. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 50 B.15. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 52
B.16. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 50 B.16. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 52
B.17. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 50 B.17. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 52
B.18. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 50 B.18. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 52
B.19. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 51 B.19. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 53
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 51 B.20. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 51 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53
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.
skipping to change at page 8, line 43 skipping to change at page 8, line 46
abruptly may be reset at any point in the frame. abruptly may be reset at any point in the frame.
HTTP/3 does not use server-initiated bidirectional streams; clients HTTP/3 does not use server-initiated bidirectional streams; clients
MUST omit or specify a value of zero for the QUIC transport parameter MUST omit or specify a value of zero for the QUIC transport parameter
"initial_max_bidi_streams". "initial_max_bidi_streams".
3.2. Unidirectional Streams 3.2. Unidirectional Streams
Unidirectional streams, in either direction, are used for a range of Unidirectional streams, in either direction, are used for a range of
purposes. The purpose is indicated by a stream type, which is sent purposes. The purpose is indicated by a stream type, which is sent
as a single byte header at the start of the stream. The format and as a variable-length integer at the start of the stream. The format
structure of data that follows this header is determined by the and structure of data that follows this integer is determined by the
stream type. stream type.
0 1 2 3 4 5 6 7 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
|Stream Type (8)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+ | Stream Type (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Unidirectional Stream Header Figure 1: Unidirectional Stream Header
Some stream types are reserved (Section 3.2.3). Two stream types are Some stream types are reserved (Section 3.2.3). Two stream types are
defined in this document: control streams (Section 3.2.1) and push defined in this document: control streams (Section 3.2.1) and push
streams (Section 3.2.2). Other stream types can be defined by streams (Section 3.2.2). Other stream types can be defined by
extensions to HTTP/3; see Section 7 for more details. extensions to HTTP/3; see Section 7 for more details.
Both clients and servers SHOULD send a value of three or greater for Both clients and servers SHOULD send a value of three or greater for
the QUIC transport parameter "initial_max_uni_streams". the QUIC transport parameter "initial_max_uni_streams".
skipping to change at page 9, line 32 skipping to change at page 9, line 40
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 A sender can close or reset a unidirectional stream unless otherwise
specified. A receiver MUST tolerate unidirectional streams being specified. A receiver MUST tolerate unidirectional streams being
closed or reset prior to the reception of the unidirectional stream closed or reset prior to the reception of the unidirectional stream
header. 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 "0x00". Data on
Data on this stream consists of HTTP/3 frames, as defined in 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. The sender MUST NOT close the control HTTP_WRONG_STREAM_COUNT. The sender MUST NOT close the control
stream. If the control stream is closed at any point, this MUST be stream. If the control stream is closed at any point, this MUST be
treated as a connection error of type 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 "0x01", followed by
followed by the Push ID of the promise that it fulfills, encoded as a the Push ID of the promise that it fulfills, encoded as a variable-
variable-length integer. The remaining data on this stream consists length integer. The remaining data on this stream consists of HTTP/3
of HTTP/3 frames, as defined in Section 4.2, and fulfills a promised frames, as defined in Section 4.2, and fulfills a promised server
server push. Server push and Push IDs are described in Section 5.4. push. Server push and Push IDs are described in Section 5.4.
Only servers can push; if a server receives a client-initiated push Only servers can push; if a server receives a client-initiated push
stream, this MUST be treated as a stream error of type stream, this MUST be treated as a stream error of type
HTTP_WRONG_STREAM_DIRECTION. HTTP_WRONG_STREAM_DIRECTION.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Stream Type (8)| Push ID (i) ... | 0x01 (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Push Stream Header Figure 2: Push Stream Header
Each Push ID MUST only be used once in a push stream header. If a Each Push ID MUST only be used once in a push stream header. If a
push stream header includes a Push ID that was used in another push push stream header includes a Push ID that was used in another push
stream header, the client MUST treat this as a connection error of stream header, the client MUST treat this as a connection error of
type HTTP_DUPLICATE_PUSH. type HTTP_DUPLICATE_PUSH.
3.2.3. Reserved Stream Types 3.2.3. Reserved Stream Types
Stream types of the format "0x1f * N" are reserved to exercise the Stream types of the format "0x1f * N + 0x21" for integer values of N
requirement that unknown types be ignored. These streams have no are reserved to exercise the requirement that unknown types be
semantic meaning, and can be sent when application-layer padding is ignored. These streams have no semantics, and can be sent when
desired. They MAY also be sent on connections where no request data application-layer padding is desired. They MAY also be sent on
is currently being transferred. Endpoints MUST NOT consider these connections where no data is currently being transferred. Endpoints
streams to have any meaning upon receipt. MUST NOT consider these 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
As discussed above, frames are carried on QUIC streams and used on HTTP frames are carried on QUIC streams, as described in Section 3.
control streams, request streams, and push streams. This section HTTP/3 defines three stream types: control stream, request stream,
describes HTTP framing in QUIC. For a comparison with HTTP/2 frames, and push stream. This section describes HTTP/3 frame formats and the
see Appendix A.2. streams types on which they are permitted; see Table 1 for an
overiew. A comparison between HTTP/2 and HTTP/3 frames is provided
in Appendix A.2.
+----------------+------------+------------+-----------+------------+
| Frame | Control | Request | Push | Section |
| | Stream | Stream | Stream | |
+----------------+------------+------------+-----------+------------+
| DATA | No | Yes | Yes | Section |
| | | | | 4.2.1 |
| | | | | |
| HEADERS | No | Yes | Yes | Section |
| | | | | 4.2.2 |
| | | | | |
| PRIORITY | Yes | Yes (1) | No | Section |
| | | | | 4.2.3 |
| | | | | |
| CANCEL_PUSH | Yes | No | No | Section |
| | | | | 4.2.4 |
| | | | | |
| SETTINGS | Yes (1) | No | No | Section |
| | | | | 4.2.5 |
| | | | | |
| PUSH_PROMISE | No | Yes | No | Section |
| | | | | 4.2.6 |
| | | | | |
| GOAWAY | Yes | No | No | Section |
| | | | | 4.2.7 |
| | | | | |
| MAX_PUSH_ID | Yes | No | No | Section |
| | | | | 4.2.8 |
| | | | | |
| DUPLICATE_PUSH | No | Yes | No | Section |
| | | | | 4.2.9 |
+----------------+------------+------------+-----------+------------+
Table 1: HTTP/3 frames and stream type overview
Certain frames can only occur as the first frame of a particular
stream type; these are indicated in Table 1 with a (1). Specific
guidance is provided in the relevant section.
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) ... | Type (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (8) | Frame Payload (*) ... | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: HTTP/3 frame format Figure 3: HTTP/3 frame format
A frame includes the following fields: A frame includes the following fields:
Length: A variable-length integer that describes the length of the Type: A variable-length integer that identifies the frame type.
Frame Payload. This length does not include the Type field.
Type: An 8-bit type for the frame. Length: A variable-length integer that describes the length of the
Frame Payload.
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 fields identified in Each frame's payload MUST contain exactly the fields identified in
its description. A frame payload that contains additional bytes its description. A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection the end of the identified fields MUST be treated as a connection
error of type HTTP_MALFORMED_FRAME. error of type HTTP_MALFORMED_FRAME.
skipping to change at page 12, line 30 skipping to change at page 13, line 30
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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=0x2) frame specifies the client-advised priority
of a request, server push or placeholder. of a request, server push or placeholder.
A PRIORITY frame identifies an element to prioritize, and an element A PRIORITY frame identifies an element to prioritize, and an element
upon which it depends. A Prioritized ID or Dependency ID identifies upon which it depends. A Prioritized ID or Dependency ID identifies
a client-initiated request using the corresponding stream ID, a a client-initiated request using the corresponding stream ID, a
server push using a Push ID (see Section 4.2.6), or a placeholder server push using a Push ID (see Section 4.2.6), or a placeholder
using a Placeholder ID (see Section 5.3.1). using a Placeholder ID (see Section 5.3.1).
When a client initiates a request, a PRIORITY frame MAY be sent as 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 the first frame of the stream, creating a dependency on an existing
skipping to change at page 13, line 20 skipping to change at page 14, line 20
| [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:
PT (Prioritized Element Type): A two-bit field indicating the type PT (Prioritized Element Type): A two-bit field indicating the type
of element being prioritized (see Table 1). When sent on a of element being prioritized (see Table 2). When sent on a
request stream, this MUST be set to "11". When sent on the request stream, this MUST be set to "11". When sent on the
control stream, this MUST NOT be set to "11". control stream, this MUST NOT be set to "11".
DT (Element Dependency Type): A two-bit field indicating the type of DT (Element Dependency Type): A two-bit field indicating the type of
element being depended on (see Table 2). element being depended on (see Table 3).
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 47 skipping to change at page 14, 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.
The values for the Prioritized Element Type (Table 1) and Element The values for the Prioritized Element Type (Table 2) and Element
Dependency Type (Table 2) imply the interpretation of the associated Dependency Type (Table 3) imply the interpretation of the associated
Element ID fields. Element ID fields.
+---------+------------------+---------------------------------+ +---------+------------------+---------------------------------+
| PT Bits | Type Description | Prioritized Element ID Contents | | PT Bits | Type Description | Prioritized Element ID Contents |
+---------+------------------+---------------------------------+ +---------+------------------+---------------------------------+
| 00 | Request stream | Stream ID | | 00 | Request stream | Stream ID |
| | | | | | | |
| 01 | Push stream | Push ID | | 01 | Push stream | Push ID |
| | | | | | | |
| 10 | Placeholder | Placeholder ID | | 10 | Placeholder | Placeholder ID |
| | | | | | | |
| 11 | Current stream | Absent | | 11 | Current stream | Absent |
+---------+------------------+---------------------------------+ +---------+------------------+---------------------------------+
Table 1: Prioritized Element Types Table 2: Prioritized Element Types
+---------+------------------+--------------------------------+ +---------+------------------+--------------------------------+
| DT Bits | Type Description | Element Dependency ID Contents | | DT Bits | Type Description | Element Dependency ID Contents |
+---------+------------------+--------------------------------+ +---------+------------------+--------------------------------+
| 00 | Request stream | Stream ID | | 00 | Request stream | Stream ID |
| | | | | | | |
| 01 | Push stream | Push ID | | 01 | Push stream | Push ID |
| | | | | | | |
| 10 | Placeholder | Placeholder ID | | 10 | Placeholder | Placeholder ID |
| | | | | | | |
| 11 | Root of the tree | Absent | | 11 | Root of the tree | Absent |
+---------+------------------+--------------------------------+ +---------+------------------+--------------------------------+
Table 2: Element Dependency Types Table 3: Element Dependency Types
Note that unlike in [RFC7540], the root of the tree cannot be 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 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 valid HTTP request. The root of the tree cannot be reprioritized. A
PRIORITY frame sent on a request stream with the Prioritized Element PRIORITY frame sent on a request stream with the Prioritized Element
Type set to any value other than "11" or which expresses a dependency 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 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 treated as a stream error of type HTTP_MALFORMED_FRAME. Likewise, a
PRIORITY frame sent on a control stream with the Prioritized Element PRIORITY frame sent on a control stream with the Prioritized Element
Type set to "11" MUST be treated as a connection error of type Type set to "11" MUST be treated as a connection error of type
skipping to change at page 15, line 9 skipping to change at page 16, line 9
A PRIORITY frame that references a non-existent Push ID, a A PRIORITY frame that references a non-existent Push ID, a
Placeholder ID greater than the server's limit, or a Stream ID the Placeholder ID greater than the server's limit, or a Stream ID the
client is not yet permitted to open MUST be treated as an client is not yet permitted to open MUST be treated as an
HTTP_LIMIT_EXCEEDED error. 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 connection
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 received. The CANCEL_PUSH server push prior to the push stream being received. The CANCEL_PUSH
frame identifies a server push by Push ID (see Section 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
skipping to change at page 16, line 39 skipping to change at page 17, line 39
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 in the SETTINGS frame. A Parameters MUST NOT occur more than once in the SETTINGS frame. A
receiver MAY treat the presence of the same parameter more than once receiver MAY treat the presence of the same parameter more than once
as a connection error 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 parameter consists of a setting identifier and a value, both
which uses the QUIC variable-length integer encoding. encoded as QUIC variable-length integers.
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 (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: SETTINGS parameter format Figure 8: SETTINGS parameter format
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.
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.
Setting identifiers of the format "0x?a?a" are reserved to exercise Setting identifiers of the format "0x1f * N + 0x21" for integer
the requirement that unknown identifiers be ignored. Such settings values of N are reserved to exercise the requirement that unknown
have no defined meaning. Endpoints SHOULD include at least one such identifiers be ignored. Such settings have no defined meaning.
setting in their SETTINGS frame. Endpoints MUST NOT consider such Endpoints SHOULD include at least one such setting in their SETTINGS
settings to have any meaning upon receipt. frame. Endpoints MUST NOT consider such settings to have any meaning
upon receipt.
Because the setting has no defined meaning, the value of the setting Because the setting has no defined meaning, the value of the setting
can be any value the implementation selects. can be any value the implementation selects.
Additional settings can be defined by extensions to HTTP/3; see Additional settings can be defined by extensions to HTTP/3; see
Section 7 for more details. Section 7 for more details.
4.2.5.2. Initialization 4.2.5.2. Initialization
An HTTP implementation MUST NOT send frames or requests which would An HTTP implementation MUST NOT send frames or requests which would
skipping to change at page 18, line 7 skipping to change at page 19, line 12
information when accepting 0-RTT data. A server uses the HTTP/3 information when accepting 0-RTT data. A server uses the HTTP/3
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=0x5) is used to carry a promised request
request header set from server to client on a request stream, as in header set from server to client on a request stream, as in HTTP/2.
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 20, line 32 skipping to change at page 21, line 42
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.
A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat A client MUST NOT send a DUPLICATE_PUSH frame. A server MUST treat
the receipt of a DUPLICATE_PUSH frame as a connection error of type the receipt of a DUPLICATE_PUSH frame as a connection error of type
HTTP_MALFORMED_FRAME. HTTP_UNEXPECTED_FRAME.
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
skipping to change at page 21, line 15 skipping to change at page 22, line 25
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
consume server push responses and not retain them for reuse over consume server push responses and not retain them for reuse over
time. Clients that see a DUPLICATE_PUSH that uses a Push ID that time. Clients that see a DUPLICATE_PUSH that uses a Push ID that
they have since consumed and discarded are forced to ignore the they have since consumed and discarded are forced to ignore the
DUPLICATE_PUSH. DUPLICATE_PUSH.
4.2.10. Reserved Frame Types 4.2.10. Reserved Frame Types
Frame types of the format "0xb + (0x1f * N)" are reserved to exercise Frame types of the format "0x1f * N + 0x21" for integer values of N
the requirement that unknown types be ignored (Section 7). These are reserved to exercise the requirement that unknown types be
frames have no semantic value, and can be sent when application-layer ignored (Section 7). These frames have no semantics, and can be sent
padding is desired. They MAY also be sent on connections where no when application-layer padding is desired. They MAY also be sent on
request data is currently being transferred. Endpoints MUST NOT connections where no data is currently being transferred. Endpoints
consider these frames to have any meaning upon receipt. MUST NOT 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 client MUST send only a single request on a given QUIC stream. A client MUST send only a single request on a given
skipping to change at page 23, line 48 skipping to change at page 25, line 13
a stream. a stream.
When the server rejects a request without performing any application When the server rejects a request without performing any application
processing, it SHOULD abort its response stream with the error code processing, it SHOULD abort its response stream with the error code
HTTP_REQUEST_REJECTED. In this context, "processed" means that some HTTP_REQUEST_REJECTED. In this context, "processed" means that some
data from the stream was passed to some higher layer of software that 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 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 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. all, thereby allowing them to be retried later on a new connection.
Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for Servers MUST NOT use the HTTP_REQUEST_REJECTED error code for
requests which were partially or fully processed. When a client requests which were partially or fully processed. When a server
sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a server MAY abandons a response after partial processing, it SHOULD abort its
indicate the error code HTTP_REQUEST_REJECTED in the corresponding response stream with the error code HTTP_REQUEST_CANCELLED.
RESET_STREAM if no processing was performed. Clients MUST NOT reset
streams with the HTTP_REQUEST_REJECTED error code except in response When a client sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a
to a QUIC STOP_SENDING frame. server MAY send 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 that contains the
same code.
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 44 skipping to change at page 27, line 14
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 When a prioritized element is first created, it has a default initial
weight of 16 and a default dependency. Requests and placeholders are weight of 16 and a default dependency. Requests and placeholders are
dependent on the root of the priority tree; pushes are dependent on dependent on the root of the priority tree; pushes are dependent on
the client request on which the PUSH_PROMISE frame was sent. the client request on which the PUSH_PROMISE frame was sent.
Requests may override the default intial values by including a Requests may override the default initial values by including a
PRIORTIY frame (see Section 4.2.3) at the beginning of the stream. 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 These priorities can be updated by sending a PRIORITY frame on the
control stream. 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
skipping to change at page 29, line 33 skipping to change at page 30, line 46
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 rejected. This enables client and server to agree on greater were rejected. This enables client and server to agree on
which requests were accepted prior to the connection shutdown. This which requests were accepted prior to the connection shutdown. This
identifier MAY be lower than the stream limit identified by a QUIC identifier MAY be lower than the stream limit identified by a QUIC
MAX_STREAM_ID frame, and MAY be zero if no requests were processed. MAX_STREAM_ID frame, and MAY be zero if no requests were processed.
Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after Servers SHOULD NOT increase the QUIC MAX_STREAM_ID limit after
sending a GOAWAY frame. sending a GOAWAY frame.
Once GOAWAY is sent, the server MUST reject requests sent on streams Clients MUST NOT send new requests on the connection after receiving
with an identifier greater than or equal to the indicated last Stream GOAWAY; a new connection MAY be established to send additional
ID. Clients MUST NOT send new requests on the connection after requests.
receiving GOAWAY, although requests might already be in transit. A
new connection can be established for new requests.
If the client has sent requests on streams with a Stream ID greater Some requests might already be in transit. If the client has already
than or equal to that indicated in the GOAWAY frame, those requests sent requests on streams with a Stream ID greater than or equal to
are considered rejected (Section 5.1.2). Clients SHOULD cancel any that indicated in the GOAWAY frame, those requests will not be
requests on streams above this ID. Servers MAY also reject requests processed and MAY be retried by the client on a different connection.
on streams below the indicated ID if these requests were not The client MAY cancel these requests. It is RECOMMENDED that the
processed. server explicitly reject such requests (see Section 5.1.2) in order
to clean up transport state for the affected streams.
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 a
are completed successfully, reset individually, or the connection response is received, the stream is reset individually, or the
terminates. connection terminates. Servers MAY reject individual requests on
streams below the indicated ID if these requests were not processed.
Servers SHOULD send a GOAWAY frame when the closing of a connection Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the is known in advance, even if the advance notice is small, so that the
remote peer can know whether a request has been partially processed remote peer can know whether a request has been partially processed
or not. For example, if an HTTP client sends a POST at the same time or not. For example, if an HTTP client sends a POST at the same time
that a server closes a QUIC connection, the client cannot know if the that a server closes a QUIC connection, the client cannot know if the
server started to process that POST request if the server does not server started to process that POST request if the server does not
send a GOAWAY frame to indicate what streams it might have acted on. send a GOAWAY frame to indicate what streams it might have acted on.
A client that is unable to retry requests loses all requests that are A client that is unable to retry requests loses all requests that are
skipping to change at page 32, line 31 skipping to change at page 33, line 45
HTTP_PUSH_REFUSED (0x02): The server has attempted to push content HTTP_PUSH_REFUSED (0x02): The server has attempted to push content
which the client will not accept on this connection. which the client will not accept on this connection.
HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the
HTTP stack. HTTP stack.
HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push
content which the client has cached. content which the client has cached.
HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the HTTP_REQUEST_CANCELLED (0x05): The request or its response is
requested data. cancelled.
HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated
without containing a fully-formed request. without containing a fully-formed request.
HTTP_CONNECT_ERROR (0x07): The connection established in response to HTTP_CONNECT_ERROR (0x07): The connection established in response to
a CONNECT request was reset or abnormally closed. a CONNECT request was reset or abnormally closed.
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.
skipping to change at page 33, line 38 skipping to change at page 34, line 51
permitted in the current state. permitted in the current state.
HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without
performing any application processing. 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. If the frame type is "0xfe" or less, the type is included as the
For example, an error in a MAX_PUSH_ID frame would be indicated last byte of the error code. For example, an error in a
with the code (0x10D). MAX_PUSH_ID frame would be indicated with the code (0x10D). The
last byte "0xff" is used to indicate any frame type greater than
"0xfe".
9. Security Considerations 9. Security Considerations
The security considerations of HTTP/3 should be comparable to those The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames of HTTP/2 with TLS. Note that where HTTP/2 employs PADDING frames
and Padding fields in other frames to make a connection more and Padding fields in other frames to make a connection more
resistant to traffic analysis, HTTP/3 can rely on QUIC PADDING frames resistant to traffic analysis, HTTP/3 can rely on QUIC PADDING frames
or employ the reserved frame and stream types discussed in or employ the reserved frame and stream types discussed in
Section 4.2.10 and Section 3.2.3. Section 4.2.10 and Section 3.2.3.
When HTTP Alternative Services is used for discovery for HTTP/3 When HTTP Alternative Services is used for discovery for HTTP/3
endpoints, the security considerations of [ALTSVC] also apply. endpoints, the security considerations of [ALTSVC] also apply.
Several protocol elements contain nested length elements, typically Several protocol elements contain nested length elements, typically
in the form of frames with an explicit length containing variable- in the form of frames with an explicit length containing variable-
length integers. This could pose a security risk to an incautious length integers. This could pose a security risk to an incautious
implementer. An implementation MUST ensure that the length of a implementer. An implementation MUST ensure that the length of a
frame exactly matches the length of the fields it contains. frame exactly matches the length of the fields it contains.
The use of 0-RTT with HTTP/3 creates an exposure to replay attack.
The anti-replay mitigations in [HTTP-REPLAY] MUST be applied when
using HTTP/3 with 0-RTT.
Certain HTTP implementations use the client address for logging or
access-control purposes. Since a QUIC client's address might change
during a connection (and future versions might support simultaneous
use of multiple addresses), such implementations will need to either
actively retrieve the client's current address or addresses when they
are relevant or explicitly accept that the original address might
change.
10. IANA Considerations 10. IANA Considerations
10.1. Registration of HTTP/3 Identification String 10.1. Registration of HTTP/3 Identification String
This document creates a new registration for the identification of This document creates a new registration for the identification of
HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol
IDs" registry established in [RFC7301]. IDs" registry established in [RFC7301].
The "h3" string identifies HTTP/3: The "h3" string identifies HTTP/3:
skipping to change at page 34, line 24 skipping to change at page 36, line 4
This document creates a new registration for the identification of This document creates a new registration for the identification of
HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol HTTP/3 in the "Application Layer Protocol Negotiation (ALPN) Protocol
IDs" registry established in [RFC7301]. IDs" registry established in [RFC7301].
The "h3" string identifies HTTP/3: The "h3" string identifies HTTP/3:
Protocol: HTTP/3 Protocol: HTTP/3
Identification Sequence: 0x68 0x33 ("h3") Identification Sequence: 0x68 0x33 ("h3")
Specification: This document Specification: This document
10.2. Registration of QUIC Version Hint Alt-Svc Parameter 10.2. Registration of QUIC Version Hint Alt-Svc Parameter
This document creates a new registration for version-negotiation This document creates a new registration for version-negotiation
hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter" hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter"
registry established in [RFC7838]. registry established in [RFC7838].
Parameter: "quic" Parameter: "quic"
Specification: This document, Section 2.2.1 Specification: This document, Section 2.2.1
10.3. Frame Types 10.3. Frame Types
This document establishes a registry for HTTP/3 frame type codes. This document establishes a registry for HTTP/3 frame type codes.
The "HTTP/3 Frame Type" registry manages an 8-bit space. The "HTTP/3 The "HTTP/3 Frame Type" registry governs a 62-bit space. This space
Frame Type" registry operates under either of the "IETF Review" or is split into three spaces that are governed by different policies.
"IESG Approval" policies [RFC8126] for values from 0x00 up to and Values between "0x00" and "0x3f" (in hexadecimal) are assigned via
including 0xef, with values from 0xf0 up to and including 0xff being the Standards Action or IESG Review policies [RFC8126]. Values from
reserved for Experimental Use. "0x40" to "0x3fff" operate on the Specification Required policy
[RFC8126]. All other values are assigned to Private Use [RFC8126].
While this registry is separate from the "HTTP/2 Frame Type" registry While this registry is separate from the "HTTP/2 Frame Type" registry
defined in [RFC7540], it is preferable that the assignments parallel defined in [RFC7540], it is preferable that the assignments parallel
each other. If an entry is present in only one registry, every each other where the code spaces overlap. If an entry is present in
effort SHOULD be made to avoid assigning the corresponding value to only one registry, every effort SHOULD be made to avoid assigning the
an unrelated operation. corresponding value to an unrelated operation.
New entries in this registry require the following information: New entries in this registry require the following information:
Frame Type: A name or label for the frame type. Frame Type: A name or label for the frame type.
Code: The 8-bit code assigned to the frame type. Code: The 62-bit code assigned to the frame type.
Specification: A reference to a specification that includes a Specification: A reference to a specification that includes a
description of the frame layout and its semantics, including any description of the frame layout and its semantics, including any
parts of the frame that are conditionally present. parts of the frame that are conditionally present.
The entries in the following table are registered by this document. The entries in the following table are registered by this document.
+----------------+------+---------------+ +----------------+------+---------------+
| Frame Type | Code | Specification | | Frame Type | Code | Specification |
+----------------+------+---------------+ +----------------+------+---------------+
skipping to change at page 35, line 43 skipping to change at page 37, line 33
| | | | | | | |
| Reserved | 0x8 | N/A | | Reserved | 0x8 | N/A |
| | | | | | | |
| Reserved | 0x9 | N/A | | Reserved | 0x9 | N/A |
| | | | | | | |
| MAX_PUSH_ID | 0xD | Section 4.2.8 | | MAX_PUSH_ID | 0xD | Section 4.2.8 |
| | | | | | | |
| DUPLICATE_PUSH | 0xE | Section 4.2.9 | | DUPLICATE_PUSH | 0xE | Section 4.2.9 |
+----------------+------+---------------+ +----------------+------+---------------+
Additionally, each code of the format "0xb + (0x1f * N)" for values Additionally, each code of the format "0x1f * N + 0x21" for integer
of N in the range (0..7) (that is, "0xb", "0x2a", "0x49", "0x68", values of N (that is, "0x21", "0x40", ..., through
"0x87", "0xa6", "0xc5", and "0xe4"), the following values should be "0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.
registered:
Frame Type: Reserved - GREASE
Specification: Section 4.2.10
10.4. Settings Parameters 10.4. Settings Parameters
This document establishes a registry for HTTP/3 settings. The This document establishes a registry for HTTP/3 settings. The
"HTTP/3 Settings" registry manages a 16-bit space. The "HTTP/3 "HTTP/3 Settings" registry governs a 62-bit space. This space is
Settings" registry operates under the "Expert Review" policy split into three spaces that are governed by different policies.
[RFC8126] for values in the range from 0x0000 to 0xefff, with values Values between "0x00" and "0x3f" (in hexadecimal) are assigned via
between and 0xf000 and 0xffff being reserved for Experimental Use. the Standards Action or IESG Review policies [RFC8126]. Values from
"0x40" to "0x3fff" operate on the Specification Required policy
[RFC8126]. All other values are assigned to Private Use [RFC8126].
The designated experts are the same as those for the "HTTP/2 The designated experts are the same as those for the "HTTP/2
Settings" registry defined in [RFC7540]. Settings" registry defined in [RFC7540].
While this registry is separate from the "HTTP/2 Settings" registry While this registry is separate from the "HTTP/2 Settings" registry
defined in [RFC7540], it is preferable that the assignments parallel defined in [RFC7540], it is preferable that the assignments parallel
each other. If an entry is present in only one registry, every each other. If an entry is present in only one registry, every
effort SHOULD be made to avoid assigning the corresponding value to effort SHOULD be made to avoid assigning the corresponding value to
an unrelated operation. an unrelated operation.
New registrations are advised to provide the following information: New registrations are advised to provide the following information:
Name: A symbolic name for the setting. Specifying a setting name is Name: A symbolic name for the setting. Specifying a setting name is
optional. optional.
Code: The 16-bit code assigned to the setting. Code: The 62-bit code assigned to the setting.
Specification: An optional reference to a specification that Specification: An optional reference to a specification that
describes the use of the setting. describes the use of the setting.
The entries in the following table are registered by this document. The entries in the following table are registered by this document.
+----------------------+------+-----------------+ +----------------------+------+-----------------+
| Setting Name | Code | Specification | | Setting Name | Code | Specification |
+----------------------+------+-----------------+ +----------------------+------+-----------------+
| Reserved | 0x2 | N/A | | Reserved | 0x2 | N/A |
skipping to change at page 36, line 49 skipping to change at page 38, line 35
| | | | | | | |
| Reserved | 0x4 | N/A | | Reserved | 0x4 | N/A |
| | | | | | | |
| Reserved | 0x5 | N/A | | Reserved | 0x5 | N/A |
| | | | | | | |
| MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.1 | | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.1 |
| | | | | | | |
| NUM_PLACEHOLDERS | 0x8 | Section 4.2.5.1 | | NUM_PLACEHOLDERS | 0x8 | Section 4.2.5.1 |
+----------------------+------+-----------------+ +----------------------+------+-----------------+
Additionally, each code of the format "0x?a?a" where each "?" is any Additionally, each code of the format "0x1f * N + 0x21" for integer
four bits (that is, "0x0a0a", "0x0a1a", etc. through "0xfafa"), the values of N (that is, "0x21", "0x40", ..., through
following values should be registered: "0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.
Name: Reserved - GREASE
Specification: Section 4.2.5.1
10.5. Error Codes 10.5. Error Codes
This document establishes a registry for HTTP/3 error codes. The This document establishes a registry for HTTP/3 error codes. The
"HTTP/3 Error Code" registry manages a 16-bit space. The "HTTP/3 "HTTP/3 Error Code" registry manages a 16-bit space. The "HTTP/3
Error Code" registry operates under the "Expert Review" policy Error Code" registry operates under the "Expert Review" policy
[RFC8126]. [RFC8126].
Registrations for error codes are required to include a description Registrations for error codes are required to include a description
of the error code. An expert reviewer is advised to examine new of the error code. An expert reviewer is advised to examine new
skipping to change at page 39, line 36 skipping to change at page 41, line 18
| | | processed | | | | | 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 governs a 62-bit space.
The "HTTP/3 Stream Type" registry operates under either of the "IETF This space is split into three spaces that are governed by different
Review" or "IESG Approval" policies [RFC8126] for values from 0x00 up policies. Values between "0x00" and 0x3f (in hexadecimal) are
to and including 0xef, with values from 0xf0 up to and including 0xff assigned via the Standards Action or IESG Review policies [RFC8126].
being reserved for Experimental Use. Values from "0x40" to "0x3fff" operate on the Specification Required
policy [RFC8126]. All other values are assigned to Private Use
[RFC8126].
New entries in this registry require the following information: New entries in this registry require the following information:
Stream Type: A name or label for the stream type. Stream Type: A name or label for the stream type.
Code: The 8-bit code assigned to the stream type. Code: The 62-bit code assigned to the stream type.
Specification: A reference to a specification that includes a Specification: A reference to a specification that includes a
description of the stream type, including the layout semantics of description of the stream type, including the layout semantics of
its payload. its payload.
Sender: Which endpoint on a connection may initiate a stream of this Sender: Which endpoint on a connection may initiate a stream of this
type. Values are "Client", "Server", or "Both". type. Values are "Client", "Server", or "Both".
The entries in the following table are registered by this document. The entries in the following table are registered by this document.
+----------------+------+---------------+--------+ +----------------+------+---------------+--------+
| Stream Type | Code | Specification | Sender | | Stream Type | Code | Specification | Sender |
+----------------+------+---------------+--------+ +----------------+------+---------------+--------+
| Control Stream | 0x43 | Section 3.2.1 | Both | | Control Stream | 0x00 | Section 3.2.1 | Both |
| | | | | | | | | |
| Push Stream | 0x50 | Section 5.4 | Server | | Push Stream | 0x01 | Section 5.4 | Server |
+----------------+------+---------------+--------+ +----------------+------+---------------+--------+
Additionally, for each code of the format "0x1f * N" for values of N Additionally, each code of the format "0x1f * N + 0x21" for integer
in the range (0..8) (that is, "0x00", "0x1f", "0x3e", "0x5d", "0x7c", values of N (that is, "0x21", "0x40", ..., through
"0x9b", "0xba", "0xd9", "0xf8"), the following values should be "0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA.
registered:
Stream Type: Reserved - GREASE
Specification: Section 3.2.3
Sender: Both
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>.
[HTTP-REPLAY]
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>.
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Header Compression for HTTP over QUIC", draft-ietf-quic- Header Compression for HTTP over QUIC", draft-ietf-quic-
qpack-06 (work in progress), January 2019. qpack-07 (work in progress), March 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-17 (work in progress), January 2019. transport-18 (work in progress), March 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 39 skipping to change at page 43, line 19
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] 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>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
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 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP
Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014,
<https://www.rfc-editor.org/info/rfc7413>. <https://www.rfc-editor.org/info/rfc7413>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
<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
[3] https://github.com/quicwg/base-drafts/labels/-http [3] https://github.com/quicwg/base-drafts/labels/-http
[4] https://www.iana.org/assignments/message-headers [4] https://www.iana.org/assignments/message-headers
skipping to change at page 44, line 49 skipping to change at page 46, line 34
contain an error code. See Section 4.2.7. contain an error code. See Section 4.2.7.
WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC WINDOW_UPDATE (0x8): WINDOW_UPDATE frames do not exist, since QUIC
provides flow control. provides flow control.
CONTINUATION (0x9): CONTINUATION frames do not exist; instead, CONTINUATION (0x9): CONTINUATION frames do not exist; instead,
larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted. larger HEADERS/PUSH_PROMISE frames than HTTP/2 are permitted.
Frame types defined by extensions to HTTP/2 need to be separately Frame types defined by extensions to HTTP/2 need to be separately
registered for HTTP/3 if still applicable. The IDs of frames defined registered for HTTP/3 if still applicable. The IDs of frames defined
in [RFC7540] have been reserved for simplicity. See Section 10.3. in [RFC7540] have been reserved for simplicity. Note that the frame
type space in HTTP/3 is substantially larger (62 bits versus 8 bits),
so many HTTP/3 frame types have no equivalent HTTP/2 code points.
See Section 10.3.
A.3. HTTP/2 SETTINGS Parameters A.3. HTTP/2 SETTINGS Parameters
An important difference from HTTP/2 is that settings are sent once, An important difference from HTTP/2 is that settings are sent once,
at the beginning of the connection, and thereafter cannot change. at the beginning of the connection, and thereafter cannot change.
This eliminates many corner cases around synchronization of changes. This eliminates many corner cases around synchronization of changes.
Some transport-level options that HTTP/2 specifies via the SETTINGS Some transport-level options that HTTP/2 specifies via the SETTINGS
frame are superseded by QUIC transport parameters in HTTP/3. The frame are superseded by QUIC transport parameters in HTTP/3. The
HTTP-level options that are retained in HTTP/3 have the same value as HTTP-level options that are retained in HTTP/3 have the same value as
skipping to change at page 45, line 46 skipping to change at page 47, line 31
In HTTP/3, setting values are variable-length integers (6, 14, 30, or In HTTP/3, setting values are variable-length integers (6, 14, 30, or
62 bits long) rather than fixed-length 32-bit fields as in HTTP/2. 62 bits long) rather than fixed-length 32-bit fields as in HTTP/2.
This will often produce a shorter encoding, but can produce a longer This will often produce a shorter encoding, but can produce a longer
encoding for settings which use the full 32-bit space. Settings encoding for settings which use the full 32-bit space. Settings
ported from HTTP/2 might choose to redefine the format of their ported from HTTP/2 might choose to redefine the format of their
settings to avoid using the 62-bit encoding. settings to avoid using the 62-bit encoding.
Settings need to be defined separately for HTTP/2 and HTTP/3. The Settings need to be defined separately for HTTP/2 and HTTP/3. The
IDs of settings defined in [RFC7540] have been reserved for IDs of settings defined in [RFC7540] have been reserved for
simplicity. See Section 10.4. simplicity. Note that the settings identifier space in HTTP/3 is
substantially larger (62 bits versus 16 bits), so many HTTP/3
settings have no equivalent HTTP/2 code point. See Section 10.4.
A.4. HTTP/2 Error Codes A.4. HTTP/2 Error Codes
QUIC has the same concepts of "stream" and "connection" errors that QUIC has the same concepts of "stream" and "connection" errors that
HTTP/2 provides. However, there is no direct portability of HTTP/2 HTTP/2 provides. However, there is no direct portability of HTTP/2
error codes. error codes.
The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the The HTTP/2 error codes defined in Section 7 of [RFC7540] map to the
HTTP/3 error codes as follows: HTTP/3 error codes as follows:
skipping to change at page 47, line 10 skipping to change at page 48, line 47
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-17 B.1. Since draft-ietf-quic-http-18
o Resetting streams following a GOAWAY is recommended, but not
required (#2256,#2457)
o Use variable-length integers throughout (#2437,#2233,#2253,#2275)
* Variable-length frame types, stream types, and settings
identifiers
* Renumbered stream type assignments
* Modified associated reserved values
o Frame layout switched from Length-Type-Value to Type-Length-Value
(#2395,#2235)
o Specified error code for servers receiving DUPLICATE_PUSH (#2497)
o Use connection error for invalid PRIORITY (#2507, #2508)
B.2. Since draft-ietf-quic-http-17
o HTTP_REQUEST_REJECTED is used to indicate a request can be retried o HTTP_REQUEST_REJECTED is used to indicate a request can be retried
(#2106, #2325) (#2106, #2325)
o Changed error code for GOAWAY on the wrong stream (#2231, #2343) o Changed error code for GOAWAY on the wrong stream (#2231, #2343)
B.2. Since draft-ietf-quic-http-16 B.3. 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
skipping to change at page 47, line 43 skipping to change at page 50, line 5
(#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.3. Since draft-ietf-quic-http-15 B.4. Since draft-ietf-quic-http-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.4. Since draft-ietf-quic-http-14 B.5. 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.5. Since draft-ietf-quic-http-13 B.6. 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.6. Since draft-ietf-quic-http-12 B.7. 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.7. Since draft-ietf-quic-http-11 B.8. 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.8. Since draft-ietf-quic-http-10 B.9. 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.9. Since draft-ietf-quic-http-09 B.10. 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.10. Since draft-ietf-quic-http-08 B.11. Since draft-ietf-quic-http-08
o Clarified connection coalescing rules (#940, #1024) o Clarified connection coalescing rules (#940, #1024)
B.11. Since draft-ietf-quic-http-07 B.12. 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.12. Since draft-ietf-quic-http-06 B.13. 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.13. Since draft-ietf-quic-http-05 B.14. 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.14. Since draft-ietf-quic-http-04 B.15. 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 50, line 4 skipping to change at page 52, line 16
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.15. Since draft-ietf-quic-http-03 B.16. Since draft-ietf-quic-http-03
None. None.
B.16. Since draft-ietf-quic-http-02 B.17. Since draft-ietf-quic-http-02
o Track changes in transport draft o Track changes in transport draft
B.17. Since draft-ietf-quic-http-01 B.18. 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
skipping to change at page 50, line 39 skipping to change at page 53, line 4
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.18. Since draft-ietf-quic-http-00 B.19. 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.19. Since draft-shade-quic-http2-mapping-00 B.20. 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. 79 change blocks. 
233 lines changed or deleted 317 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/