draft-ietf-quic-http-11.txt   draft-ietf-quic-http-12.txt 
QUIC M. Bishop, Ed. QUIC M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track April 17, 2018 Intended status: Standards Track May 22, 2018
Expires: October 19, 2018 Expires: November 23, 2018
Hypertext Transfer Protocol (HTTP) over QUIC Hypertext Transfer Protocol (HTTP) over QUIC
draft-ietf-quic-http-11 draft-ietf-quic-http-12
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 October 19, 2018. This Internet-Draft will expire on November 23, 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 39 skipping to change at page 2, line 39
2.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 6 2.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 6
3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7
3.1. Control Streams . . . . . . . . . . . . . . . . . . . . . 8 3.1. Control Streams . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . . . . . . . . . . . . . . . . . . 13
4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13
4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . 17 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. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 22
4.2.9. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 23 5. Connection Management . . . . . . . . . . . . . . . . . . . . 23
5. Connection Management . . . . . . . . . . . . . . . . . . . . 24
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 24 6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 25 6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 24
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 . . . . . . . . . . . . . . . . . . . . 25
7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 26 7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 27
7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 28 7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 28
7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 29 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Security Considerations . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9.1. Registration of HTTP/QUIC Identification String . . . . . 29
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 35
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 36
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 37 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 36
B.1. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 37 B.1. Since draft-ietf-quic-http-11 . . . . . . . . . . . . . . 36
B.2. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 37 B.2. Since draft-ietf-quic-http-10 . . . . . . . . . . . . . . 36
B.3. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 37 B.3. Since draft-ietf-quic-http-09 . . . . . . . . . . . . . . 36
B.4. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 37 B.4. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 36
B.5. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 37 B.5. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 36
B.6. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 37 B.6. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 37
B.7. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 38 B.7. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 37
B.8. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 38 B.8. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 37
B.9. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 38 B.9. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 37
B.10. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 38 B.10. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 37
B.11. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 39 B.11. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 37
B.12. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 39 B.12. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 38
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 39 B.13. 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 7, line 23 skipping to change at page 7, line 23
no guarantees about order of delivery with regard to bytes on other no guarantees about order of delivery with regard to bytes on other
streams. On the wire, data is framed into QUIC STREAM frames, but streams. On the wire, data is framed into QUIC STREAM frames, but
this framing is invisible to the HTTP framing layer. A QUIC receiver this framing is invisible to the HTTP framing layer. A QUIC receiver
buffers and orders received STREAM frames, exposing the data buffers and orders received STREAM frames, exposing the data
contained within as a reliable byte stream to the application. contained within as a reliable byte stream to the application.
QUIC reserves the first client-initiated, bidirectional stream QUIC reserves the first client-initiated, bidirectional stream
(Stream 0) for cryptographic operations. HTTP over QUIC reserves the (Stream 0) for cryptographic operations. HTTP over QUIC reserves the
first unidirectional stream sent by either peer (Streams 2 and 3) for first unidirectional stream sent by either peer (Streams 2 and 3) for
sending and receiving HTTP control frames. This pair of sending and receiving HTTP control frames. This pair of
unidirectional streams is analogous to HTTP/2's Stream 0. The data unidirectional streams is analogous to HTTP/2's Stream 0. HTTP over
sent on these streams is critical to the HTTP connection. If either QUIC also reserves the second and third unidirectional streams for
control stream is closed for any reason, this MUST be treated as a each peer's QPACK encoder and decoder. The client's QPACK encoder
connection error of type QUIC_CLOSED_CRITICAL_STREAM. uses stream 6 and decoder uses stream 10. The server's encoder and
decoder use streams 7 and 11, respectively. The data sent on these
streams is critical to the HTTP connection. If any control stream is
closed for any reason, this MUST be treated as a connection error of
type QUIC_CLOSED_CRITICAL_STREAM.
When HTTP headers and data are sent over QUIC, the QUIC layer handles When HTTP headers and data are sent over QUIC, the QUIC layer handles
most of the stream management. most of the stream management.
An HTTP request/response consumes a single client-initiated, An HTTP request/response consumes a single client-initiated,
bidirectional stream. A bidirectional stream ensures that the bidirectional stream. A bidirectional stream ensures that the
response can be readily correlated with the request. This means that response can be readily correlated with the request. This means that
the client's first request occurs on QUIC stream 4, with subsequent the client's first request occurs on QUIC stream 4, with subsequent
requests on stream 8, 12, and so on. requests on stream 8, 12, and so on.
skipping to change at page 11, line 29 skipping to change at page 11, line 36
(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 in a similar manner to [RFC7540], but HTTP/QUIC supports server push in a similar manner to [RFC7540], but
uses different mechanisms. During connection establishment, the uses different mechanisms. During connection establishment, the
client enables server push by sending a MAX_PUSH_ID frame (see client enables server push by sending a MAX_PUSH_ID frame (see
Section 4.2.9). A server cannot use server push until it receives a Section 4.2.8). A server cannot use server push until it receives a
MAX_PUSH_ID frame. 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 (see Section 4.2.6) that includes sending a PUSH_PROMISE frame (see Section 4.2.6) that includes
request headers for the promised request. Promised requests MUST request headers for the promised request. Promised requests MUST
conform to the requirements in Section 8.2 of [RFC7540]. conform to the requirements in Section 8.2 of [RFC7540].
The PUSH_PROMISE frame is sent on the client-initiated, bidirectional The PUSH_PROMISE frame is sent on the client-initiated, bidirectional
stream that carried the request that generated the push. This allows stream that carried the request that generated the push. This allows
the server push to be associated with a request. Ordering of a the server push to be associated with a request. Ordering of a
skipping to change at page 11, line 45 skipping to change at page 12, line 4
conform to the requirements in Section 8.2 of [RFC7540]. conform to the requirements in Section 8.2 of [RFC7540].
The PUSH_PROMISE frame is sent on the client-initiated, bidirectional The PUSH_PROMISE frame is sent on the client-initiated, bidirectional
stream that carried the request that generated the push. This allows stream that carried the request that generated the push. This allows
the server push to be associated with a request. Ordering of a the server push to be associated with a request. Ordering of a
PUSH_PROMISE in relation to certain parts of the response is PUSH_PROMISE in relation to certain parts of the response is
important (see Section 8.2.1 of [RFC7540]). 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.
This allows a server to fulfill promises in the order that best suits This allows a server to fulfill promises in the 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 identifies the Push ID of the unidirectional stream. A push stream identifies the Push ID of the
promise that it fulfills, encoded as a variable-length integer. promise that it fulfills, encoded as a variable-length integer.
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.8) 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.
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.
skipping to change at page 14, line 10 skipping to change at page 14, line 14
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 QPACK. See [QPACK] for more details. compressed using QPACK. See [QPACK] for more details.
The HEADERS frame defines a single flag: The HEADERS frame defines no flags.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Header Block (*) ... | Header Block (*) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: HEADERS frame payload Figure 4: HEADERS frame payload
HEADERS frames can be sent on the Control Stream as well as on HEADERS frames can only be sent on request / push streams.
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 18, line 49 skipping to change at page 18, line 49
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. 2^30 - 1. The default value is 4,096 bytes.
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. The default value is unlimited.
SETTINGS_QPACK_BLOCKED_STREAMS (0x7): An integer with a maximum
value of 2^16 - 1. The default value is 100.
4.2.5.3. Initial SETTINGS Values 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 MUST store the settings the server provided in the frame. Clients MUST store the settings the server provided in the
session being resumed and MUST comply with stored settings until the session being resumed and MUST comply with stored settings until the
server's current settings are received. server's current settings are received.
Servers MAY continue processing data from clients which exceed its Servers MAY continue processing data from clients which exceed its
skipping to change at page 19, line 25 skipping to change at page 19, line 28
client MUST apply the new settings immediately upon receipt. client MUST apply the new settings immediately upon receipt.
When a 1-RTT QUIC connection is being used, the client MUST NOT send When a 1-RTT QUIC connection is being used, the client MUST NOT send
requests prior to receiving and processing the server's SETTINGS requests prior to receiving and processing the server's SETTINGS
frame. frame.
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 no flags.
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 8: PUSH_PROMISE frame payload Figure 8: PUSH_PROMISE frame payload
skipping to change at page 19, line 52 skipping to change at page 19, line 51
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: QPACK-compressed request headers for the promised Header Block: QPACK-compressed request headers for the promised
response. See [QPACK] 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.8). 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 22, line 42 skipping to change at page 22, line 42
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. HEADER_ACK 4.2.8. MAX_PUSH_ID
The HEADER_ACK frame (type=0x8) is used by header compression to
ensure consistency. The frames are sent from the QPACK decoder 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
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 QPACK
decoder has fully processed a header block. It is used by the peer's
QPACK 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 [QPACK] 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 28 skipping to change at page 24, line 40
HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the HTTP_INTERNAL_ERROR (0x03): An internal error has occurred in the
HTTP stack. HTTP stack.
HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push HTTP_PUSH_ALREADY_IN_CACHE (0x04): The server has attempted to push
content which the client has cached. content which the client has cached.
HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the HTTP_REQUEST_CANCELLED (0x05): The client no longer needs the
requested data. requested data.
HTTP_HPACK_DECOMPRESSION_FAILED (0x06): HPACK failed to decompress a HTTP_QPACK_DECOMPRESSION_FAILED (0x06): QPACK failed to decompress a
frame and cannot continue. frame and cannot continue.
HTTP_CONNECT_ERROR (0x07): The connection established in response to HTTP_CONNECT_ERROR (0x07): The connection established in response to
a CONNECT request was reset or abnormally closed. a CONNECT request was reset or abnormally closed.
HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is HTTP_EXCESSIVE_LOAD (0x08): The endpoint detected that its peer is
exhibiting a behavior that might be generating excessive load. exhibiting a behavior that might be generating excessive load.
HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be HTTP_VERSION_FALLBACK (0x09): The requested operation cannot be
served over HTTP/QUIC. The peer should retry over HTTP/2. served over HTTP/QUIC. The peer should retry over HTTP/2.
skipping to change at page 29, line 51 skipping to change at page 29, line 12
control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA control. Would provoke a QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA
from the QUIC layer. from the QUIC layer.
SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of SETTINGS_TIMEOUT (0x4): Not applicable, since no acknowledgement of
SETTINGS is defined. SETTINGS is defined.
STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream STREAM_CLOSED (0x5): Not applicable, since QUIC handles stream
management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION management. Would provoke a QUIC_STREAM_DATA_AFTER_TERMINATION
from the QUIC layer. from the QUIC layer.
FRAME_SIZE_ERROR (0x6) No single mapping. See new error codes FRAME_SIZE_ERROR (0x6): No single mapping. See new error codes
defined in Section 6.1. defined in Section 6.1.
REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream REFUSED_STREAM (0x7): Not applicable, since QUIC handles stream
management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the management. Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the
QUIC layer. QUIC layer.
CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1. CANCEL (0x8): HTTP_REQUEST_CANCELLED in Section 6.1.
COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in COMPRESSION_ERROR (0x9): HTTP_HPACK_DECOMPRESSION_FAILED in
Section 6.1. Section 6.1.
skipping to change at page 30, line 29 skipping to change at page 29, line 39
provide sufficient security on all connections. provide sufficient security on all connections.
HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1. HTTP_1_1_REQUIRED (0xd): HTTP_VERSION_FALLBACK in Section 6.1.
Error codes need to be defined for HTTP/2 and HTTP/QUIC separately. Error codes need to be defined for HTTP/2 and HTTP/QUIC separately.
See Section 9.5. See Section 9.5.
8. Security Considerations 8. Security Considerations
The security considerations of HTTP over QUIC should be comparable to The security considerations of HTTP over QUIC should be comparable to
those of HTTP/2. those of HTTP/2 with TLS.
The modified SETTINGS format contains nested length elements, which The modified SETTINGS format contains nested length elements, which
could pose a security risk to an uncautious implementer. A SETTINGS could pose a security risk to an uncautious implementer. A SETTINGS
frame parser MUST ensure that the length of the frame exactly matches frame parser MUST ensure that the length of the frame exactly matches
the length of the settings it contains. the length of the settings it contains.
9. IANA Considerations 9. IANA Considerations
9.1. Registration of HTTP/QUIC Identification String 9.1. Registration of HTTP/QUIC Identification String
skipping to change at page 32, line 24 skipping to change at page 31, line 24
| 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 | Section 4.2.8 | | Reserved | 0x8 | N/A |
| | | | | | | |
| Reserved | 0x9 | N/A | | Reserved | 0x9 | N/A |
| | | | | | | |
| MAX_PUSH_ID | 0xD | Section 4.2.9 | | MAX_PUSH_ID | 0xD | Section 4.2.8 |
+--------------+------+---------------+ +--------------+------+---------------+
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
skipping to change at page 33, line 10 skipping to change at page 32, line 10
Name: A symbolic name for the setting. Specifying a setting name is Name: A symbolic name for the setting. Specifying a setting name is
optional. optional.
Code: The 16-bit code assigned to the setting. Code: The 16-bit code assigned to the setting.
Specification: An optional reference to a specification that Specification: An optional reference to a specification that
describes the use of the setting. describes the use of the setting.
The entries in the following table are registered by this document. The entries in the following table are registered by this document.
+----------------------+------+-----------------+ +-----------------------+------+-----------------+
| Setting Name | Code | Specification | | Setting Name | Code | Specification |
+----------------------+------+-----------------+ +-----------------------+------+-----------------+
| HEADER_TABLE_SIZE | 0x1 | Section 4.2.5.2 | | HEADER_TABLE_SIZE | 0x1 | Section 4.2.5.2 |
| | | | | | | |
| Reserved | 0x2 | N/A | | Reserved | 0x2 | N/A |
| | | | | | | |
| Reserved | 0x3 | N/A | | Reserved | 0x3 | N/A |
| | | | | | | |
| Reserved | 0x4 | N/A | | Reserved | 0x4 | N/A |
| | | | | | | |
| Reserved | 0x5 | N/A | | Reserved | 0x5 | N/A |
| | | | | | | |
| MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.2 | | MAX_HEADER_LIST_SIZE | 0x6 | Section 4.2.5.2 |
+----------------------+------+-----------------+ | | | |
| QPACK_BLOCKED_STREAMS | 0x7 | Section 4.2.5.2 |
+-----------------------+------+-----------------+
9.5. Error Codes 9.5. Error Codes
This document establishes a registry for HTTP/QUIC error codes. The This document establishes a registry for HTTP/QUIC error codes. The
"HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/ "HTTP/QUIC Error Code" registry manages a 16-bit space. The "HTTP/
QUIC Error Code" registry operates under the "Expert Review" policy QUIC Error Code" registry operates under the "Expert Review" policy
[RFC8126]. [RFC8126].
Registrations for error codes are required to include a description Registrations for error codes are required to include a description
of the error code. An expert reviewer is advised to examine new of the error code. An expert reviewer is advised to examine new
skipping to change at page 35, line 27 skipping to change at page 34, line 29
| | | formatting | | | | | formatting | |
| | | or use | | | | | or use | |
+----------------------------+--------+------------+----------------+ +----------------------------+--------+------------+----------------+
10. References 10. References
10.1. Normative References 10.1. Normative References
[QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK: [QPACK] Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
Header Compression for HTTP over QUIC", draft-ietf-quic- Header Compression for HTTP over QUIC", draft-ietf-quic-
qpack-00 (work in progress), April 2018. qpack-00 (work in progress), May 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-11 (work in progress), April 2018. transport-11 (work in progress), May 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 37, line 13 skipping to change at page 36, line 18
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-10 B.1. Since draft-ietf-quic-http-11
o Moved QPACK table updates and acknowledgments to dedicated streams
(#1121, #1122, #1238)
B.2. Since draft-ietf-quic-http-10
o Settings need to be remembered when attempting and accepting 0-RTT o Settings need to be remembered when attempting and accepting 0-RTT
(#1157, #1207) (#1157, #1207)
B.2. Since draft-ietf-quic-http-09 B.3. 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.3. Since draft-ietf-quic-http-08 B.4. Since draft-ietf-quic-http-08
o Clarified connection coalescing rules (#940, #1024) o Clarified connection coalescing rules (#940, #1024)
B.4. Since draft-ietf-quic-http-07 B.5. 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.5. Since draft-ietf-quic-http-06 B.6. 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.6. Since draft-ietf-quic-http-05 B.7. 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.7. Since draft-ietf-quic-http-04 B.8. 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.8. Since draft-ietf-quic-http-03 B.9. Since draft-ietf-quic-http-03
None. None.
B.9. Since draft-ietf-quic-http-02 B.10. Since draft-ietf-quic-http-02
o Track changes in transport draft o Track changes in transport draft
B.10. Since draft-ietf-quic-http-01 B.11. 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 39, line 4 skipping to change at page 38, line 15
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.11. Since draft-ietf-quic-http-00 B.12. 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.12. Since draft-shade-quic-http2-mapping-00 B.13. 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. 40 change blocks. 
134 lines changed or deleted 102 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/