draft-ietf-quic-http-22.txt   draft-ietf-quic-http-latest.txt 
QUIC Working Group M. Bishop, Ed. QUIC Working Group M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track July 9, 2019 Intended status: Standards Track August 23, 2019
Expires: January 10, 2020 Expires: February 24, 2020
Hypertext Transfer Protocol Version 3 (HTTP/3) Hypertext Transfer Protocol Version 3 (HTTP/3)
draft-ietf-quic-http-22 draft-ietf-quic-http-latest
Abstract Abstract
The QUIC transport protocol has several features that are desirable The QUIC transport protocol has several features that are desirable
in a transport for HTTP, such as stream multiplexing, per-stream flow in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC. This document also describes a mapping of HTTP semantics over QUIC. This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to HTTP/3. how HTTP/2 extensions can be ported to HTTP/3.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 10, 2020. This Internet-Draft will expire on February 24, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 40 skipping to change at page 2, line 40
3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 8 3.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 8
3.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 9 3.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 9
3.3. Connection Establishment . . . . . . . . . . . . . . . . 9 3.3. Connection Establishment . . . . . . . . . . . . . . . . 9
3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 10 3.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 10
4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 10 4. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 10
4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 10 4.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 10
4.1.1. Header Formatting and Compression . . . . . . . . . . 12 4.1.1. Header Formatting and Compression . . . . . . . . . . 12
4.1.2. Request Cancellation and Rejection . . . . . . . . . 13 4.1.2. Request Cancellation and Rejection . . . . . . . . . 13
4.1.3. Malformed Requests and Responses . . . . . . . . . . 14 4.1.3. Malformed Requests and Responses . . . . . . . . . . 14
4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 14 4.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 14
4.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 15 4.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 16
4.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 17 4.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 17
4.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 17 4.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 17
4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 18 4.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 18
5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 20 5. Connection Closure . . . . . . . . . . . . . . . . . . . . . 20
5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 20 5.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 20
5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 20 5.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 20
5.3. Immediate Application Closure . . . . . . . . . . . . . . 22 5.3. Immediate Application Closure . . . . . . . . . . . . . . 22
5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 22 5.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 22
6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 22 6. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 22
6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 23 6.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 23
6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 23 6.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 23
6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 24 6.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 24
6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 25 6.2.2. Push Streams . . . . . . . . . . . . . . . . . . . . 25
6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 25 6.2.3. Reserved Stream Types . . . . . . . . . . . . . . . . 26
7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 26 7. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 26
7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 27 7.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 28 7.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 28
7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 28 7.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 29 7.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 29
7.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 29 7.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 29
7.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 32 7.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 32
7.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 32 7.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 32
7.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 35 7.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 35
7.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 36 7.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 36
7.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 36 7.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 36
7.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 37 7.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 37
7.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 38 7.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 38
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 38 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 38
8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 39 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 39
9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 40 9. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 40
10. Security Considerations . . . . . . . . . . . . . . . . . . . 41 10. Security Considerations . . . . . . . . . . . . . . . . . . . 41
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 42 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11.1. Registration of HTTP/3 Identification String . . . . . . 42 11.1. Registration of HTTP/3 Identification String . . . . . . 41
11.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 42 11.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 42
11.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 42 11.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 42
11.4. Settings Parameters . . . . . . . . . . . . . . . . . . 43 11.4. Settings Parameters . . . . . . . . . . . . . . . . . . 43
11.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 44 11.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 44
11.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 47 11.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 47
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 48 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
12.1. Normative References . . . . . . . . . . . . . . . . . . 48 12.1. Normative References . . . . . . . . . . . . . . . . . . 47
12.2. Informative References . . . . . . . . . . . . . . . . . 49 12.2. Informative References . . . . . . . . . . . . . . . . . 49
12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 50 12.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 50 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 50
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 50 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 50 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 50
A.2.1. Prioritization Differences . . . . . . . . . . . . . 51 A.2.1. Prioritization Differences . . . . . . . . . . . . . 51
A.2.2. Header Compression Differences . . . . . . . . . . . 51 A.2.2. Header Compression Differences . . . . . . . . . . . 51
A.2.3. Guidance for New Frame Type Definitions . . . . . . . 52 A.2.3. Guidance for New Frame Type Definitions . . . . . . . 52
A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 52 A.2.4. Mapping Between HTTP/2 and HTTP/3 Frame Types . . . . 52
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 53 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 53
A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 54 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 54
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 55 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 55
B.1. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 55 B.1. Since draft-ietf-quic-http-21 . . . . . . . . . . . . . . 55
B.2. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 55 B.2. Since draft-ietf-quic-http-20 . . . . . . . . . . . . . . 55
B.3. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 56 B.3. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 56
B.4. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 56 B.4. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 56
B.5. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 57 B.5. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 57
B.6. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 57 B.6. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 57
B.7. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 58 B.7. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 57
B.8. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 58 B.8. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 57
B.9. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 58 B.9. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 58
B.10. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 58 B.10. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 58
B.11. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 59 B.11. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 58
B.12. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 59 B.12. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 58
B.13. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 59 B.13. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 58
B.14. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 59 B.14. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 59
B.15. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 59 B.15. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 59
B.16. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 59 B.16. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 59
B.17. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 59 B.17. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 59
B.18. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 60 B.18. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 59
B.19. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 60 B.19. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 60
B.20. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 60 B.20. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 60
B.21. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 60 B.21. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 60
B.22. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 61 B.22. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 60
B.23. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 61 B.23. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 61
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 61 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 61
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 61
1. Introduction 1. Introduction
HTTP semantics are used for a broad range of services on the HTTP semantics are used for a broad range of services on the
Internet. These semantics have commonly been used with two different Internet. These semantics have commonly been used with two different
TCP mappings, HTTP/1.1 and HTTP/2. HTTP/3 supports the same TCP mappings, HTTP/1.1 and HTTP/2. HTTP/3 supports the same
semantics over a new transport protocol, QUIC. semantics over a new transport protocol, QUIC.
skipping to change at page 5, line 8 skipping to change at page 5, line 8
1.2. Delegation to QUIC 1.2. Delegation to QUIC
The QUIC transport protocol incorporates stream multiplexing and per- The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing stream flow control, similar to that provided by the HTTP/2 framing
layer. By providing reliability at the stream level and congestion layer. By providing reliability at the stream level and congestion
control across the entire connection, it has the capability to control across the entire connection, it has the capability to
improve the performance of HTTP compared to a TCP mapping. QUIC also improve the performance of HTTP compared to a TCP mapping. QUIC also
incorporates TLS 1.3 at the transport layer, offering comparable incorporates TLS 1.3 at the transport layer, offering comparable
security to running TLS over TCP, with the improved connection setup security to running TLS over TCP, with the improved connection setup
latency of TCP Fast Open [RFC7413]}. latency of TCP Fast Open [RFC7413].
This document defines a mapping of HTTP semantics over the QUIC This document defines a mapping of HTTP semantics over the QUIC
transport protocol, drawing heavily on the design of HTTP/2. While transport protocol, drawing heavily on the design of HTTP/2. While
delegating stream lifetime and flow control issues to QUIC, a similar delegating stream lifetime and flow control issues to QUIC, a similar
binary framing is used on each stream. Some HTTP/2 features are binary framing is used on each stream. Some HTTP/2 features are
subsumed by QUIC, while other features are implemented atop QUIC. subsumed by QUIC, while other features are implemented atop QUIC.
QUIC is described in [QUIC-TRANSPORT]. For a full description of QUIC is described in [QUIC-TRANSPORT]. For a full description of
HTTP/2, see [HTTP2]. HTTP/2, see [HTTP2].
skipping to change at page 11, line 12 skipping to change at page 11, line 12
QUIC stream. A client MUST send only a single request on a given QUIC stream. A client MUST send only a single request on a given
stream. A server sends zero or more non-final HTTP responses on the stream. A server sends zero or more non-final HTTP responses on the
same stream as the request, followed by a single final HTTP response, same stream as the request, followed by a single final HTTP response,
as detailed below. as detailed below.
An HTTP message (request or response) consists of: An HTTP message (request or response) consists of:
1. the message header (see [RFC7230], Section 3.2), sent as a single 1. the message header (see [RFC7230], Section 3.2), sent as a single
HEADERS frame (see Section 7.2.2), HEADERS frame (see Section 7.2.2),
2. the payload body (see [RFC7230], Section 3.3), sent as a series 2. optionally, the payload body, if present (see [RFC7230],
of DATA frames (see Section 7.2.1), Section 3.3), sent as a series of DATA frames (see
Section 7.2.1),
3. optionally, one HEADERS frame containing the trailer-part, if 3. optionally, trailing headers, if present (see [RFC7230],
present (see [RFC7230], Section 4.1.2). Section 4.1.2), sent as a single HEADERS frame.
A server MAY send one or more PUSH_PROMISE frames (see Section 7.2.6) A server MAY send one or more PUSH_PROMISE frames (see Section 7.2.6)
before, after, or interleaved with the frames of a response message. before, after, or interleaved with the frames of a response message.
These PUSH_PROMISE frames are not part of the response; see These PUSH_PROMISE frames are not part of the response; see
Section 4.4 for more details. Section 4.4 for more details.
Frames of unknown types (Section 9), including reserved frames
(Section 7.2.10) MAY be sent on a request or push stream before,
after, or interleaved with other frames described in this section.
The HEADERS and PUSH_PROMISE frames might reference updates to the The HEADERS and PUSH_PROMISE frames might reference updates to the
QPACK dynamic table. While these updates are not directly part of QPACK dynamic table. While these updates are not directly part of
the message exchange, they must be received and processed before the the message exchange, they must be received and processed before the
message can be consumed. See Section 4.1.1 for more details. message can be consumed. See Section 4.1.1 for more details.
The "chunked" transfer encoding defined in Section 4.1 of [RFC7230] The "chunked" transfer encoding defined in Section 4.1 of [RFC7230]
MUST NOT be used. MUST NOT be used.
If a DATA frame is received before a HEADERS frame on a either a
request or push stream, the recipient MUST respond with a connection
error of type HTTP_UNEXPECTED_FRAME (Section 8).
Trailing header fields are carried in an additional HEADERS frame
following the body. Senders MUST send only one HEADERS frame in the
trailers section; receivers MUST discard any subsequent HEADERS
frames.
A response MAY consist of multiple messages when and only when one or A response MAY consist of multiple messages when and only when one or
more informational responses (1xx; see [RFC7231], Section 6.2) more informational responses (1xx; see [RFC7231], Section 6.2)
precede a final response to the same request. Non-final responses do precede a final response to the same request. Non-final responses do
not contain a payload body or trailers. not contain a payload body or trailers.
If an endpoint receives an invalid sequence of frames on either a
request or a push stream, it MUST respond with a connection error of
type HTTP_UNEXPECTED_FRAME (Section 8). In particular, a DATA frame
before any HEADERS frame, or a HEADERS or DATA frame after the
trailing HEADERS frame is considered invalid.
An HTTP request/response exchange fully consumes a bidirectional QUIC An HTTP request/response exchange fully consumes a bidirectional QUIC
stream. After sending a request, a client MUST close the stream for stream. After sending a request, a client MUST close the stream for
sending. Unless using the CONNECT method (see Section 4.2), clients sending. Unless using the CONNECT method (see Section 4.2), clients
MUST NOT make stream closure dependent on receiving a response to MUST NOT make stream closure dependent on receiving a response to
their request. After sending a final response, the server MUST close their request. After sending a final response, the server MUST close
the stream for sending. At this point, the QUIC stream is fully the stream for sending. At this point, the QUIC stream is fully
closed. closed.
When a stream is closed, this indicates the end of an HTTP message. When a stream is closed, this indicates the end of an HTTP message.
Because some messages are large or unbounded, endpoints SHOULD begin Because some messages are large or unbounded, endpoints SHOULD begin
processing partial HTTP messages once enough of the message has been processing partial HTTP messages once enough of the message has been
received to make progress. If a client stream terminates without received to make progress. If a client stream terminates without
enough of the HTTP message to provide a complete response, the server enough of the HTTP message to provide a complete response, the server
SHOULD abort its response with the error code SHOULD abort its response with the error code
HTTP_INCOMPLETE_REQUEST. HTTP_REQUEST_INCOMPLETE.
A server can send a complete response prior to the client sending an A server can send a complete response prior to the client sending an
entire request if the response does not depend on any portion of the entire request if the response does not depend on any portion of the
request that has not been sent and received. When this is true, a request that has not been sent and received. When this is true, a
server MAY request that the client abort transmission of a request server MAY abort reading the request stream with error code
without error by triggering a QUIC STOP_SENDING frame with error code HTTP_EARLY_RESPONSE, send a complete response, and cleanly close the
HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing sending part of the stream. Clients MUST NOT discard complete
its stream. Clients MUST NOT discard complete responses as a result responses as a result of having their request terminated abruptly,
of having their request terminated abruptly, though clients can though clients can always discard responses at their discretion for
always discard responses at their discretion for other reasons. other reasons.
4.1.1. Header Formatting and Compression 4.1.1. Header Formatting and Compression
HTTP message headers carry information as a series of key-value HTTP message headers carry information as a series of key-value
pairs, called header fields. For a listing of registered HTTP header pairs, called header fields. For a listing of registered HTTP header
fields, see the "Message Header Field" registry maintained at fields, see the "Message Header Field" registry maintained at
https://www.iana.org/assignments/message-headers [4]. https://www.iana.org/assignments/message-headers [4].
Just as in previous versions of HTTP, header field names are strings Just as in previous versions of HTTP, header field names are strings
of ASCII characters that are compared in a case-insensitive fashion. of ASCII characters that are compared in a case-insensitive fashion.
skipping to change at page 13, line 5 skipping to change at page 13, line 7
Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT Pseudo-header fields are not HTTP header fields. Endpoints MUST NOT
generate pseudo-header fields other than those defined in [HTTP2]. generate pseudo-header fields other than those defined in [HTTP2].
The restrictions on the use of pseudo-header fields in The restrictions on the use of pseudo-header fields in
Section 8.1.2.1 of [HTTP2] also apply to HTTP/3. Section 8.1.2.1 of [HTTP2] also apply to HTTP/3.
HTTP/3 uses QPACK header compression as described in [QPACK], a HTTP/3 uses QPACK header compression as described in [QPACK], a
variation of HPACK which allows the flexibility to avoid header- variation of HPACK which allows the flexibility to avoid header-
compression-induced head-of-line blocking. See that document for compression-induced head-of-line blocking. See that document for
additional details. additional details.
To allow for better compression efficiency, the cookie header field
[RFC6265] MAY be split into separate header fields, each with one or
more cookie-pairs, before compression. If a decompressed header list
contains multiple cookie header fields, these MUST be concatenated
before being passed into a non-HTTP/2, non-HTTP/3 context, as
described in [HTTP2], Section 8.1.2.5.
An HTTP/3 implementation MAY impose a limit on the maximum size of An HTTP/3 implementation MAY impose a limit on the maximum size of
the message header it will accept on an individual HTTP message. A the message header it will accept on an individual HTTP message. A
server that receives a larger header field list than it is willing to server that receives a larger header field list than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status handle can send an HTTP 431 (Request Header Fields Too Large) status
code [RFC6585]. A client can discard responses that it cannot code [RFC6585]. A client can discard responses that it cannot
process. The size of a header field list is calculated based on the process. The size of a header field list is calculated based on the
uncompressed size of header fields, including the length of the name uncompressed size of header fields, including the length of the name
and value in bytes plus an overhead of 32 bytes for each header and value in bytes plus an overhead of 32 bytes for each header
field. field.
If an implementation wishes to advise its peer of this limit, it can If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the be conveyed as a number of bytes in the
"SETTINGS_MAX_HEADER_LIST_SIZE" parameter. An implementation which "SETTINGS_MAX_HEADER_LIST_SIZE" parameter. An implementation which
has received this parameter SHOULD NOT send an HTTP message header has received this parameter SHOULD NOT send an HTTP message header
which exceeds the indicated size, as the peer will likely refuse to which exceeds the indicated size, as the peer will likely refuse to
process it. However, because this limit is applied at each hop, process it. However, because this limit is applied at each hop,
messages below this limit are not guaranteed to be accepted. messages below this limit are not guaranteed to be accepted.
4.1.2. Request Cancellation and Rejection 4.1.2. Request Cancellation and Rejection
Clients can cancel requests by aborting the stream (QUIC RESET_STREAM Clients can cancel requests by resetting and aborting the request
and/or STOP_SENDING frames, as appropriate) with an error code of stream with an error code of HTTP_REQUEST_CANCELLED (Section 8.1).
HTTP_REQUEST_CANCELLED (Section 8.1). When the client cancels a When the client aborts reading a response, it indicates that this
response, it indicates that this response is no longer of interest. response is no longer of interest. Implementations SHOULD cancel
Implementations SHOULD cancel requests by aborting both directions of requests by abruptly terminating any directions of a stream that are
a stream. still open.
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 server requests which were partially or fully processed. When a server
abandons a response after partial processing, it SHOULD abort its abandons a response after partial processing, it SHOULD abort its
response stream with the error code HTTP_REQUEST_CANCELLED. response stream with the error code HTTP_REQUEST_CANCELLED.
When a client sends a STOP_SENDING with HTTP_REQUEST_CANCELLED, a When a client resets a request with the error code
server MAY send the error code HTTP_REQUEST_REJECTED in the HTTP_REQUEST_CANCELLED, a server MAY abruptly terminate the response
corresponding RESET_STREAM if no processing was performed. Clients using the error code HTTP_REQUEST_REJECTED if no processing was
MUST NOT reset streams with the HTTP_REQUEST_REJECTED error code performed. Clients MUST NOT use the HTTP_REQUEST_REJECTED error
except in response to a QUIC STOP_SENDING frame that contains the code, except when a server has requested closure of the request
same code. stream with this error 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).
4.1.3. Malformed Requests and Responses 4.1.3. Malformed Requests and Responses
skipping to change at page 15, line 34 skipping to change at page 15, line 43
The TCP connection can be closed by either peer. When the client The TCP connection can be closed by either peer. When the client
ends the request stream (that is, the receive stream at the proxy ends the request stream (that is, the receive stream at the proxy
enters the "Data Recvd" state), the proxy will set the FIN bit on its enters the "Data Recvd" state), the proxy will set the FIN bit on its
connection to the TCP server. When the proxy receives a packet with connection to the TCP server. When the proxy receives a packet with
the FIN bit set, it will terminate the send stream that it sends to the FIN bit set, it will terminate the send stream that it sends to
the client. TCP connections which remain half-closed in a single the client. TCP connections which remain half-closed in a single
direction are not invalid, but are often handled poorly by servers, direction are not invalid, but are often handled poorly by servers,
so clients SHOULD NOT close a stream for sending while they still so clients SHOULD NOT close a stream for sending while they still
expect to receive data from the target of the CONNECT. expect to receive data from the target of the CONNECT.
A TCP connection error is signaled with QUIC RESET_STREAM frame. A A TCP connection error is signaled by abruptly terminating the
proxy treats any error in the TCP connection, which includes stream. A proxy treats any error in the TCP connection, which
receiving a TCP segment with the RST bit set, as a stream error of includes receiving a TCP segment with the RST bit set, as a stream
type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, if a proxy error of type HTTP_CONNECT_ERROR (Section 8.1). Correspondingly, if
detects an error with the stream or the QUIC connection, it MUST a proxy detects an error with the stream or the QUIC connection, it
close the TCP connection. If the underlying TCP implementation MUST close the TCP connection. If the underlying TCP implementation
permits it, the proxy SHOULD send a TCP segment with the RST bit set. permits it, the proxy SHOULD send a TCP segment with the RST bit set.
4.3. Prioritization 4.3. Prioritization
The purpose of prioritization is to allow a client to express how it The purpose of prioritization is to allow a client to express how it
would prefer the server to allocate resources when managing would prefer the server to allocate resources when managing
concurrent streams. Most importantly, priority can be used to select concurrent streams. Most importantly, priority can be used to select
streams for transmitting frames when there is limited capacity for streams for transmitting frames when there is limited capacity for
sending. sending.
skipping to change at page 19, line 49 skipping to change at page 20, line 10
resources and cancel the requests if the requested resource is resources and cancel the requests if the requested resource is
already being pushed. When a client receives a new push stream with already being pushed. When a client receives a new push stream with
an as-yet-unknown Push ID, both the associated client request and the an as-yet-unknown Push ID, both the associated client request and the
pushed request headers are unknown. The client can buffer the stream pushed request headers are unknown. The client can buffer the stream
data in expectation of the matching PUSH_PROMISE. The client can use data in expectation of the matching PUSH_PROMISE. The client can use
stream flow control (see section 4.1 of [QUIC-TRANSPORT]) to limit stream flow control (see section 4.1 of [QUIC-TRANSPORT]) to limit
the amount of data a server may commit to the pushed stream. the amount of data a server may commit to the pushed stream.
If a promised server push is not needed by the client, the client If a promised server push is not needed by the client, the client
SHOULD send a CANCEL_PUSH frame. If the push stream is already open SHOULD send a CANCEL_PUSH frame. If the push stream is already open
or opens after sending the CANCEL_PUSH frame, a QUIC STOP_SENDING or opens after sending the CANCEL_PUSH frame, the client can abort
frame with an error code of HTTP_REQUEST_CANCELLED can be used. This reading the stream with an error code of HTTP_REQUEST_CANCELLED.
asks the server not to transfer additional data and indicates that it This asks the server not to transfer additional data and indicates
will be discarded upon receipt. that it will be discarded upon receipt.
5. Connection Closure 5. Connection Closure
Once established, an HTTP/3 connection can be used for many requests Once established, an HTTP/3 connection can be used for many requests
and responses over time until the connection is closed. Connection and responses over time until the connection is closed. Connection
closure can happen in any of several different ways. closure can happen in any of several different ways.
5.1. Idle Connections 5.1. Idle Connections
Each QUIC endpoint declares an idle timeout during the handshake. If Each QUIC endpoint declares an idle timeout during the handshake. If
skipping to change at page 20, line 50 skipping to change at page 21, line 12
continue to completion. Servers perform the same function by continue to completion. Servers perform the same function by
communicating with clients. communicating with clients.
Servers initiate the shutdown of a connection by sending a GOAWAY Servers initiate the shutdown of a connection by sending a GOAWAY
frame (Section 7.2.7). The GOAWAY frame indicates that client- frame (Section 7.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 zero if no requests were processed. Servers SHOULD identifier MAY be zero if no requests were processed. Servers SHOULD
NOT increase the QUIC MAX_STREAMS limit after sending a GOAWAY frame. NOT permit additional QUIC streams after sending a GOAWAY frame.
Clients MUST NOT send new requests on the connection after receiving Clients MUST NOT send new requests on the connection after receiving
GOAWAY; a new connection MAY be established to send additional GOAWAY; a new connection MAY be established to send additional
requests. requests.
Some requests might already be in transit. If the client has already Some requests might already be in transit. If the client has already
sent requests on streams with a Stream ID greater than or equal to sent requests on streams with a Stream ID greater than or equal to
that indicated in the GOAWAY frame, those requests will not be that indicated in the GOAWAY frame, those requests will not be
processed and MAY be retried by the client on a different connection. processed and MAY be retried by the client on a different connection.
The client MAY cancel these requests. It is RECOMMENDED that the The client MAY cancel these requests. It is RECOMMENDED that the
skipping to change at page 23, line 12 skipping to change at page 23, line 22
multiplexing when using QUIC - data sent over a QUIC stream always multiplexing when using QUIC - data sent over a QUIC stream always
maps to a particular HTTP transaction or connection context. maps to a particular HTTP transaction or connection context.
6.1. Bidirectional Streams 6.1. Bidirectional Streams
All client-initiated bidirectional streams are used for HTTP requests All client-initiated bidirectional streams are used for HTTP requests
and responses. A bidirectional stream ensures that the response can and responses. A bidirectional stream ensures that the response can
be readily correlated with the request. This means that the client's be readily correlated with the request. This means that the client's
first request occurs on QUIC stream 0, with subsequent requests on first request occurs on QUIC stream 0, with subsequent requests on
stream 4, 8, and so on. In order to permit these streams to open, an stream 4, 8, and so on. In order to permit these streams to open, an
HTTP/3 client SHOULD send non-zero values for the QUIC transport HTTP/3 server SHOULD configure non-zero minimum values for the number
parameters "initial_max_stream_data_bidi_local". An HTTP/3 server of permitted streams and the initial stream flow control window. It
SHOULD send non-zero values for the QUIC transport parameters is RECOMMENDED that at least 100 requests be permitted at a time, so
"initial_max_stream_data_bidi_remote" and "initial_max_bidi_streams". as to not unnecessarily limit parallelism.
It is RECOMMENDED that "initial_max_bidi_streams" be no smaller than
100, so as to not unnecessarily limit parallelism.
HTTP/3 does not use server-initiated bidirectional streams, though an HTTP/3 does not use server-initiated bidirectional streams, though an
extension could define a use for these streams. Clients MUST treat extension could define a use for these streams. Clients MUST treat
receipt of a server-initiated bidirectional stream as a connection receipt of a server-initiated bidirectional stream as a connection
error of type HTTP_STREAM_CREATION_ERROR unless such an extension has error of type HTTP_STREAM_CREATION_ERROR unless such an extension has
been negotiated. been negotiated.
6.2. Unidirectional Streams 6.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
skipping to change at page 23, line 48 skipping to change at page 24, line 7
Figure 2: Unidirectional Stream Header Figure 2: Unidirectional Stream Header
Some stream types are reserved (Section 6.2.3). Two stream types are Some stream types are reserved (Section 6.2.3). Two stream types are
defined in this document: control streams (Section 6.2.1) and push defined in this document: control streams (Section 6.2.1) and push
streams (Section 6.2.2). Other stream types can be defined by streams (Section 6.2.2). Other stream types can be defined by
extensions to HTTP/3; see Section 9 for more details. extensions to HTTP/3; see Section 9 for more details.
The performance of HTTP/3 connections in the early phase of their The performance of HTTP/3 connections in the early phase of their
lifetime is sensitive to the creation and exchange of data on lifetime is sensitive to the creation and exchange of data on
unidirectional streams. Endpoints that set low values for the QUIC unidirectional streams. Endpoints that excessively restrict the
transport parameters "initial_max_uni_streams" and number of streams or the flow control window of these streams will
"initial_max_stream_data_uni" will increase the chance that the increase the chance that the remote peer reaches the limit early and
remote peer reaches the limit early and becomes blocked. In becomes blocked. In particular, implementations should consider that
particular, the value chosen for "initial_max_uni_streams" should remote peers may wish to exercise reserved stream behavior
consider that remote peers may wish to exercise reserved stream (Section 6.2.3) with some of the unidirectional streams they are
behavior (Section 6.2.3). To avoid blocking, both clients and permitted to use. To avoid blocking, the transport parameters sent
servers MUST allow the peer to create at least one unidirectional by both clients and servers MUST allow the peer to create at least
stream for the HTTP control stream plus the number of unidirectional one unidirectional stream for the HTTP control stream plus the number
streams required by mandatory extensions (such as QPACK) by setting of unidirectional streams required by mandatory extensions (three
an appropriate value for the QUIC transport parameter being the minimum number required for the base HTTP/3 protocol and
"initial_max_uni_streams" (three being the minimum value required for QPACK), and SHOULD provide at least 1,024 bytes of flow control
the base HTTP/3 protocol and QPACK), and SHOULD use a value of 1,024 credit to each stream.
or greater for the QUIC transport parameter
"initial_max_stream_data_uni".
Note that an endpoint is not required to grant additional credits to Note that an endpoint is not required to grant additional credits to
create more unidirectional streams if its peer consumes all the create more unidirectional streams if its peer consumes all the
initial credits before creating the critical unidirectional streams. initial credits before creating the critical unidirectional streams.
Endpoints SHOULD create the HTTP control stream as well as the Endpoints SHOULD create the HTTP control stream as well as the
unidirectional streams required by mandatory extensions (such as the unidirectional streams required by mandatory extensions (such as the
QPACK encoder and decoder streams) first, and then create additional QPACK encoder and decoder streams) first, and then create additional
streams as allowed by their peer. streams as allowed by their peer.
If the stream header indicates a stream type which is not supported If the stream header indicates a stream type which is not supported
by the recipient, the remainder of the stream cannot be consumed as by the recipient, the remainder of the stream cannot be consumed as
the semantics are unknown. Recipients of unknown stream types MAY the semantics are unknown. Recipients of unknown stream types MAY
trigger a QUIC STOP_SENDING frame with an error code of abort reading of the stream with an error code of
HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be HTTP_STREAM_CREATION_ERROR, but MUST NOT consider such streams to be
a connection error of any kind. a connection error of any kind.
Implementations MAY send stream types before knowing whether the peer Implementations MAY send stream types before knowing whether the peer
supports them. However, stream types which could modify the state or supports them. However, stream types which could modify the state or
semantics of existing protocol components, including QPACK or other semantics of existing protocol components, including QPACK or other
extensions, MUST NOT be sent until the peer is known to support them. extensions, MUST NOT be sent until the peer is known to support them.
A sender can close or reset a unidirectional stream unless otherwise 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
skipping to change at page 25, line 26 skipping to change at page 25, line 31
6.2.2. Push Streams 6.2.2. Push Streams
Server push is an optional feature introduced in HTTP/2 that allows a Server push is an optional feature introduced in HTTP/2 that allows a
server to initiate a response before a request has been made. See server to initiate a response before a request has been made. See
Section 4.4 for more details. Section 4.4 for more details.
A push stream is indicated by a stream type of "0x01", followed by A push stream is indicated by a stream type of "0x01", followed by
the Push ID of the promise that it fulfills, encoded as a variable- the Push ID of the promise that it fulfills, encoded as a variable-
length integer. The remaining data on this stream consists of HTTP/3 length integer. The remaining data on this stream consists of HTTP/3
frames, as defined in Section 7.2, and fulfills a promised server frames, as defined in Section 7.2, and fulfills a promised server
push. Server push and Push IDs are described in Section 4.4. push by zero or more non-final HTTP responses followed by a single
final HTTP response, as defined in Section 4.1. Server push and Push
IDs are described in Section 4.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 connection error of type stream, this MUST be treated as a connection error of type
HTTP_STREAM_CREATION_ERROR. HTTP_STREAM_CREATION_ERROR.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0x01 (i) ... | 0x01 (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 28, line 31 skipping to change at page 28, line 31
Length: A variable-length integer that describes the length of the Length: A variable-length integer that describes the length of the
Frame Payload. 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_FRAME_ERROR.
When a stream terminates cleanly, if the last frame on the stream was When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error (Section 8) of truncated, this MUST be treated as a connection error (Section 8) of
type HTTP_MALFORMED_FRAME. Streams which terminate abruptly may be type HTTP_FRAME_ERROR. Streams which terminate abruptly may be reset
reset at any point in a frame. at any point in a frame.
7.2. Frame Definitions 7.2. Frame Definitions
7.2.1. DATA 7.2.1. DATA
DATA frames (type=0x0) convey arbitrary, variable-length sequences of DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with an HTTP request or response payload. bytes associated with an HTTP request or response payload.
DATA frames MUST be associated with an HTTP request or response. If DATA frames MUST be associated with an HTTP request or response. If
a DATA frame is received on a control stream, the recipient MUST a DATA frame is received on a control stream, the recipient MUST
skipping to change at page 31, line 26 skipping to change at page 31, line 26
Table 2: Element Types of a PRIORITY frame Table 2: Element Types of a PRIORITY frame
Note that unlike in [HTTP2], the root of the tree cannot be Note that unlike in [HTTP2], 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. valid HTTP request. The root of the tree cannot be reprioritized.
The PRIORITY frame can express relationships which might not be The PRIORITY frame can express relationships which might not be
permitted based on the stream on which it is sent or its position in permitted based on the stream on which it is sent or its position in
the stream. These situations MUST be treated as a connection error the stream. These situations MUST be treated as a connection error
of type HTTP_MALFORMED_FRAME. The following situations are examples of type HTTP_FRAME_ERROR. The following situations are examples of
of invalid PRIORITY frames: invalid PRIORITY frames:
o A PRIORITY frame with the Prioritized Element Type set to "11". o A PRIORITY frame with the Prioritized Element Type set to "11".
o A PRIORITY frame which claims to reference a request, but the o A PRIORITY frame which claims to reference a request, but the
associated ID does not identify a client-initiated bidirectional associated ID does not identify a client-initiated bidirectional
stream stream
A PRIORITY frame with Empty bits not set to zero MAY be treated as a A PRIORITY frame with Empty bits not set to zero MAY be treated as a
connection error of type HTTP_MALFORMED_FRAME. connection error of type HTTP_FRAME_ERROR.
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 a connection client is not yet permitted to open MUST be treated as a connection
error of type HTTP_ID_ERROR. error of type HTTP_ID_ERROR.
A PRIORITY frame received on any stream other than the control stream A PRIORITY frame received on any stream other than the control stream
MUST be treated as a connection error of type HTTP_WRONG_STREAM. MUST be treated as a connection error of type HTTP_WRONG_STREAM.
PRIORITY frames received by a client MUST be treated as a connection PRIORITY frames received by a client MUST be treated as a connection
skipping to change at page 32, line 16 skipping to change at page 32, line 16
The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a The CANCEL_PUSH frame (type=0x3) is used to request cancellation of a
server push prior to the push stream being received. The CANCEL_PUSH server push prior to the push stream being received. The CANCEL_PUSH
frame identifies a server push by Push ID (see Section 7.2.6), frame identifies a server push by Push ID (see Section 7.2.6),
encoded as a variable-length integer. encoded as a variable-length integer.
When a server receives this frame, it aborts sending the response for When a server receives this frame, it aborts sending the response for
the identified server push. If the server has not yet started to the identified server push. If the server has not yet started to
send the server push, it can use the receipt of a CANCEL_PUSH frame send the server push, it can use the receipt of a CANCEL_PUSH frame
to avoid opening a push stream. If the push stream has been opened to avoid opening a push stream. If the push stream has been opened
by the server, the server SHOULD send a QUIC RESET_STREAM frame on by the server, the server SHOULD abruptly terminate that stream.
that stream and cease transmission of the response.
A server can send the CANCEL_PUSH frame to indicate that it will not A server can send the CANCEL_PUSH frame to indicate that it will not
be fulfilling a promise prior to creation of a push stream. Once the be fulfilling a promise prior to creation of a push stream. Once the
push stream has been created, sending CANCEL_PUSH has no effect on push stream has been created, sending CANCEL_PUSH has no effect on
the state of the push stream. A QUIC RESET_STREAM frame SHOULD be the state of the push stream. The server SHOULD abruptly terminate
used instead to abort transmission of the server push response. the push stream instead.
A CANCEL_PUSH frame is sent on the control stream. Receiving a A CANCEL_PUSH frame is sent on the control stream. Receiving a
CANCEL_PUSH frame on a stream other than the control stream MUST be CANCEL_PUSH frame on a stream other than the control stream MUST be
treated as a connection error of type HTTP_WRONG_STREAM. treated as a connection error of type HTTP_WRONG_STREAM.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ... | Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 36, line 28 skipping to change at page 36, line 28
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ... | Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: GOAWAY frame payload Figure 11: GOAWAY frame payload
The GOAWAY frame is always sent on the control stream. It carries a The GOAWAY frame is always sent on the control stream. It carries a
QUIC Stream ID for a client-initiated bidirectional stream encoded as QUIC Stream ID for a client-initiated bidirectional stream encoded as
a variable-length integer. A client MUST treat receipt of a GOAWAY a variable-length integer. A client MUST treat receipt of a GOAWAY
frame containing a Stream ID of any other type as a connection error frame containing a Stream ID of any other type as a connection error
of type HTTP_MALFORMED_FRAME. of type HTTP_ID_ERROR.
Clients do not need to send GOAWAY to initiate a graceful shutdown; Clients do not need to send GOAWAY to initiate a graceful shutdown;
they simply stop making new requests. A server MUST treat receipt of they simply stop making new requests. A server MUST treat receipt of
a GOAWAY frame on any stream as a connection error (Section 8) of a GOAWAY frame on any stream as a connection error (Section 8) of
type HTTP_UNEXPECTED_FRAME. type HTTP_UNEXPECTED_FRAME.
The GOAWAY frame applies to the connection, not a specific stream. A The GOAWAY frame applies to the connection, not a specific stream. A
client MUST treat a GOAWAY frame on a stream other than the control client MUST treat a GOAWAY frame on a stream other than the control
stream as a connection error (Section 8) of type HTTP_WRONG_STREAM. stream as a connection error (Section 8) of type HTTP_WRONG_STREAM.
See Section 5.2 for more information on the use of the GOAWAY frame. See Section 5.2 for more information on the use of the GOAWAY frame.
7.2.8. MAX_PUSH_ID 7.2.8. MAX_PUSH_ID
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
number of server pushes that the server can initiate. This sets the number of server pushes that the server can initiate. This sets the
maximum value for a Push ID that the server can use in a PUSH_PROMISE maximum value for a Push ID that the server can use in a PUSH_PROMISE
frame. Consequently, this also limits the number of push streams frame. Consequently, this also limits the number of push streams
that the server can initiate in addition to the limit set by the QUIC that the server can initiate in addition to the limit maintained by
MAX_STREAMS frame. the QUIC transport.
The MAX_PUSH_ID frame is always sent on the control stream. Receipt The MAX_PUSH_ID frame is always sent on the control stream. Receipt
of a MAX_PUSH_ID frame on any other stream MUST be treated as a of a MAX_PUSH_ID frame on any other stream MUST be treated as a
connection error of type HTTP_WRONG_STREAM. connection error of type HTTP_WRONG_STREAM.
A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the A server MUST NOT send a MAX_PUSH_ID frame. A client MUST treat the
receipt of a MAX_PUSH_ID frame as a connection error of type receipt of a MAX_PUSH_ID frame as a connection error of type
HTTP_UNEXPECTED_FRAME. HTTP_UNEXPECTED_FRAME.
The maximum Push ID is unset when a connection is created, meaning The maximum Push ID is unset when a connection is created, meaning
skipping to change at page 39, line 7 skipping to change at page 39, line 7
streams or the entire connection when an error is encountered. These streams or the entire connection when an error is encountered. These
are referred to as "stream errors" or "connection errors" and are are referred to as "stream errors" or "connection errors" and are
described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose described in more detail in [QUIC-TRANSPORT]. An endpoint MAY choose
to treat a stream error as a connection error. to treat a stream error as a connection error.
This section describes HTTP/3-specific error codes which can be used This section describes HTTP/3-specific error codes which can be used
to express the cause of a connection or stream error. to express the cause of a connection or stream error.
8.1. HTTP/3 Error Codes 8.1. HTTP/3 Error Codes
The following error codes are defined for use in QUIC RESET_STREAM The following error codes are defined for use when abruptly
frames, STOP_SENDING frames, and CONNECTION_CLOSE frames when using terminating streams, aborting reading of streams, or immediately
HTTP/3. closing connections.
HTTP_NO_ERROR (0x00): No error. This is used when the connection or HTTP_NO_ERROR (0x100): No error. This is used when the connection
stream needs to be closed, but there is no error to signal. or stream needs to be closed, but there is no error to signal.
HTTP_GENERAL_PROTOCOL_ERROR (0x01): Peer violated protocol HTTP_GENERAL_PROTOCOL_ERROR (0x101): 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.
Reserved (0x02): This code is reserved and has no meaning. HTTP_INTERNAL_ERROR (0x102): An internal error has occurred in the
HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the
HTTP stack. HTTP stack.
Reserved (0x04): This code is reserved and has no meaning. HTTP_STREAM_CREATION_ERROR (0x103): The endpoint detected that its
peer created a stream that it will not accept.
HTTP_REQUEST_CANCELLED (0x05): The request or its response HTTP_CLOSED_CRITICAL_STREAM (0x104): A stream required by the
(including pushed response) is cancelled. connection was closed or reset.
HTTP_INCOMPLETE_REQUEST (0x06): The client's stream terminated HTTP_UNEXPECTED_FRAME (0x105): A frame was received which was not
without containing a fully-formed request. permitted in the current state.
HTTP_CONNECT_ERROR (0x07): The connection established in response to HTTP_FRAME_ERROR (0x106): A frame that fails to satisfy layout
a CONNECT request was reset or abnormally closed. requirements or with an invalid size was received.
HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is HTTP_EXCESSIVE_LOAD (0x107): The endpoint detected that its peer is
exhibiting a behavior that might be generating excessive load. exhibiting a behavior that might be generating excessive load.
HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be HTTP_WRONG_STREAM (0x108): A frame was received on a stream where it
served over HTTP/3. The peer should retry over HTTP/1.1.
HTTP_WRONG_STREAM (0x0A): A frame was received on a stream where it
is not permitted. is not permitted.
HTTP_ID_ERROR (0x0B): A Stream ID, Push ID, or Placeholder ID was HTTP_ID_ERROR (0x109): A Stream ID, Push ID, or Placeholder ID was
used incorrectly, such as exceeding a limit, reducing a limit, or used incorrectly, such as exceeding a limit, reducing a limit, or
being reused. being reused.
Reserved (0x0C): N/A HTTP_SETTINGS_ERROR (0x10A): An endpoint detected an error in the
payload of a SETTINGS frame: a duplicate setting was detected, a
client-only setting was sent by a server, or a server-only setting
by a client.
HTTP_STREAM_CREATION_ERROR (0x0D): The endpoint detected that its HTTP_MISSING_SETTINGS (0x10B): No SETTINGS frame was received at the
peer created a stream that it will not accept. beginning of the control stream.
Reserved (0x0E): N/A HTTP_REQUEST_REJECTED (0x10C): A server rejected a request without
HTTP_CLOSED_CRITICAL_STREAM (0x0F): A stream required by the performing any application processing.
connection was closed or reset.
Reserved (0x0010): N/A HTTP_REQUEST_CANCELLED (0x10D): The request or its response
(including pushed response) is cancelled.
HTTP_EARLY_RESPONSE (0x0011): The remainder of the client's request HTTP_REQUEST_INCOMPLETE (0x10E): The client's stream terminated
without containing a fully-formed request.
HTTP_EARLY_RESPONSE (0x10F): The remainder of the client's request
is not needed to produce a response. For use in STOP_SENDING is not needed to produce a response. For use in STOP_SENDING
only. only.
HTTP_MISSING_SETTINGS (0x0012): No SETTINGS frame was received at HTTP_CONNECT_ERROR (0x110): The connection established in response
the beginning of the control stream. to a CONNECT request was reset or abnormally closed.
HTTP_UNEXPECTED_FRAME (0x0013): A frame was received which was not
permitted in the current state.
HTTP_REQUEST_REJECTED (0x0014): A server rejected a request without
performing any application processing.
HTTP_SETTINGS_ERROR (0x00FF): An endpoint detected an error in the
payload of a SETTINGS frame: a duplicate setting was detected, a
client-only setting was sent by a server, or a server-only setting
by a client.
HTTP_MALFORMED_FRAME (0x01XX): An error in a specific frame type. HTTP_VERSION_FALLBACK (0x111): The requested operation cannot be
If the frame type is "0xfe" or less, the type is included as the served over HTTP/3. The peer should retry over HTTP/1.1.
last byte of the error code. For example, an error in a
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. Extensions to HTTP/3 9. Extensions to HTTP/3
HTTP/3 permits extension of the protocol. Within the limitations HTTP/3 permits extension of the protocol. Within the limitations
described in this section, protocol extensions can be used to provide described in this section, protocol extensions can be used to provide
additional services or alter any aspect of the protocol. Extensions additional services or alter any aspect of the protocol. Extensions
are effective only within the scope of a single HTTP/3 connection. are effective only within the scope of a single HTTP/3 connection.
This applies to the protocol elements defined in this document. This This applies to the protocol elements defined in this document. This
does not affect the existing options for extending HTTP, such as does not affect the existing options for extending HTTP, such as
skipping to change at page 41, line 31 skipping to change at page 41, line 18
willingness to use the extension, then the extension can be used. If willingness to use the extension, then the extension can be used. If
a setting is used for extension negotiation, the default value MUST a setting is used for extension negotiation, the default value MUST
be defined in such a fashion that the extension is disabled if the be defined in such a fashion that the extension is disabled if the
setting is omitted. setting is omitted.
10. Security Considerations 10. 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 either rely on transport-
or employ the reserved frame and stream types discussed in layer padding or employ the reserved frame and stream types discussed
Section 7.2.10 and Section 6.2.3. in Section 7.2.10 and Section 6.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.
skipping to change at page 45, line 28 skipping to change at page 45, line 21
if no detailed specification is provided. if no detailed specification is provided.
Specification: An optional reference for a specification that Specification: An optional reference for a specification that
defines the error code. defines the error code.
The entries in the following table are registered by this document. The entries in the following table are registered by this document.
+----------------------------+--------+-------------+---------------+ +----------------------------+--------+-------------+---------------+
| Name | Code | Description | Specification | | Name | Code | Description | Specification |
+----------------------------+--------+-------------+---------------+ +----------------------------+--------+-------------+---------------+
| HTTP_NO_ERROR | 0x0000 | No error | Section 8.1 | | HTTP_NO_ERROR | 0x0100 | No error | Section 8.1 |
| | | | | | | | | |
| HTTP_GENERAL_PROTOCOL_ERRO | 0x0001 | General | Section 8.1 | | HTTP_GENERAL_PROTOCOL_ERRO | 0x0101 | General | Section 8.1 |
| R | | protocol | | | R | | protocol | |
| | | error | | | | | error | |
| | | | | | | | | |
| Reserved | 0x0002 | N/A | N/A | | HTTP_INTERNAL_ERROR | 0x0102 | Internal | Section 8.1 |
| | | | |
| HTTP_INTERNAL_ERROR | 0x0003 | Internal | Section 8.1 |
| | | error | | | | | error | |
| | | | | | | | | |
| Reserved | 0x0004 | N/A | N/A | | HTTP_STREAM_CREATION_ERROR | 0x0103 | Stream | Section 8.1 |
| | | creation | |
| | | error | |
| | | | | | | | | |
| HTTP_REQUEST_CANCELLED | 0x0005 | Data no | Section 8.1 | | HTTP_CLOSED_CRITICAL_STREA | 0x0104 | Critical | Section 8.1 |
| | | longer | | | M | | stream was | |
| | | needed | | | | | closed | |
| | | | | | | | | |
| HTTP_INCOMPLETE_REQUEST | 0x0006 | Stream | Section 8.1 | | HTTP_UNEXPECTED_FRAME | 0x0105 | Frame not | Section 8.1 |
| | | terminated | | | | | permitted | |
| | | early | | | | | in the | |
| | | current | |
| | | state | |
| | | | | | | | | |
| HTTP_CONNECT_ERROR | 0x0007 | TCP reset | Section 8.1 | | HTTP_FRAME_ERROR | 0x0106 | Frame | Section 8.1 |
| | | or error on | | | | | violated | |
| | | CONNECT | | | | | layout or | |
| | | request | | | | | size rules | |
| | | | | | | | | |
| HTTP_EXCESSIVE_LOAD | 0x0008 | Peer | Section 8.1 | | HTTP_EXCESSIVE_LOAD | 0x0107 | Peer | Section 8.1 |
| | | generating | | | | | generating | |
| | | excessive | | | | | excessive | |
| | | load | | | | | load | |
| | | | | | | | | |
| HTTP_VERSION_FALLBACK | 0x0009 | Retry over | Section 8.1 | | HTTP_WRONG_STREAM | 0x0108 | A frame was | Section 8.1 |
| | | HTTP/1.1 | |
| | | | |
| HTTP_WRONG_STREAM | 0x000A | A frame was | Section 8.1 |
| | | sent on the | | | | | sent on the | |
| | | wrong | | | | | wrong | |
| | | stream | | | | | stream | |
| | | | | | | | | |
| HTTP_ID_ERROR | 0x000B | An | Section 8.1 | | HTTP_ID_ERROR | 0x0109 | An | Section 8.1 |
| | | identifier | | | | | identifier | |
| | | was used | | | | | was used | |
| | | incorrectly | | | | | incorrectly | |
| | | | | | | | | |
| Reserved | 0x000C | N/A | N/A | | HTTP_SETTINGS_ERROR | 0x010A | SETTINGS | Section 8.1 |
| | | frame | |
| | | contained | |
| | | invalid | |
| | | values | |
| | | | | | | | | |
| HTTP_STREAM_CREATION_ERROR | 0x000D | Stream | Section 8.1 | | HTTP_MISSING_SETTINGS | 0x010B | No SETTINGS | Section 8.1 |
| | | creation | | | | | frame | |
| | | error | | | | | received | |
| | | | | | | | | |
| Reserved | 0x000E | N/A | N/A | | HTTP_REQUEST_REJECTED | 0x010C | Request not | Section 8.1 |
| | | processed | |
| | | | | | | | | |
| HTTP_CLOSED_CRITICAL_STREA | 0x000F | Critical | Section 8.1 | | HTTP_REQUEST_CANCELLED | 0x010D | Data no | Section 8.1 |
| M | | stream was | | | | | longer | |
| | | closed | | | | | needed | |
| | | | | | | | | |
| Reserved | 0x000E | N/A | N/A | | HTTP_REQUEST_INCOMPLETE | 0x010E | Stream | Section 8.1 |
| | | terminated | |
| | | early | |
| | | | | | | | | |
| HTTP_EARLY_RESPONSE | 0x0011 | Remainder | Section 8.1 | | HTTP_EARLY_RESPONSE | 0x010F | Remainder | Section 8.1 |
| | | of request | | | | | of request | |
| | | not needed | | | | | not needed | |
| | | | | | | | | |
| HTTP_MISSING_SETTINGS | 0x0012 | No SETTINGS | Section 8.1 | | HTTP_CONNECT_ERROR | 0x0110 | TCP reset | Section 8.1 |
| | | frame | | | | | or error on | |
| | | received | | | | | CONNECT | |
| | | | | | | | request | |
| HTTP_UNEXPECTED_FRAME | 0x0013 | Frame not | Section 8.1 |
| | | permitted | |
| | | in the | |
| | | current | |
| | | state | |
| | | | |
| HTTP_REQUEST_REJECTED | 0x0014 | Request not | Section 8.1 |
| | | processed | |
| | | | |
| HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 8.1 |
| | | frame | |
| | | formatting | |
| | | | | | | | | |
| HTTP_SETTINGS_ERROR | 0x00FF | SETTINGS | Section 8.1 | | HTTP_VERSION_FALLBACK | 0x0111 | Retry over | Section 8.1 |
| | | frame | | | | | HTTP/1.1 | |
| | | contained | |
| | | invalid | |
| | | values | |
+----------------------------+--------+-------------+---------------+ +----------------------------+--------+-------------+---------------+
11.6. Stream Types 11.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 governs a 62-bit space. types. The "HTTP/3 Stream Type" registry governs a 62-bit space.
This space is split into three spaces that are governed by different This space is split into three spaces that are governed by different
policies. Values between "0x00" and 0x3f (in hexadecimal) are policies. Values between "0x00" and 0x3f (in hexadecimal) are
assigned via the Standards Action or IESG Review policies [RFC8126]. assigned via the Standards Action or IESG Review policies [RFC8126].
Values from "0x40" to "0x3fff" operate on the Specification Required Values from "0x40" to "0x3fff" operate on the Specification Required
skipping to change at page 48, line 29 skipping to change at page 48, line 17
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [HTTP2] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Header Compression for HTTP over QUIC", draft-ietf-quic- Header Compression for HTTP over QUIC", draft-ietf-quic-
qpack-09 (work in progress). qpack-latest (work in progress).
[QUIC-TRANSPORT] [QUIC-TRANSPORT]
Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
Multiplexed and Secure Transport", draft-ietf-quic- Multiplexed and Secure Transport", draft-ietf-quic-
transport-22 (work in progress). transport-latest (work in progress).
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, [RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981, RFC 793, DOI 10.17487/RFC0793, September 1981,
<https://www.rfc-editor.org/info/rfc793>. <https://www.rfc-editor.org/info/rfc793>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
[RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS) [RFC6066] Eastlake 3rd, D., "Transport Layer Security (TLS)
Extensions: Extension Definitions", RFC 6066, Extensions: Extension Definitions", RFC 6066,
DOI 10.17487/RFC6066, January 2011, DOI 10.17487/RFC6066, January 2011,
<https://www.rfc-editor.org/info/rfc6066>. <https://www.rfc-editor.org/info/rfc6066>.
[RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265,
DOI 10.17487/RFC6265, April 2011,
<https://www.rfc-editor.org/info/rfc6265>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", Protocol (HTTP/1.1): Message Syntax and Routing",
RFC 7230, DOI 10.17487/RFC7230, June 2014, RFC 7230, DOI 10.17487/RFC7230, June 2014,
<https://www.rfc-editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
DOI 10.17487/RFC7231, June 2014, DOI 10.17487/RFC7231, June 2014,
<https://www.rfc-editor.org/info/rfc7231>. <https://www.rfc-editor.org/info/rfc7231>.
skipping to change at page 49, line 40 skipping to change at page 49, line 30
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[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>.
12.2. Informative References 12.2. Informative References
[HPACK] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [HPACK] Peon, R. and H. Ruellan, "HPACK: Header Compression for
Protocol (HTTP/1.1): Semantics and Content", RFC 7231, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7541>.
<https://www.rfc-editor.org/info/rfc7231>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status
Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012, Codes", RFC 6585, DOI 10.17487/RFC6585, April 2012,
<https://www.rfc-editor.org/info/rfc6585>. <https://www.rfc-editor.org/info/rfc6585>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [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>.
skipping to change at page 54, line 29 skipping to change at page 54, line 22
Settings need to be defined separately for HTTP/2 and HTTP/3. The Settings need to be defined separately for HTTP/2 and HTTP/3. The
IDs of settings defined in [HTTP2] have been reserved for simplicity. IDs of settings defined in [HTTP2] have been reserved for simplicity.
Note that the settings identifier space in HTTP/3 is substantially Note that the settings identifier space in HTTP/3 is substantially
larger (62 bits versus 16 bits), so many HTTP/3 settings have no larger (62 bits versus 16 bits), so many HTTP/3 settings have no
equivalent HTTP/2 code point. See Section 11.4. equivalent HTTP/2 code point. See Section 11.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 to HTTP/3 error codes; the values are shifted in order to
prevent accidental or implicit conversion.
The HTTP/2 error codes defined in Section 7 of [HTTP2] map to the The HTTP/2 error codes defined in Section 7 of [HTTP2] logically map
HTTP/3 error codes as follows: to the HTTP/3 error codes as follows:
NO_ERROR (0x0): HTTP_NO_ERROR in Section 8.1. NO_ERROR (0x0): HTTP_NO_ERROR in Section 8.1.
PROTOCOL_ERROR (0x1): This is mapped to HTTP_GENERAL_PROTOCOL_ERROR PROTOCOL_ERROR (0x1): This is mapped to HTTP_GENERAL_PROTOCOL_ERROR
except in cases where more specific error codes have been defined. except in cases where more specific error codes have been defined.
This includes HTTP_MALFORMED_FRAME, HTTP_WRONG_STREAM, This includes HTTP_WRONG_STREAM, HTTP_UNEXPECTED_FRAME and
HTTP_UNEXPECTED_FRAME and HTTP_CLOSED_CRITICAL_STREAM defined in HTTP_CLOSED_CRITICAL_STREAM defined in Section 8.1.
Section 8.1.
INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 8.1. INTERNAL_ERROR (0x2): HTTP_INTERNAL_ERROR in Section 8.1.
FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow FLOW_CONTROL_ERROR (0x3): Not applicable, since QUIC handles flow
control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA control.
from the QUIC layer.
SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of
SETTINGS is defined. SETTINGS is defined.
STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream
management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION management.
from the QUIC layer.
FRAME_SIZE_ERROR (0x6): HTTP_MALFORMED_FRAME error codes defined in FRAME_SIZE_ERROR (0x6): HTTP_FRAME_ERROR error code defined in
Section 8.1. Section 8.1.
REFUSED_STREAM (0x7): HTTP_REQUEST_REJECTED (in Section 8.1) is used REFUSED_STREAM (0x7): HTTP_REQUEST_REJECTED (in Section 8.1) is used
to indicate that a request was not processed. Otherwise, not to indicate that a request was not processed. Otherwise, not
applicable because QUIC handles stream management. A applicable because QUIC handles stream management.
STREAM_ID_ERROR at the QUIC layer is used for streams that are
improperly opened.
CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1. CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 8.1.
COMPRESSION_ERROR (0x9): Multiple error codes are defined in COMPRESSION_ERROR (0x9): Multiple error codes are defined in
[QPACK]. [QPACK].
CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1. CONNECT_ERROR (0xa): HTTP_CONNECT_ERROR in Section 8.1.
ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1. ENHANCE_YOUR_CALM (0xb): HTTP_EXCESSIVE_LOAD in Section 8.1.
 End of changes. 86 change blocks. 
223 lines changed or deleted 206 lines changed or added

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