draft-ietf-quic-http-19.txt   draft-ietf-quic-http-20.txt 
QUIC M. Bishop, Ed. QUIC M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track March 11, 2019 Intended status: Standards Track April 23, 2019
Expires: September 12, 2019 Expires: October 25, 2019
Hypertext Transfer Protocol Version 3 (HTTP/3) Hypertext Transfer Protocol Version 3 (HTTP/3)
draft-ietf-quic-http-19 draft-ietf-quic-http-20
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 September 12, 2019. This Internet-Draft will expire on October 25, 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 33 skipping to change at page 2, line 33
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Connection Setup and Management . . . . . . . . . . . . . . . 5 2. Connection Setup and Management . . . . . . . . . . . . . . . 5
2.1. Draft Version Identification . . . . . . . . . . . . . . 5 2.1. Draft Version Identification . . . . . . . . . . . . . . 5
2.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 5 2.2. Discovering an HTTP/3 Endpoint . . . . . . . . . . . . . 5
2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6 2.2.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 6
2.3. Connection Establishment . . . . . . . . . . . . . . . . 6 2.3. Connection Establishment . . . . . . . . . . . . . . . . 6
2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7 2.4. Connection Reuse . . . . . . . . . . . . . . . . . . . . 7
3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7
3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8 3.1. Bidirectional Streams . . . . . . . . . . . . . . . . . . 8
3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8 3.2. Unidirectional Streams . . . . . . . . . . . . . . . . . 8
3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 9 3.2.1. Control Streams . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . 11
4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11
4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 12 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13
4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14
4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 17
4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 17 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 18
4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 20
4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 20 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 21
4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 21 4.2.9. DUPLICATE_PUSH . . . . . . . . . . . . . . . . . . . 22
4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 22 4.2.10. Reserved Frame Types . . . . . . . . . . . . . . . . 23
5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 22 5. HTTP Request Lifecycle . . . . . . . . . . . . . . . . . . . 23
5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 22 5.1. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 23
5.1.1. Header Formatting and Compression . . . . . . . . . . 24 5.1.1. Header Formatting and Compression . . . . . . . . . . 25
5.1.2. Request Cancellation and Rejection . . . . . . . . . 24 5.1.2. Request Cancellation and Rejection . . . . . . . . . 25
5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 25 5.2. The CONNECT Method . . . . . . . . . . . . . . . . . . . 26
5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 26 5.3. Prioritization . . . . . . . . . . . . . . . . . . . . . 27
5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 27 5.3.1. Placeholders . . . . . . . . . . . . . . . . . . . . 28
5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 27 5.3.2. Priority Tree Maintenance . . . . . . . . . . . . . . 28
5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 28 5.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 29
6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 29 6. Connection Closure . . . . . . . . . . . . . . . . . . . . . 31
6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 30 6.1. Idle Connections . . . . . . . . . . . . . . . . . . . . 31
6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 30 6.2. Connection Shutdown . . . . . . . . . . . . . . . . . . . 31
6.3. Immediate Application Closure . . . . . . . . . . . . . . 31 6.3. Immediate Application Closure . . . . . . . . . . . . . . 33
6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 32 6.4. Transport Closure . . . . . . . . . . . . . . . . . . . . 33
7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 32 7. Extensions to HTTP/3 . . . . . . . . . . . . . . . . . . . . 33
8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 33 8. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 34
8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 33 8.1. HTTP/3 Error Codes . . . . . . . . . . . . . . . . . . . 34
9. Security Considerations . . . . . . . . . . . . . . . . . . . 35 9. Security Considerations . . . . . . . . . . . . . . . . . . . 36
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 35 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 37
10.1. Registration of HTTP/3 Identification String . . . . . . 35 10.1. Registration of HTTP/3 Identification String . . . . . . 37
10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 36 10.2. Registration of QUIC Version Hint Alt-Svc Parameter . . 37
10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 36 10.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . 37
10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 37 10.4. Settings Parameters . . . . . . . . . . . . . . . . . . 38
10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 38 10.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . 39
10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 41 10.6. Stream Types . . . . . . . . . . . . . . . . . . . . . . 42
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
11.1. Normative References . . . . . . . . . . . . . . . . . . 42 11.1. Normative References . . . . . . . . . . . . . . . . . . 43
11.2. Informative References . . . . . . . . . . . . . . . . . 43 11.2. Informative References . . . . . . . . . . . . . . . . . 44
11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 43 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Appendix A. Considerations for Transitioning from HTTP/2 . . . . 44 Appendix A. Considerations for Transitioning from HTTP/2 . . . . 45
A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 44 A.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 45
A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 44 A.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 45
A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 46 A.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 48
A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 47 A.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 49
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 48 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 50
B.1. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 48 B.1. Since draft-ietf-quic-http-19 . . . . . . . . . . . . . . 50
B.2. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 49 B.2. Since draft-ietf-quic-http-18 . . . . . . . . . . . . . . 50
B.3. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 49 B.3. Since draft-ietf-quic-http-17 . . . . . . . . . . . . . . 50
B.4. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 50 B.4. Since draft-ietf-quic-http-16 . . . . . . . . . . . . . . 51
B.5. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 50 B.5. Since draft-ietf-quic-http-15 . . . . . . . . . . . . . . 51
B.6. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 50 B.6. Since draft-ietf-quic-http-14 . . . . . . . . . . . . . . 51
B.7. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 50 B.7. Since draft-ietf-quic-http-13 . . . . . . . . . . . . . . 52
B.8. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 51 B.8. Since draft-ietf-quic-http-12 . . . . . . . . . . . . . . 52
B.9. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 51 B.9. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 52
B.10. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 51 B.10. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 52
B.11. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 51 B.11. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 52
B.12. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 51 B.12. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 53
B.13. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 51 B.13. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 53
B.14. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 51 B.14. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 53
B.15. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 52 B.15. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 53
B.16. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 52 B.16. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 53
B.17. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 52 B.17. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 54
B.18. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 52 B.18. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 54
B.19. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 53 B.19. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 54
B.20. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 53 B.20. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 54
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53 B.21. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 53 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 55
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 55
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 9, line 18 skipping to change at page 9, line 18
| Stream Type (i) ... | 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 The performance of HTTP/3 connections in the early phase of their
the QUIC transport parameter "initial_max_uni_streams". lifetime is sensitive to the creation and exchange of data on
unidirectional streams. Endpoints that set low values for the QUIC
transport parameters "initial_max_uni_streams" and
"initial_max_stream_data_uni" will increase the chance that the
remote peer reaches the limit early and becomes blocked. In
particular, the value chosen for "initial_max_uni_streams" should
consider that remote peers may wish to exercise reserved stream
behaviour (Section 3.2.3). To reduce the likelihood of blocking,
both clients and servers SHOULD send a value of three or greater for
the QUIC transport parameter "initial_max_uni_streams", and a value
of 1,024 or greater for the QUIC transport parameter
"initial_max_stream_data_uni".
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 trigger a QUIC STOP_SENDING frame with an error code of
HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an HTTP_UNKNOWN_STREAM_TYPE, but MUST NOT consider such streams to be an
error of any kind. error of any kind.
Implementations MAY send stream types before knowing whether the peer Implementations MAY send stream types before knowing whether the peer
supports them. However, stream types which could modify the state or supports them. However, stream types which could modify the state or
skipping to change at page 14, line 27 skipping to change at page 15, line 27
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 2). 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 3). 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 has no
ignored on receipt. semantic value 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.
Element Dependency ID: A variable-length integer that identifies the Element Dependency ID: A variable-length integer that identifies the
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
skipping to change at page 15, line 42 skipping to change at page 16, line 42
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
HTTP_MALFORMED_FRAME. A PRIORITY frame with Empty bits not set to
zero MAY be treated as a connection error of type
HTTP_MALFORMED_FRAME. HTTP_MALFORMED_FRAME.
When a PRIORITY frame claims to reference a request, the associated When a PRIORITY frame claims to reference a request, the associated
ID MUST identify a client-initiated bidirectional stream. A server ID MUST identify a client-initiated bidirectional stream. A server
MUST treat receipt of a PRIORITY frame identifying a stream of any MUST treat receipt of a PRIORITY frame identifying a stream of any
other type as a connection error of type HTTP_MALFORMED_FRAME. other type as a connection error of type HTTP_MALFORMED_FRAME.
A PRIORITY frame that references a non-existent Push ID, 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
skipping to change at page 18, line 15 skipping to change at page 19, line 15
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 (0x9): 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 "0x1f * N + 0x21" for integer Setting identifiers of the format "0x1f * N + 0x21" for integer
values of N are reserved to exercise the requirement that unknown values of N are reserved to exercise the requirement that unknown
identifiers be ignored. Such settings have no defined meaning. identifiers be ignored. Such settings have no defined meaning.
Endpoints SHOULD include at least one such setting in their SETTINGS Endpoints SHOULD include at least one such setting in their SETTINGS
frame. Endpoints MUST NOT consider such settings to have any meaning frame. Endpoints MUST NOT consider such settings to have any meaning
upon receipt. upon receipt.
skipping to change at page 20, line 46 skipping to change at page 21, line 46
See Section 6.2 for more information on the use of the GOAWAY frame. See Section 6.2 for more information on the use of the GOAWAY frame.
4.2.8. MAX_PUSH_ID 4.2.8. MAX_PUSH_ID
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
number of server pushes that the server can initiate. This sets the number of server pushes that the server can initiate. This sets the
maximum value for a Push ID that the server can use in a PUSH_PROMISE maximum value for a Push ID that the server can use in a PUSH_PROMISE
frame. Consequently, this also limits the number of push streams frame. Consequently, this also limits the number of push streams
that the server can initiate in addition to the limit set by the QUIC that the server can initiate in addition to the limit set by the QUIC
MAX_STREAM_ID frame. MAX_STREAMS frame.
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 29, line 22 skipping to change at page 30, line 22
(see Section 4.2.6) on the request stream which generated the push. (see Section 4.2.6) on the request stream which generated the push.
This allows the server push to be associated with a client request. This allows the server push to be associated with a client request.
Ordering of a PUSH_PROMISE in relation to certain parts of the Ordering of a PUSH_PROMISE in relation to certain parts of the
response is important (see Section 8.2.1 of [RFC7540]). Promised response is important (see Section 8.2.1 of [RFC7540]). Promised
requests MUST conform to the requirements in Section 8.2 of requests MUST conform to the requirements in Section 8.2 of
[RFC7540]. [RFC7540].
The same server push can be associated with additional client The same server push can be associated with additional client
requests using a DUPLICATE_PUSH frame (see Section 4.2.9). Ordering requests using a DUPLICATE_PUSH frame (see Section 4.2.9). Ordering
of a DUPLICATE_PUSH in relation to certain parts of the response is of a DUPLICATE_PUSH in relation to certain parts of the response is
similarly important. Due to reordering, DUPLICATE_PUSH frames can similarly important.
arrive before the corresponding PUSH_PROMISE frame, in which case the
request headers of the push would not be immediately available.
Clients which receive a DUPLICATE_PUSH frame for an as-yet-unknown
Push ID can either delay generating new requests for content
referenced following the DUPLICATE_PUSH frame until the request
headers become available, or can initiate requests for discovered
resources and cancel the requests if the requested resource is
already being pushed.
When a server later fulfills a promise, the server push response is When a server later fulfills a promise, the server push response is
conveyed on a push stream (see Section 3.2.2). The push stream conveyed on a push stream (see Section 3.2.2). The push stream
identifies the Push ID of the promise that it fulfills, then contains identifies the Push ID of the promise that it fulfills, then contains
a response to the promised request using the same format described a response to the promised request using the same format described
for responses in Section 5.1. for responses in Section 5.1.
Due to reordering, DUPLICATE_PUSH frames or push stream data can
arrive before the corresponding PUSH_PROMISE frame. When a client
receives a DUPLICATE_PUSH frame for an as-yet-unknown Push ID, the
request headers of the push are not immediately available. The
client can either delay generating new requests for content
referenced following the DUPLICATE_PUSH frame until the request
headers become available, or can initiate requests for discovered
resources and cancel the requests if the requested resource is
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
pushed request headers are unknown. The client can buffer the stream
data in expectation of the matching PUSH_PROMISE. The client can use
stream flow control (see section 4.1 of [QUIC-TRANSPORT]) to limit
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, a QUIC STOP_SENDING
frame with an appropriate error code can also be used (e.g., frame with an appropriate error code can also be used (e.g.,
HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see Section 8). This HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see Section 8). This
asks the server not to transfer additional data and indicates that it asks the server not to transfer additional data and indicates that it
will be discarded upon receipt. will be discarded upon receipt.
6. Connection Closure 6. Connection Closure
skipping to change at page 31, line 43 skipping to change at page 33, line 5
prohibited. After allowing time for any in-flight requests (at least prohibited. After allowing time for any in-flight requests (at least
one round-trip time), the server MAY send another GOAWAY frame with one round-trip time), the server MAY send another GOAWAY frame with
an updated last Stream ID. This ensures that a connection can be an updated last Stream ID. This ensures that a connection can be
cleanly shut down without losing requests. cleanly shut down without losing requests.
Once all accepted requests have been processed, the server can permit Once all accepted requests have been processed, the server can permit
the connection to become idle, or MAY initiate an immediate closure the connection to become idle, or MAY initiate an immediate closure
of the connection. An endpoint that completes a graceful shutdown of the connection. An endpoint that completes a graceful shutdown
SHOULD use the HTTP_NO_ERROR code when closing the connection. SHOULD use the HTTP_NO_ERROR code when closing the connection.
If a client has consumed all available bidirectional stream IDs with
requests, the server need not send a GOAWAY frame, since the client
is unable to make further requests.
6.3. Immediate Application Closure 6.3. Immediate Application Closure
An HTTP/3 implementation can immediately close the QUIC connection at An HTTP/3 implementation can immediately close the QUIC connection at
any time. This results in sending a QUIC CONNECTION_CLOSE frame to any time. This results in sending a QUIC CONNECTION_CLOSE frame to
the peer; the error code in this frame indicates to the peer why the the peer; the error code in this frame indicates to the peer why the
connection is being closed. See Section 8 for error codes which can connection is being closed. See Section 8 for error codes which can
be used when closing a connection. be used when closing a connection.
Before closing the connection, a GOAWAY MAY be sent to allow the Before closing the connection, a GOAWAY MAY be sent to allow the
client to retry some requests. Including the GOAWAY frame in the client to retry some requests. Including the GOAWAY frame in the
skipping to change at page 37, line 35 skipping to change at page 38, line 41
| | | | | | | |
| 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 "0x1f * N + 0x21" for integer Additionally, each code of the format "0x1f * N + 0x21" for integer
values of N (that is, "0x21", "0x40", ..., through values of N (that is, "0x21", "0x40", ..., through
"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA. "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
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 governs a 62-bit space. This space is "HTTP/3 Settings" registry governs a 62-bit space. This space is
split into three spaces that are governed by different policies. split into three spaces that are governed by different policies.
Values between "0x00" and "0x3f" (in hexadecimal) are assigned via Values between "0x00" and "0x3f" (in hexadecimal) are assigned via
the Standards Action or IESG Review policies [RFC8126]. Values from the Standards Action or IESG Review policies [RFC8126]. Values from
"0x40" to "0x3fff" operate on the Specification Required policy "0x40" to "0x3fff" operate on the Specification Required policy
[RFC8126]. All other values are assigned to Private Use [RFC8126]. [RFC8126]. All other values are assigned to Private Use [RFC8126].
skipping to change at page 38, line 32 skipping to change at page 39, line 39
| Reserved | 0x2 | N/A | | Reserved | 0x2 | N/A |
| | | | | | | |
| Reserved | 0x3 | N/A | | Reserved | 0x3 | N/A |
| | | | | | | |
| 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 | 0x9 | Section 4.2.5.1 |
+----------------------+------+-----------------+ +----------------------+------+-----------------+
Additionally, each code of the format "0x1f * N + 0x21" for integer Additionally, each code of the format "0x1f * N + 0x21" for integer
values of N (that is, "0x21", "0x40", ..., through values of N (that is, "0x21", "0x40", ..., through
"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA. "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
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 41, line 51 skipping to change at page 43, line 15
+----------------+------+---------------+--------+ +----------------+------+---------------+--------+
| Stream Type | Code | Specification | Sender | | Stream Type | Code | Specification | Sender |
+----------------+------+---------------+--------+ +----------------+------+---------------+--------+
| Control Stream | 0x00 | Section 3.2.1 | Both | | Control Stream | 0x00 | Section 3.2.1 | Both |
| | | | | | | | | |
| Push Stream | 0x01 | Section 5.4 | Server | | Push Stream | 0x01 | Section 5.4 | Server |
+----------------+------+---------------+--------+ +----------------+------+---------------+--------+
Additionally, each code of the format "0x1f * N + 0x21" for integer Additionally, each code of the format "0x1f * N + 0x21" for integer
values of N (that is, "0x21", "0x40", ..., through values of N (that is, "0x21", "0x40", ..., through
"0x‭3FFFFFFFFFFFFFFE‬") MUST NOT be assigned by IANA. "0x3FFFFFFFFFFFFFFE") MUST NOT be assigned by IANA.
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] [HTTP-REPLAY]
Thomson, M., Nottingham, M., and W. Tarreau, "Using Early Thomson, M., Nottingham, M., and W. Tarreau, "Using Early
Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September Data in HTTP", RFC 8470, DOI 10.17487/RFC8470, September
2018, <https://www.rfc-editor.org/info/rfc8470>. 2018, <https://www.rfc-editor.org/info/rfc8470>.
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Header Compression for HTTP over QUIC", draft-ietf-quic- Header Compression for HTTP over QUIC", draft-ietf-quic-
qpack-07 (work in progress), March 2019. qpack-08 (work in progress), April 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-18 (work in progress), March 2019. transport-18 (work in progress), April 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 45, line 15 skipping to change at page 46, line 25
be received in the order sent, HTTP/3 will break them. be received in the order sent, HTTP/3 will break them.
For example, implicit in the HTTP/2 prioritization scheme is the For example, implicit in the HTTP/2 prioritization scheme is the
notion of in-order delivery of priority changes (i.e., dependency notion of in-order delivery of priority changes (i.e., dependency
tree mutations): since operations on the dependency tree such as tree mutations): since operations on the dependency tree such as
reparenting a subtree are not commutative, both sender and receiver reparenting a subtree are not commutative, both sender and receiver
must apply them in the same order to ensure that both sides have a must apply them in the same order to ensure that both sides have a
consistent view of the stream dependency tree. HTTP/2 specifies consistent view of the stream dependency tree. HTTP/2 specifies
priority assignments in PRIORITY frames and (optionally) in HEADERS priority assignments in PRIORITY frames and (optionally) in HEADERS
frames. To achieve in-order delivery of priority changes in HTTP/3, frames. To achieve in-order delivery of priority changes in HTTP/3,
PRIORITY frames are sent on the control stream and exclusive PRIORITY frames are sent as the first frame on a request stream or on
prioritization has been removed. the control stream and exclusive prioritization has been removed.
HTTP/3 permits the prioritisation of requests, pushes and
placeholders that each exist in separate identifier spaces. The
HTTP/3 PRIORITY frame replaces the stream dependency field with
fields that can identify the element of interest and its dependency.
Likewise, HPACK was designed with the assumption of in-order Likewise, HPACK was designed with the assumption of in-order
delivery. A sequence of encoded header blocks must arrive (and be delivery. A sequence of encoded header blocks must arrive (and be
decoded) at an endpoint in the same order in which they were encoded. decoded) at an endpoint in the same order in which they were encoded.
This ensures that the dynamic state at the two endpoints remains in This ensures that the dynamic state at the two endpoints remains in
sync. As a result, HTTP/3 uses a modified version of HPACK, sync. As a result, HTTP/3 uses a modified version of HPACK,
described in [QPACK]. described in [QPACK].
Frame type definitions in HTTP/3 often use the QUIC variable-length Frame type definitions in HTTP/3 often use the QUIC variable-length
integer encoding. In particular, Stream IDs use this encoding, which integer encoding. In particular, Stream IDs use this encoding, which
skipping to change at page 45, line 48 skipping to change at page 47, line 16
portable to QUIC simply by replacing Stream 0 in HTTP/2 with a portable to QUIC simply by replacing Stream 0 in HTTP/2 with a
control stream in HTTP/3. HTTP/3 extensions will not assume control stream in HTTP/3. HTTP/3 extensions will not assume
ordering, but would not be harmed by ordering, and would be portable ordering, but would not be harmed by ordering, and would be portable
to HTTP/2 in the same manner. to HTTP/2 in the same manner.
Below is a listing of how each HTTP/2 frame type is mapped: Below is a listing of how each HTTP/2 frame type is mapped:
DATA (0x0): Padding is not defined in HTTP/3 frames. See DATA (0x0): Padding is not defined in HTTP/3 frames. See
Section 4.2.1. Section 4.2.1.
HEADERS (0x1): As described above, the PRIORITY region of HEADERS is HEADERS (0x1): The PRIORITY region of HEADERS is not defined in
not supported. A separate PRIORITY frame MUST be used. Padding HTTP/3 frames. A separate PRIORITY frame is used in all cases.
is not defined in HTTP/3 frames. See Section 4.2.2. Padding is not defined in HTTP/3 frames. See Section 4.2.2.
PRIORITY (0x2): As described above, the PRIORITY frame is sent on PRIORITY (0x2): As described above, the PRIORITY frame references a
the control stream and can reference a variety of identifiers. variety of identifiers. It is sent as the first frame on a
See Section 4.2.3. request streams or on the control stream. See Section 4.2.3.
RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC RST_STREAM (0x3): RST_STREAM frames do not exist, since QUIC
provides stream lifecycle management. The same code point is used provides stream lifecycle management. The same code point is used
for the CANCEL_PUSH frame (Section 4.2.4). for the CANCEL_PUSH frame (Section 4.2.4).
SETTINGS (0x4): SETTINGS frames are sent only at the beginning of SETTINGS (0x4): SETTINGS frames are sent only at the beginning of
the connection. See Section 4.2.5 and Appendix A.3. the connection. See Section 4.2.5 and Appendix A.3.
PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream; PUSH_PROMISE (0x5): The PUSH_PROMISE does not reference a stream;
instead the push stream references the PUSH_PROMISE frame using a instead the push stream references the PUSH_PROMISE frame using a
skipping to change at page 48, line 47 skipping to change at page 50, line 15
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-18 B.1. Since draft-ietf-quic-http-19
o SETTINGS_NUM_PLACEHOLDERS is 0x9 (#2443,#2530)
o Non-zero bits in the Empty field of the PRIORITY frame MAY be
treated as an error (#2501)
B.2. Since draft-ietf-quic-http-18
o Resetting streams following a GOAWAY is recommended, but not o Resetting streams following a GOAWAY is recommended, but not
required (#2256,#2457) required (#2256,#2457)
o Use variable-length integers throughout (#2437,#2233,#2253,#2275) o Use variable-length integers throughout (#2437,#2233,#2253,#2275)
* Variable-length frame types, stream types, and settings * Variable-length frame types, stream types, and settings
identifiers identifiers
* Renumbered stream type assignments * Renumbered stream type assignments
* Modified associated reserved values * Modified associated reserved values
o Frame layout switched from Length-Type-Value to Type-Length-Value o Frame layout switched from Length-Type-Value to Type-Length-Value
(#2395,#2235) (#2395,#2235)
skipping to change at page 49, line 18 skipping to change at page 50, line 43
* Modified associated reserved values * Modified associated reserved values
o Frame layout switched from Length-Type-Value to Type-Length-Value o Frame layout switched from Length-Type-Value to Type-Length-Value
(#2395,#2235) (#2395,#2235)
o Specified error code for servers receiving DUPLICATE_PUSH (#2497) o Specified error code for servers receiving DUPLICATE_PUSH (#2497)
o Use connection error for invalid PRIORITY (#2507, #2508) o Use connection error for invalid PRIORITY (#2507, #2508)
B.2. Since draft-ietf-quic-http-17 B.3. 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.3. Since draft-ietf-quic-http-16 B.4. 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 50, line 5 skipping to change at page 51, line 31
(#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.4. Since draft-ietf-quic-http-15 B.5. Since draft-ietf-quic-http-15
Substantial editorial reorganization; no technical changes. Substantial editorial reorganization; no technical changes.
B.5. Since draft-ietf-quic-http-14 B.6. 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.6. Since draft-ietf-quic-http-13 B.7. 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.7. Since draft-ietf-quic-http-12 B.8. 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.8. Since draft-ietf-quic-http-11 B.9. 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.9. Since draft-ietf-quic-http-10 B.10. 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.10. Since draft-ietf-quic-http-09 B.11. 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.11. Since draft-ietf-quic-http-08 B.12. Since draft-ietf-quic-http-08
o Clarified connection coalescing rules (#940, #1024) o Clarified connection coalescing rules (#940, #1024)
B.12. Since draft-ietf-quic-http-07 B.13. 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.13. Since draft-ietf-quic-http-06 B.14. 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.14. Since draft-ietf-quic-http-05 B.15. 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.15. Since draft-ietf-quic-http-04 B.16. 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)
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.16. Since draft-ietf-quic-http-03 B.17. Since draft-ietf-quic-http-03
None. None.
B.17. Since draft-ietf-quic-http-02 B.18. Since draft-ietf-quic-http-02
o Track changes in transport draft o Track changes in transport draft
B.18. Since draft-ietf-quic-http-01 B.19. 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 53, line 4 skipping to change at page 54, line 35
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.19. Since draft-ietf-quic-http-00 B.20. 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
skipping to change at page 53, line 21 skipping to change at page 55, line 4
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.20. Since draft-shade-quic-http2-mapping-00 B.21. 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. 47 change blocks. 
124 lines changed or deleted 161 lines changed or added

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