draft-ietf-quic-http-09.txt   draft-ietf-quic-http-10.txt 
QUIC M. Bishop, Ed. QUIC M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track January 28, 2018 Intended status: Standards Track March 05, 2018
Expires: August 1, 2018 Expires: September 6, 2018
Hypertext Transfer Protocol (HTTP) over QUIC Hypertext Transfer Protocol (HTTP) over QUIC
draft-ietf-quic-http-09 draft-ietf-quic-http-10
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 QUIC. how HTTP/2 extensions can be ported to QUIC.
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 August 1, 2018. This Internet-Draft will expire on September 6, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
2. Connection Setup and Management . . . . . . . . . . . . . . . 4 2. Connection Setup and Management . . . . . . . . . . . . . . . 4
2.1. Discovering an HTTP/QUIC Endpoint . . . . . . . . . . . . 4 2.1. Discovering an HTTP/QUIC Endpoint . . . . . . . . . . . . 4
2.1.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 4 2.1.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 5
2.2. Connection Establishment . . . . . . . . . . . . . . . . 5 2.2. Connection Establishment . . . . . . . . . . . . . . . . 5
2.2.1. Draft Version Identification . . . . . . . . . . . . 5 2.2.1. Draft Version Identification . . . . . . . . . . . . 6
2.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 6 2.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 6
3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 6 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7
3.1. Control Streams . . . . . . . . . . . . . . . . . . . . . 7 3.1. Control Streams . . . . . . . . . . . . . . . . . . . . . 8
3.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 7 3.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 8
3.2.1. Header Compression . . . . . . . . . . . . . . . . . 9 3.2.1. Header Compression . . . . . . . . . . . . . . . . . 9
3.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 9 3.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 9
3.3. Request Prioritization . . . . . . . . . . . . . . . . . 10 3.2.3. Request Cancellation . . . . . . . . . . . . . . . . 10
3.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Request Prioritization . . . . . . . . . . . . . . . . . 11
4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11 3.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 11
4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 12
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 . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 13 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14
4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 15 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16
4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 15 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 16
4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19
4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 21 4.2.8. HEADER_ACK . . . . . . . . . . . . . . . . . . . . . 22
5. Connection Management . . . . . . . . . . . . . . . . . . . . 22 4.2.9. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 23
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 22 5. Connection Management . . . . . . . . . . . . . . . . . . . . 24
6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 23 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 24
7. Considerations for Transitioning from HTTP/2 . . . . . . . . 24 6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 24
7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 24 7. Considerations for Transitioning from HTTP/2 . . . . . . . . 25
7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 26 7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 27 7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 28
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 28
9.1. Registration of HTTP/QUIC Identification String . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 29 9.1. Registration of HTTP/QUIC Identification String . . . . . 30
9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 30 9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 30
9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 31 9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 30
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 31
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 32
10.2. Informative References . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 34
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 35
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
B.1. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 35 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36
B.2. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 35 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36
B.3. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 35 B.1. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 36
B.4. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 35 B.2. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 36
B.5. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 35 B.3. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 36
B.6. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 36 B.4. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 37
B.7. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 36 B.5. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 37
B.8. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 36 B.6. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 37
B.9. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 36 B.7. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 37
B.10. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 37 B.8. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 B.9. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 37
B.10. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 38
B.11. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38
1. Introduction 1. Introduction
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, drawing heavily on describes a mapping of HTTP semantics over QUIC, drawing heavily on
the existing TCP mapping, HTTP/2. Specifically, this document the existing TCP mapping, HTTP/2. Specifically, this document
identifies HTTP/2 features that are subsumed by QUIC, and describes identifies HTTP/2 features that are subsumed by QUIC, and describes
how the other features can be implemented atop QUIC. how the other features can be implemented atop QUIC.
skipping to change at page 4, line 50 skipping to change at page 5, line 10
Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the
same port across all IP addresses that serve a single domain, and same port across all IP addresses that serve a single domain, and
SHOULD NOT change this port. SHOULD NOT change this port.
2.1.1. QUIC Version Hints 2.1.1. QUIC Version Hints
This document defines the "quic" parameter for Alt-Svc, which MAY be This document defines the "quic" parameter for Alt-Svc, which MAY be
used to provide version-negotiation hints to HTTP/QUIC clients. QUIC used to provide version-negotiation hints to HTTP/QUIC clients. QUIC
versions are four-octet sequences with no additional constraints on versions are four-octet sequences with no additional constraints on
format. Syntax: format. Leading zeros SHOULD be omitted for brevity.
quic = version-number
version-number = 1*8HEXDIG; hex-encoded QUIC version
Leading zeros SHOULD be omitted for brevity. When multiple versions Syntax:
are supported, the "quic" parameter MAY be repeated multiple times in
a single Alt-Svc entry. For example, if a server supported both
version 0x00000001 and the version rendered in ASCII as "Q034", it
could specify the following header:
Alt-Svc: hq=":49288";quic=1;quic=51303334 quic = DQUOTE version-number [ "," version-number ] * DQUOTE
version-number = 1*8HEXDIG; hex-encoded QUIC version
Where multiple versions are listed, the order of the values reflects Where multiple versions are listed, the order of the values reflects
the server's preference (with the first value being the most the server's preference (with the first value being the most
preferred version). Origins SHOULD list only versions which are preferred version). Reserved versions MAY be listed, but unreserved
supported by the alternative, but MAY omit supported versions for any versions which are not supported by the alternative SHOULD NOT be
present in the list. Origins MAY omit supported versions for any
reason. reason.
Clients MUST ignore any included versions which they do not support.
The "quic" parameter MUST NOT occur more than once; clients SHOULD
process only the first occurrence.
For example, suppose a server supported both version 0x00000001 and
the version rendered in ASCII as "Q034". If it opted to include the
reserved versions (from Section 4 of [QUIC-TRANSPORT]) 0x0 and
0x1abadaba, it could specify the following header:
Alt-Svc: hq=":49288";quic="1,1abadaba,51303334,0"
A client acting on this header would drop the reserved versions
(because it does not support them), then attempt to connect to the
alternative using the first version in the list which it does
support.
2.2. Connection Establishment 2.2. Connection Establishment
HTTP/QUIC relies on QUIC as the underlying transport. The QUIC HTTP/QUIC relies on QUIC as the underlying transport. The QUIC
version being used MUST use TLS version 1.3 or greater as its version being used MUST use TLS version 1.3 or greater as its
handshake protocol. The Server Name Indication (SNI) extension handshake protocol. The Server Name Indication (SNI) extension
[RFC6066] MUST be included in the TLS handshake. [RFC6066] MUST be included in the TLS handshake.
QUIC connections are established as described in [QUIC-TRANSPORT]. QUIC connections are established as described in [QUIC-TRANSPORT].
During connection establishment, HTTP/QUIC support is indicated by During connection establishment, HTTP/QUIC support is indicated by
selecting the ALPN token "hq" in the TLS handshake. Support for selecting the ALPN token "hq" in the TLS handshake. Support for
skipping to change at page 9, line 7 skipping to change at page 9, line 24
without error by triggering a QUIC STOP_SENDING with error code without error by triggering a QUIC STOP_SENDING with error code
HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing HTTP_EARLY_RESPONSE, sending a complete response, and cleanly closing
its streams. Clients MUST NOT discard complete responses as a result its streams. Clients MUST NOT discard complete responses as a result
of having their request terminated abruptly, though clients can of having their request terminated abruptly, though clients can
always discard responses at their discretion for other reasons. always discard responses at their discretion for other reasons.
Servers MUST NOT abort a response in progress as a result of Servers MUST NOT abort a response in progress as a result of
receiving a solicited RST_STREAM. receiving a solicited RST_STREAM.
3.2.1. Header Compression 3.2.1. Header Compression
HTTP/QUIC uses HPACK header compression as described in [RFC7541]. HTTP/QUIC uses QCRAM header compression as described in [QCRAM], a
HPACK was designed for HTTP/2 with the assumption of in-order variation of HPACK which allows the flexibility to avoid header-
delivery such as that provided by TCP. A sequence of encoded header compression-induced head-of-line blocking. See that document for
blocks must arrive (and be decoded) at an endpoint in the same order additional details.
in which they were encoded. This ensures that the dynamic state at
the two endpoints remains in sync.
QUIC streams provide in-order delivery of data sent on those streams,
but there are no guarantees about order of delivery between streams.
QUIC anticipates moving to a modified version of HPACK without this
assumption. In the meantime, by fixing the size of the dynamic table
at zero, HPACK can be used in an unordered environment.
3.2.2. The CONNECT Method 3.2.2. The CONNECT Method
The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily
used with HTTP proxies to establish a TLS session with an origin used with HTTP proxies to establish a TLS session with an origin
server for the purposes of interacting with "https" resources. In server for the purposes of interacting with "https" resources. In
HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a
tunnel to a remote host. In HTTP/2, the CONNECT method is used to tunnel to a remote host. In HTTP/2, the CONNECT method is used to
establish a tunnel over a single HTTP/2 stream to a remote host for establish a tunnel over a single HTTP/2 stream to a remote host for
similar purposes. similar purposes.
skipping to change at page 10, line 17 skipping to change at page 10, line 26
so clients SHOULD NOT cause send a STREAM frame with a FIN bit for so clients SHOULD NOT cause send a STREAM frame with a FIN bit for
connections on which they are still expecting data. connections on which they are still expecting data.
A TCP connection error is signaled with RST_STREAM. A proxy treats A TCP connection error is signaled with RST_STREAM. A proxy treats
any error in the TCP connection, which includes receiving a TCP any error in the TCP connection, which includes receiving a TCP
segment with the RST bit set, as a stream error of type segment with the RST bit set, as a stream error of type
HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send
a TCP segment with the RST bit set if it detects an error with the a TCP segment with the RST bit set if it detects an error with the
stream or the QUIC connection. stream or the QUIC connection.
3.2.3. Request Cancellation
Either client or server can cancel requests by closing the stream
(QUIC RST_STREAM or STOP_SENDING frames, as appropriate) with an
error type of HTTP_REQUEST_CANCELLED (Section 6.1). When the client
cancels a request or response, it indicates that the response is no
longer of interest.
When the server cancels either direction of the request stream using
HTTP_REQUEST_CANCELLED, it indicates that no application processing
was performed. The client can treat requests cancelled by the server
as though they had never been sent at all, thereby allowing them to
be retried later on a new connection. Servers MUST NOT use the
HTTP_REQUEST_CANCELLED status for requests which were partially or
fully processed.
Note: In this context, "processed" means that some data from the
stream was passed to some higher layer of software that might have
taken some action as a result.
If a stream is cancelled after receiving a complete response, the
client MAY ignore the cancellation and use the response. However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used. Automatically retrying such requests is
not possible, unless this is otherwise permitted (e.g., idempotent
actions like GET, PUT, or DELETE).
3.3. Request Prioritization 3.3. Request Prioritization
HTTP/QUIC uses the priority scheme described in [RFC7540], HTTP/QUIC uses the priority scheme described in [RFC7540],
Section 5.3. In this priority scheme, a given request can be Section 5.3. In this priority scheme, a given request can be
designated as dependent upon another request, which expresses the designated as dependent upon another request, which expresses the
preference that the latter stream (the "parent" request) be allocated preference that the latter stream (the "parent" request) be allocated
resources before the former stream (the "dependent" request). Taken resources before the former stream (the "dependent" request). Taken
together, the dependencies across all requests in a connection form a together, the dependencies across all requests in a connection form a
dependency tree. The structure of the dependency tree changes as dependency tree. The structure of the dependency tree changes as
PRIORITY frames add, remove, or change the dependency links between PRIORITY frames add, remove, or change the dependency links between
skipping to change at page 10, line 40 skipping to change at page 11, line 28
identifying the stream that carries a request or by using a Push ID identifying the stream that carries a request or by using a Push ID
(Section 4.2.6). (Section 4.2.6).
Only a client can send PRIORITY frames. A server MUST NOT send a Only a client can send PRIORITY frames. A server MUST NOT send a
PRIORITY frame. PRIORITY frame.
3.4. Server Push 3.4. Server Push
HTTP/QUIC supports server push as described in [RFC7540]. During HTTP/QUIC supports server push as described in [RFC7540]. During
connection establishment, the client enables server push by sending a connection establishment, the client enables server push by sending a
MAX_PUSH_ID frame (see Section 4.2.8). A server cannot use server MAX_PUSH_ID frame (see Section 4.2.9). A server cannot use server
push until it receives a MAX_PUSH_ID frame. push until it receives a MAX_PUSH_ID frame.
As with server push for HTTP/2, the server initiates a server push by As with server push for HTTP/2, the server initiates a server push by
sending a PUSH_PROMISE frame that includes request header fields sending a PUSH_PROMISE frame that includes request header fields
attributed to the request. The PUSH_PROMISE frame is sent on the attributed to the request. The PUSH_PROMISE frame is sent on the
client-initiated, bidirectional stream that carried the request that client-initiated, bidirectional stream that carried the request that
generated the push. This allows the server push to be associated generated the push. This allows the server push to be associated
with a request. Ordering of a PUSH_PROMISE in relation to certain with a request. Ordering of a PUSH_PROMISE in relation to certain
parts of the response is important (see Section 8.2.1 of [RFC7540]). parts of the response is important (see Section 8.2.1 of [RFC7540]).
skipping to change at page 11, line 25 skipping to change at page 12, line 14
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ... | Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Push Stream Header Figure 1: Push Stream Header
A server SHOULD use Push IDs sequentially, starting at 0. A client A server SHOULD use Push IDs sequentially, starting at 0. A client
uses the MAX_PUSH_ID frame (Section 4.2.8) to limit the number of uses the MAX_PUSH_ID frame (Section 4.2.9) to limit the number of
pushes that a server can promise. A client MUST treat receipt of a pushes that a server can promise. A client MUST treat receipt of a
push stream with a Push ID that is greater than the maximum Push ID push stream with a Push ID that is greater than the maximum Push ID
as a connection error of type HTTP_PUSH_LIMIT_EXCEEDED. as a connection error of type HTTP_PUSH_LIMIT_EXCEEDED.
Each Push ID MUST only be used once in a push stream header. If a Each Push ID MUST only be used once in a push stream header. If a
push stream header includes a Push ID that was used in another push push stream header includes a Push ID that was used in another push
stream header, the client MUST treat this as a connection error of stream header, the client MUST treat this as a connection error of
type HTTP_DUPLICATE_PUSH. The same Push ID can be used in multiple type HTTP_DUPLICATE_PUSH. The same Push ID can be used in multiple
PUSH_PROMISE frames (see Section 4.2.6). PUSH_PROMISE frames (see Section 4.2.6).
skipping to change at page 13, line 10 skipping to change at page 13, line 51
DATA frames MUST contain a non-zero-length payload. If a DATA frame DATA frames MUST contain a non-zero-length payload. If a DATA frame
is received with a payload length of zero, the recipient MUST respond is received with a payload length of zero, the recipient MUST respond
with a stream error (Section 6) of type HTTP_MALFORMED_FRAME. with a stream error (Section 6) of type HTTP_MALFORMED_FRAME.
4.2.2. HEADERS 4.2.2. HEADERS
The HEADERS frame (type=0x1) is used to carry a header block, The HEADERS frame (type=0x1) is used to carry a header block,
compressed using HPACK Section 3.2.1. compressed using HPACK Section 3.2.1.
No flags are defined for the HEADERS frame. The HEADERS frame defines a single flag:
A HEADERS frame with any flags set MUST be treated as a connection BLOCKING (0x01): Indicates the stream might need to wait for
error of type HTTP_MALFORMED_FRAME. dependent headers before processing. If 0, the frame can be
processed immediately upon receipt.
HEADERS frames can be sent on the Control Stream as well as on
request / push streams. The value of BLOCKING MUST be 0 for HEADERS
frames on the Control Stream, since they can only depend on previous
HEADERS on the same stream.
4.2.3. PRIORITY 4.2.3. PRIORITY
The PRIORITY (type=0x02) frame specifies the sender-advised priority The PRIORITY (type=0x02) frame specifies the sender-advised priority
of a stream and is substantially different in format from [RFC7540]. of a stream and is substantially different in format from [RFC7540].
In order to ensure that prioritization is processed in a consistent In order to ensure that prioritization is processed in a consistent
order, PRIORITY frames MUST be sent on the control stream. A order, PRIORITY frames MUST be sent on the control stream. A
PRIORITY frame sent on any other stream MUST be treated as a PRIORITY frame sent on any other stream MUST be treated as a
HTTP_WRONG_STREAM error. HTTP_WRONG_STREAM error.
skipping to change at page 17, line 19 skipping to change at page 18, line 19
4.2.5.1. Integer encoding 4.2.5.1. Integer encoding
Settings which are integers use the QUIC variable-length integer Settings which are integers use the QUIC variable-length integer
encoding. encoding.
4.2.5.2. Defined SETTINGS Parameters 4.2.5.2. Defined SETTINGS Parameters
The following settings are defined in HTTP/QUIC: The following settings are defined in HTTP/QUIC:
SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of SETTINGS_HEADER_TABLE_SIZE (0x1): An integer with a maximum value of
2^30 - 1. This value MUST be zero. 2^30 - 1.
SETTINGS_MAX_HEADER_LIST_SIZE (0x6): An integer with a maximum value SETTINGS_MAX_HEADER_LIST_SIZE (0x6): An integer with a maximum value
of 2^30 - 1 of 2^30 - 1
4.2.5.3. Usage in 0-RTT 4.2.5.3. Usage in 0-RTT
When a 0-RTT QUIC connection is being used, the client's initial When a 0-RTT QUIC connection is being used, the client's initial
requests will be sent before the arrival of the server's SETTINGS requests will be sent before the arrival of the server's SETTINGS
frame. Clients SHOULD cache at least the following settings about frame. Clients SHOULD cache at least the following settings about
servers: servers:
skipping to change at page 18, line 12 skipping to change at page 19, line 12
the server on the closed connection. (This assumes that only the server on the closed connection. (This assumes that only
requests that are safe to retry are sent in 0-RTT.) If the requests that are safe to retry are sent in 0-RTT.) If the
connection was closed before the SETTINGS frame was received, clients connection was closed before the SETTINGS frame was received, clients
SHOULD discard any cached values and use the defaults above on the SHOULD discard any cached values and use the defaults above on the
next connection. next connection.
4.2.6. PUSH_PROMISE 4.2.6. PUSH_PROMISE
The PUSH_PROMISE frame (type=0x05) is used to carry a request header The PUSH_PROMISE frame (type=0x05) is used to carry a request header
set from server to client, as in HTTP/2. The PUSH_PROMISE frame set from server to client, as in HTTP/2. The PUSH_PROMISE frame
defines no flags. defines a single flag:
BLOCKING (0x01): Indicates the stream might need to wait for
dependent headers before processing. If 0, the frame can be
processed immediately upon receipt.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ... | Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Block (*) ... | Header Block (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: PUSH_PROMISE frame payload Figure 5: PUSH_PROMISE frame payload
The payload consists of: The payload consists of:
Push ID: A variable-length integer that identifies the server push Push ID: A variable-length integer that identifies the server push
request. A push ID is used in push stream header (Section 3.4), request. A push ID is used in push stream header (Section 3.4),
CANCEL_PUSH frames (Section 4.2.4), and PRIORITY frames CANCEL_PUSH frames (Section 4.2.4), and PRIORITY frames
(Section 4.2.3). (Section 4.2.3).
Header Block: HPACK-compressed request headers for the promised Header Block: QCRAM-compressed request headers for the promised
response. response. See [QCRAM] for more details.
A server MUST NOT use a Push ID that is larger than the client has A server MUST NOT use a Push ID that is larger than the client has
provided in a MAX_PUSH_ID frame (Section 4.2.8). A client MUST treat provided in a MAX_PUSH_ID frame (Section 4.2.9). A client MUST treat
receipt of a PUSH_PROMISE that contains a larger Push ID than the receipt of a PUSH_PROMISE that contains a larger Push ID than the
client has advertised as a connection error of type client has advertised as a connection error of type
HTTP_MALFORMED_FRAME. HTTP_MALFORMED_FRAME.
A server MAY use the same Push ID in multiple PUSH_PROMISE frames. A server MAY use the same Push ID in multiple PUSH_PROMISE frames.
This allows the server to use the same server push in response to This allows the server to use the same server push in response to
multiple concurrent requests. Referencing the same server push multiple concurrent requests. Referencing the same server push
ensures that a PUSH_PROMISE can be made in relation to every response ensures that a PUSH_PROMISE can be made in relation to every response
in which server push might be needed without duplicating pushes. in which server push might be needed without duplicating pushes.
skipping to change at page 19, line 25 skipping to change at page 20, line 28
4.2.7. GOAWAY 4.2.7. GOAWAY
The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of
a connection by a server. GOAWAY allows a server to stop accepting a connection by a server. GOAWAY allows a server to stop accepting
new requests while still finishing processing of previously received new requests while still finishing processing of previously received
requests. This enables administrative actions, like server requests. This enables administrative actions, like server
maintenance. GOAWAY by itself does not close a connection. maintenance. GOAWAY by itself does not close a connection.
The GOAWAY frame does not define any flags, and the payload is a QUIC The GOAWAY frame does not define any flags, and the payload is a QUIC
Stream ID for a client-initiated, bidirectional stream encoded as a Stream ID for a client-initiated, bidirectional stream encoded as a
variable-length integer. variable-length integer. A client MUST treat receipt of a GOAWAY
frame containing a Stream ID of any other type as a connection error
of type HTTP_MALFORMED_FRAME.
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 as a connection error (Section 6) of type a GOAWAY frame as a connection error (Section 6) of type
HTTP_UNEXPECTED_GOAWAY. HTTP_UNEXPECTED_GOAWAY.
A client MUST treat receipt of a GOAWAY frame containing a Stream ID
of any other type as a connection error of type HTTP_MALFORMED_FRAME.
The GOAWAY frame applies to the connection, not a specific stream. The GOAWAY frame applies to the connection, not a specific stream.
An endpoint MUST treat a GOAWAY frame on a stream other than the An endpoint MUST treat a GOAWAY frame on a stream other than the
control stream as a connection error (Section 6) of type control stream as a connection error (Section 6) of type
HTTP_WRONG_STREAM. HTTP_WRONG_STREAM.
New client requests might already have been sent before the client New client requests might already have been sent before the client
receives the server's GOAWAY frame. The GOAWAY frame contains the receives the server's GOAWAY frame. The GOAWAY frame contains the
Stream ID of the last client-initiated request that was or might be Stream ID of the last client-initiated request that was or might be
processed in this connection, which enables client and server to processed in this connection, which enables client and server to
agree on which requests were accepted prior to the connection agree on which requests were accepted prior to the connection
shutdown. This identifier MAY be lower than the stream limit shutdown. This identifier MAY be lower than the stream limit
identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no
requests were processed. Servers SHOULD NOT increase the requests were processed. Servers SHOULD NOT increase the
MAX_STREAM_ID limit after sending a GOAWAY frame. MAX_STREAM_ID limit after sending a GOAWAY frame.
Note: In this context, "processed" means that some data from the Once sent, the server MUST cancel requests sent on streams with an
stream was passed to some higher layer of software that might have
taken some action as a result.
Once sent, the server will refuse requests sent on streams with an
identifier higher than the included last Stream ID. Clients MUST NOT identifier higher than the included last Stream ID. Clients MUST NOT
send new requests on the connection after receiving GOAWAY, although send new requests on the connection after receiving GOAWAY, although
requests might already be in transit. A new connection can be requests might already be in transit. A new connection can be
established for new requests. established for new requests.
If the client has sent requests on streams with a higher Stream ID If the client has sent requests on streams with a higher Stream ID
than indicated in the GOAWAY frame, those requests were not and will than indicated in the GOAWAY frame, those requests are considered
not be processed. Endpoints SHOULD reset any streams above this ID cancelled (Section 3.2.3). Clients SHOULD reset any streams above
with the error code HTTP_REQUEST_CANCELLED. Servers MAY also reset this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also
streams below the indicated ID with HTTP_REQUEST_CANCELLED if the cancel requests on streams below the indicated ID if these requests
associated requests were not processed. Servers MUST NOT use the were not processed.
HTTP_REQUEST_CANCELLED status for requests which were partially or
fully processed.
The client can treat requests cancelled by the server as though they
had never been sent at all, thereby allowing them to be retried later
on a new connection. If a stream is cancelled after receiving a
complete response, the client MAY ignore the cancellation and use the
response. However, if a stream is cancelled after receiving a
partial response, the response SHOULD NOT be used. Automatically
retrying such requests is not possible, unless this is otherwise
permitted (e.g., idempotent actions like GET, PUT, or DELETE).
Requests on Stream IDs less than or equal to the Stream ID in the Requests on Stream IDs less than or equal to the Stream ID in the
GOAWAY frame might have been processed; their status cannot be known GOAWAY frame might have been processed; their status cannot be known
until they are completed successfully, reset individually, or the until they are completed successfully, reset individually, or the
connection terminates. connection terminates.
Servers SHOULD send a GOAWAY frame when the closing of a connection Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the is known in advance, even if the advance notice is small, so that the
remote peer can know whether a stream has been partially processed or remote peer can know whether a stream has been partially processed or
not. For example, if an HTTP client sends a POST at the same time not. For example, if an HTTP client sends a POST at the same time
that a server closes a QUIC connection, the client cannot know if the that a server closes a QUIC connection, the client cannot know if the
skipping to change at page 21, line 38 skipping to change at page 22, line 22
losing requests. losing requests.
Once all requests on streams at or below the identified stream number Once all requests on streams at or below the identified stream number
have been completed or cancelled, and all promised server push have been completed or cancelled, and all promised server push
responses associated with those requests have been completed or responses associated with those requests have been completed or
cancelled, the connection can be closed using an Immediate Close (see cancelled, the connection can be closed using an Immediate Close (see
[QUIC-TRANSPORT]). An endpoint that completes a graceful shutdown [QUIC-TRANSPORT]). An endpoint that completes a graceful shutdown
SHOULD use the QUIC APPLICATION_CLOSE frame with the HTTP_NO_ERROR SHOULD use the QUIC APPLICATION_CLOSE frame with the HTTP_NO_ERROR
code. code.
4.2.8. MAX_PUSH_ID 4.2.8. HEADER_ACK
The HEADER_ACK frame (type=0x8) is used by header compression to
ensure consistency. The frames are sent from the QCRAM decoder to
the QCRAM encoder; that is, the server sends them to the client to
acknowledge processing of the client's header blocks, and the client
sends them to the server to acknowledge processing of the server's
header blocks.
The HEADER_ACK frame is sent on the Control Stream when the QCRAM
decoder has fully processed a header block. It is used by the peer's
QCRAM encoder to determine whether subsequent indexed representations
that might reference that block are vulnerable to head-of-line
blocking, and to prevent eviction races. See [QCRAM] for more
details on the use of this information.
The HEADER_ACK frame indicates the stream on which the header block
was processed by encoding the Stream ID as a variable-length integer.
The same Stream ID can be identified multiple times, as multiple
header-containing blocks can be sent on a single stream in the case
of intermediate responses, trailers, pushed requests, etc. as well as
on the Control Streams. Since header frames on each stream are
received and processed in order, this gives the encoder precise
feedback on which header blocks within a stream have been fully
processed.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| Stream ID (i) ...
+---+---+---+---+---+---+---+---+
HEADER_ACK frame
The HEADER_ACK frame does not define any flags.
4.2.9. MAX_PUSH_ID
The MAX_PUSH_ID frame (type=0xD) is used by clients to control the The MAX_PUSH_ID frame (type=0xD) is used by clients to control the
number of server pushes that the server can initiate. This sets the number of server pushes that the server can initiate. This sets the
maximum value for a Push ID that the server can use in a PUSH_PROMISE maximum value for a Push ID that the server can use in a PUSH_PROMISE
frame. Consequently, this also limits the number of push streams frame. Consequently, this also limits the number of push streams
that the server can initiate in addition to the limit set by the QUIC that the server can initiate in addition to the limit set by the QUIC
MAX_STREAM_ID frame. MAX_STREAM_ID frame.
The MAX_PUSH_ID frame is always sent on a control stream. Receipt of The MAX_PUSH_ID frame is always sent on a control stream. Receipt of
a MAX_PUSH_ID frame on any other stream MUST be treated as a a MAX_PUSH_ID frame on any other stream MUST be treated as a
skipping to change at page 25, line 18 skipping to change at page 26, line 43
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/ frames. To achieve in-order delivery of priority changes in HTTP/
QUIC, PRIORITY frames are sent on the control stream and the PRIORITY QUIC, PRIORITY frames are sent on the control stream and the PRIORITY
section is removed from the HEADERS frame. section is removed from the HEADERS frame.
Likewise, HPACK was designed with the assumption of in-order
delivery. A sequence of encoded header blocks must arrive (and be
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
sync. As a result, HTTP/QUIC uses a modified version of HPACK,
described in [QCRAM].
Frame type definitions in HTTP/QUIC often use the QUIC variable- Frame type definitions in HTTP/QUIC often use the QUIC variable-
length integer encoding. In particular, Stream IDs use this length integer encoding. In particular, Stream IDs use this
encoding, which allow for a larger range of possible values than the encoding, which allow for a larger range of possible values than the
encoding used in HTTP/2. Some frames in HTTP/QUIC use an identifier encoding used in HTTP/2. Some frames in HTTP/QUIC use an identifier
rather than a Stream ID (e.g. Push IDs in PRIORITY frames). rather than a Stream ID (e.g. Push IDs in PRIORITY frames).
Redefinition of the encoding of extension frame types might be Redefinition of the encoding of extension frame types might be
necessary if the encoding includes a Stream ID. necessary if the encoding includes a Stream ID.
Other than this issue, frame type HTTP/2 extensions are typically Other than this issue, frame type HTTP/2 extensions are typically
portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 2 portable to QUIC simply by replacing Stream 0 in HTTP/2 with Stream 2
skipping to change at page 30, line 5 skipping to change at page 31, line 20
Code: The 8-bit code assigned to the frame type. Code: The 8-bit code assigned to the frame type.
Specification: A reference to a specification that includes a Specification: A reference to a specification that includes a
description of the frame layout, its semantics, and flags that the description of the frame layout, its semantics, and flags that the
frame type uses, including any parts of the frame that are frame type uses, including any parts of the frame that are
conditionally present based on the value of flags. conditionally present based on the value of flags.
The entries in the following table are registered by this document. The entries in the following table are registered by this document.
+--------------+------+---------------+ +--------------+------+---------------------+
| Frame Type | Code | Specification | | Frame Type | Code | Specification |
+--------------+------+---------------+ +--------------+------+---------------------+
| DATA | 0x0 | Section 4.2.1 | | DATA | 0x0 | Section 4.2.1 |
| | | | | | | |
| HEADERS | 0x1 | Section 4.2.2 | | HEADERS | 0x1 | Section 4.2.2 |
| | | | | | | |
| PRIORITY | 0x2 | Section 4.2.3 | | PRIORITY | 0x2 | Section 4.2.3 |
| | | | | | | |
| CANCEL_PUSH | 0x3 | Section 4.2.4 | | CANCEL_PUSH | 0x3 | Section 4.2.4 |
| | | | | | | |
| SETTINGS | 0x4 | Section 4.2.5 | | SETTINGS | 0x4 | Section 4.2.5 |
| | | | | | | |
| PUSH_PROMISE | 0x5 | Section 4.2.6 | | PUSH_PROMISE | 0x5 | Section 4.2.6 |
| | | | | | | |
| Reserved | 0x6 | N/A | | Reserved | 0x6 | N/A |
| | | | | | | |
| GOAWAY | 0x7 | Section 4.2.7 | | GOAWAY | 0x7 | Section 4.2.7 |
| | | | | | | |
| Reserved | 0x8 | N/A | | HEADER_ACK | 0x8 | {{frame-header-ack} |
| | | | | | | |
| Reserved | 0x9 | N/A | | Reserved | 0x9 | N/A |
| | | | | | | |
| MAX_PUSH_ID | 0xD | Section 4.2.8 | | MAX_PUSH_ID | 0xD | Section 4.2.9 |
+--------------+------+---------------+ +--------------+------+---------------------+
9.4. Settings Parameters 9.4. Settings Parameters
This document establishes a registry for HTTP/QUIC settings. The This document establishes a registry for HTTP/QUIC settings. The
"HTTP/QUIC Settings" registry manages a 16-bit space. The "HTTP/QUIC "HTTP/QUIC Settings" registry manages a 16-bit space. The "HTTP/QUIC
Settings" registry operates under the "Expert Review" policy Settings" registry operates under the "Expert Review" policy
[RFC8126] for values in the range from 0x0000 to 0xefff, with values [RFC8126] for values in the range from 0x0000 to 0xefff, with values
between and 0xf000 and 0xffff being reserved for Experimental Use. between and 0xf000 and 0xffff being reserved for Experimental Use.
The designated experts are the same as those for the "HTTP/2 The designated experts are the same as those for the "HTTP/2
Settings" registry defined in [RFC7540]. Settings" registry defined in [RFC7540].
skipping to change at page 33, line 25 skipping to change at page 34, line 43
| HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 6.1 | | HTTP_MALFORMED_FRAME | 0x01XX | Error in | Section 6.1 |
| | | frame | | | | | frame | |
| | | formatting | | | | | formatting | |
| | | or use | | | | | or use | |
+----------------------------+--------+------------+----------------+ +----------------------------+--------+------------+----------------+
10. References 10. References
10.1. Normative References 10.1. Normative References
[QCRAM] Krasic, C., Bishop, M., and A. Frindell, Ed., "Header
Compression for HTTP over QUIC", draft-ietf-quic-qcram-00
(work in progress), March 2018.
[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-09 (work in progress), January 2018. transport-10 (work in progress), March 2018.
[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 34, line 20 skipping to change at page 35, line 39
[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>.
[RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
Transfer Protocol Version 2 (HTTP/2)", RFC 7540, Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
DOI 10.17487/RFC7540, May 2015, DOI 10.17487/RFC7540, May 2015,
<https://www.rfc-editor.org/info/rfc7540>. <https://www.rfc-editor.org/info/rfc7540>.
[RFC7541] Peon, R. and H. Ruellan, "HPACK: Header Compression for
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<https://www.rfc-editor.org/info/rfc7541>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <https://www.rfc-editor.org/info/rfc7838>. April 2016, <https://www.rfc-editor.org/info/rfc7838>.
[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>.
10.2. Informative References 10.2. Informative References
skipping to change at page 35, line 18 skipping to change at page 36, line 31
Warres. Warres.
A substantial portion of Mike's contribution was supported by A substantial portion of Mike's contribution was supported by
Microsoft during his employment there. Microsoft during his employment there.
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-08 B.1. Since draft-ietf-quic-http-09
o Selected QCRAM for header compression (#228, #1117)
o The server_name TLS extension is now mandatory (#296, #495)
o Specified handling of unsupported versions in Alt-Svc (#1093,
#1097)
B.2. Since draft-ietf-quic-http-08
o Clarified connection coalescing rules (#940, #1024) o Clarified connection coalescing rules (#940, #1024)
B.2. Since draft-ietf-quic-http-07 B.3. 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.3. Since draft-ietf-quic-http-06 B.4. 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.4. Since draft-ietf-quic-http-05 B.5. 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.5. Since draft-ietf-quic-http-04 B.6. 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.6. Since draft-ietf-quic-http-03 B.7. Since draft-ietf-quic-http-03
None. None.
B.7. Since draft-ietf-quic-http-02 B.8. Since draft-ietf-quic-http-02
o Track changes in transport draft o Track changes in transport draft
B.8. Since draft-ietf-quic-http-01 B.9. Since draft-ietf-quic-http-01
o SETTINGS changes (#181): o SETTINGS changes (#181):
* SETTINGS can be sent only once at the start of a connection; no * SETTINGS can be sent only once at the start of a connection; no
changes thereafter changes thereafter
* SETTINGS_ACK removed * SETTINGS_ACK removed
* Settings can only occur in the SETTINGS frame a single time * Settings can only occur in the SETTINGS frame a single time
* Boolean format updated * Boolean format updated
o Alt-Svc parameter changed from "v" to "quic"; format updated o Alt-Svc parameter changed from "v" to "quic"; format updated
(#229) (#229)
o Closing the connection control stream or any message control o Closing the connection control stream or any message control
stream is a fatal error (#176) stream is a fatal error (#176)
o HPACK Sequence counter can wrap (#173) o HPACK Sequence counter can wrap (#173)
o 0-RTT guidance added o 0-RTT guidance added
o Guide to differences from HTTP/2 and porting HTTP/2 extensions o Guide to differences from HTTP/2 and porting HTTP/2 extensions
added (#127,#242) added (#127,#242)
B.9. Since draft-ietf-quic-http-00 B.10. Since draft-ietf-quic-http-00
o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29) o Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout (#11,#29)
o Changed from using HTTP/2 framing within Stream 3 to new framing o Changed from using HTTP/2 framing within Stream 3 to new framing
format and two-stream-per-request model (#71,#72,#73) format and two-stream-per-request model (#71,#72,#73)
o Adopted SETTINGS format from draft-bishop-httpbis-extended- o Adopted SETTINGS format from draft-bishop-httpbis-extended-
settings-01 settings-01
o Reworked SETTINGS_ACK to account for indeterminate inter-stream o Reworked SETTINGS_ACK to account for indeterminate inter-stream
order (#75) order (#75)
o Described CONNECT pseudo-method (#95) o Described CONNECT pseudo-method (#95)
o Updated ALPN token and Alt-Svc guidance (#13,#87) o Updated ALPN token and Alt-Svc guidance (#13,#87)
o Application-layer-defined error codes (#19,#74) o Application-layer-defined error codes (#19,#74)
B.10. Since draft-shade-quic-http2-mapping-00 B.11. 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
Author's Address Author's Address
Mike Bishop (editor) Mike Bishop (editor)
Akamai Akamai
 End of changes. 49 change blocks. 
153 lines changed or deleted 234 lines changed or added

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