Draft: draft-ietf-quic-http

Commentary: note : " payload body " -"payload data "
Paragraph (version A):
The term "payload body" is defined in Section 5.5.4 of SEMANTICS.
Paragraph (version B):
The term "payload data" is defined in Section 6.4 of SEMANTICS.
Paragraph (version A):
A client sends an HTTP request on a request stream, which is a
client-initiated bidirectional QUIC stream; see request-streams.  A
client MUST send only a single request on a given stream.  A server
sends zero or more interim HTTP responses on the same stream as the
request, followed by a single final HTTP response, as detailed below.
See Section 14 of SEMANTICS for a description of interim and final
HTTP responses.
Paragraph (version B):
A client sends an HTTP request on a request stream, which is a
client-initiated bidirectional QUIC stream; see request-streams.  A
client MUST send only a single request on a given stream.  A server
sends zero or more interim HTTP responses on the same stream as the
request, followed by a single final HTTP response, as detailed below.
See Section 15 of SEMANTICS for a description of interim and final
HTTP responses.
Paragraph (version A):
Header and trailer field sections are described in Sections 5.4 and
SEMANTICS.
Paragraph (version B):
Header and trailer field sections are described in Sections 6.3 and
SEMANTICS.
Paragraph (version A):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see Section 14.2 of SEMANTICS) precede a
final response to the same request.  Interim 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 interim responses (1xx; see Section 15.2 of SEMANTICS) precede a
final response to the same request.  Interim responses do not contain
payload data or trailers.
Paragraph (version A):
HTTP messages carry metadata as a series of key-value pairs called
HTTP fields; see Sections 5.4 and 5.6 of SEMANTICS.  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/>.
Paragraph (version B):
HTTP messages carry metadata as a series of key-value pairs called
HTTP fields; see Sections 6.3 and 6.5 of SEMANTICS.  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/>.
Paragraph (version A):
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 5.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):
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 5.1 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 A):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see Section 14 of SEMANTICS.  This
pseudo-header field MUST be included in all responses; otherwise, the
response is malformed (malformed).
Paragraph (version B):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see Section 15 of SEMANTICS.  This
pseudo-header field MUST be included in all responses; otherwise, the
response is malformed (malformed).
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_FIELD_SECTION_SIZE parameter.  An implementation that
has received this parameter SHOULD NOT send an HTTP message header
that exceeds the indicated size, as the peer will likely refuse to
process it.  However, an HTTP message can traverse one or more
intermediaries before reaching the origin server; see Section 3.7 of
SEMANTICS.  Because this limit is applied separately by each
implementation which processes the message, messages below this limit
are not guaranteed to be accepted.
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 that
has received this parameter SHOULD NOT send an HTTP message header
that exceeds the indicated size, as the peer will likely refuse to
process it.  However, an HTTP message can traverse one or more
intermediaries before reaching the origin server; see Section 3.6 of
SEMANTICS.  Because this limit is applied separately by each
implementation which processes the message, messages below this limit
are not guaranteed to be accepted.
Paragraph (version A):
If a stream is canceled after receiving a complete response, the
client MAY ignore the cancellation and use the response.  However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used.  Only idempotent actions such as GET,
PUT, or DELETE can be safely retried; a client SHOULD NOT
automatically retry a request with a non-idempotent method unless it
has some means to know that the request semantics are idempotent
independent of the method or some means to detect that the original
request was never applied.  See Section 8.2.2 of SEMANTICS for more
details.
Paragraph (version B):
If a stream is canceled after receiving a complete response, the
client MAY ignore the cancellation and use the response.  However, if
a stream is cancelled after receiving a partial response, the
response SHOULD NOT be used.  Only idempotent actions such as GET,
PUT, or DELETE can be safely retried; a client SHOULD NOT
automatically retry a request with a non-idempotent method unless it
has some means to know that the request semantics are idempotent
independent of the method or some means to detect that the original
request was never applied.  See Section 9.2.2 of SEMANTICS for more
details.
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 5.5.4 of
SEMANTICS, can have a non-zero Content-Length field, even though no
content is included in DATA frames.
Paragraph (version B):
A request or response that includes payload data 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 lengths that form the payload data.  A response
that is defined to have no payload, as described in Section 6.4 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; see
Section 8.3.6 of SEMANTICS.  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; see
Section 9.3.6 of SEMANTICS.  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 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 Section 14.3 of SEMANTICS.
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 15.3 of SEMANTICS.
Paragraph (version A):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 6.6 of
SEMANTICS) or 101 (Switching Protocols) informational status code
(Section 14.2.2 of SEMANTICS).
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of
SEMANTICS) or 101 (Switching Protocols) informational status code
(Section 15.2.2 of SEMANTICS).
Paragraph (version A):
DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with an HTTP request or response payload body.
Paragraph (version B):
DATA frames (type=0x0) convey arbitrary, variable-length sequences of
bytes associated with HTTP request or response payload data.
Paragraph (version A):
HTTP/3 relies on the HTTP definition of authority.  The security
considerations of establishing authority are discussed in
Section 16.1 of SEMANTICS.
Paragraph (version B):
HTTP/3 relies on the HTTP definition of authority.  The security
considerations of establishing authority are discussed in
Section 17.1 of SEMANTICS.
Paragraph (version A):
The HTTP/3 field encoding allows the expression of names that are not
valid field names in the syntax used by HTTP (Section 5.4.3 of
SEMANTICS).  Requests or responses containing invalid field names
MUST be treated as malformed (malformed).  An intermediary therefore
cannot translate an HTTP/3 request or response containing an invalid
field name into an HTTP/1.1 message.
Paragraph (version B):
The HTTP/3 field encoding allows the expression of names that are not
valid field names in the syntax used by HTTP (Section 5.1 of
SEMANTICS).  Requests or responses containing invalid field names
MUST be treated as malformed (malformed).  An intermediary therefore
cannot translate an HTTP/3 request or response containing an invalid
field name into an HTTP/1.1 message.
Paragraph (version A):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the
zero character (NUL, ASCII 0x0) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 5.4.4 of SEMANTICS.
Paragraph (version B):
Similarly, HTTP/3 can transport field values that are not valid.
While most values that can be encoded will not alter field parsing,
carriage return (CR, ASCII 0xd), line feed (LF, ASCII 0xa), and the
zero character (NUL, ASCII 0x0) might be exploited by an attacker if
they are translated verbatim.  Any request or response that contains
a character not permitted in a field value MUST be treated as
malformed (malformed).  Valid characters are defined by the "field-
content" ABNF rule in Section 5.5 of SEMANTICS.
Paragraph (version A):
Compression can allow an attacker to recover secret data when it is
compressed in the same context as data under attacker control.
HTTP/3 enables compression of fields (header-formatting); the
following concerns also apply to the use of HTTP compressed content-
codings; see Section 7.5.1 of SEMANTICS.
Paragraph (version B):
Compression can allow an attacker to recover secret data when it is
compressed in the same context as data under attacker control.
HTTP/3 enables compression of fields (header-formatting); the
following concerns also apply to the use of HTTP compressed content-
codings; see Section 8.5.1 of SEMANTICS.