draft-ietf-quic-http-04.txt   draft-ietf-quic-http-latest.txt 
QUIC Working Group M. Bishop, Ed. QUIC Working Group M. Bishop, Ed.
Internet-Draft Microsoft Internet-Draft Microsoft
Intended status: Standards Track June 13, 2017 Intended status: Standards Track July 20, 2017
Expires: December 15, 2017 Expires: January 21, 2018
Hypertext Transfer Protocol (HTTP) over QUIC Hypertext Transfer Protocol (HTTP) over QUIC
draft-ietf-quic-http-04 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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 December 15, 2017. This Internet-Draft will expire on January 21, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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 9, line 25 skipping to change at page 9, line 25
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.
4.3. Stream Priorities 4.3. Stream Priorities
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 stream can be Section 5.3. In this priority scheme, a given stream can be
designated as dependent upon another stream, which expresses the designated as dependent upon another stream, which expresses the
preference that the latter stream (the "parent" stream) be allocated preference that the latter stream (the "parent" stream) be allocated
resources before the former stream (the "dependent" stream). Taken resources before the former stream (the "dependent" stream). Taken
together, the dependencies across all streams in a connection form a together, the dependencies across all streams 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
streams. streams.
For consistency's sake, all PRIORITY frames MUST refer to the message For consistency's sake, all PRIORITY frames MUST refer to the message
skipping to change at page 12, line 6 skipping to change at page 12, line 6
to support ordering, it MUST be sent only on the connection control to support ordering, it MUST be sent only on the connection control
stream. The format has been modified to accommodate not being sent stream. The format has been modified to accommodate not being sent
on-stream and the larger stream ID space of QUIC. on-stream and the larger stream ID space of QUIC.
The semantics of the Stream Dependency, Weight, and E flag are the The semantics of the Stream Dependency, Weight, and E flag are the
same as in HTTP/2. same as in HTTP/2.
The flags defined are: The flags defined are:
E (0x01): Indicates that the stream dependency is exclusive (see E (0x01): Indicates that the stream dependency is exclusive (see
[RFC7540] Section 5.3). [RFC7540], Section 5.3).
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 Stream (32) | | Prioritized Stream (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Dependent Stream (32) | | Dependent Stream (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Weight (8) | | Weight (8) |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
Figure 3: PRIORITY frame payload Figure 3: PRIORITY frame payload
The HEADERS frame payload has the following fields: The HEADERS frame payload has the following fields:
Prioritized Stream: A 32-bit stream identifier for the message Prioritized Stream: A 32-bit stream identifier for the message
control stream whose priority is being updated. control stream whose priority is being updated.
Stream Dependency: A 32-bit stream identifier for the stream that Stream Dependency: A 32-bit stream identifier for the stream that
this stream depends on (see Section 4.3 and {!RFC7540}} this stream depends on (see Section 4.3 and [RFC7540],
Section 5.3). Section 5.3).
Weight: An unsigned 8-bit integer representing a priority weight for Weight: An unsigned 8-bit integer representing a priority weight for
the stream (see [RFC7540] Section 5.3). Add one to the value to the stream (see [RFC7540], Section 5.3). Add one to the value to
obtain a weight between 1 and 256. obtain a weight between 1 and 256.
A PRIORITY frame MUST have a payload length of nine octets. A A PRIORITY frame MUST have a payload length of nine octets. A
PRIORITY frame of any other length MUST be treated as a connection PRIORITY frame of any other length MUST be treated as a connection
error of type HTTP_MALFORMED_PRIORITY. error of type HTTP_MALFORMED_PRIORITY.
5.2.3. SETTINGS 5.2.3. SETTINGS
The SETTINGS frame (type=0x4) conveys configuration parameters that The SETTINGS frame (type=0x4) conveys configuration parameters that
affect how endpoints communicate, such as preferences and constraints affect how endpoints communicate, such as preferences and constraints
skipping to change at page 13, line 50 skipping to change at page 13, line 50
A SETTINGS frame MUST be sent as the first frame of the connection A SETTINGS frame MUST be sent as the first frame of the connection
control stream (see Section 4) by each peer, and MUST NOT be sent control stream (see Section 4) by each peer, and MUST NOT be sent
subsequently or on any other stream. If an endpoint receives an subsequently or on any other stream. If an endpoint receives an
SETTINGS frame on a different stream, the endpoint MUST respond with SETTINGS frame on a different stream, the endpoint MUST respond with
a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an a connection error of type HTTP_SETTINGS_ON_WRONG_STREAM. If an
endpoint receives a second SETTINGS frame, the endpoint MUST respond endpoint receives a second SETTINGS frame, the endpoint MUST respond
with a connection error of type HTTP_MULTIPLE_SETTINGS. with a connection error of type HTTP_MULTIPLE_SETTINGS.
The SETTINGS frame affects connection state. A badly formed or The SETTINGS frame affects connection state. A badly formed or
incomplete SETTINGS frame MUST be treated as a connection error incomplete SETTINGS frame MUST be treated as a connection error
(Section 5.4.1) of type HTTP_MALFORMED_SETTINGS. (Section 6) of type HTTP_MALFORMED_SETTINGS.
5.2.3.1. Integer encoding 5.2.3.1. Integer encoding
Settings which are integers are transmitted in network byte order. Settings which are integers are transmitted in network byte order.
Leading zero octets are permitted, but implementations SHOULD use Leading zero octets are permitted, but implementations SHOULD use
only as many bytes as are needed to represent the value. An integer only as many bytes as are needed to represent the value. An integer
MUST NOT be represented in more bytes than would be used to transfer MUST NOT be represented in more bytes than would be used to transfer
the maximum permitted value. the maximum permitted value.
5.2.3.2. Defined SETTINGS Parameters 5.2.3.2. Defined SETTINGS Parameters
skipping to change at page 26, line 26 skipping to change at page 26, line 26
HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015, HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
<http://www.rfc-editor.org/info/rfc7541>. <http://www.rfc-editor.org/info/rfc7541>.
[RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP [RFC7838] Nottingham, M., McManus, P., and J. Reschke, "HTTP
Alternative Services", RFC 7838, DOI 10.17487/RFC7838, Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
April 2016, <http://www.rfc-editor.org/info/rfc7838>. April 2016, <http://www.rfc-editor.org/info/rfc7838>.
10.2. Informative References 10.2. Informative References
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", RFC 5226,
DOI 10.17487/RFC5226, May 2008, DOI 10.17487/RFC5226, May 2008,
<http://www.rfc-editor.org/info/rfc5226>. <http://www.rfc-editor.org/info/rfc5226>.
[RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
"Transport Layer Security (TLS) Application-Layer Protocol "Transport Layer Security (TLS) Application-Layer Protocol
Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
July 2014, <http://www.rfc-editor.org/info/rfc7301>. July 2014, <http://www.rfc-editor.org/info/rfc7301>.
Appendix A. Contributors Appendix A. Contributors
 End of changes. 9 change blocks. 
10 lines changed or deleted 10 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/