QUIC                                                      M. Bishop, Ed.
Internet-Draft                                                 Microsoft
Intended status: Standards Track                       November 28, 2016                        January 14, 2017
Expires: June 1, July 18, 2017

              Hypertext Transfer Protocol (HTTP) over QUIC
                        draft-ietf-quic-http-00
                        draft-ietf-quic-http-01

Abstract

   The QUIC transport protocol has several features that are desirable
   in a transport for HTTP/2, HTTP, such as stream multiplexing, per-stream flow
   control, and low-latency connection establishment.  This document
   describes a mapping of HTTP/2 HTTP semantics over QUIC.  Specifically, this
   document identifies HTTP/2 features that are subsumed by QUIC, and
   describes how the other features can be implemented atop QUIC.

Note to Readers

   Discussion of this draft takes place on the QUIC working group
   mailing list (quic@ietf.org), which is archived at
   https://mailarchive.ietf.org/arch/search/?email_list=quic .

   Working Group information can be found at https://github.com/quicwg ;
   source code and issues list for this draft can be found at
   https://github.com/quicwg/base-drafts/labels/http .

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on June 1, July 18, 2017.

Copyright Notice

   Copyright (c) 2016 2017 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2   3
     1.1.  Notational Conventions  . . . . . . . . . . . . . . . . .   2   3
   2.  QUIC advertisement Advertisement  . . . . . . . . . . . . . . . . . . . . .   3
     2.1.  QUIC Version Hints  . . . . . . . . . . . . . . . . . . .   4
   3.  Connection establishment Establishment  . . . . . . . . . . . . . . . . . .   3   4
     3.1.  Draft Version Identification  . . . . . . . . . . . . . .   5
   4.  Sending a request on an HTTP/2-over-QUIC connection  Stream Mapping and Usage  . . . . .   4 . . . . . . . . . . . . .   5
     4.1.  Terminating a stream  Stream 3: Connection Control Stream . . . . . . . . . . .   6
     4.2.  HTTP Message Exchanges  . . . . . . . .   4
   5.  Writing data to QUIC streams . . . . . . . . .   6
       4.2.1.  Header Compression  . . . . . . . .   5
   6. . . . . . . . . .   7
       4.2.2.  The CONNECT Method  . . . . . . . . . . . . . . . . .   8
     4.3.  Stream Mapping Priorities . . . . . . . . . . . . . . . . . . . .   9
     4.4.  Flow Control  . . .   5
     6.1.  Reserved Streams . . . . . . . . . . . . . . . . . . .   9
     4.5.  Server Push .   5
       6.1.1.  Stream 3: headers . . . . . . . . . . . . . . . . . .   6
       6.1.2.  Stream states . . . .   9
   5.  HTTP Framing Layer  . . . . . . . . . . . . . . . .   6
   7.  Stream Priorities . . . . .  10
     5.1.  Frame Layout  . . . . . . . . . . . . . . . . .   7
   8.  Flow Control . . . . .  10
     5.2.  Frame Definitions . . . . . . . . . . . . . . . . . . .   8
   9.  Server Push .  11
       5.2.1.  DATA  . . . . . . . . . . . . . . . . . . . . . . . .   8
   10. Error Codes  11
       5.2.2.  HEADERS . . . . . . . . . . . . . . . . . . . . . . .  11
       5.2.3.  PRIORITY  . .   8
   11. Other HTTP/2 frames . . . . . . . . . . . . . . . . . . . .  12
       5.2.4.  RST_STREAM  .   9
     11.1.  GOAWAY frame . . . . . . . . . . . . . . . . . . . .  13
       5.2.5.  SETTINGS  . .   9
     11.2.  PING frame . . . . . . . . . . . . . . . . . . . .  13
       5.2.6.  PUSH_PROMISE  . . . .  10
     11.3.  PADDING frame . . . . . . . . . . . . . . . .  16
       5.2.7.  PING  . . . . .  10
   12. Security Considerations . . . . . . . . . . . . . . . . . . .  10
   13. IANA Considerations  17
       5.2.8.  GOAWAY frame  . . . . . . . . . . . . . . . . . . . .  17
       5.2.9.  WINDOW_UPDATE frame .  10
   14. Normative References . . . . . . . . . . . . . . . .  17
       5.2.10. CONTINUATION frame  . . . .  10
   Appendix A.  Contributors . . . . . . . . . . . . .  17
       5.2.11. SETTINGS_ACK Frame  . . . . . . . . .  11
   Author's Address . . . . . . . .  18
   6.  Error Handling  . . . . . . . . . . . . . . . .  11

1.  Introduction

   The . . . . . . .  19
     6.1.  HTTP-Defined QUIC transport protocol Error Codes . . . . . . . . . . . . . .  19
     6.2.  Mapping HTTP/2 Error Codes  . . . . . . . . . . . . . . .  20

   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  21
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Registration of HTTP/QUIC Identification String . . . . .  21
     8.2.  Registration of Version Hint Alt-Svc Parameter  . . . . .  21
     8.3.  Existing Frame Types  . . . . . . . . . . . . . . . . . .  22
     8.4.  New Frame Types . . . . . . . . . . . . . . . . . . . . .  23
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  23
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  23
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  24
   Appendix A.  Contributors . . . . . . . . . . . . . . . . . . . .  24
   Appendix B.  Change Log . . . . . . . . . . . . . . . . . . . . .  24
     B.1.  Since draft-ietf-quic-http-00:  . . . . . . . . . . . . .  24
     B.2.  Since draft-shade-quic-http2-mapping-00:  . . . . . . . .  25
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  25

1.  Introduction

   The QUIC transport protocol has several features that are desirable
   in a transport for HTTP, such as stream multiplexing, per-stream flow
   control, and low-latency connection establishment.  This document
   describes a mapping of HTTP semantics over QUIC, drawing heavily on
   the existing TCP mapping, HTTP/2.  Specifically, this document
   identifies HTTP/2 features that are subsumed by QUIC, and describes
   how the other features can be implemented atop QUIC.

   QUIC is described in [QUIC-TRANSPORT].  For a full description of
   HTTP/2, see [RFC7540].

1.1.  Notational Conventions

   The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
   document.  It's not shouting; when they are capitalized, they have
   the special meaning defined in [RFC2119].

2.  QUIC Advertisement

   A server advertises that it can speak HTTP/QUIC via the Alt-Svc
   ([RFC7838]) HTTP response header (or the semantically equivalent Alt-
   Svc HTTP/2 Extension Frame Type), using the ALPN token defined in
   Section 3.

   Thus, a server could indicate in an HTTP/1.1 or HTTP/2 response that
   HTTP/QUIC was available on UDP port 443 by including the following
   header in any response:

   Alt-Svc: hq=":443"

2.1.  QUIC Version Hints

   This document defines the "v" parameter for Alt-Svc, which is used to
   provide version-negotiation hints to HTTP/QUIC clients.  Syntax:

   v = version
   version = DQUOTE ( "c" version-string / "x" version-number ) DQUOTE
   version-string = token; percent-encoded QUIC version
   version-number = 1*8 HEXDIG; hex-encoded QUIC version

   When multiple versions are supported, the "v" parameter MAY be
   repeated multiple times in a single Alt-Svc entry.  For example, if a
   server supported both version "Q034" and version 0x00000001, it would
   specify the following header:

   Alt-Svc: hq=":443";v="x1";v="cQ034"

   Where multiple versions are listed, the order of the values reflects
   the server's preference (with the first value being the most
   preferred version).

   QUIC versions are four-octet sequences with no additional constraints
   on format.  Versions containing octets not allowed in tokens
   ([RFC7230], Section 3.2.6) MUST be encoded using the hexidecimal
   representation.  Versions containing only octets allowed in tokens
   MAY be encoded using either representation.

   On receipt of an Alt-Svc header indicating QUIC support, a client MAY
   attempt to establish a QUIC connection on the indicated port and, if
   successful, send HTTP requests using the mapping described in this
   document.  Servers SHOULD list only versions which they support, but
   MAY omit supported versions for any reason.

   Connectivity problems (e.g. firewall blocking UDP) may result in QUIC
   connection establishment failure, in which case the client should
   gracefully fall back to HTTP/2.

3.  Connection Establishment

   HTTP/QUIC connections are established as described in
   [QUIC-TRANSPORT].  During connection establishment, HTTP/QUIC support
   is indicated by selecting the ALPN token "hq" in the crypto
   handshake.

   While connection-level options pertaining to the core QUIC protocol
   are set in the initial crypto handshake, HTTP-specific settings are
   conveyed in the SETTINGS frame.  After the QUIC connection is
   established, a SETTINGS frame (Section 5.2.5) MUST be sent as the
   initial frame of the HTTP control stream (StreamID 3, see Section 4).

3.1.  Draft Version Identification

      *RFC Editor's Note:* Please remove this section prior to
      publication of a final version of this document.

   Only implementations of the final, published RFC can identify
   themselves as "hq".  Until such an RFC exists, implementations MUST
   NOT identify themselves using these strings.

   Implementations of draft versions of the protocol MUST add the string
   "-" and the corresponding draft number to the identifier.  For
   example, draft-ietf-quic-http-01 is identified using the string "hq-
   01".

   Non-compatible experiments that are based on these draft versions
   MUST append the string "-" and an experiment name to the identifier.
   For example, an experimental implementation based on draft-ietf-quic-
   http-09 which reserves an extra stream for unsolicited transmission
   of 1980s pop music might identify itself as "hq-09-rickroll".  Note
   that any label MUST conform to the "token" syntax defined in
   Section 3.2.6 of [RFC7230].  Experimenters are encouraged to
   coordinate their experiments on the quic@ietf.org mailing list.

4.  Stream Mapping and Usage

   A QUIC stream provides reliable in-order delivery of bytes, but makes
   no guarantees about order of delivery with regard to bytes on other
   streams.  On the wire, data is framed into QUIC STREAM frames, but
   this framing is invisible to the HTTP framing layer.  A QUIC receiver
   buffers and orders received STREAM frames, exposing the data
   contained within as a reliable byte stream to the application.

   QUIC reserves Stream 1 for crypto operations (the handshake, crypto
   config updates).  Stream 3 is reserved for sending and receiving HTTP
   control frames, and is analogous to HTTP/2's Stream 0.

   When HTTP headers and data are sent over QUIC, the QUIC layer handles
   most of the stream management.  An HTTP request/response consumes a
   pair of streams: This means that the client's first request occurs on
   QUIC streams 5 and 7, the second on stream 9 and 11, and so on.  The
   server's first push consumes streams 2 and 4.  This amounts to the
   second least-significant bit differentiating the two streams in a
   request.

   The lower-numbered stream is called the message control stream and
   carries frames related to the request/response, including HEADERS.
   All request control streams are exempt from connection-level flow
   control.  The higher-numbered stream is the data stream and carries
   the request/response body with no additional framing.  Note that a
   request or response without a body will cause this stream to be half-
   closed in the corresponding direction without transferring data.

   Pairs of streams must be utilized sequentially, with no gaps.  The
   data stream MUST be reserved with the QUIC implementation when the
   message control stream is opened or reserved, and MUST be closed
   after transferring the body, or else closed immediately after sending
   the request headers if there is no body.

   HTTP does not need to do any separate multiplexing when using QUIC -
   data sent over a QUIC stream always maps to a particular HTTP
   transaction.  Requests and responses are considered complete when the
   corresponding QUIC streams are closed in the appropriate direction.

4.1.  Stream 3: Connection Control Stream

   Since most connection-level concerns from HTTP/2 will be managed by
   QUIC, the primary use of Stream 3 will be for SETTINGS and PRIORITY
   frames.  Stream 3 is exempt from connection-level flow-control.

4.2.  HTTP Message Exchanges

   A client sends an HTTP request on a new pair of QUIC streams.  A
   server sends an HTTP response on the same streams as the request.

   An HTTP message (request or response) consists of:

   1.  for a response only, zero or more header blocks (a sequence of
       HEADERS frames with End Header Block set on the last) on the
       control stream containing the message headers of informational
       (1xx) HTTP responses (see [RFC7230], Section 3.2 and [RFC7231],
       Section 6.2),

   2.  one header block on the control stream containing the message
       headers (see [RFC7230], Section 3.2),

   3.  the payload body (see [RFC7230], Section 3.3), sent on the data
       stream,

   4.  optionally, one header block on the control stream containing the
       trailer-part, if present (see [RFC7230], Section 4.1.2).

   The data stream MUST be half-closed immediately after the transfer of
   the body.  If the message does not contain a body, the corresponding
   data stream MUST still be half-closed without transferring any data.
   The "chunked" transfer encoding defined in Section 4.1 of [RFC7230]
   MUST NOT be used.

   Trailing header fields are carried in a header block following the
   body.  Such a header block is a sequence of HEADERS frames with End
   Header Block set on the last frame.  Header blocks after the first
   but before the end of the stream are invalid.  These MUST be decoded
   to maintain HPACK decoder state, but the resulting output MUST be
   discarded.

   An HTTP request/response exchange fully consumes a pair of streams.
   After sending a request, a client closes the streams for sending;
   after sending a response, the server closes its streams for sending
   and the QUIC streams are fully closed.

   A server can send a complete response prior to the client sending an
   entire request if the response does not depend on any portion of the
   request that has not been sent and received.  When this is true, a
   server MAY request that the client abort transmission of a request
   without error by sending a RST_STREAM with an error code of NO_ERROR
   after sending a complete response and closing its stream.  Clients
   MUST NOT discard responses as a result of receiving such a
   RST_STREAM, though clients can always discard responses at their
   discretion for other reasons.

4.2.1.  Header Compression

   HTTP/QUIC uses HPACK header compression as described in [RFC7541].
   HPACK was designed for HTTP/2 with the assumption of in- order
   delivery such as that provided by TCP.  A sequence of encoded header
   blocks must arrive (and be decoded) at an endpoint in the same order
   in which they were encoded.  This ensures that the dynamic state at
   the two endpoints remains in sync.

   QUIC streams provide in-order delivery of data sent on those streams,
   but there are no guarantees about order of delivery between streams.
   To achieve in-order delivery of HEADERS frames in QUIC, the HPACK-
   bearing frames contain a counter which can be used to ensure in-order
   processing.  Data (request/response bodies) which arrive out of order
   are buffered until the corresponding HEADERS arrive.

   This does introduce head-of-line blocking: if the packet containing
   HEADERS for stream N is lost or reordered then the HEADERS for stream
   N+4 cannot be processed until it has several features been retransmitted successfully,
   even though the HEADERS for stream N+4 may have arrived.

   DISCUSS:  Keep HPACK with HOLB?  Redesign HPACK to be order-
      invariant?  How much do we need to retain compatibility with
      HTTP/2's HPACK?

4.2.2.  The CONNECT Method

   The pseudo-method CONNECT ([RFC7231], Section 4.3.6) is primarily
   used with HTTP proxies to establish a TLS session with an origin
   server for the purposes of interacting with "https" resources.  In
   HTTP/1.x, CONNECT is used to convert an entire HTTP connection into a
   tunnel to a remote host.  In HTTP/2, the CONNECT method is used to
   establish a tunnel over a single HTTP/2 stream to a remote host for
   similar purposes.

   A CONNECT request in HTTP/QUIC functions in the same manner as in
   HTTP/2.  The request MUST be formatted as described in [RFC7540],
   Section 8.3.  A CONNECT request that does not conform to these
   restrictions is malformed.  The message data stream MUST NOT be
   closed at the end of the request.

   A proxy that supports CONNECT establishes a TCP connection
   ([RFC0793]) to the server identified in the ":authority" pseudo-
   header field.  Once this connection is successfully established, the
   proxy sends a HEADERS frame containing a 2xx series status code to
   the client, as defined in [RFC7231], Section 4.3.6, on the message
   control stream.

   All QUIC STREAM frames on the message data stream correspond to data
   sent on the TCP connection.  Any QUIC STREAM frame sent by the client
   is transmitted by the proxy to the TCP server; data received from the
   TCP server is written to the data stream by the proxy.  Note that the
   size and number of TCP segments is not guaranteed to map predictably
   to the size and number of QUIC STREAM frames.

   The TCP connection can be closed by either peer.  When the client
   half-closes the data stream, the proxy will set the FIN bit on its
   connection to the TCP server.  When the proxy receives a packet with
   the FIN bit set, it will half-close the corresponding data stream.
   TCP connections which remain half-closed in a single direction are
   not invalid, but are often handled poorly by servers, so clients
   SHOULD NOT half-close connections on which they are still expecting
   data.

   A TCP connection error is signaled with RST_STREAM.  A proxy treats
   any error in the TCP connection, which includes receiving a TCP
   segment with the RST bit set, as a stream error of type
   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
   stream or the QUIC connection.

4.3.  Stream Priorities

   HTTP/QUIC uses the priority scheme described in [RFC7540]
   Section 5.3.  In this priority scheme, a given stream can be
   designated as dependent upon another stream, which expresses the
   preference that are desirable the latter stream (the "parent" stream) be allocated
   resources before the former stream (the "dependent" stream).  Taken
   together, the dependencies across all streams in a transport for HTTP/2, connection form a
   dependency tree.  The structure of the dependency tree changes as
   HEADERS and PRIORITY frames add, remove, or change the dependency
   links between streams.

   Implicit in this scheme is the notion of in-order delivery of
   priority changes (i.e., dependency tree mutations): since operations
   on the dependency tree such as stream multiplexing, per-stream
   flow control, reparenting a subtree are not
   commutative, both sender and low-latency connection establishment.  This
   document describes receiver must apply them in the same
   order to ensure that both sides have a mapping consistent view of the stream
   dependency tree.  HTTP/2 specifies priority assignments in PRIORITY
   frames and (optionally) in HEADERS frames.  To achieve in-order
   delivery of priority changes in HTTP/QUIC, PRIORITY frames are sent
   on the connection control stream and the PRIORITY section is removed
   from the HEADERS frame.  The semantics over QUIC.
   Specifically, this document identifies HTTP/2 features that of the Stream Dependency,
   Weight, E flag, and (for HEADERS frames) PRIORITY flag are
   subsumed the same
   as in HTTP/2.

   For consistency's sake, all PRIORITY frames MUST refer to the message
   control stream of the dependent request, not the data stream.

4.4.  Flow Control

   QUIC provides stream and connection level flow control, similar in
   principle to HTTP/2's flow control but with some implementation
   differences.  As flow control is handled by QUIC, and describes how the other features can be
   implemented atop QUIC.

   QUIC is HTTP mapping
   need not concern itself with maintaining flow control state.  The
   HTTP mapping MUST NOT send WINDOW_UPDATE frames at the HTTP level.

4.5.  Server Push

   HTTP/QUIC supports server push as described in [QUIC-TRANSPORT].  For a full description of
   HTTP/2, see [RFC7540].

1.1.  Notational Conventions

   The words "MUST", "MUST NOT", "SHOULD", and "MAY" are used in this
   document.  It's not shouting; when they are capitalized, they have  During
   connection establishment, the special meaning defined in [RFC2119].

2.  QUIC advertisement

   A server advertises that client indicates whether it can speak HTTP/2-over-QUIC is willing
   to receive server pushes via the Alt-
   Svc HTTP response header.  It does so SETTINGS_ENABLE_PUSH setting in the
   SETTINGS frame (see Section 3), which defaults to 1 (true).

   As with server push for HTTP/2, the server initiates a server push by including
   sending a PUSH_PROMISE frame containing the StreamID of the stream to
   be pushed, as well as request header in any
   response fields attributed to the
   request.  The PUSH_PROMISE frame is sent over a non-QUIC (e.g.  HTTP/2 over TLS) connection:

   Alt-Svc: quic=":443"

   In addition, on the list control stream of QUIC versions supported by the server can be
   specified by
   associated (client-initiated) request, while the v= parameter.  For example, if a server supported
   both version 33 and 34 it would specify Promised Stream ID
   field specifies the following header:

   Alt-Svc: quic=":443"; v="34,33"

   On receipt Stream ID of this header, a client may attempt to establish the control stream for the server-
   initiated request.

   The server push response is conveyed in the same way as a QUIC
   connection non-server-
   push response, with response headers and (if present) trailers
   carried by HEADERS frames sent on port 443 and, if successful, send the control stream, and response
   body (if any) sent via the corresponding data stream.

5.  HTTP Framing Layer

   Many framing concepts from HTTP/2 requests using can be elided away on QUIC, because
   the mapping described in transport deals with them.  Because frames are already on a
   stream, they can omit the stream number.  Because frames do not block
   multiplexing (QUIC's multiplexing occurs below this document.

   Connectivity problems (e.g. firewall blocking UDP) may result in QUIC
   connection establishment failure, in which case layer), the client should
   gracefully fallback to HTTP/2-over-TLS/TCP.

3.  Connection establishment

   HTTP/2-over-QUIC connections
   support for variable-maximum-length packets can be removed.  Because
   stream termination is handled by QUIC, an END_STREAM flag is not
   required.

   Frames are established as described in
   [QUIC-TRANSPORT].  The QUIC crypto handshake MUST use TLS [QUIC-TLS].

   While connection-level options pertaining to used only on the core QUIC protocol connection (stream 3) and message
   (streams 5, 9, etc.) control streams.  Other streams carry data
   payload and are set in not framed at the initial crypto handshake [QUIC-TLS].  HTTP/2-specific
   settings HTTP layer.

   Frame payloads are conveyed largely drawn from [RFC7540].  However, QUIC
   includes some features (e.g. flow control) which are also present in
   HTTP/2.  In these cases, the HTTP/2 SETTINGS frame.  After the QUIC
   connection is established, HTTP mapping need not re-implement them.
   As a result, some frame types are not required when using QUIC.
   Where an HTTP/2 SETTINGS HTTP/2-defined frame may be sent as is no longer used, the initial frame of the QUIC headers stream (StreamID 3, See
   Section 6).  As ID is
   reserved in HTTP/2, additional SETTINGS frames may be sent
   mid-connection by either endpoint.

   TODO:  Decide whether order to acknowledge receipt of SETTINGS through
      empty SETTINGS maximize portability between HTTP/2 and HTTP/
   QUIC implementations.  However, equivalent frames with ACK bit set, as between the two
   mappings are not necessarily identical.

   This section describes HTTP framing in HTTP/2, or rely on
      transport- level acknowledgment.

   Some transport-level options that HTTP/2-over-TCP specifies via QUIC and highlights
   differences from HTTP/2 framing.

5.1.  Frame Layout

   All frames have the
   SETTINGS following format:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |           Length (16)         |     Type (8)  |   Flags (8)   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Frame Payload (*)                     ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                          HTTP/QUIC frame format

5.2.  Frame Definitions

5.2.1.  DATA

   DATA frames do not exist.  Frame type 0x0 is reserved.

5.2.2.  HEADERS

   The HEADERS frame are superseded by QUIC transport parameters in HTTP/2-
   over-QUIC.  Below (type=0x1) is a listing used to carry part of how each HTTP/2 SETTINGS parameter
   is mapped:

   SETTINGS_HEADER_TABLE_SIZE:  Sent in HTTP/2 SETTINGS frame.

   SETTINGS_ENABLE_PUSH:  Sent in HTTP/2 SETTINGS frame (TBD, currently
      set a header set,
   compressed using QUIC "SPSH" connection option)

   SETTINGS_MAX_CONCURRENT_STREAMS  QUIC requires the maximum number of
      incoming HPACK [RFC7541].  Because HEADERS frames from
   different streams per connection to will be specified in the initial
      crypto handshake, using the "MSPC" tag.  Specifying
      SETTINGS_MAX_CONCURRENT_STREAMS in delivered out-of-order and priority-changes
   are not commutative, the HTTP/2 SETTINGS frame PRIORITY region of HEADERS is an
      error.

   SETTINGS_INITIAL_WINDOW_SIZE:  QUIC requires both stream and
      connection flow control window sizes to not supported.
   A separate PRIORITY frame MUST be specified in the
      initial crypto handshake, using the "SFCW" and "CFCW" tags,
      respectively.  Specifying SETTINGS_INITIAL_WINDOW_SIZE in the used.

   Padding MUST NOT be used.  The flags defined are:

   Reserved (0x1):  Reserved for HTTP/2 SETTINGS frame is an error.

   SETTINGS_MAX_FRAME_SIZE: compatibility.

   End Header Block (0x4):  This setting has no equivalent in QUIC.
      Specifying it in the HTTP/2 SETTINGS frame is an error.

   SETTINGS_MAX_HEADER_LIST_SIZE  Sent in concludes a header block.

   Reserved (0x8):  Reserved for HTTP/2 SETTINGS frame.

   As with HTTP/2-over-TCP, unknown SETTINGS parameters are tolerated
   but ignored.  SETTINGS parameters are acknowledged by the receiving
   peer, by sending an empty SETTINGS compatibility.

   Reserved (0x20):  Reserved for HTTP/2 compatibility.

   A HEADERS frame in response with the ACK bit
   set.

4.  Sending Reserved bits set MUST be treated as a request on an HTTP/2-over-QUIC connection

   A high level overview of sending an HTTP/2 request on an established
   QUIC
   connection is as follows, with further details in later sections error of this document.  A client should first encode any HTTP headers
   using HPACK [RFC7541] and type HTTP_MALFORMED_HEADERS.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Sequence? (16)          |    Header Block Fragment (*)...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                           HEADERS frame them as HTTP/2 payload

   The HEADERS frames.  These
   are sent frame payload has the following fields:

   Sequence Number:  Present only on StreamID 3 (see Section 6).  The exact layout of the
   HEADERS first frame is described in Section 6.2 of [RFC7540].  No HTTP/2
   padding is required: QUIC provides a PADDING header block
      sequence.  This MUST be set to zero on the first header block
      sequence, and incremented on each header block.

   The next frame for this purpose.

   While HEADERS are sent on stream 3, the mandatory same stream identifier
   in each after a HEADERS frame indicates without the QUIC StreamID on which a
   corresponding request body may
   EHB flag set MUST be sent.  If there is no non-header
   data, another HEADERS frame.  A receiver MUST treat
   the specified QUIC data stream will never be used.

4.1.  Terminating receipt of any other type of frame as a stream

   A stream error of type
   HTTP_INTERRUPTED_HEADERS.  (Note that QUIC can be terminated in one intersperse data from
   other streams between frames, or even during transmission of three ways:

   o  the request/response frames,
   so multiplexing is headers only, not blocked by this requirement.)

   A full header block is contained in which case a sequence of zero or more
   HEADERS frames without EHB set, followed by a HEADERS frame with EHB
   set.

   On receipt, header blocks (HEADERS, PUSH_PROMISE) MUST be processed
   by the END_STREAM bit set ends the stream specified HPACK decoder in sequence.  If a block is missing, all
   subsequent HPACK frames MUST be held until it arrives, or the
      HEADERS
   connection terminated.

5.2.3.  PRIORITY

   The PRIORITY (type=0x02) frame

   o specifies the request/response has headers sender-advised priority
   of a stream and body but no trailing headers,
      in which case the final QUIC STREAM frame will have the FIN bit
      set

   o is substantially different from [RFC7540].  In order
   to support ordering, it MUST be sent only on the request/response connection control
   stream.  The format has headers, body, and trailing headers, in
      which case the final QUIC STREAM frame will been modified to accommodate not have the FIN bit
      set, being sent
   on-stream and the trailing larger stream ID space of QUIC.

   The flags defined are:

   E (0x01):  Indicates that the stream dependency is exclusive (see
      [RFC7540] Section 5.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Prioritized Stream (32)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Dependent Stream (32)                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |   Weight (8)  |
      +-+-+-+-+-+-+-+-+

                           HEADERS frame will have payload

   The HEADERS frame payload has the END_STREAM bit
      set

   (TODO: Describe mapping of HTTP/2 following fields:

   Prioritized Stream:  A 32-bit stream state machine to QUIC identifier for the message
      control stream
   state machine.)

5.  Writing data to QUIC streams whose priority is being updated.

   Stream Dependency:  A QUIC 32-bit stream provides reliable in-order delivery of bytes, within
   that stream.  On identifier for the wire, data is framed into QUIC STREAM frames,
   but stream that
      this framing is invisible to the HTTP/2 layer.  A QUIC receiver
   buffers stream depends on (see Section 4.3 and orders received STREAM frames, exposing the data
   contained within as {!RFC7540}}
      Section 5.3).

   Weight:  An unsigned 8-bit integer representing a reliable byte priority weight for
      the stream (see [RFC7540] Section 5.3).  Add one to the application.

   Bytes written value to Stream 3 must be HTTP/2 HEADERS frames (or
      obtain a weight between 1 and 256.

   A PRIORITY frame MUST have a payload length of nine octets.  A
   PRIORITY frame of any other
   HTTP/2 non-data frames), whereas bytes written to data streams should
   simply length MUST be request or response bodies.  No further framing is required
   by HTTP/2 (i.e. no HTTP/2 DATA frames are used).

   If data arrives on treated as a data stream before the corresponding HEADERS
   have arrived on connection
   error of type HTTP_MALFORMED_PRIORITY.

5.2.4.  RST_STREAM

   RST_STREAM frames do not exist, since QUIC provides stream 3, then the data lifecycle
   management.  Frame type 0x3 is buffered until the HEADERS
   arrive.

6.  Stream Mapping

   When HTTP/2 headers reserved.

5.2.5.  SETTINGS

   The SETTINGS frame (type=0x4) conveys configuration parameters that
   affect how endpoints communicate, such as preferences and data constraints
   on peer behavior, and is substantially different from [RFC7540].
   Individually, a SETTINGS parameter can also be referred to as a
   "setting".

   SETTINGS parameters are sent over QUIC, the QUIC layer
   handles most not negotiated; they describe characteristics
   of the stream management.  HTTP/2 StreamIDs are replaced sending peer, which can be used by QUIC StreamIDs.  HTTP/2 does not need to do any explicit stream
   framing when using QUIC the receiving peer.
   However, a negotiation can be implied by the use of SETTINGS - data sent over a QUIC stream simply
   consists peer
   uses SETTINGS to advertise a set of HTTP/2 headers or body.  Requests and responses supported values.  The recipient
   can then choose which entries from this list are
   considered complete when also acceptable and
   proceed with the QUIC stream is closed value it has chosen.  (This choice could be
   announced in the
   corresponding direction.

   Like HTTP/2, QUIC uses odd-numbered StreamIDs for client initiated
   streams, and even-numbered IDs for server initiated (i.e. server
   push) streams.  Unlike HTTP/2 there are a couple field of reserved (or
   dedicated) StreamIDs in QUIC.

6.1.  Reserved Streams

   StreamID 1 is reserved for crypto operations (the handshake, crypto
   config updates), and MUST NOT be used for HTTP/2 headers an extension frame, or body, see
   [QUIC-TRANSPORT].  StreamID 3 is reserved in its own value in
   SETTINGS.)

   Different values for sending and receiving
   HTTP/2 HEADERS frames.  Therefore the first same parameter can be advertised by each
   peer.  For example, a client initiated data
   stream has StreamID 5.

   There are no reserved might permit a very large HPACK state
   table while a server initiated StreamIDs, so chooses to use a small one to conserve memory.

   A SETTINGS frame MAY be sent at any time by either endpoint over the first server
   initiated (i.e. server push) stream has an ID
   lifetime of 2, followed by 4,
   etc.

6.1.1.  Stream 3: headers

   HTTP/2-over-QUIC uses HPACK header compression as described the connection.

   Each parameter in
   [RFC7541].  HPACK was designed a SETTINGS frame replaces any existing value for HTTP/2 with
   that parameter.  Parameters are processed in the assumption of in- order delivery such as in which they
   appear, and a receiver of a SETTINGS frame does not need to maintain
   any state other than the current value of its parameters.  Therefore,
   the value of a SETTINGS parameter is the last value that provided is seen by TCP.  A sequence of encoded
   header blocks must arrive (and be decoded) at an endpoint in a
   receiver.

   The SETTINGS frame defines the same
   order in following flag:

   REQUEST_ACK (0x1):  When set, bit 0 indicates that this frame
      contains values which they the sender wants to know were encoded.  This ensures understood and
      applied.  For more information, see Section 5.2.5.3.

   The payload of a SETTINGS frame consists of zero or more parameters,
   each consisting of an unsigned 16-bit setting identifier and a
   length-prefixed binary value.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |        Identifier (16)        |B|        Length (15)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Contents (?)                       ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                      Figure 1: SETTINGS value format

   A zero-length content indicates that the dynamic
   state at setting value is a Boolean
   given by the two endpoints remains in sync.

   QUIC streams provide in-order delivery B bit.  If Length is not zero, the B bit MUST be zero,
   and MUST be ignored by receivers.  The initial value of data sent on those streams,
   but there are no guarantees about order each setting
   is "false" unless otherwise specified by the definition of delivery between streams.
   To achieve in-order delivery the
   setting.

   Non-zero-length values MUST be compared against the remaining length
   of HEADERS frames in QUIC, they are all
   sent on the reserved Stream 3.  Data (request/response bodies) SETTINGS frame.  Any value which
   arrive on other data streams are buffered until purports to cross the corresponding
   HEADERS arrive and are read out end of Stream 3.

   This does introduce head-of-line blocking: if
   the packet containing
   HEADERS for stream N is lost or reordered then stream N+2 cannot frame MUST cause the SETTINGS frame to be
   processed until they it has been retransmitted successfully, even
   though considered malformed
   and trigger a connection error.

   An implementation MUST ignore the HEADERS contents for stream N+2 may have arrived.

   Trailing headers (trailers) can also any SETTINGS
   identifier it does not understand.

   SETTINGS frames always apply to a connection, never a single stream,
   and MUST only be sent on the connection control stream 3.  These are
   sent as HTTP/2 HEADERS frames, but MUST have (Stream 3).
   If an endpoint receives an SETTINGS frame whose stream identifier
   field is anything other than 0x0, the END_STREAM bit set,
   and endpoint MUST include respond with a ":final-offset" pseudo-header.  Since QUIC
   supports out of order delivery, receipt
   connection error of a HEADERS type HTTP_SETTINGS_ON_WRONG_STREAM.

   The SETTINGS frame with affects connection state.  A badly formed or
   incomplete SETTINGS frame MUST be treated as a connection error
   (Section 5.4.1) of type HTTP_MALFORMED_SETTINGS.

5.2.5.1.  Integer encoding

   Settings which are integers are transmitted in network byte order.
   Leading zero octets are permitted, but implementations SHOULD use
   only as many bytes as are needed to represent the
   END_STREAM bit set does not guarantee that value.  An integer
   MUST NOT be represented in more bytes than would be used to transfer
   the entire request/
   response body has been fully received.  Therefore, maximum permitted value.

5.2.5.2.  Defined SETTINGS Parameters

   Some transport-level options that HTTP/2 specifies via the extra ":final-
   offset" pseudo-header SETTINGS
   frame are superseded by QUIC transport parameters in HTTP/QUIC.
   Below is a listing of how each HTTP/2 SETTINGS parameter is included mapped:

   SETTINGS_HEADER_TABLE_SIZE:  An integer with a maximum value of 2^32
      - 1.

   SETTINGS_ENABLE_PUSH:  Transmitted as a Boolean.  The default remains
      "true" as specified in trailing HEADERS frames to
   indicate [RFC7540].

   SETTINGS_MAX_CONCURRENT_STREAMS:  QUIC requires the total maximum number of body bytes sent on
      incoming streams per connection to be specified in the corresponding
   data stream.  This is used by initial
      crypto handshake, using the "MSPC" tag.  Specifying
      SETTINGS_MAX_CONCURRENT_STREAMS in the SETTINGS frame is an error.

   SETTINGS_INITIAL_WINDOW_SIZE:  QUIC layer requires both stream and
      connection flow control window sizes to determine be specified in the
      initial crypto handshake, using the "SFCW" and "CFCW" tags,
      respectively.  Specifying SETTINGS_INITIAL_WINDOW_SIZE in the
      SETTINGS frame is an error.

   SETTINGS_MAX_FRAME_SIZE:  This setting has no equivalent in QUIC.
      Specifying it in the SETTINGS frame is an error.

   SETTINGS_MAX_HEADER_LIST_SIZE:  An integer with a maximium value of
      2^32 - 1.

5.2.5.3.  Settings Synchronization

   Some values in SETTINGS benefit from or require an understanding of
   when the
   full request peer has been received and therefore when it is safe to tear
   down local stream state.  The ":final-offset" pseudo header is
   stripped from applied the HEADERS before passing changed parameter values.
   In order to provide such synchronization timepoints, the HTTP/2 layer.

6.1.2.  Stream states

   The mapping of HTTP/2-over-QUIC with potential out recipient of order delivery
   of HEADERS frames results
   a SETTINGS frame MUST apply the updated parameters as soon as
   possible upon receipt.  The values in some changes to the HTTP/2 stream state
   transition diagram ([RFC7540], Section 5.1}}.  Specifically SETTINGS frame MUST be
   processed in the
   transition from "open" to "half closed (remote)", and order they appear, with no other frame processing
   between values.  Unsupported parameters MUST be ignored.

   Once all values have been processed, if the transition
   from "half closed (local)" to "closed" takes place only when: REQUEST_ACK flag was set,
   the recipient MUST emit the following frames:

   o  On the peer has explicitly ended connection control stream, a SETTINGS_ACK frame
      (Section 5.2.11) listing the identifiers whose values were not
      understood.

   o  On each request control stream via either
      * which is not in the "half-closed
      (local)" or "closed" state, an HTTP/2 HEADERS empty SETTINGS_ACK frame.

   The SETTINGS_ACK frame with END_STREAM bit set and, in on the
         case of trailing headers, connection control stream contains the :final-offset pseudo-header

      *  or a QUIC
   highest stream frame with number which was open at the FIN bit set.

   o  and time the full request or response body has been SETTINGS frame
   was received.

7.  Stream Priorities

   HTTP/2-over-QUIC uses  All streams with higher numbers can safely be assumed
   to have the HTTP/2 priority scheme described new settings in
   [RFC7540] Section 5.3.  In effect when they open.

   For already-open streams including the HTTP/2 priority scheme, a given stream
   can be designated as dependent upon another connection control stream, the
   SETTINGS_ACK frame indicates the point at which expresses the preference new settings took
   effect, if they did so before the peer half-closed the stream.  If
   the peer closed the stream before receiving the SETTINGS frame, the
   previous settings were in effect for the full lifetime of that
   stream.

   In certain conditions, the latter stream (the "parent" stream) SETTINGS_ACK frame can be
   allocated resources before the former first frame
   on a given stream (the "dependent"
   stream).  Taken together, - this simply indicates that the dependencies across all streams in a
   connection form a dependency tree.  The structure of new settings apply
   from the dependency
   tree changes as HTTP/2 HEADERS and PRIORITY frames add, remove, or
   change beginning of that stream.

   If the dependency links between streams.

   Implicit in this scheme is sender of a SETTINGS frame with the notion REQUEST_ACK flag set does
   not receive full acknowledgement within a reasonable amount of in-order delivery time,
   it MAY issue a connection error (Section 6) of
   priority changes (i.e., dependency tree mutations): since operations type
   HTTP_SETTINGS_TIMEOUT.  A full acknowledgement has occurred when:

   o  All previous SETTINGS frames have been fully acknowledged,

   o  A SETTINGS_ACK frame has been received on the dependency tree such as reparenting connection control
      stream,

   o  All message control streams with a subtree are not
   commutative, both sender and receiver must apply them Stream ID through those given
      in the same
   order to ensure that both sides SETTINGS_ACK frame have either closed or received a consistent view of the stream
   dependency tree.  HTTP/2 specifies priority assignments in PRIORITY
   frames and (optionally) in HEADERS frames.  To achieve in-order
   delivery of HTTP/2 priority changes in HTTP/2-over-QUIC, HTTP/2
   PRIORITY frames, in addition
      SETTINGS_ACK frame.

5.2.6.  PUSH_PROMISE

   The PUSH_PROMISE frame (type=0x05) is used to HEADERS frames, are also sent on
   reserved stream 3. carry a request header
   set from server to client, as in HTTP/2.  It defines no flags.

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Promised Stream ID (32)                     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Sequence? (16)          |         Header Block (*)    ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                        PUSH_PROMISE frame payload

   The semantics of the payload consists of:

   Promised Stream Dependency, Weight, E
   flag, and (for HEADERS frames) PRIORITY flag are ID:  A 32-bit Stream ID indicating the same as in
   HTTP/2-over-TCP.

   Since HEADERS and PRIORITY frames are sent QUIC stream on a different
      which the response headers will be sent.  (The response body
      stream than is implied by the STREAM frames headers stream, as defined in Section 4.)

   HPACK Sequence:  A sixteen-bit counter, equivalent to the Sequence
      field in HEADERS

   Payload:  HPACK-compressed request headers for the streams they reference, they promised response.

   TODOs:

   o  QUIC stream space may be
   delivered out-of-order with respect enlarged; would need to the STREAM frames.  There redefine Promised
      Stream field in this case.

   o  No CONTINUATION - HEADERS have EHB; do we need it here?

5.2.7.  PING

   PING frames do not exist, since QUIC provides equivalent
   functionality.  Frame type 0x6 is
   no special handling for this-the receiver should simply assign
   resources according to reserved.

5.2.8.  GOAWAY frame

   GOAWAY frames do not exist, since QUIC provides equivalent
   functionality.  Frame type 0x7 is reserved.

5.2.9.  WINDOW_UPDATE frame

   WINDOW_UPDATE frames do not exist, since QUIC provides equivalent
   functionality.  Frame type 0x8 is reserved.

5.2.10.  CONTINUATION frame

   CONTINUATION frames do not exist, since larger supported HEADERS/
   PUSH_PROMISE frames provide equivalent functionality.  Frame type 0x9
   is reserved.

5.2.11.  SETTINGS_ACK Frame

   The SETTINGS_ACK frame (id = 0x0b) acknowledges receipt and
   application of specific values in the peer's SETTINGS frame.
   Depending on the most recent stream priority information
   that where it has received.

   ALTERNATIVE DESIGN: if the core QUIC protocol implements priorities,
   then this document should map is sent, it takes two different
   forms.

   On the HTTP/2 priorities scheme to that
   provided by connection control stream, it contains information about how
   and when the core protocol.  This would likely involve prohibiting sender has processed the sending of HTTP/2 PRIORITY frames most recently-received SETTINGS
   frame, and setting of has the PRIORITY
   flag in HTTP/2 HEADERS frames, to avoid conflicting directives.

8.  Flow Control

   QUIC provides stream and following payload:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Highest Local Stream (32)                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                   Highest Remote Stream (32)                  |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Unrecognized Identifiers (*)               ...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          Figure 2: SETTINGS_ACK connection level flow control, similar in
   principle to HTTP/2's flow control but with some implementation
   differences.  As flow control stream format

   Highest Local Stream (32 bits):  The highest locally-initiated Stream
      ID which is handled by QUIC, the HTTP/2 mapping
   need not concern itself with maintaining flow control state, or how/
   when to send flow control frames to in the peer. "idle" state

   Highest Remote Stream (32 bits):  The HTTP/2 mapping
   must highest peer-initiated Stream
      ID which is not send HTTP/2 WINDOW_UPDATE frames.

   The initial flow control window sizes (stream and connection) are
   communicated during in the crypto handshake (see Section 3).  Setting
   these values to "idle" state

   Unrecognized Identifiers:  A list of 16-bit SETTINGS identifiers
      which the maximum size (2^31 - 1) effectively disables flow
   control.

   Relatively small initial windows can sender has not understood and therefore ignored.  This
      list MAY be used, as QUIC will attempt to
   auto-tune the flow empty.

   On message control windows based on usage. streams, the SETTINGS_ACK frame carries no
   payload, and is strictly a synchronization marker for settings
   application.  See
   [QUIC-TRANSPORT] Section 5.2.5.3 for more details.

9.  Server Push

   HTTP/2-over-QUIC supports HTTP/2 server push.  During detail.  A SETTINGS_ACK
   frame with a non-zero length MUST be treated as a connection
   establishment, the client indicates whether or it is willing to
   receive server pushes via error of
   type HTTP_MALFORMED_SETTINGS_ACK.

   On the SETTINGS_ENABLE_PUSH setting in connection control stream, the
   HTTP/2 SETTINGS SETTINGS_ACK frame (see Section 3), MUST have a
   length which defaults to 1 (true).

   As with server push for HTTP/2-over-TCP, the server initiates is a
   server push by sending an HTTP/2 PUSH_PROMISE multiple of two octets.  A SETTINGS_ACK frame containing the
   StreamID of the stream to
   any other length MUST be pushed, as well treated as request header fields
   attributed to a connection error of type
   HTTP_MALFORMED_SETTINGS_ACK.

6.  Error Handling

   This section describes the request.  The PUSH_PROMISE frame is sent on stream
   3, to ensure proper ordering with respect specific error codes defined by HTTP and
   the mapping of HTTP/2 error codes into the QUIC error code space.

6.1.  HTTP-Defined QUIC Error Codes

   QUIC allocates error codes 0x0000-0x3FFF to other HEADERS application protocol
   definition.  The following error codes are defined by HTTP for use in
   QUIC RST_STREAM, GOAWAY, and non-
   data CONNECTION_CLOSE frames.  Within the PUSH_PROMISE frame, the StreamID in the
   common HTTP/2

   HTTP_SETTINGS_TIMEOUT (0x00):  After sending a SETTINGS frame header indicates the associated (client-
   initiated) stream for which
      requested acknowledgement, the new acknowledgement was not completed
      (see Section 5.2.5.3) in a timely manner.

   HTTP_PUSH_REFUSED (0x01):  The server has attempted to push stream, while the Promised Stream
   ID field specifies content
      which the StreamID of client will not accept on this connection.

   HTTP_INTERNAL_ERROR (0x02):  An internal error has occurred in the new push stream.
      HTTP stack.

   HTTP_PUSH_ALREADY_IN_CACHE (0x03):  The server has attempted to push
      content which the client has cached.

   HTTP_REQUEST_CANCELLED (0x04):  The client no longer needs the
      requested data.

   HTTP_HPACK_DECOMPRESSION_FAILED (0x05):  HPACK failed to decompress a
      frame and cannot continue.

   HTTP_CONNECT_ERROR (0x06):  The connection established in response to
      a CONNECT request was reset or abnormally closed.

   HTTP_EXCESSIVE_LOAD (0x07):  The endpoint detected that its peer is conveyed in the same way as
      exhibiting a non-server-
   push response, behavior that might be generating excessive load.

   HTTP_VERSION_FALLBACK (0x08):  The requested operation cannot be
      served over HTTP/QUIC.  The peer should retry over HTTP/2.

   HTTP_MALFORMED_HEADERS (0x09):  A HEADERS frame has been received
      with response headers and (if present) trailers
   carried by HTTP/2 an invalid format.

   HTTP_MALFORMED_PRIORITY (0x0A):  A HEADERS frames sent on reserved stream 3, and
   response body (if any) sent via QUIC stream frames on the stream
   specified in frame has been received
      with an invalid format.

   HTTP_MALFORMED_SETTINGS (0x0B):  A HEADERS frame has been received
      with an invalid format.

   HTTP_MALFORMED_PUSH_PROMISE (0x0C):  A HEADERS frame has been
      received with an invalid format.

   HTTP_MALFORMED_SETTINGS_ACK (0x0D):  A HEADERS frame has been
      received with an invalid format.

   HTTP_INTERRUPTED_HEADERS (0x0E):  A HEADERS frame without the corresponding PUSH_PROMISE frame.

10. End
      Header Block flag was followed by a frame other than HEADERS.

   HTTP_SETTINGS_ON_WRONG_STREAM (0x0F):  A SETTINGS frame was received
      on a request control stream.

6.2.  Mapping HTTP/2 Error Codes

   The HTTP/2 error codes defined in Section 7 of [RFC7540] map to QUIC
   error codes as follows:

   NO_ERROR (0x0):  Maps to  QUIC_NO_ERROR

   PROTOCOL_ERROR (0x1):  No single mapping?

   INTERNAL_ERROR (0x2)  QUIC_INTERNAL_ERROR? (not currently defined in
      core protocol spec)

   FLOW_CONTROL_ERROR (0x3):  QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA?
      (not currently defined in core protocol spec)

   SETTINGS_TIMEOUT (0x4):  (depends on whether we support SETTINGS
      acks)

   STREAM_CLOSED (0x5):  QUIC_STREAM_DATA_AFTER_TERMINATION

   FRAME_SIZE_ERROR (0x6)  QUIC_INVALID_FRAME_DATA

   REFUSED_STREAM (0x7):  ?

   CANCEL (0x8):  ?

   COMPRESSION_ERROR (0x9):  QUIC_DECOMPRESSION_FAILURE (not currently mapping.  See new HTTP_MALFORMED_*
      error codes defined in core spec)

   CONNECT_ERROR (0xa):  ? (depends whether we decide to support
      CONNECT)

   ENHANCE_YOUR_CALM (0xb):  ?

   INADEQUATE_SECURITY (0xc):  QUIC_HANDSHAKE_FAILED,
      QUIC_CRYPTO_NO_SUPPORT

   HTTP_1_1_REQUIRED (0xd):  ?

   TODO: fill Section 6.1.

   INTERNAL_ERROR (0x2)  HTTP_INTERNAL_ERROR in missing error code mappings.

11.  Other HTTP/2 frames Section 6.1.

   FLOW_CONTROL_ERROR (0x3):  Not applicable, since QUIC includes some features (e.g. handles flow control) which are also
   present in HTTP/2.  In these cases the HTTP/2 mapping need not re-
   implement them.  As
      control.  Would provoke a result some HTTP/2 frame types are not required
   when using QUIC, as they either are directly implemented in the QUIC
   layer, or their functionality is provided via other means.  This
   section of QUIC_FLOW_CONTROL_RECEIVED_TOO_MUCH_DATA
      from the document describes these cases.

11.1.  GOAWAY frame QUIC has its own GOAWAY frame, and layer.

   SETTINGS_TIMEOUT (0x4):  HTTP_SETTINGS_TIMEOUT in Section 6.1.

   STREAM_CLOSED (0x5):  Not applicable, since QUIC implementations may to expose
   the sending of handles stream
      management.  Would provoke a GOAWAY to QUIC_STREAM_DATA_AFTER_TERMINATION
      from the application.  The semantics of sending
   a GOAWAY in QUIC are identical to HTTP/2: an endpoint sending a
   GOAWAY will continue processing open streams, but will not accept
   newly created streams.

   QUIC's GOAWAY frame is described in detail layer.

   FRAME_SIZE_ERROR (0x6)  No single mapping.  See new error codes
      defined in the [QUIC-TRANSPORT].

11.2.  PING frame Section 6.1.

   REFUSED_STREAM (0x7):  Not applicable, since QUIC has its own PING frame, which is currently exposed to handles stream
      management.  Would provoke a QUIC_TOO_MANY_OPEN_STREAMS from the
   application.
      QUIC clients send periodic PINGs to servers if there
   are no currently active data streams on the connection.

   QUIC's PING frame is described layer.

   CANCEL (0x8):  HTTP_REQUEST_CANCELLED in detail Section 6.1.

   COMPRESSION_ERROR (0x9):  HTTP_HPACK_DECOMPRESSION_FAILED in the [QUIC-TRANSPORT].

11.3.  PADDING frame

   There is no HTTP/2 padding
      Section 6.1.

   CONNECT_ERROR (0xa):  HTTP_CONNECT_ERROR in this mapping; padding is instead
   provided at the QUIC layer by including QUIC PADDING frames Section 6.1.

   ENHANCE_YOUR_CALM (0xb):  HTTP_EXCESSIVE_LOAD in a
   packet payload.  An HTTP/2 over QUIC mapping should treat any HTTP/2
   level padding as an error, to avoid any possibility of inconsistent
   flow control states between endpoints (e.g. client sends HTTP/2
   padding, counts it against flow control, server ignores).

12. Section 6.1.

   INADEQUATE_SECURITY (0xc):  Not applicable, since QUIC is assumed to
      provide sufficient security on all connections.

   HTTP_1_1_REQUIRED (0xd):  HTTP_VERSION_FALLBACK in Section 6.1.

   TODO: fill in missing error code mappings.

7.  Security Considerations

   The security considerations of HTTP over QUIC should be comparable to
   those of HTTP/2.

13.

   The modified SETTINGS format contains nested length elements, which
   could pose a security risk to an uncautious implementer.  A SETTINGS
   frame parser MUST ensure that the length of the frame exactly matches
   the length of the settings it contains.

8.  IANA Considerations

8.1.  Registration of HTTP/QUIC Identification String

   This document has no IANA actions.  Yet.

14. creates a new registration for the identification of
   HTTP/QUIC in the "Application Layer Protocol Negotiation (ALPN)
   Protocol IDs" registry established in [RFC7301].

   The "hq" string identifies HTTP/QUIC:

   Protocol:  HTTP over QUIC

   Identification Sequence:  0x68 0x71 ("hq")

   Specification:  This document

8.2.  Registration of Version Hint Alt-Svc Parameter

   This document creates a new registration for version-negotiation
   hints in the "Hypertext Transfer Protocol (HTTP) Alt-Svc Parameter"
   registry established in [RFC7838].

   Parameter:  "v"

   Specification:  This document, Section 2.1

8.3.  Existing Frame Types

   This document adds two new columns to the "HTTP/2 Frame Type"
   registry defined in [RFC7540]:

   Supported Protocols:  Indicates which associated protocols use the
      frame type.  Values MUST be one of:

      *  "HTTP/2 only"

      *  "HTTP/QUIC only"

      *  "Both"

   HTTP/QUIC Specification:  Indicates where this frame's behavior over
      QUIC is defined; required if the frame is supported over QUIC.

   Values for existing registrations are assigned by this document:

   +---+---------------+---------------------+-------------------------+
   |   |   Frame Type  | Supported Protocols | HTTP/QUIC Specification |
   +---+---------------+---------------------+-------------------------+
   |   |      DATA     | HTTP/2 only         | N/A                     |
   |   |               |                     |                         |
   |   |    HEADERS    | Both                | Section 5.2.2           |
   |   |               |                     |                         |
   |   |    PRIORITY   | Both                | Section 5.2.3           |
   |   |               |                     |                         |
   |   |   RST_STREAM  | HTTP/2 only         | N/A                     |
   |   |               |                     |                         |
   |   |    SETTINGS   | Both                | Section 5.2.5           |
   |   |               |                     |                         |
   |   |  PUSH_PROMISE | Both                | Section 5.2.6           |
   |   |               |                     |                         |
   |   |      PING     | HTTP/2 only         | N/A                     |
   |   |               |                     |                         |
   |   |     GOAWAY    | HTTP/2 only         | N/A                     |
   |   |               |                     |                         |
   |   | WINDOW_UPDATE | HTTP/2 only         | N/A                     |
   |   |               |                     |                         |
   |   |  CONTINUATION | HTTP/2 only         | N/A                     |
   +---+---------------+---------------------+-------------------------+

   The "Specification" column is renamed to "HTTP/2 specification" and
   is only required if the frame is supported over HTTP/2.

8.4.  New Frame Types

   This document adds one new entry to the "HTTP/2 Frame Type" registry
   defined in [RFC7540]:

   Frame Type:  SETTINGS_ACK

   Code:  0x0b

   HTTP/2 Specification:  N/A

   Supported Protocols:  HTTP/QUIC only

   HTTP/QUIC Specification:  Section 5.2.11

9.  References

9.1.  Normative References

   [QUIC-TLS]
              Thomson, M., Ed. and S. Turner, Ed, Ed., "Using Transport
              Layer Security (TLS) to Secure QUIC", November 2016. QUIC".

   [QUIC-TRANSPORT]
              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", November 2016. Transport".

   [RFC0793]  Postel, J., "Transmission Control Protocol", STD 7,
              RFC 793, DOI 10.17487/RFC0793, September 1981,
              <http://www.rfc-editor.org/info/rfc793>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Message Syntax and Routing",
              RFC 7230, DOI 10.17487/RFC7230, June 2014,
              <http://www.rfc-editor.org/info/rfc7230>.

   [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
              Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
              DOI 10.17487/RFC7231, June 2014,
              <http://www.rfc-editor.org/info/rfc7231>.

   [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
              Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
              DOI 10.17487/RFC7540, May 2015,
              <http://www.rfc-editor.org/info/rfc7540>.

   [RFC7541]  Peon, R. and H. Ruellan, "HPACK: Header Compression for
              HTTP/2", RFC 7541, DOI 10.17487/RFC7541, May 2015,
              <http://www.rfc-editor.org/info/rfc7541>.

   [RFC7838]  Nottingham, M., McManus, P., and J. Reschke, "HTTP
              Alternative Services", RFC 7838, DOI 10.17487/RFC7838,
              April 2016, <http://www.rfc-editor.org/info/rfc7838>.

9.2.  Informative References

   [RFC7301]  Friedl, S., Popov, A., Langley, A., and E. Stephan,
              "Transport Layer Security (TLS) Application-Layer Protocol
              Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
              July 2014, <http://www.rfc-editor.org/info/rfc7301>.

Appendix A.  Contributors

   The original authors of this specification were Robbie Shade and Mike
   Warres.

Appendix B.  Change Log

      *RFC Editor's Note:* Please remove this section prior to
      publication of a final version of this document.

B.1.  Since draft-ietf-quic-http-00:

   o  Changed "HTTP/2-over-QUIC" to "HTTP/QUIC" throughout

   o  Changed from using HTTP/2 framing within Stream 3 to new framing
      format and two-stream-per-request model

   o  Adopted SETTINGS format from draft-bishop-httpbis-extended-
      settings-01

   o  Reworked SETTINGS_ACK to account for indeterminate inter-stream
      order.

   o  Described CONNECT pseudo-method

   o  Updated ALPN token and Alt-Svc guidance

   o  Application-layer-defined error codes

B.2.  Since draft-shade-quic-http2-mapping-00:

   o  Adopted as base for draft-ietf-quic-http.

   o  Updated authors/editors list.

Author's Address

   Mike Bishop (editor)
   Microsoft

   Email: Mike.Bishop@microsoft.com Michael.Bishop@microsoft.com