draft-ietf-quic-http-09.txt   draft-ietf-quic-http-latest.txt 
QUIC Working Group M. Bishop, Ed. QUIC Working Group M. Bishop, Ed.
Internet-Draft Akamai Internet-Draft Akamai
Intended status: Standards Track January 28, 2018 Intended status: Standards Track February 19, 2018
Expires: August 1, 2018 Expires: August 23, 2018
Hypertext Transfer Protocol (HTTP) over QUIC Hypertext Transfer Protocol (HTTP) over QUIC
draft-ietf-quic-http-09 draft-ietf-quic-http-latest
Abstract Abstract
The QUIC transport protocol has several features that are desirable The QUIC transport protocol has several features that are desirable
in a transport for HTTP, such as stream multiplexing, per-stream flow in a transport for HTTP, such as stream multiplexing, per-stream flow
control, and low-latency connection establishment. This document control, and low-latency connection establishment. This document
describes a mapping of HTTP semantics over QUIC. This document also describes a mapping of HTTP semantics over QUIC. This document also
identifies HTTP/2 features that are subsumed by QUIC, and describes identifies HTTP/2 features that are subsumed by QUIC, and describes
how HTTP/2 extensions can be ported to QUIC. how HTTP/2 extensions can be ported to QUIC.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 1, 2018. This Internet-Draft will expire on August 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 28 skipping to change at page 2, line 28
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3
2. Connection Setup and Management . . . . . . . . . . . . . . . 4 2. Connection Setup and Management . . . . . . . . . . . . . . . 4
2.1. Discovering an HTTP/QUIC Endpoint . . . . . . . . . . . . 4 2.1. Discovering an HTTP/QUIC Endpoint . . . . . . . . . . . . 4
2.1.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 4 2.1.1. QUIC Version Hints . . . . . . . . . . . . . . . . . 4
2.2. Connection Establishment . . . . . . . . . . . . . . . . 5 2.2. Connection Establishment . . . . . . . . . . . . . . . . 5
2.2.1. Draft Version Identification . . . . . . . . . . . . 5 2.2.1. Draft Version Identification . . . . . . . . . . . . 6
2.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 6 2.3. Connection Reuse . . . . . . . . . . . . . . . . . . . . 6
3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 6 3. Stream Mapping and Usage . . . . . . . . . . . . . . . . . . 7
3.1. Control Streams . . . . . . . . . . . . . . . . . . . . . 7 3.1. Control Streams . . . . . . . . . . . . . . . . . . . . . 8
3.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 7 3.2. HTTP Message Exchanges . . . . . . . . . . . . . . . . . 8
3.2.1. Header Compression . . . . . . . . . . . . . . . . . 9 3.2.1. Header Compression . . . . . . . . . . . . . . . . . 9
3.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 9 3.2.2. The CONNECT Method . . . . . . . . . . . . . . . . . 9
3.3. Request Prioritization . . . . . . . . . . . . . . . . . 10 3.2.3. Request Cancellation . . . . . . . . . . . . . . . . 10
3.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 10 3.3. Request Prioritization . . . . . . . . . . . . . . . . . 11
4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 11 3.4. Server Push . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 12 4. HTTP Framing Layer . . . . . . . . . . . . . . . . . . . . . 12
4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 12 4.1. Frame Layout . . . . . . . . . . . . . . . . . . . . . . 13
4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Frame Definitions . . . . . . . . . . . . . . . . . . . . 13
4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 13 4.2.1. DATA . . . . . . . . . . . . . . . . . . . . . . . . 13
4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 13 4.2.2. HEADERS . . . . . . . . . . . . . . . . . . . . . . . 14
4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 15 4.2.3. PRIORITY . . . . . . . . . . . . . . . . . . . . . . 14
4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 15 4.2.4. CANCEL_PUSH . . . . . . . . . . . . . . . . . . . . . 16
4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 18 4.2.5. SETTINGS . . . . . . . . . . . . . . . . . . . . . . 16
4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.6. PUSH_PROMISE . . . . . . . . . . . . . . . . . . . . 19
4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 21 4.2.7. GOAWAY . . . . . . . . . . . . . . . . . . . . . . . 20
5. Connection Management . . . . . . . . . . . . . . . . . . . . 22 4.2.8. MAX_PUSH_ID . . . . . . . . . . . . . . . . . . . . . 22
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 22 5. Connection Management . . . . . . . . . . . . . . . . . . . . 23
6. Error Handling . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 23 6.1. HTTP/QUIC Error Codes . . . . . . . . . . . . . . . . . . 23
7. Considerations for Transitioning from HTTP/2 . . . . . . . . 24 7. Considerations for Transitioning from HTTP/2 . . . . . . . . 24
7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Streams . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 24 7.2. HTTP Frame Types . . . . . . . . . . . . . . . . . . . . 25
7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 26 7.3. HTTP/2 SETTINGS Parameters . . . . . . . . . . . . . . . 27
7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 27 7.4. HTTP/2 Error Codes . . . . . . . . . . . . . . . . . . . 27
8. Security Considerations . . . . . . . . . . . . . . . . . . . 28 8. Security Considerations . . . . . . . . . . . . . . . . . . . 29
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29
9.1. Registration of HTTP/QUIC Identification String . . . . . 28 9.1. Registration of HTTP/QUIC Identification String . . . . . 29
9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 28 9.2. Registration of QUIC Version Hint Alt-Svc Parameter . . . 29
9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 29 9.3. Frame Types . . . . . . . . . . . . . . . . . . . . . . . 29
9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 30 9.4. Settings Parameters . . . . . . . . . . . . . . . . . . . 30
9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 31 9.5. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 31
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.1. Normative References . . . . . . . . . . . . . . . . . . 33 10.1. Normative References . . . . . . . . . . . . . . . . . . 33
10.2. Informative References . . . . . . . . . . . . . . . . . 34 10.2. Informative References . . . . . . . . . . . . . . . . . 34
10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 35
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 35
B.1. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 35 B.1. Since draft-ietf-quic-http-08 . . . . . . . . . . . . . . 35
B.2. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 35 B.2. Since draft-ietf-quic-http-07 . . . . . . . . . . . . . . 35
B.3. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 35 B.3. Since draft-ietf-quic-http-06 . . . . . . . . . . . . . . 35
B.4. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 35 B.4. Since draft-ietf-quic-http-05 . . . . . . . . . . . . . . 36
B.5. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 35 B.5. Since draft-ietf-quic-http-04 . . . . . . . . . . . . . . 36
B.6. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 36 B.6. Since draft-ietf-quic-http-03 . . . . . . . . . . . . . . 36
B.7. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 36 B.7. Since draft-ietf-quic-http-02 . . . . . . . . . . . . . . 36
B.8. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 36 B.8. Since draft-ietf-quic-http-01 . . . . . . . . . . . . . . 36
B.9. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 36 B.9. Since draft-ietf-quic-http-00 . . . . . . . . . . . . . . 37
B.10. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 37 B.10. Since draft-shade-quic-http2-mapping-00 . . . . . . . . . 37
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 37
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
skipping to change at page 4, line 50 skipping to change at page 5, line 5
Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the Servers MAY serve HTTP/QUIC on any UDP port. Servers MUST use the
same port across all IP addresses that serve a single domain, and same port across all IP addresses that serve a single domain, and
SHOULD NOT change this port. SHOULD NOT change this port.
2.1.1. QUIC Version Hints 2.1.1. QUIC Version Hints
This document defines the "quic" parameter for Alt-Svc, which MAY be This document defines the "quic" parameter for Alt-Svc, which MAY be
used to provide version-negotiation hints to HTTP/QUIC clients. QUIC used to provide version-negotiation hints to HTTP/QUIC clients. QUIC
versions are four-octet sequences with no additional constraints on versions are four-octet sequences with no additional constraints on
format. Syntax: format. Leading zeros SHOULD be omitted for brevity.
quic = version-number
version-number = 1*8HEXDIG; hex-encoded QUIC version
Leading zeros SHOULD be omitted for brevity. When multiple versions Syntax:
are supported, the "quic" parameter MAY be repeated multiple times in
a single Alt-Svc entry. For example, if a server supported both
version 0x00000001 and the version rendered in ASCII as "Q034", it
could specify the following header:
Alt-Svc: hq=":49288";quic=1;quic=51303334 quic = DQUOTE version-number [ "," version-number ] * DQUOTE
version-number = 1*8HEXDIG; hex-encoded QUIC version
Where multiple versions are listed, the order of the values reflects Where multiple versions are listed, the order of the values reflects
the server's preference (with the first value being the most the server's preference (with the first value being the most
preferred version). Origins SHOULD list only versions which are preferred version). Reserved versions MAY be listed, but unreserved
supported by the alternative, but MAY omit supported versions for any versions which are not supported by the alternative SHOULD NOT be
present in the list. Origins MAY omit supported versions for any
reason. reason.
Clients MUST ignore any included versions which they do not support.
The "quic" parameter MUST NOT occur more than once; clients SHOULD
process only the first occurrence.
For example, suppose a server supported both version 0x00000001 and
the version rendered in ASCII as "Q034". If it opted to include the
reserved versions (from Section 4 of [QUIC-TRANSPORT]) 0x0 and
0x1abadaba, it could specify the following header:
Alt-Svc: hq=":49288";quic="1,1abadaba,51303334,0"
A client acting on this header would drop the reserved versions
(because it does not support them), then attempt to connect to the
alternative using the first version in the list which it does
support.
2.2. Connection Establishment 2.2. Connection Establishment
HTTP/QUIC relies on QUIC as the underlying transport. The QUIC HTTP/QUIC relies on QUIC as the underlying transport. The QUIC
version being used MUST use TLS version 1.3 or greater as its version being used MUST use TLS version 1.3 or greater as its
handshake protocol. The Server Name Indication (SNI) extension handshake protocol. The Server Name Indication (SNI) extension
[RFC6066] MUST be included in the TLS handshake. [RFC6066] MUST be included in the TLS handshake.
QUIC connections are established as described in [QUIC-TRANSPORT]. QUIC connections are established as described in [QUIC-TRANSPORT].
During connection establishment, HTTP/QUIC support is indicated by During connection establishment, HTTP/QUIC support is indicated by
selecting the ALPN token "hq" in the TLS handshake. Support for selecting the ALPN token "hq" in the TLS handshake. Support for
skipping to change at page 10, line 17 skipping to change at page 10, line 35
so clients SHOULD NOT cause send a STREAM frame with a FIN bit for so clients SHOULD NOT cause send a STREAM frame with a FIN bit for
connections on which they are still expecting data. connections on which they are still expecting data.
A TCP connection error is signaled with RST_STREAM. A proxy treats A TCP connection error is signaled with RST_STREAM. A proxy treats
any error in the TCP connection, which includes receiving a TCP any error in the TCP connection, which includes receiving a TCP
segment with the RST bit set, as a stream error of type segment with the RST bit set, as a stream error of type
HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send HTTP_CONNECT_ERROR (Section 6.1). Correspondingly, a proxy MUST send
a TCP segment with the RST bit set if it detects an error with the a TCP segment with the RST bit set if it detects an error with the
stream or the QUIC connection. stream or the QUIC connection.
3.2.3. Request Cancellation
Either client or server can cancel requests by closing the stream
(QUIC RST_STREAM or STOP_SENDING frames, as appropriate) with an
error type of HTTP_REQUEST_CANCELLED (Section 6.1). When the client
cancels a request or response, it indicates that the response is no
longer of interest.
When the server cancels either direction of the request stream using
HTTP_REQUEST_CANCELLED, it indicates that no application processing
was performed. The client can treat requests cancelled by the server
as though they had never been sent at all, thereby allowing them to
be retried later on a new connection. Servers MUST NOT use the
HTTP_REQUEST_CANCELLED status for requests which were partially or
fully processed.
Note: In this context, "processed" means that some data from the
stream was passed to some higher layer of software that might have
taken some action as a result.
If a stream is cancelled after receiving a complete response, the
client MAY ignore the cancellation and use the response. However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used. Automatically retrying such requests is
not possible, unless this is otherwise permitted (e.g., idempotent
actions like GET, PUT, or DELETE).
3.3. Request Prioritization 3.3. Request Prioritization
HTTP/QUIC uses the priority scheme described in [RFC7540], HTTP/QUIC uses the priority scheme described in [RFC7540],
Section 5.3. In this priority scheme, a given request can be Section 5.3. In this priority scheme, a given request can be
designated as dependent upon another request, which expresses the designated as dependent upon another request, which expresses the
preference that the latter stream (the "parent" request) be allocated preference that the latter stream (the "parent" request) be allocated
resources before the former stream (the "dependent" request). Taken resources before the former stream (the "dependent" request). Taken
together, the dependencies across all requests in a connection form a together, the dependencies across all requests in a connection form a
dependency tree. The structure of the dependency tree changes as dependency tree. The structure of the dependency tree changes as
PRIORITY frames add, remove, or change the dependency links between PRIORITY frames add, remove, or change the dependency links between
skipping to change at page 19, line 25 skipping to change at page 20, line 25
4.2.7. GOAWAY 4.2.7. GOAWAY
The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of The GOAWAY frame (type=0x7) is used to initiate graceful shutdown of
a connection by a server. GOAWAY allows a server to stop accepting a connection by a server. GOAWAY allows a server to stop accepting
new requests while still finishing processing of previously received new requests while still finishing processing of previously received
requests. This enables administrative actions, like server requests. This enables administrative actions, like server
maintenance. GOAWAY by itself does not close a connection. maintenance. GOAWAY by itself does not close a connection.
The GOAWAY frame does not define any flags, and the payload is a QUIC The GOAWAY frame does not define any flags, and the payload is a QUIC
Stream ID for a client-initiated, bidirectional stream encoded as a Stream ID for a client-initiated, bidirectional stream encoded as a
variable-length integer. variable-length integer. A client MUST treat receipt of a GOAWAY
frame containing a Stream ID of any other type as a connection error
of type HTTP_MALFORMED_FRAME.
Clients do not need to send GOAWAY to initiate a graceful shutdown; Clients do not need to send GOAWAY to initiate a graceful shutdown;
they simply stop making new requests. A server MUST treat receipt of they simply stop making new requests. A server MUST treat receipt of
a GOAWAY frame as a connection error (Section 6) of type a GOAWAY frame as a connection error (Section 6) of type
HTTP_UNEXPECTED_GOAWAY. HTTP_UNEXPECTED_GOAWAY.
A client MUST treat receipt of a GOAWAY frame containing a Stream ID
of any other type as a connection error of type HTTP_MALFORMED_FRAME.
The GOAWAY frame applies to the connection, not a specific stream. The GOAWAY frame applies to the connection, not a specific stream.
An endpoint MUST treat a GOAWAY frame on a stream other than the An endpoint MUST treat a GOAWAY frame on a stream other than the
control stream as a connection error (Section 6) of type control stream as a connection error (Section 6) of type
HTTP_WRONG_STREAM. HTTP_WRONG_STREAM.
New client requests might already have been sent before the client New client requests might already have been sent before the client
receives the server's GOAWAY frame. The GOAWAY frame contains the receives the server's GOAWAY frame. The GOAWAY frame contains the
Stream ID of the last client-initiated request that was or might be Stream ID of the last client-initiated request that was or might be
processed in this connection, which enables client and server to processed in this connection, which enables client and server to
agree on which requests were accepted prior to the connection agree on which requests were accepted prior to the connection
shutdown. This identifier MAY be lower than the stream limit shutdown. This identifier MAY be lower than the stream limit
identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no identified by a QUIC MAX_STREAM_ID frame, and MAY be zero if no
requests were processed. Servers SHOULD NOT increase the requests were processed. Servers SHOULD NOT increase the
MAX_STREAM_ID limit after sending a GOAWAY frame. MAX_STREAM_ID limit after sending a GOAWAY frame.
Note: In this context, "processed" means that some data from the Once sent, the server MUST cancel requests sent on streams with an
stream was passed to some higher layer of software that might have
taken some action as a result.
Once sent, the server will refuse requests sent on streams with an
identifier higher than the included last Stream ID. Clients MUST NOT identifier higher than the included last Stream ID. Clients MUST NOT
send new requests on the connection after receiving GOAWAY, although send new requests on the connection after receiving GOAWAY, although
requests might already be in transit. A new connection can be requests might already be in transit. A new connection can be
established for new requests. established for new requests.
If the client has sent requests on streams with a higher Stream ID If the client has sent requests on streams with a higher Stream ID
than indicated in the GOAWAY frame, those requests were not and will than indicated in the GOAWAY frame, those requests are considered
not be processed. Endpoints SHOULD reset any streams above this ID cancelled (Section 3.2.3). Clients SHOULD reset any streams above
with the error code HTTP_REQUEST_CANCELLED. Servers MAY also reset this ID with the error code HTTP_REQUEST_CANCELLED. Servers MAY also
streams below the indicated ID with HTTP_REQUEST_CANCELLED if the cancel requests on streams below the indicated ID if these requests
associated requests were not processed. Servers MUST NOT use the were not processed.
HTTP_REQUEST_CANCELLED status for requests which were partially or
fully processed.
The client can treat requests cancelled by the server as though they
had never been sent at all, thereby allowing them to be retried later
on a new connection. If a stream is cancelled after receiving a
complete response, the client MAY ignore the cancellation and use the
response. However, if a stream is cancelled after receiving a
partial response, the response SHOULD NOT be used. Automatically
retrying such requests is not possible, unless this is otherwise
permitted (e.g., idempotent actions like GET, PUT, or DELETE).
Requests on Stream IDs less than or equal to the Stream ID in the Requests on Stream IDs less than or equal to the Stream ID in the
GOAWAY frame might have been processed; their status cannot be known GOAWAY frame might have been processed; their status cannot be known
until they are completed successfully, reset individually, or the until they are completed successfully, reset individually, or the
connection terminates. connection terminates.
Servers SHOULD send a GOAWAY frame when the closing of a connection Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the is known in advance, even if the advance notice is small, so that the
remote peer can know whether a stream has been partially processed or remote peer can know whether a stream has been partially processed or
not. For example, if an HTTP client sends a POST at the same time not. For example, if an HTTP client sends a POST at the same time
that a server closes a QUIC connection, the client cannot know if the that a server closes a QUIC connection, the client cannot know if the
 End of changes. 22 change blocks. 
70 lines changed or deleted 94 lines changed or added

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