Draft: rfc9114

Commentary: In , the http - core editors decided to use mostly the named anchors we 've used in this draft , but changed [ SEMANTICS ] to [ HTTP ] . This keeps the documents consistent by making the same change in HTTP/3 .
Paragraph (version A):
HTTP semantics (SEMANTICS) are used for a broad range of services on
the Internet.  These semantics have most commonly been used with
HTTP/1.1 and HTTP/2.  HTTP/1.1 has been used over a variety of
transport and session layers, while HTTP/2 has been used primarily
with TLS over TCP.  HTTP/3 supports the same semantics over a new
transport protocol: QUIC.
Paragraph (version B):
HTTP semantics (HTTP) are used for a broad range of services on the
Internet.  These semantics have most commonly been used with HTTP/1.1
and HTTP/2.  HTTP/1.1 has been used over a variety of transport and
session layers, while HTTP/2 has been used primarily with TLS over
TCP.  HTTP/3 supports the same semantics over a new transport
protocol: QUIC.
Paragraph (version A):
The term "content" is defined in Section 6.4 of SEMANTICS.
Paragraph (version A):
Finally, the terms "resource", "message", "user agent", "origin
server", "gateway", "intermediary", "proxy", and "tunnel" are defined
in Section 3 of SEMANTICS.
Paragraph (version B):
The term "content" is defined in Section 6.4 of HTTP.
Paragraph (version B):
Finally, the terms "resource", "message", "user agent", "origin
server", "gateway", "intermediary", "proxy", and "tunnel" are defined
in Section 3 of HTTP.
Paragraph (version A):
HTTP relies on the notion of an authoritative response: a response
that has been determined to be the most appropriate response for that
request given the state of the target resource at the time of
response message origination by (or at the direction of) the origin
server identified within the target URI.  Locating an authoritative
server for an HTTP URI is discussed in Section 4.3 of SEMANTICS.
Paragraph (version A):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URI.  Upon receiving a
server certificate in the TLS handshake, the client MUST verify that
the certificate is an acceptable match for the URI's origin server
using the process described in Section 4.3.4 of SEMANTICS.  If the
certificate cannot be verified with respect to the URI's origin
server, the client MUST NOT consider the server authoritative for
that origin.
Paragraph (version B):
HTTP relies on the notion of an authoritative response: a response
that has been determined to be the most appropriate response for that
request given the state of the target resource at the time of
response message origination by (or at the direction of) the origin
server identified within the target URI.  Locating an authoritative
server for an HTTP URI is discussed in Section 4.3 of HTTP.
Paragraph (version B):
The "https" scheme associates authority with possession of a
certificate that the client considers to be trustworthy for the host
identified by the authority component of the URI.  Upon receiving a
server certificate in the TLS handshake, the client MUST verify that
the certificate is an acceptable match for the URI's origin server
using the process described in Section 4.3.4 of HTTP.  If the
certificate cannot be verified with respect to the URI's origin
server, the client MUST NOT consider the server authoritative for
that origin.
Paragraph (version A):
Once a connection to a server endpoint exists, this connection MAY be
reused for requests with multiple different URI authority components.
To use an existing connection for a new origin, clients MUST validate
the certificate presented by the server for the new origin server
using the process described in Section 4.3.4 of SEMANTICS.  This
implies that clients will need to retain the server certificate and
any additional information needed to verify that certificate; clients
that do not do so will be unable to reuse the connection for
additional origins.
Paragraph (version B):
Once a connection to a server endpoint exists, this connection MAY be
reused for requests with multiple different URI authority components.
To use an existing connection for a new origin, clients MUST validate
the certificate presented by the server for the new origin server
using the process described in Section 4.3.4 of HTTP.  This implies
that clients will need to retain the server certificate and any
additional information needed to verify that certificate; clients
that do not do so will be unable to reuse the connection for
additional origins.
Paragraph (version A):
A server that does not wish clients to reuse HTTP/3 connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see Section 7.4 of SEMANTICS.
Paragraph (version B):
A server that does not wish clients to reuse HTTP/3 connections for a
particular origin can indicate that it is not authoritative for a
request by sending a 421 (Misdirected Request) status code in
response to the request; see Section 7.4 of HTTP.
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 15 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 HTTP for a description of interim and final HTTP
responses.
Paragraph (version A):
Header and trailer sections are described in Sections 6.3 and 6.5 of
SEMANTICS; the content is described in Section 6.4 of SEMANTICS.
Paragraph (version B):
Header and trailer sections are described in Sections 6.3 and 6.5 of
HTTP; the content is described in Section 6.4 of HTTP.
Paragraph (version A):
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
content or trailer sections.
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 HTTP) precede a
final response to the same request.  Interim responses do not contain
content or trailer sections.
Paragraph (version A):
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):
Field names are strings containing a subset of ASCII characters.
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 B):
HTTP messages carry metadata as a series of key-value pairs called
"HTTP fields"; see Sections 6.3 and 6.5 of HTTP.  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):
Field names are strings containing a subset of ASCII characters.
Properties of HTTP field names and values are discussed in more
detail in Section 5.1 of HTTP.  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):
An intermediary transforming an HTTP/1.x message to HTTP/3 MUST
remove connection-specific header fields as discussed in
Section 7.6.1 of SEMANTICS, or their messages will be treated by
other HTTP/3 endpoints as malformed (malformed).
Paragraph (version B):
An intermediary transforming an HTTP/1.x message to HTTP/3 MUST
remove connection-specific header fields as discussed in
Section 7.6.1 of HTTP, or their messages will be treated by other
HTTP/3 endpoints 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 7.1 of SEMANTICS.  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 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 7.1 of HTTP.  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 7.1 of SEMANTICS.
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 7.1 of HTTP.
Paragraph (version A):
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 (see malformed).
Paragraph (version B):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see Section 15 of HTTP.  This pseudo-
header field MUST be included in all responses; otherwise, the
response is malformed (see 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 that 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.7 of
HTTP.  Because this limit is applied separately by each
implementation that processes the message, messages below this limit
are not guaranteed to be accepted.
Paragraph (version A):
If a stream is cancelled 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 B):
If a stream is cancelled 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 HTTP for more
details.
Paragraph (version A):
A request or response that is defined as having content when it
contains a Content-Length header field (Section 6.4.1 of SEMANTICS),
is malformed if the value of a Content-Length header field does not
equal the sum of the DATA frame lengths received.  A response that is
defined as never having content, even when a Content-Length is
present, 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 is defined as having content when it
contains a Content-Length header field (Section 6.4.1 of HTTP), is
malformed if the value of a Content-Length header field does not
equal the sum of the DATA frame lengths received.  A response that is
defined as never having content, even when a Content-Length is
present, 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 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 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 HTTP.  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):
The ":authority" pseudo-header field contains the host and port to
connect to (equivalent to the authority-form of the request-target
of CONNECT requests; see Section 7.1 of SEMANTICS).
Paragraph (version B):
The ":authority" pseudo-header field contains the host and port to
connect to (equivalent to the authority-form of the request-target
of CONNECT requests; see Section 7.1 of HTTP).
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 15.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 HTTP.
Paragraph (version A):
Since CONNECT creates a tunnel to an arbitrary server, proxies that
support CONNECT SHOULD restrict its use to a set of known ports or a
list of safe request targets; see Section 9.3.6 of SEMANTICS for more
details.
Paragraph (version A):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of
SEMANTICS) or the 101 (Switching Protocols) informational status code
(Section 15.2.2 of SEMANTICS).
Paragraph (version B):
Since CONNECT creates a tunnel to an arbitrary server, proxies that
support CONNECT SHOULD restrict its use to a set of known ports or a
list of safe request targets; see Section 9.3.6 of HTTP for more
details.
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (Section 7.8 of
SEMANTICS) or the 101 (Switching Protocols) informational status code
(Section 15.2.2 of HTTP).
Paragraph (version A):
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 B):
HTTP/3 relies on the HTTP definition of authority.  The security
considerations of establishing authority are discussed in
Section 17.1 of HTTP.
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.1 of
SEMANTICS).  Requests or responses containing invalid field names
MUST be treated as malformed (malformed).  Therefore, an intermediary
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 HTTP).
Requests or responses containing invalid field names MUST be treated
as malformed (malformed).  Therefore, an intermediary 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 0x0d), line feed (LF, ASCII 0x0d), and the
zero character (NUL, ASCII 0x0d) 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 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 0x0d), line feed (LF, ASCII 0x0d), and the
zero character (NUL, ASCII 0x0d) 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 HTTP.
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 8.4.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.4.1 of HTTP.