Draft: draft-ietf-quic-http

Commentary: by migrating all RFC723X references to http - core drafts by changing all HTTP references to " HTTP ( header ) fields " ; core editors especially , please double - check my use of the new terminology I have not attempted to make corresponding changes to QPACK ; I can do that in a future PR if you do n't get to it first . Precursor to fixing and , since they depend on text in http - core 
 Note that my intention in this PR is to keep the references to HTTP/1.1 ( draft - ietf - httpbis - messaging ) informative - only , though some of those references flirt with the boundary of normative a little too closely . I 've filed a few http - core issues where something that 's used cross - version is found in the 1.1 draft . 
 Yes , I assume we 'll need to do a pass once the docs are mostly - final to verify all the references , particularly to things that have n't hit RFC yet . I do n't feel like that would be substantially more work than re - doing this migration at some point in the future . 
 Landing now ; any additional work can be in a follow - up PR . 
 HTTP - core is making some terminology changes that HTTP/3 should track : In , " non - final " responses are " interim " responses In , terminology around header , field , value is changing Related to , but this is more than just pointing at the new documents . 
 Some references in HTTP / QUIC would benefit from invoking the HTTPter drafts instead , if they finish before we do . For example , the text is is unnecessarily awkward because it references concepts from RFC 7230 while disclaiming the wire format . The equivalent text in is far more appropriate . 
 I think this should be unparked before last call . 
 The intent was to make the cut - over if the dependency would not delay QUIC . It seems like they 're progressing quickly enough that we could probably do that . 
 I 'm a bit concerned because in the core specs , sections will still move around , and in the MD format , you have no way to automatically adjust those references automatically ... LGTM modulo nits .
Paragraph (version A):
HTTP semantics are used for a broad range of services on the
Internet.  These semantics have commonly been used with two different
TCP mappings, HTTP/1.1 and HTTP/2.  HTTP/3 supports the same
semantics over a new transport protocol, QUIC.
Paragraph (version A):
HTTP/1.1 is a TCP mapping which uses whitespace-delimited text fields
to convey HTTP messages.  While these exchanges are human-readable,
using whitespace for message formatting leads to parsing difficulties
and workarounds to be tolerant of variant behavior.  Because each
connection can transfer only a single HTTP request or response at a
time in each direction, multiple parallel TCP connections are often
used, reducing the ability of the congestion controller to accurately
manage traffic between endpoints.
Paragraph (version A):
HTTP/2 introduced a binary framing and multiplexing layer to improve
latency without modifying the transport layer.  However, because the
parallel nature of HTTP/2's multiplexing is not visible to TCP's loss
recovery mechanisms, a lost or reordered packet causes all active
transactions to experience a stall regardless of whether that
transaction was impacted by the lost packet.
Paragraph (version B):
HTTP semantics SEMANTICS are used for a broad range of services on
the Internet.  These semantics have most commonly been used with two
different TCP mappings, HTTP/1.1 and HTTP/2.  HTTP/3 supports the
same semantics over a new transport protocol, QUIC.
Paragraph (version B):
HTTP/1.1 HTTP11 is a TCP mapping which uses whitespace-delimited text
fields to convey HTTP messages.  While these exchanges are human-
readable, using whitespace for message formatting leads to parsing
complexity and motivates tolerance of variant behavior.  Because each
connection can transfer only a single HTTP request or response at a
time in each direction, multiple parallel TCP connections are often
used, reducing the ability of the congestion controller to
effectively manage traffic between endpoints.
Paragraph (version A):
As in HTTP/2, request and response headers are compressed for
transmission.  Because HPACK HPACK relies on in-order transmission of
compressed header blocks (a guarantee not provided by QUIC), HTTP/3
replaces HPACK with QPACK QPACK.  QPACK uses separate unidirectional
streams to modify and track header table state, while header blocks
refer to the state of the table without modifying it.
Paragraph (version A):
The term "payload body" is defined in Section 3.3 of RFC7230.
Paragraph (version A):
Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"
are defined in Section 2.3 of RFC7230.  Intermediaries act as both
client and server at different times.
Paragraph (version B):
The term "payload body" is defined in Section 6.3.3 of SEMANTICS.
Paragraph (version B):
Finally, the terms "gateway", "intermediary", "proxy", and "tunnel"
are defined in Section 2.2 of SEMANTICS.  Intermediaries act as both
client and server at different times.
Paragraph (version A):
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 "h3-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.
Paragraph (version B):
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 "h3-09-rickroll".  Note
that any label MUST conform to the "token" syntax defined in
Section 4.4.1.1 of SEMANTICS.  Experimenters are encouraged to
coordinate their experiments on the quic@ietf.org mailing list.
Paragraph (version A):
A client sends an HTTP request on a client-initiated bidirectional
QUIC stream.  A client MUST send only a single request on a given
stream.  A server sends zero or more non-final HTTP responses on the
same stream as the request, followed by a single final HTTP response,
as detailed below.
Paragraph (version A):
Pushed responses are sent on a server-initiated unidirectional QUIC
stream (see push-streams).  A server sends zero or more non-final
HTTP responses, followed by a single final HTTP response, in the same
manner as a standard response.  Push is described in more detail in
server-push.
Paragraph (version B):
Pushed responses are sent on a server-initiated unidirectional QUIC
stream (see push-streams).  A server sends zero or more interim HTTP
responses, followed by a single final HTTP response, in the same
manner as a standard response.  Push is described in more detail in
server-push.
Paragraph (version B):
the header field section (see Section 4 of SEMANTICS), sent as a
single HEADERS frame (see frame-headers),
Paragraph (version B):
optionally, the payload body, if present (see Section 6.3.3 of
SEMANTICS), sent as a series of DATA frames (see frame-data),
Paragraph (version B):
optionally, the trailer field section, if present (see Section 4.6
of SEMANTICS), sent as a single HEADERS frame.
Paragraph (version A):
The "chunked" transfer encoding defined in Section 4.1 of RFC7230
MUST NOT be used.
Paragraph (version B):
A response MAY consist of multiple messages when and only when one or
more informational responses (1xx; see Section 9.2 of SEMANTICS)
precede a final response to the same request.  Interim responses do
not contain a payload body or trailers.
Paragraph (version A):
HTTP message headers carry information as a series of key-value
pairs, called header fields.  For a listing of registered HTTP header
fields, see the "Message Header Field" registry maintained at
https://www.iana.org/assignments/message-headers [4].
Paragraph (version A):
Just as in previous versions of HTTP, header field names are strings
of ASCII characters that are compared in a case-insensitive fashion.
Properties of HTTP header field names and values are discussed in
more detail in Section 3.2 of RFC7230, though the wire rendering in
HTTP/3 differs.  As in HTTP/2, header field names MUST be converted
to lowercase prior to their encoding.  A request or response
containing uppercase header field names MUST be treated as malformed
(malformed).
Paragraph (version A):
Like HTTP/2, HTTP/3 does not use the Connection header field to
indicate connection-specific header fields; in this protocol,
connection-specific metadata is conveyed by other means.  An endpoint
MUST NOT generate an HTTP/3 message containing connection-specific
header fields; any message containing connection-specific header
fields MUST be treated as malformed (malformed).
Paragraph (version A):
The only exception to this is the TE header field, which MAY be
present in an HTTP/3 request; when it is, it MUST NOT contain any
value other than "trailers".
Paragraph (version A):
This means that an intermediary transforming an HTTP/1.x message to
HTTP/3 will need to remove any header fields nominated by the
Connection header field, along with the Connection header field
itself.  Such intermediaries SHOULD also remove other connection-
specific header fields, such as Keep-Alive, Proxy-Connection,
Transfer-Encoding, and Upgrade, even if they are not nominated by the
Connection header field.
Paragraph (version A):
As in HTTP/2, HTTP/3 uses special pseudo-header fields beginning with
the ':' character (ASCII 0x3a) to convey the target URI, the method
of the request, and the status code for the response.
Paragraph (version A):
Pseudo-header fields are not HTTP header fields.  Endpoints MUST NOT
generate pseudo-header fields other than those defined in this
document, except as negotiated via an extension; see extensions.
Paragraph (version B):
HTTP messages carry metadata as a series of key-value pairs, called
HTTP fields.  For a listing of registered HTTP fields, see the
"Hypertext Transfer Protocol (HTTP) Field Name Registry" maintained
at https://www.iana.org/assignments/http-fields/ [4].
Paragraph (version B):
As in previous versions of HTTP, field names are strings containing a
subset of ASCII characters that are compared in a case-insensitive
fashion.  Properties of HTTP field names and values are discussed in
more detail in Section 4.3 of SEMANTICS.  As in HTTP/2, characters in
field names MUST be converted to lowercase prior to their encoding.
A request or response containing uppercase characters in field names
MUST be treated as malformed (malformed).
Paragraph (version B):
Like HTTP/2, HTTP/3 does not use the Connection header field to
indicate connection-specific fields; in this protocol, connection-
specific metadata is conveyed by other means.  An endpoint MUST NOT
generate an HTTP/3 field section containing connection-specific
fields; any message containing connection-specific fields MUST be
treated as malformed (malformed).
Paragraph (version B):
The only exception to this is the TE header field, which MAY be
present in an HTTP/3 request header; when it is, it MUST NOT contain
any value other than "trailers".
Paragraph (version B):
Like HTTP/2, HTTP/3 employs a series of pseudo-header fields where
the field name begins with the ':' character (ASCII 0x3a).  These
pseudo-header fields convey the target URI, the method of the
request, and the status code for the response.
Paragraph (version B):
Pseudo-header fields are not HTTP fields.  Endpoints MUST NOT
generate pseudo-header fields other than those defined in this
document, except as negotiated via an extension; see extensions.
Paragraph (version A):
All pseudo-header fields MUST appear in the header block before
regular header fields.  Any request or response that contains a
pseudo-header field that appears in a header block after a regular
header field MUST be treated as malformed (malformed).
Paragraph (version A):
To ensure that the HTTP/1.1 request line can be reproduced
accurately, this pseudo-header field MUST be omitted when
translating from an HTTP/1.1 request that has a request target in
origin or asterisk form (see Section 5.3 of RFC7230).  Clients
that generate HTTP/3 requests directly SHOULD use the ":authority"
pseudo-header field instead of the Host header field.  An
intermediary that converts an HTTP/3 request to HTTP/1.1 MUST
create a Host header field if one is not present in a request by
copying the value of the ":authority" pseudo-header field.
Paragraph (version B):
To ensure that the HTTP/1.1 request line can be reproduced
accurately, this pseudo-header field MUST be omitted when
translating from an HTTP/1.1 request that has a request target in
origin or asterisk form (see Section 3.2 of HTTP11).  Clients that
generate HTTP/3 requests directly SHOULD use the ":authority"
pseudo-header field instead of the Host field.  An intermediary
that converts an HTTP/3 request to HTTP/1.1 MUST create a Host
field if one is not present in a request by copying the value of
the ":authority" pseudo-header field.
Paragraph (version A):
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'.  The exception to this rule is an
OPTIONS request for an "http" or "https" URI that does not include
a path component; these MUST include a ":path" pseudo-header field
with a value of '*' (see Section 5.3.4 of RFC7230).
Paragraph (version A):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
request (connect).  An HTTP request that omits mandatory pseudo-
header fields or contains invalid values for those fields is
malformed (malformed).
Paragraph (version A):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code field (see Section 6 of RFC7231).  This
pseudo-header field MUST be included in all responses; otherwise, the
response is malformed (malformed).
Paragraph (version B):
This pseudo-header field MUST NOT be empty for "http" or "https"
URIs; "http" or "https" URIs that do not contain a path component
MUST include a value of '/'.  The exception to this rule is an
OPTIONS request for an "http" or "https" URI that does not include
a path component; these MUST include a ":path" pseudo-header field
with a value of '*' (see Section 3.2.4 of HTTP11).
Paragraph (version B):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless it is a CONNECT
request (connect).  An HTTP request that omits mandatory pseudo-
header fields or contains invalid values for those pseudo-header
fields is malformed (malformed).
Paragraph (version B):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code (see Section 9 of SEMANTICS).  This
pseudo-header field MUST be included in all responses; otherwise, the
response is malformed (malformed).
Paragraph (version A):
HTTP/3 uses QPACK header compression as described in QPACK, a
variation of HPACK which allows the flexibility to avoid header-
compression-induced head-of-line blocking.  See that document for
additional details.
Paragraph (version A):
To allow for better compression efficiency, the cookie header field
RFC6265 MAY be split into separate header fields, each with one or
more cookie-pairs, before compression.  If a decompressed header list
contains multiple cookie header fields, these MUST be concatenated
into a single octet string using the two-octet delimiter of 0x3B,
0x20 (the ASCII string "; ") before being passed into a context other
than HTTP/2 or HTTP/3, such as an HTTP/1.1 connection, or a generic
HTTP server application.
Paragraph (version A):
An HTTP/3 implementation MAY impose a limit on the maximum size of
the message header it will accept on an individual HTTP message.  A
server that receives a larger header field list than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status
code RFC6585.  A client can discard responses that it cannot process.
The size of a header field list is calculated based on the
uncompressed size of header fields, including the length of the name
and value in bytes plus an overhead of 32 bytes for each header
field.
Paragraph (version A):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the
"SETTINGS_MAX_HEADER_LIST_SIZE" parameter.  An implementation which
has received this parameter SHOULD NOT send an HTTP message header
which exceeds the indicated size, as the peer will likely refuse to
process it.  However, because this limit is applied at each hop,
messages below this limit are not guaranteed to be accepted.
Paragraph (version B):
An HTTP/3 implementation MAY impose a limit on the maximum size of
the message header it will accept on an individual HTTP message.  A
server that receives a larger header section than it is willing to
handle can send an HTTP 431 (Request Header Fields Too Large) status
code (RFC6585).  A client can discard responses that it cannot
process.  The size of a field list is calculated based on the
uncompressed size of fields, including the length of the name and
value in bytes plus an overhead of 32 bytes for each field.
Paragraph (version B):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the
"SETTINGS_MAX_FIELD_SECTION_SIZE" parameter.  An implementation which
has received this parameter SHOULD NOT send an HTTP message header
which exceeds the indicated size, as the peer will likely refuse to
process it.  However, because this limit is applied at each hop,
messages below this limit are not guaranteed to be accepted.
Paragraph (version A):
the presence of prohibited header fields or pseudo-header fields,
Paragraph (version A):
pseudo-header fields after header fields,
Paragraph (version A):
the inclusion of uppercase header field names.
Paragraph (version A):
A request or response that includes a payload body can include a
"content-length" header field.  A request or response is also
malformed if the value of a content-length header field does not
equal the sum of the DATA frame payload lengths that form the body.
A response that is defined to have no payload, as described in
Section 3.3.2 of RFC7230 can have a non-zero content-length header
field, even though no content is included in DATA frames.
Paragraph (version B):
the presence of prohibited fields or pseudo-header fields,
Paragraph (version B):
pseudo-header fields after fields,
Paragraph (version B):
the inclusion of uppercase field names.
Paragraph (version B):
A request or response that includes a payload body can include a
"content-length" header field.  A request or response is also
malformed if the value of a content-length header field does not
equal the sum of the DATA frame payload lengths that form the body.
A response that is defined to have no payload, as described in
Section 6.3.3 of SEMANTICS can have a non-zero content-length field,
even though no content is included in DATA frames.
Paragraph (version A):
The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target
(Section 4.3.6 of RFC7231).  It is primarily used with HTTP proxies
to establish a TLS session with an origin server for the purposes of
interacting with "https" resources.
Paragraph (version B):
The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target
(Section 3.2 of HTTP11).  It is primarily used with HTTP proxies to
establish a TLS session with an origin server for the purposes of
interacting with "https" resources.
Paragraph (version B):
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 Section 9.3 of SEMANTICS.
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 9.9 of
HTTP11) or 101 (Switching Protocols) informational status code
(Section 9.2.2 of SEMANTICS).
Paragraph (version A):
Each server push is identified by a unique Push ID.  This Push ID is
used in one or more PUSH_PROMISE frames (see frame-push-promise) that
carry the request headers, then included with the push stream which
ultimately fulfills those promises.  When the same Push ID is
promised on multiple request streams, the decompressed request header
sets MUST contain the same fields in the same order, and both the
name and the value in each field MUST be exact matches.
Paragraph (version A):
The header of the request message is carried by a PUSH_PROMISE frame
(see frame-push-promise) on the request stream which generated the
push.  This allows the server push to be associated with a client
request.
Paragraph (version A):
Due to reordering, push stream data can arrive before the
corresponding PUSH_PROMISE frame.  When a client receives a new push
stream with an as-yet-unknown Push ID, both the associated client
request and the pushed request headers are unknown.  The client can
buffer the stream data in expectation of the matching PUSH_PROMISE.
The client can use stream flow control (see section 4.1 of QUIC-
TRANSPORT) to limit the amount of data a server may commit to the
pushed stream.
Paragraph (version B):
Due to reordering, push stream data can arrive before the
corresponding PUSH_PROMISE frame.  When a client receives a new push
stream with an as-yet-unknown Push ID, both the associated client
request and the pushed request header fields are unknown.  The client
can buffer the stream data in expectation of the matching
PUSH_PROMISE.  The client can use stream flow control (see section
commit to the pushed stream.
Paragraph (version A):
Pushed responses that are cacheable (see Section 3 of RFC7234) can be
stored by the client, if it implements an HTTP cache.  Pushed
responses are considered successfully validated on the origin server
(e.g., if the "no-cache" cache response directive is present
(Section 5.2.2 of RFC7234)) at the time the pushed response is
received.
Paragraph (version A):
When HTTP headers and data are sent over QUIC, the QUIC layer handles
most of the stream management.  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 or connection context.
Paragraph (version B):
When HTTP fields and data are sent over QUIC, the QUIC layer handles
most of the stream management.  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 or connection context.
Paragraph (version A):
A push stream is indicated by a stream type of "0x01", followed by
the Push ID of the promise that it fulfills, encoded as a variable-
length integer.  The remaining data on this stream consists of HTTP/3
frames, as defined in frames, and fulfills a promised server push by
zero or more non-final HTTP responses followed by a single final HTTP
response, as defined in request-response.  Server push and Push IDs
are described in server-push.
Paragraph (version B):
A push stream is indicated by a stream type of "0x01", followed by
the Push ID of the promise that it fulfills, encoded as a variable-
length integer.  The remaining data on this stream consists of HTTP/3
frames, as defined in frames, and fulfills a promised server push by
zero or more interim HTTP responses followed by a single final HTTP
response, as defined in request-response.  Server push and Push IDs
are described in server-push.
Paragraph (version A):
The HEADERS frame (type=0x1) is used to carry a header block,
compressed using QPACK.  See QPACK for more details.
Paragraph (version B):
The HEADERS frame (type=0x1) is used to carry an HTTP field section,
encoded using QPACK.  See QPACK for more details.
Paragraph (version A):
Different values for the same parameter can be advertised by each
peer.  For example, a client might be willing to consume a very large
response header, while servers are more cautious about request size.
Paragraph (version B):
Different values for the same parameter can be advertised by each
peer.  For example, a client might be willing to consume a very large
response field section, while servers are more cautious about request
size.
Paragraph (version A):
The PUSH_PROMISE frame (type=0x5) is used to carry a promised request
header set from server to client on a request stream, as in HTTP/2.
Paragraph (version A):
QPACK-compressed request header fields for the promised response.
See QPACK for more details.
Paragraph (version B):
QPACK-encoded request header fields for the promised response.
See QPACK for more details.
Paragraph (version A):
A server MAY use the same Push ID in multiple PUSH_PROMISE frames.
If so, the decompressed request header sets MUST contain the same
fields in the same order, and both the name and the value in each
field MUST be exact matches.  Clients SHOULD compare the request
header sets for resources promised multiple times.  If a client
receives a Push ID that has already been promised and detects a
mismatch, it MUST respond with a connection error of type
H3_GENERAL_PROTOCOL_ERROR.  If the decompressed header sets match
exactly, the client SHOULD associate the pushed content with each
stream on which a PUSH_PROMISE was received.
Paragraph (version A):
This applies to the protocol elements defined in this document.  This
does not affect the existing options for extending HTTP, such as
defining new methods, status codes, or header fields.
Paragraph (version B):
This applies to the protocol elements defined in this document.  This
does not affect the existing options for extending HTTP, such as
defining new methods, status codes, or fields.