draft-ietf-quic-http-10.txt   draft-ietf-quic-http-11.txt 
QUIC M. Bishop, Ed. QUIC M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track March 05, 2018 Intended status: Standards Track April 17, 2018
Expires: September 6, 2018 Expires: October 19, 2018
Hypertext Transfer Protocol (HTTP) over QUIC Hypertext Transfer Protocol (HTTP) over QUIC
draft-ietf-quic-http-10 draft-ietf-quic-http-11
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 September 6, 2018. This Internet-Draft will expire on October 19, 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
skipping to change at page 2, line 42 skipping to change at page 2, line 42
3.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 8 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.2.3. Request Cancellation . . . . . . . . . . . . . . . . 10 3.2.3. Request Cancellation . . . . . . . . . . . . . . . . 10
3.3. Request Prioritization . . . . . . . . . . . . . . . . . 11 3.3. Request Prioritization . . . . . . . . . . . . . . . . . 11
3.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 11 3.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 11
4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 12 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 12
4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13
4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14
4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16
4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 16 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 17
4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19
4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.8. HEADER_ACK . . . . . . . . . . . . . . . . . . . . . 22 4.2.8. HEADER_ACK . . . . . . . . . . . . . . . . . . . . . 22
4.2.9. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 23 4.2.9. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 23
5. Connection Management . . . . . . . . . . . . . . . . . . . . 24 5. Connection Management . . . . . . . . . . . . . . . . . . . . 24
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 24 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 24 6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 25
7. Considerations for Transitioning from HTTP/2 . . . . . . . . 25 7. Considerations for Transitioning from HTTP/2 . . . . . . . . 26
7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 26
7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 26 7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 26
7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 28 7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 28
7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 28 7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 8. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
9.1. Registration of HTTP/QUIC Identification String . . . . . 30 9.1. Registration of HTTP/QUIC Identification String . . . . . 30
9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 30 9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 31
9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 30 9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 31
9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 31 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 32
9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 32 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 33
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 34 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.1. Normative References . . . . . . . . . . . . . . . . . . 34 10.1. Normative References . . . . . . . . . . . . . . . . . . 35
10.2. Informative References . . . . . . . . . . . . . . . . . 35 10.2. Informative References . . . . . . . . . . . . . . . . . 36
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37
B.1. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 36 B.1. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 37
B.2. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 36 B.2. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 37
B.3. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 36 B.3. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 37
B.4. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 37 B.4. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 37
B.5. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 37 B.5. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 37
B.6. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 37 B.6. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 37
B.7. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 37 B.7. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 38
B.8. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 37 B.8. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 38
B.9. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 37 B.9. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 38
B.10. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 38 B.10. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 38
B.11. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 38 B.11. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 38 B.12. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 39
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39
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 39 skipping to change at page 4, line 39
An HTTP origin advertises the availability of an equivalent HTTP/QUIC An HTTP origin advertises the availability of an equivalent HTTP/QUIC
endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC endpoint via the Alt-Svc HTTP response header or the HTTP/2 ALTSVC
frame ([RFC7838]), using the ALPN token defined in Section 2.2. frame ([RFC7838]), using the ALPN token defined in Section 2.2.
For example, an origin could indicate in an HTTP/1.1 or HTTP/2 For example, an origin could indicate in an HTTP/1.1 or HTTP/2
response that HTTP/QUIC was available on UDP port 50781 at the same response that HTTP/QUIC was available on UDP port 50781 at the same
hostname by including the following header in any response: hostname by including the following header in any response:
Alt-Svc: hq=":50781" Alt-Svc: hq=":50781"
On receipt of an Alt-Svc header indicating HTTP/QUIC support, a On receipt of an Alt-Svc record indicating HTTP/QUIC support, a
client MAY attempt to establish a QUIC connection to the indicated client MAY attempt to establish a QUIC connection to the indicated
host and port and, if successful, send HTTP requests using the host and port and, if successful, send HTTP requests using the
mapping described in this document. mapping described in this document.
Connectivity problems (e.g. firewall blocking UDP) can result in QUIC Connectivity problems (e.g. firewall blocking UDP) can result in QUIC
connection establishment failure, in which case the client SHOULD connection establishment failure, in which case the client SHOULD
continue using the existing connection or try another alternative continue using the existing connection or try another alternative
endpoint offered by the origin. endpoint offered by the origin.
Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the Servers MAY serve HTTP/QUIC on any UDP port, since an alternative
same port across all IP addresses that serve a single domain, and always includes an explicit 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. Leading zeros SHOULD be omitted for brevity. format. Leading zeros SHOULD be omitted for brevity.
Syntax: Syntax:
skipping to change at page 9, line 24 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 QCRAM header compression as described in [QCRAM], a HTTP/QUIC uses QPACK header compression as described in [QPACK], a
variation of HPACK which allows the flexibility to avoid header- variation of HPACK which allows the flexibility to avoid header-
compression-induced head-of-line blocking. See that document for compression-induced head-of-line blocking. See that document for
additional details. additional details.
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
skipping to change at page 11, line 26 skipping to change at page 11, line 26
The PRIORITY frame Section 4.2.3 identifies a request either by The PRIORITY frame Section 4.2.3 identifies a request either by
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 in a similar manner to [RFC7540], but
connection establishment, the client enables server push by sending a uses different mechanisms. During connection establishment, the
MAX_PUSH_ID frame (see Section 4.2.9). A server cannot use server client enables server push by sending a MAX_PUSH_ID frame (see
push until it receives a MAX_PUSH_ID frame. Section 4.2.9). A server cannot use server 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 (see Section 4.2.6) that includes
attributed to the request. The PUSH_PROMISE frame is sent on the request headers for the promised request. Promised requests MUST
client-initiated, bidirectional stream that carried the request that conform to the requirements in Section 8.2 of [RFC7540].
generated the push. This allows the server push to be associated
with a request. Ordering of a PUSH_PROMISE in relation to certain The PUSH_PROMISE frame is sent on the client-initiated, bidirectional
parts of the response is important (see Section 8.2.1 of [RFC7540]). stream that carried the request that generated the push. This allows
the server push to be associated 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]).
Unlike HTTP/2, the PUSH_PROMISE does not reference a stream; it Unlike HTTP/2, the PUSH_PROMISE does not reference a stream; it
contains a Push ID. The Push ID uniquely identifies a server push contains a Push ID. The Push ID uniquely identifies a server push.
(see Section 4.2.6). This allows a server to fulfill promises in the This allows a server to fulfill promises in the order that best suits
order that best suits its needs. its needs.
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. A push stream is a server-initiated, conveyed on a push stream. A push stream is a server-initiated,
unidirectional stream. A push stream always begins with a header unidirectional stream. A push stream identifies the Push ID of the
(see Figure 1) that identifies the Push ID of the promise that it promise that it fulfills, encoded as a variable-length integer.
fulfills, encoded as a variable-length integer.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.9) 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
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
type HTTP_DUPLICATE_PUSH. The same Push ID can be used in multiple
PUSH_PROMISE frames (see Section 4.2.6).
After the push stream header, a push contains a response
(Section 3.2), with response headers, a response body (if any)
carried by DATA frames, then trailers (if any) carried by HEADERS
frames.
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,
a QUIC STOP_SENDING frame with an appropriate error code can be used a QUIC STOP_SENDING frame with an appropriate error code can be used
instead (e.g., HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see instead (e.g., HTTP_PUSH_REFUSED, HTTP_PUSH_ALREADY_IN_CACHE; see
Section 6). This asks the server not to transfer the data and Section 6). This asks the server not to transfer the data and
indicates that it will be discarded upon receipt. indicates that it will be discarded upon receipt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Push Stream Header
Push streams always begin with a header containing the Push ID. 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 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
PUSH_PROMISE frames (see Section 4.2.6).
After the header, a push stream contains a response (Section 3.2),
with response headers, a response body (if any) carried by DATA
frames, then trailers (if any) carried by HEADERS frames.
4. HTTP Framing Layer 4. HTTP Framing Layer
Frames are used on each stream. This section describes HTTP framing Frames are used on each stream. This section describes HTTP framing
in QUIC and highlights some differences from HTTP/2 framing. For in QUIC and highlights some differences from HTTP/2 framing. For
more detail on differences from HTTP/2, see Section 7.2. more detail on differences from HTTP/2, see Section 7.2.
4.1. Frame Layout 4.1. Frame Layout
All frames have the following format: All frames have the following format:
skipping to change at page 13, line 42 skipping to change at page 13, line 42
DATA frames (type=0x0) convey arbitrary, variable-length sequences of DATA frames (type=0x0) convey arbitrary, variable-length sequences of
octets associated with an HTTP request or response payload. octets associated with an HTTP request or response payload.
The DATA frame defines no flags. The DATA frame defines no flags.
DATA frames MUST be associated with an HTTP request or response. If DATA frames MUST be associated with an HTTP request or response. If
a DATA frame is received on either control stream, the recipient MUST a DATA frame is received on either control stream, the recipient MUST
respond with a connection error (Section 6) of type respond with a connection error (Section 6) of type
HTTP_WRONG_STREAM. HTTP_WRONG_STREAM.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Payload (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: DATA frame payload
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 QPACK. See [QPACK] for more details.
The HEADERS frame defines a single flag: The HEADERS frame defines a single flag:
BLOCKING (0x01): Indicates the stream might need to wait for BLOCKING (0x01): Indicates the stream might need to wait for
dependent headers before processing. If 0, the frame can be dependent headers before processing. If 0, the frame can be
processed immediately upon receipt. processed immediately upon receipt.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Block (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HEADERS frame payload
HEADERS frames can be sent on the Control Stream as well as on 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 request / push streams. The value of BLOCKING MUST be 0 for HEADERS
frames on the Control Stream, since they can only depend on previous frames on the Control Stream, since they can only depend on previous
HEADERS on the same stream. 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
skipping to change at page 14, line 48 skipping to change at page 15, line 15
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prioritized Request ID (i) | | Prioritized Request ID (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream Dependency ID (i) | | Stream Dependency ID (i) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight (8) | | Weight (8) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: PRIORITY frame payload Figure 5: PRIORITY frame payload
The PRIORITY frame payload has the following fields: The PRIORITY frame payload has the following fields:
Prioritized Request ID: A variable-length integer that identifies a Prioritized Request ID: A variable-length integer that identifies a
request. This contains the Stream ID of a request stream when the request. This contains the Stream ID of a request stream when the
PUSH_PRIORITIZED flag is clear, or a Push ID when the PUSH_PRIORITIZED flag is clear, or a Push ID when the
PUSH_PRIORITIZED flag is set. PUSH_PRIORITIZED flag is set.
Stream Dependency ID: A variable-length integer that identifies a Stream Dependency ID: A variable-length integer that identifies a
dependent request. This contains the Stream ID of a request dependent request. This contains the Stream ID of a request
skipping to change at page 16, line 31 skipping to change at page 16, line 46
has been created, sending CANCEL_PUSH has no effect on the state of has been created, sending CANCEL_PUSH has no effect on the state of
the push stream. A QUIC RST_STREAM frame SHOULD be used instead to the push stream. A QUIC RST_STREAM frame SHOULD be used instead to
cancel transmission of the server push response. cancel transmission of the server push response.
A CANCEL_PUSH frame is sent on the control stream. Sending a A CANCEL_PUSH frame is sent on the control stream. Sending a
CANCEL_PUSH frame on a stream other than the control stream MUST be CANCEL_PUSH frame on a stream other than the control stream MUST be
treated as a stream error of type HTTP_WRONG_STREAM. treated as a stream error of type HTTP_WRONG_STREAM.
The CANCEL_PUSH frame has no defined flags. The CANCEL_PUSH frame has no defined flags.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6: CANCEL_PUSH frame payload
The CANCEL_PUSH frame carries a Push ID encoded as a variable-length The CANCEL_PUSH frame carries a Push ID encoded as a variable-length
integer. The Push ID identifies the server push that is being integer. The Push ID identifies the server push that is being
cancelled (see Section 4.2.6). cancelled (see Section 4.2.6).
If the client receives a CANCEL_PUSH frame, that frame might identify If the client receives a CANCEL_PUSH frame, that frame might identify
a Push ID that has not yet been mentioned by a PUSH_PROMISE frame. a Push ID that has not yet been mentioned by a PUSH_PROMISE frame.
An endpoint MUST treat a CANCEL_PUSH frame which does not contain An endpoint MUST treat a CANCEL_PUSH frame which does not contain
exactly one properly-formatted variable-length integer as a exactly one properly-formatted variable-length integer as a
connection error of type HTTP_MALFORMED_FRAME. connection error of type HTTP_MALFORMED_FRAME.
skipping to change at page 17, line 31 skipping to change at page 18, line 13
length-prefixed binary value. length-prefixed binary value.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier (16) | Length (i) ... | Identifier (16) | Length (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Contents (?) ... | Contents (?) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: SETTINGS value format Figure 7: SETTINGS value format
A zero-length content indicates that the setting value is a Boolean A zero-length content indicates that the setting value is a Boolean
and true. False is indicated by the absence of the setting. and true. False is indicated by the absence of the setting.
Non-zero-length values MUST be compared against the remaining length Non-zero-length values MUST be compared against the remaining length
of the SETTINGS frame. Any value which purports to cross the end of of the SETTINGS frame. Any value which purports to cross the end of
the frame MUST cause the SETTINGS frame to be considered malformed the frame MUST cause the SETTINGS frame to be considered malformed
and trigger a connection error of type HTTP_MALFORMED_FRAME. and trigger a connection error of type HTTP_MALFORMED_FRAME.
An implementation MUST ignore the contents for any SETTINGS An implementation MUST ignore the contents for any SETTINGS
skipping to change at page 18, line 24 skipping to change at page 19, line 5
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. 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. Initial SETTINGS Values
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 MUST store the settings the server provided in the
servers: session being resumed and MUST comply with stored settings until the
server's current settings are received.
o SETTINGS_HEADER_TABLE_SIZE
o SETTINGS_MAX_HEADER_LIST_SIZE
Clients MUST comply with cached settings until the server's current
settings are received. If a client does not have cached values, it
SHOULD assume the following values:
o SETTINGS_HEADER_TABLE_SIZE: 0 octets
o SETTINGS_MAX_HEADER_LIST_SIZE: 16,384 octets
Servers MAY continue processing data from clients which exceed its Servers MAY continue processing data from clients which exceed its
current configuration during the initial flight. In this case, the current configuration during the initial flight. In this case, the
client MUST apply the new settings immediately upon receipt. client MUST apply the new settings immediately upon receipt.
If the connection is closed because these or other constraints were When a 1-RTT QUIC connection is being used, the client MUST NOT send
violated during the 0-RTT flight (e.g. with requests prior to receiving and processing the server's SETTINGS
HTTP_HPACK_DECOMPRESSION_FAILED), clients MAY establish a new frame.
connection and retry any 0-RTT requests using the settings sent by
the server on the closed connection. (This assumes that only
requests that are safe to retry are sent in 0-RTT.) If the
connection was closed before the SETTINGS frame was received, clients
SHOULD discard any cached values and use the defaults above on the
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 a single flag: defines a single flag:
BLOCKING (0x01): Indicates the stream might need to wait for BLOCKING (0x01): Indicates the stream might need to wait for
dependent headers before processing. If 0, the frame can be dependent headers before processing. If 0, the frame can be
processed immediately upon receipt. 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 8: 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: QCRAM-compressed request headers for the promised Header Block: QPACK-compressed request headers for the promised
response. See [QCRAM] for more details. response. See [QPACK] for more details.
A server MUST NOT use a Push ID that is larger than the client has A server MUST NOT use a Push ID that is larger than the client has
provided in a MAX_PUSH_ID frame (Section 4.2.9). 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
skipping to change at page 20, line 26 skipping to change at page 20, line 38
PUSH_PROMISE. PUSH_PROMISE.
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.
Stream ID for a client-initiated, bidirectional stream encoded as a
variable-length integer. A client MUST treat receipt of a GOAWAY 0 1 2 3
frame containing a Stream ID of any other type as a connection error 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
of type HTTP_MALFORMED_FRAME. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Stream ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: GOAWAY frame payload
The GOAWAY frame carries a QUIC Stream ID for a client-initiated,
bidirectional stream encoded as a variable-length integer. A client
MUST treat receipt of a GOAWAY frame containing a Stream ID of any
other type as a connection error 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.
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.
skipping to change at page 22, line 25 skipping to change at page 22, line 45
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. HEADER_ACK 4.2.8. HEADER_ACK
The HEADER_ACK frame (type=0x8) is used by header compression to The HEADER_ACK frame (type=0x8) is used by header compression to
ensure consistency. The frames are sent from the QCRAM decoder to ensure consistency. The frames are sent from the QPACK decoder to
the QCRAM encoder; that is, the server sends them to the client to the QPACK encoder; that is, the server sends them to the client to
acknowledge processing of the client's header blocks, and the client acknowledge processing of the client's header blocks, and the client
sends them to the server to acknowledge processing of the server's sends them to the server to acknowledge processing of the server's
header blocks. header blocks.
The HEADER_ACK frame is sent on the Control Stream when the QCRAM The HEADER_ACK frame is sent on the Control Stream when the QPACK
decoder has fully processed a header block. It is used by the peer's decoder has fully processed a header block. It is used by the peer's
QCRAM encoder to determine whether subsequent indexed representations QPACK encoder to determine whether subsequent indexed representations
that might reference that block are vulnerable to head-of-line that might reference that block are vulnerable to head-of-line
blocking, and to prevent eviction races. See [QCRAM] for more blocking, and to prevent eviction races. See [QPACK] for more
details on the use of this information. details on the use of this information.
The HEADER_ACK frame indicates the stream on which the header block The HEADER_ACK frame indicates the stream on which the header block
was processed by encoding the Stream ID as a variable-length integer. was processed by encoding the Stream ID as a variable-length integer.
The same Stream ID can be identified multiple times, as multiple The same Stream ID can be identified multiple times, as multiple
header-containing blocks can be sent on a single stream in the case header-containing blocks can be sent on a single stream in the case
of intermediate responses, trailers, pushed requests, etc. as well as of intermediate responses, trailers, pushed requests, etc. as well as
on the Control Streams. Since header frames on each stream are on the Control Streams. Since header frames on each stream are
received and processed in order, this gives the encoder precise received and processed in order, this gives the encoder precise
feedback on which header blocks within a stream have been fully feedback on which header blocks within a stream have been fully
skipping to change at page 23, line 39 skipping to change at page 24, line 7
HTTP_MALFORMED_FRAME. HTTP_MALFORMED_FRAME.
The maximum Push ID is unset when a connection is created, meaning The maximum Push ID is unset when a connection is created, meaning
that a server cannot push until it receives a MAX_PUSH_ID frame. A that a server cannot push until it receives a MAX_PUSH_ID frame. A
client that wishes to manage the number of promised server pushes can client that wishes to manage the number of promised server pushes can
increase the maximum Push ID by sending a MAX_PUSH_ID frame as the increase the maximum Push ID by sending a MAX_PUSH_ID frame as the
server fulfills or cancels server pushes. server fulfills or cancels server pushes.
The MAX_PUSH_ID frame has no defined flags. The MAX_PUSH_ID frame has no defined flags.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Push ID (i) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: MAX_PUSH_ID frame payload
The MAX_PUSH_ID frame carries a single variable-length integer that The MAX_PUSH_ID frame carries a single variable-length integer that
identifies the maximum value for a Push ID that the server can use identifies the maximum value for a Push ID that the server can use
(see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum (see Section 4.2.6). A MAX_PUSH_ID frame cannot reduce the maximum
Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than Push ID; receipt of a MAX_PUSH_ID that contains a smaller value than
previously received MUST be treated as a connection error of type previously received MUST be treated as a connection error of type
HTTP_MALFORMED_FRAME. HTTP_MALFORMED_FRAME.
A server MUST treat a MAX_PUSH_ID frame payload that does not contain A server MUST treat a MAX_PUSH_ID frame payload that does not contain
a single variable-length integer as a connection error of type a single variable-length integer as a connection error of type
HTTP_MALFORMED_FRAME. HTTP_MALFORMED_FRAME.
skipping to change at page 26, line 48 skipping to change at page 27, line 23
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 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/QUIC uses a modified version of HPACK, sync. As a result, HTTP/QUIC uses a modified version of HPACK,
described in [QCRAM]. described in [QPACK].
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
skipping to change at page 31, line 20 skipping to change at page 32, line 5
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 |
| | | | | | | |
| HEADER_ACK | 0x8 | {{frame-header-ack} | | HEADER_ACK | 0x8 | Section 4.2.8 |
| | | | | | | |
| Reserved | 0x9 | N/A | | Reserved | 0x9 | N/A |
| | | | | | | |
| MAX_PUSH_ID | 0xD | Section 4.2.9 | | 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 34, line 43 skipping to change at page 35, line 25
| 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 [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Compression for HTTP over QUIC", draft-ietf-quic-qcram-00 Header Compression for HTTP over QUIC", draft-ietf-quic-
(work in progress), March 2018. qpack-00 (work in progress), April 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-10 (work in progress), March 2018. transport-11 (work in progress), April 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 36, line 31 skipping to change at page 37, line 13
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-09 B.1. Since draft-ietf-quic-http-10
o Settings need to be remembered when attempting and accepting 0-RTT
(#1157, #1207)
B.2. 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.2. Since draft-ietf-quic-http-08 B.3. Since draft-ietf-quic-http-08
o Clarified connection coalescing rules (#940, #1024) o Clarified connection coalescing rules (#940, #1024)
B.3. Since draft-ietf-quic-http-07 B.4. 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.4. Since draft-ietf-quic-http-06 B.5. 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.5. Since draft-ietf-quic-http-05 B.6. 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.6. Since draft-ietf-quic-http-04 B.7. 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.7. Since draft-ietf-quic-http-03 B.8. Since draft-ietf-quic-http-03
None. None.
B.8. Since draft-ietf-quic-http-02 B.9. Since draft-ietf-quic-http-02
o Track changes in transport draft o Track changes in transport draft
B.9. Since draft-ietf-quic-http-01 B.10. 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)
skipping to change at page 38, line 15 skipping to change at page 39, line 4
o Alt-Svc parameter changed from "v" to "quic"; format updated o Alt-Svc parameter changed from "v" to "quic"; format updated
(#229) (#229)
o Closing the connection control stream or any message control o Closing the connection control stream or any message control
stream is a fatal error (#176) stream is a fatal error (#176)
o HPACK Sequence counter can wrap (#173) o HPACK Sequence counter can wrap (#173)
o 0-RTT guidance added o 0-RTT guidance added
o Guide to differences from HTTP/2 and porting HTTP/2 extensions o Guide to differences from HTTP/2 and porting HTTP/2 extensions
added (#127,#242) added (#127,#242)
B.10. Since draft-ietf-quic-http-00 B.11. 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.11. Since draft-shade-quic-http2-mapping-00 B.12. 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. 53 change blocks. 
152 lines changed or deleted 184 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/