Draft: draft-ietf-quic-http

Commentary: Martin flagged this on some imported text in , but others have crept in other places , mostly also as text imported from RFC7540 . For future reference , ( ( { { ] ) ) , ( Section \d+(.\d+ ) * ) = 1
Paragraph (version A):
the message header (see RFC7230, Section 3.2), sent as a single
HEADERS frame (see frame-headers),
Paragraph (version A):
optionally, the payload body, if present (see RFC7230,
Section 3.3), sent as a series of DATA frames (see frame-data),
Paragraph (version A):
optionally, trailing headers, if present (see RFC7230,
Section 4.1.2), sent as a single HEADERS frame.
Paragraph (version B):
the message header (see Section 3.2 of RFC7230), sent as a single
HEADERS frame (see frame-headers),
Paragraph (version B):
optionally, the payload body, if present (see Section 3.3 of
RFC7230), sent as a series of DATA frames (see frame-data),
Paragraph (version B):
optionally, trailing headers, if present (see Section 4.1.2 of
RFC7230), sent as a single HEADERS frame.
Paragraph (version A):
A response MAY consist of multiple messages when and only when one or
more informational responses (1xx; see RFC7231, Section 6.2) precede
a final response to the same request.  Non-final responses do not
contain a payload body or trailers.
Paragraph (version B):
A response MAY consist of multiple messages when and only when one or
more informational responses (1xx; see Section 6.2 of RFC7231)
precede a final response to the same request.  Non-final responses do
not contain a payload body or trailers.
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
before being passed into a non-HTTP/2, non-HTTP/3 context, as
described in HTTP2, Section 8.1.2.5.
Paragraph (version B):
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
before being passed into a non-HTTP/2, non-HTTP/3 context, as
described in Section 8.1.2.5 of HTTP2.
Paragraph (version A):
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.
Paragraph (version A):
A CONNECT request in HTTP/3 functions in the same manner as in
HTTP/2.  The request MUST be formatted as described in HTTP2,
Section 8.3.  A CONNECT request that does not conform to these
restrictions is malformed (see malformed).  The request stream MUST
NOT be closed at the end of the request.
Paragraph (version A):
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.
Paragraph (version B):
The pseudo-method CONNECT (Section 4.3.6 of RFC7231) 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.
Paragraph (version B):
A CONNECT request in HTTP/3 functions in the same manner as in
HTTP/2.  The request MUST be formatted as described in Section 8.3 of
HTTP2.  A CONNECT request that does not conform to these restrictions
is malformed (see malformed).  The request stream MUST NOT be closed
at the end of the request.
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 4.3.6 of RFC7231.
Paragraph (version A):
HTTP/3 does not support the HTTP Upgrade mechanism (RFC7230,
Section 6.7) or 101 (Switching Protocols) informational status code
(RFC7231, Section 6.2.2).
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 6.7 of
RFC7230) or 101 (Switching Protocols) informational status code
(Section 6.2.2 of RFC7231).