Draft: rfc9114

Commentary: and some other things besides . This presupposes a resolution of to be " treat them the same as regular fields , " which is ugly but logically consistent . Easy enough to adjust if that is n't the eventual decision , of course . 
 Note that while the style guide says to use 6265bis for COOKIES , I 'm continuing to point to RFC 6265 unless and until we decide to take another delaying dependency . ( I note that http - core also uses RFC 6265 . ) 
 That sounds very sensible to me , especially given the context in which they are spoken to in this document . 
 The RFC Editor asks : The last is a deliberate difference , deferring to the naming used in various sources , but the others should be reviewed and potentially aligned . 
 As part of this fix , the " malformed " definition has an extraneous comma following the reference to Content - Length ; clean that up at the same time . 
 The convention in http - core appears to be : when  is being introduced and defined thereafter However , HTTP/2 appears to use instead . Seems like we should align here . ( please correct me if I 'm extrapolating your usage incorrectly . likewise . ) 
 I think so . Perhaps we should set up a style guide on ? 
 See 
 Pity we did n't do this earlier . Now , what should we put in the currently - empty section ? I tend to think we can follow what methods do and just have the bare header name , but there are also some cases where it would be nice to separate it . 
 I had a go ; take a look ... 
 FWIW , http - core uses " x : dfn " ( an extension in my XSLT ) , which translates into " \<tt " in xml2rfc . And that , when generating plain text , leads to underscore use ( " definition " ) , which could n't stand . My XSLT now maps " x : dfn " ( which we keep in our source ) to plain quotes . 
 Fixed in . 
 Took a quick look - seems fine to meExcellent , I shall borrow the referencing markdown into my draft
Paragraph (version A):
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):
HTTP/1.1 (HTTP11) 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
excessive tolerance of variant behavior.
Paragraph (version B):
HTTP semantics (RFC9110) 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/1.1 (RFC9112) 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
excessive tolerance of variant behavior.
Paragraph (version A):
HTTP/2 (HTTP2) 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 directly impacted by the lost packet.
Paragraph (version B):
HTTP/2 (RFC9113) 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 directly impacted by the lost packet.
Paragraph (version A):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, QUIC has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 (TLS13) at the transport layer, offering
comparable confidentiality and integrity to running TLS over TCP,
with the improved connection setup latency of TCP Fast Open (TFO).
Paragraph (version B):
The QUIC transport protocol incorporates stream multiplexing and per-
stream flow control, similar to that provided by the HTTP/2 framing
layer.  By providing reliability at the stream level and congestion
control across the entire connection, QUIC has the capability to
improve the performance of HTTP compared to a TCP mapping.  QUIC also
incorporates TLS 1.3 (TLS) at the transport layer, offering
comparable confidentiality and integrity to running TLS over TCP,
with the improved connection setup latency of TCP Fast Open (TFO).
Paragraph (version A):
QUIC is described in QUIC-TRANSPORT.  For a full description of
HTTP/2, see HTTP2.
Paragraph (version B):
QUIC is described in QUIC-TRANSPORT.  For a full description of
HTTP/2, see RFC9113.
Paragraph (version A):
Server push is an interaction mode introduced in HTTP/2 (HTTP2) that
permits a server to push a request-response exchange to a client in
anticipation of the client making the indicated request.  This trades
off network usage against a potential latency gain.  Several HTTP/3
frames are used to manage server push, such as , , and .
Paragraph (version A):
As in HTTP/2, request and response fields are compressed for
transmission.  Because HPACK (HPACK) relies on in-order transmission
of compressed field sections (a guarantee not provided by QUIC),
HTTP/3 replaces HPACK with QPACK (QPACK).  QPACK uses separate
unidirectional streams to modify and track field table state, while
encoded field sections refer to the state of the table without
modifying it.
Paragraph (version B):
Server push is an interaction mode introduced in HTTP/2 (RFC9113)
that permits a server to push a request-response exchange to a client
in anticipation of the client making the indicated request.  This
trades off network usage against a potential latency gain.  Several
HTTP/3 frames are used to manage server push, such as , , and .
Paragraph (version B):
As in HTTP/2, request and response fields are compressed for
transmission.  Because HPACK (HPACK) relies on in-order transmission
of compressed field sections (a guarantee not provided by QUIC),
HTTP/3 replaces HPACK with QPACK (RFC9204).  QPACK uses separate
unidirectional streams to modify and track field table state, while
encoded field sections refer to the state of the table without
modifying it.
Paragraph (version A):
The term "content" is defined in HTTP.
Paragraph (version A):
Finally, the terms "resource", "message", "user agent", "origin
server", "gateway", "intermediary", "proxy", and "tunnel" are defined
in HTTP.
Paragraph (version B):
The term "content" is defined in RFC9110.
Paragraph (version B):
Finally, the terms "resource", "message", "user agent", "origin
server", "gateway", "intermediary", "proxy", and "tunnel" are defined
in RFC9110.
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 HTTP.
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 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 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 RFC9110.
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 RFC9110.  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 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 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 RFC9110.  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 HTTP.
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 RFC9110.
Paragraph (version A):
A client sends an HTTP request on a , 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 HTTP for a
description of interim and final HTTP responses.
Paragraph (version B):
A client sends an HTTP request on a , 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 RFC9110 for a
description of interim and final HTTP responses.
Paragraph (version A):
Header and trailer sections are described in Sections HTTP and HTTP
of HTTP; the content is described in HTTP.
Paragraph (version B):
Header and trailer sections are described in Sections RFC9110 and
RFC9110 of RFC9110; the content is described in RFC9110.
Paragraph (version A):
Transfer codings (see HTTP11) are not defined for HTTP/3; the
Transfer-Encoding header field MUST NOT be used.
Paragraph (version A):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see HTTP) precede a final response to
the same request.  Interim responses do not contain content or
trailer sections.
Paragraph (version B):
Transfer codings (see RFC9112) are not defined for HTTP/3; the
Transfer-Encoding header field MUST NOT be used.
Paragraph (version B):
A response MAY consist of multiple messages when and only when one or
more interim responses (1xx; see RFC9110) precede a final response to
the same request.  Interim responses do not contain content or
trailer sections.
Paragraph (version A):
SHOULD continue sending the body of the request and close the stream
normally.
Paragraph (version B):
SHOULD continue sending the content of the request and close the
stream normally.
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 HTTP 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 RFC9110 for more details.
Paragraph (version A):
A request or response that is defined as having content when it
contains a Content-Length header field (HTTP), is if the value of a
Content-Length header field does not equal the sum of the 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 frames.
Paragraph (version B):
A request or response that is defined as having content when it
contains a Content-Length header field (RFC9110) is if the value of
the Content-Length header field does not equal the sum of the 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 header field even though no content is included in
frames.
Paragraph (version A):
HTTP messages carry metadata as a series of key-value pairs called
"HTTP fields"; see Sections HTTP and HTTP 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 A):
Field names are strings containing a subset of ASCII characters.
Properties of HTTP field names and values are discussed in more
detail in 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 .
Paragraph (version B):
HTTP messages carry metadata as a series of key-value pairs called
"HTTP fields"; see Sections RFC9110 and RFC9110 of RFC9110.  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 RFC9110.  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 .
Paragraph (version A):
An intermediary transforming an HTTP/1.x message to HTTP/3 MUST
remove connection-specific header fields as discussed in HTTP, or
their messages will be treated by other HTTP/3 endpoints as .
Paragraph (version A):
QPACK describes a variation of HPACK that gives an encoder some
control over how much head-of-line blocking can be caused by
compression.  This allows an encoder to balance compression
efficiency with latency.  HTTP/3 uses QPACK to compress header and
trailer sections, including the control data present in the header
section.
Paragraph (version A):
To allow for better compression efficiency, the "Cookie" field
(RFC6265) MAY be split into separate field lines, each with one or
more cookie-pairs, before compression.  If a decompressed field
section contains multiple cookie field lines, these MUST be
concatenated into a single byte string using the two-byte delimiter
of "; " (ASCII 0x3b, 0x20) 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 B):
An intermediary transforming an HTTP/1.x message to HTTP/3 MUST
remove connection-specific header fields as discussed in RFC9110, or
their messages will be treated by other HTTP/3 endpoints as .
Paragraph (version B):
RFC9204 describes a variation of HPACK that gives an encoder some
control over how much head-of-line blocking can be caused by
compression.  This allows an encoder to balance compression
efficiency with latency.  HTTP/3 uses QPACK to compress header and
trailer sections, including the control data present in the header
section.
Paragraph (version B):
To allow for better compression efficiency, the Cookie header field
(COOKIES) MAY be split into separate field lines, each with one or
more cookie-pairs, before compression.  If a decompressed field
section contains multiple cookie field lines, these MUST be
concatenated into a single byte string using the two-byte delimiter
of "; " (ASCII 0x3b, 0x20) 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):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the 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 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 B):
If an implementation wishes to advise its peer of this limit, it can
be conveyed as a number of bytes in the 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 RFC9110.
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):
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 message control data; see HTTP.
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 message control data; see RFC9110.
Paragraph (version A):
All HTTP/3 requests MUST include exactly one value for the ":method",
":scheme", and ":path" pseudo-header fields, unless the request is a
CONNECT request; see connect.
Paragraph (version A):
If the ":scheme" pseudo-header field identifies a scheme that has a
mandatory authority component (including "http" and "https"), the
request MUST contain either an ":authority" pseudo-header field or a
"Host" header field.  If these fields are present, they MUST NOT be
empty.  If both fields are present, they MUST contain the same value.
If the scheme does not have a mandatory authority component and none
is provided in the request target, the request MUST NOT contain the
":authority" pseudo-header or "Host" header fields.
Paragraph (version B):
All HTTP/3 requests MUST include exactly one value for the :method,
:scheme, and :path pseudo-header fields, unless the request is a
CONNECT request; see connect.
Paragraph (version B):
If the :scheme pseudo-header field identifies a scheme that has a
mandatory authority component (including "http" and "https"), the
request MUST contain either an :authority pseudo-header field or a
Host header field.  If these fields are present, they MUST NOT be
empty.  If both fields are present, they MUST contain the same value.
If the scheme does not have a mandatory authority component and none
is provided in the request target, the request MUST NOT contain the
:authority pseudo-header or Host header fields.
Paragraph (version A):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see HTTP.  This pseudo-header field
MUST be included in all responses; otherwise, the response is (see
malformed).
Paragraph (version B):
For responses, a single ":status" pseudo-header field is defined that
carries the HTTP status code; see RFC9110.  This pseudo-header field
MUST be included in all responses; otherwise, the response is (see
malformed).
Paragraph (version A):
The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target; see
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 B):
The CONNECT method requests that the recipient establish a tunnel to
the destination origin server identified by the request-target; see
RFC9110.  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 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
frame containing a 2xx series status code to the client, as defined
in HTTP.
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 RFC9110).
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 frame
containing a 2xx series status code to the client, as defined in
RFC9110.
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 HTTP for more details.
Paragraph (version A):
HTTP/3 does not support the HTTP Upgrade mechanism (HTTP) or the 101
(Switching Protocols) informational status code (HTTP).
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 RFC9110 for more details.
Paragraph (version B):
HTTP/3 does not support the HTTP Upgrade mechanism (RFC9110) or the
101 (Switching Protocols) informational status code (RFC9110).
Paragraph (version A):
Server push is an interaction mode that permits a server to push a
request-response exchange to a client in anticipation of the client
making the indicated request.  This trades off network usage against
a potential latency gain.  HTTP/3 server push is similar to what is
described in HTTP2, but it uses different mechanisms.
Paragraph (version B):
Server push is an interaction mode that permits a server to push a
request-response exchange to a client in anticipation of the client
making the indicated request.  This trades off network usage against
a potential latency gain.  HTTP/3 server push is similar to what is
described in RFC9113, but it uses different mechanisms.
Paragraph (version A):
The server MUST include a value in the ":authority" pseudo-header
field for which the server is authoritative.  If the client has not
yet validated the connection for the origin indicated by the pushed
request, it MUST perform the same verification process it would do
before sending a request for that origin on the connection; see
connection-reuse.  If this verification fails, the client MUST NOT
consider the server authoritative for that origin.
Paragraph (version B):
The server MUST include a value in the :authority pseudo-header field
for which the server is authoritative.  If the client has not yet
validated the connection for the origin indicated by the pushed
request, it MUST perform the same verification process it would do
before sending a request for that origin on the connection; see
connection-reuse.  If this verification fails, the client MUST NOT
consider the server authoritative for that origin.
Paragraph (version A):
Clients SHOULD send a frame upon receipt of a frame carrying a
request that is not cacheable, is not known to be safe, that
indicates the presence of a request body, or for which it does not
consider the server authoritative.  Any corresponding responses MUST
NOT be used or cached.
Paragraph (version B):
Clients SHOULD send a frame upon receipt of a frame carrying a
request that is not cacheable, is not known to be safe, that
indicates the presence of request content, or for which it does not
consider the server authoritative.  Any corresponding responses MUST
NOT be used or cached.
Paragraph (version A):
Pushed responses that are cacheable (see CACHING) 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; see CACHING) at the
time the pushed response is received.
Paragraph (version B):
Pushed responses that are cacheable (see RFC9111) 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; see RFC9111) at the
time the pushed response is received.
Paragraph (version A):
Two stream types are defined in this document: control streams
(control-streams) and (push-streams).  QPACK defines two additional
stream types.  Other stream types can be defined by extensions to
HTTP/3; see extensions for more details.  Some stream types are
reserved (stream-grease).
Paragraph (version B):
Two stream types are defined in this document: control streams
(control-streams) and (push-streams).  RFC9204 defines two additional
stream types.  Other stream types can be defined by extensions to
HTTP/3; see extensions for more details.  Some stream types are
reserved (stream-grease).
Paragraph (version A):
The frame (type=0x01) is used to carry an HTTP field section that is
encoded using QPACK.  See QPACK for more details.
Paragraph (version B):
The frame (type=0x01) is used to carry an HTTP field section that is
encoded using QPACK.  See RFC9204 for more details.
Paragraph (version A):
Setting identifiers that were defined in HTTP2 where there is no
corresponding HTTP/3 setting have also been reserved (iana-settings).
These reserved settings MUST NOT be sent, and their receipt MUST be
treated as a of type .
Paragraph (version B):
Setting identifiers that were defined in RFC9113 where there is no
corresponding HTTP/3 setting have also been reserved (iana-settings).
These reserved settings MUST NOT be sent, and their receipt MUST be
treated as a of type .
Paragraph (version A):
The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS.  However, many of the considerations from HTTP2
apply to QUIC-TRANSPORT and are discussed in that document.
Paragraph (version A):
HTTP/3 relies on the HTTP definition of authority.  The security
considerations of establishing authority are discussed in HTTP.
Paragraph (version B):
The security considerations of HTTP/3 should be comparable to those
of HTTP/2 with TLS.  However, many of the considerations from RFC9113
apply to QUIC-TRANSPORT and are discussed in that document.
Paragraph (version B):
HTTP/3 relies on the HTTP definition of authority.  The security
considerations of establishing authority are discussed in RFC9110.
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 (HTTP).  Requests or
responses containing invalid field names MUST be treated as .
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 (RFC9110).  Requests or
responses containing invalid field names MUST be treated as .
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 (ASCII 0x0d), line feed (ASCII 0x0a), and the null
character (ASCII 0x00) 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 .  Valid
characters are defined by the "field-content" ABNF rule in HTTP.
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 (ASCII 0x0d), line feed (ASCII 0x0a), and the null
character (ASCII 0x00) 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 .  Valid
characters are defined by the "field-content" ABNF rule in RFC9110.
Paragraph (version A):
Compression of field sections also offers some opportunities to waste
processing resources; see QPACK for more details on potential abuses.
Paragraph (version B):
Compression of field sections also offers some opportunities to waste
processing resources; see RFC9204 for more details on potential
abuses.
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 HTTP.
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 RFC9110.
Paragraph (version A):
Further considerations regarding the compression of field sections
are described in QPACK.
Paragraph (version B):
Further considerations regarding the compression of field sections
are described in RFC9204.
Paragraph (version A):
While this registry is separate from the "HTTP/2 Frame Type" registry
defined in HTTP2, it is preferable that the assignments parallel each
other where the code spaces overlap.  If an entry is present in only
one registry, every effort SHOULD be made to avoid assigning the
corresponding value to an unrelated operation.  Expert reviewers MAY
reject unrelated registrations that would conflict with the same
value in the corresponding registry.
Paragraph (version B):
While this registry is separate from the "HTTP/2 Frame Type" registry
defined in RFC9113, it is preferable that the assignments parallel
each other where the code spaces overlap.  If an entry is present in
only one registry, every effort SHOULD be made to avoid assigning the
corresponding value to an unrelated operation.  Expert reviewers MAY
reject unrelated registrations that would conflict with the same
value in the corresponding registry.
Paragraph (version A):
While this registry is separate from the "HTTP/2 Settings" registry
defined in HTTP2, it is preferable that the assignments parallel each
other.  If an entry is present in only one registry, every effort
SHOULD be made to avoid assigning the corresponding value to an
unrelated operation.  Expert reviewers MAY reject unrelated
registrations that would conflict with the same value in the
corresponding registry.
Paragraph (version B):
While this registry is separate from the "HTTP/2 Settings" registry
defined in RFC9113, it is preferable that the assignments parallel
each other.  If an entry is present in only one registry, every
effort SHOULD be made to avoid assigning the corresponding value to
an unrelated operation.  Expert reviewers MAY reject unrelated
registrations that would conflict with the same value in the
corresponding registry.