draft-ietf-quic-http-02.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 March 13, 2017 Intended status: Standards Track April 24, 2017
Expires: September 14, 2017 Expires: October 26, 2017
Hypertext Transfer Protocol (HTTP) over QUIC Hypertext Transfer Protocol (HTTP) over QUIC
draft-ietf-quic-http-02 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 September 14, 2017. This Internet-Draft will expire on October 26, 2017.
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 4, line 45 skipping to change at page 4, line 45
HTTP/QUIC connections are established as described in HTTP/QUIC connections are established as described in
[QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support [QUIC-TRANSPORT]. During connection establishment, HTTP/QUIC support
is indicated by selecting the ALPN token "hq" in the crypto is indicated by selecting the ALPN token "hq" in the crypto
handshake. handshake.
While connection-level options pertaining to the core QUIC protocol While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, HTTP-specific settings are are set in the initial crypto handshake, HTTP-specific settings are
conveyed in the SETTINGS frame. After the QUIC connection is conveyed in the SETTINGS frame. After the QUIC connection is
established, a SETTINGS frame (Section 5.2.3) MUST be sent as the established, a SETTINGS frame (Section 5.2.3) MUST be sent as the
initial frame of the HTTP control stream (StreamID 3, see Section 4). initial frame of the HTTP control stream (Stream ID 3, see
The server MUST NOT send data on any other stream until the client's Section 4). The server MUST NOT send data on any other stream until
SETTINGS frame has been received. the client's SETTINGS frame has been received.
3.1. Draft Version Identification 3.1. Draft Version Identification
*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.
Only implementations of the final, published RFC can identify Only implementations of the final, published RFC can identify
themselves as "hq". Until such an RFC exists, implementations MUST themselves as "hq". Until such an RFC exists, implementations MUST
NOT identify themselves using this string. NOT identify themselves using this string.
skipping to change at page 9, line 46 skipping to change at page 9, line 46
control stream of the dependent request, not the data stream. control stream of the dependent request, not the data stream.
4.4. Server Push 4.4. Server Push
HTTP/QUIC supports server push as described in [RFC7540]. During HTTP/QUIC supports server push as described in [RFC7540]. During
connection establishment, the client indicates whether it is willing connection establishment, the client indicates whether it is willing
to receive server pushes via the SETTINGS_DISABLE_PUSH setting in the to receive server pushes via the SETTINGS_DISABLE_PUSH setting in the
SETTINGS frame (see Section 3), which defaults to 1 (true). SETTINGS frame (see Section 3), which defaults to 1 (true).
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 containing the StreamID of the stream to sending a PUSH_PROMISE frame containing the Stream ID of the stream
be pushed, as well as request header fields attributed to the to be pushed, as well as request header fields attributed to the
request. The PUSH_PROMISE frame is sent on the control stream of the request. The PUSH_PROMISE frame is sent on the control stream of the
associated (client-initiated) request, while the Promised Stream ID associated (client-initiated) request, while the Promised Stream ID
field specifies the Stream ID of the control stream for the server- field specifies the Stream ID of the control stream for the server-
initiated request. initiated request.
The server push response is conveyed in the same way as a non-server- The server push response is conveyed in the same way as a non-server-
push response, with response headers and (if present) trailers push response, with response headers and (if present) trailers
carried by HEADERS frames sent on the control stream, and response carried by HEADERS frames sent on the control stream, and response
body (if any) sent via the corresponding data stream. body (if any) sent via the corresponding data stream.
skipping to change at page 25, line 35 skipping to change at page 25, line 35
| | | stream was | | | | | stream was | |
| | | RST | | | | | RST | |
+------------------------------+-----+--------------+---------------+ +------------------------------+-----+--------------+---------------+
10. References 10. References
10.1. Normative References 10.1. Normative References
[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". Multiplexed and Secure Transport", draft-ietf-quic-
transport-latest (work in progress).
[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,
<http://www.rfc-editor.org/info/rfc793>. <http://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,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
 End of changes. 6 change blocks. 
10 lines changed or deleted 11 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/