Draft: rfc9114

Commentary: This replaces the frequent references to definition sections noted in with index entries which are hyperlinked in the HTML output . As people review , I 'd like particular attention on anywhere we think the cross - reference is so critical it needs to be explicit so it appears in the text output as well . I 've attempted to keep any cross - references that pointed to a section which is not the one the hyperlink would take you to ( e.g. Connection Closure is not the definition of the GOAWAY frame ) . You can see the hyperlinked output . 
 The RFC Editor asks : Endpoints MUST treat a request or response that contains undefined or invalid pseudo - header fields as malformed ( Section 4.1.3 ) . appears in a header section after a regular header field MUST be treated as malformed ( Section 4.1.3 ) . In the HTML copy , this could be addressed by making the term itself a hyperlink , rather than spelling out the cross - reference in text each time . ( See , for example , the hyperlinking of frame names in the HTTP/2 specification . ) 
 Fixed by . 
 Wonderful .
Paragraph (version A):
Within each stream, the basic unit of HTTP/3 communication is a frame
(frames).  Each frame type serves a different purpose.  For example,
HEADERS and DATA frames form the basis of HTTP requests and responses
(request-response).  Frames that apply to the entire connection are
conveyed on a dedicated control stream.
Paragraph (version B):
Within each stream, the basic unit of HTTP/3 communication is a frame
(frames).  Each frame type serves a different purpose.  For example,
and frames form the basis of HTTP requests and responses (request-
response).  Frames that apply to the entire connection are conveyed
on a dedicated .
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 PUSH_PROMISE,
MAX_PUSH_ID, and CANCEL_PUSH.
Paragraph (version B):
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):
While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, settings specific to HTTP/3
are conveyed in the SETTINGS frame (frame-settings).  After the QUIC
connection is established, a SETTINGS frame MUST be sent by each
endpoint as the initial frame of their respective HTTP control
stream; see control-streams.
Paragraph (version B):
While connection-level options pertaining to the core QUIC protocol
are set in the initial crypto handshake, settings specific to HTTP/3
are conveyed in the frame.  After the QUIC connection is established,
a frame MUST be sent by each endpoint as the initial frame of their
respective HTTP .
Paragraph (version A):
Servers are encouraged to maintain open HTTP/3 connections for as
long as possible but are permitted to terminate idle connections if
necessary.  When either endpoint chooses to close the HTTP/3
connection, the terminating endpoint SHOULD first send a GOAWAY frame
(connection-shutdown) so that both endpoints can reliably determine
whether previously sent frames have been processed and gracefully
complete or terminate any necessary remaining tasks.
Paragraph (version B):
Servers are encouraged to maintain open HTTP/3 connections for as
long as possible but are permitted to terminate idle connections if
necessary.  When either endpoint chooses to close the HTTP/3
connection, the terminating endpoint SHOULD first send a frame
(connection-shutdown) so that both endpoints can reliably determine
whether previously sent frames have been processed and gracefully
complete or terminate any necessary remaining tasks.
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 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 HTTP for a
description of interim and final HTTP responses.
Paragraph (version A):
On a given stream, receipt of multiple requests or receipt of an
additional HTTP response following a final HTTP response MUST be
treated as malformed (malformed).
Paragraph (version A):
the header section, including message control data, sent as a
single HEADERS frame (see frame-headers),
Paragraph (version A):
optionally, the trailer section, if present, sent as a single
HEADERS frame.
Paragraph (version A):
Receipt of an invalid sequence of frames MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED; see errors.  In
particular, a DATA frame before any HEADERS frame, or a HEADERS or
DATA frame after the trailing HEADERS frame, is considered invalid.
Other frame types, especially unknown frame types, might be permitted
subject to their own rules; see extensions.
Paragraph (version A):
A server MAY send one or more PUSH_PROMISE frames (frame-push-
promise) before, after, or interleaved with the frames of a response
message.  These PUSH_PROMISE frames are not part of the response; see
server-push for more details.  PUSH_PROMISE frames are not permitted
on push streams; a pushed response that includes PUSH_PROMISE frames
MUST be treated as a connection error of type H3_FRAME_UNEXPECTED;
see errors.
Paragraph (version A):
Frames of unknown types (extensions), including reserved frames
(frame-reserved) MAY be sent on a request or push stream before,
after, or interleaved with other frames described in this section.
Paragraph (version A):
The HEADERS and PUSH_PROMISE frames might reference updates to the
QPACK dynamic table.  While these updates are not directly part of
the message exchange, they must be received and processed before the
message can be consumed.  See header-formatting for more details.
Paragraph (version B):
On a given stream, receipt of multiple requests or receipt of an
additional HTTP response following a final HTTP response MUST be
treated as .
Paragraph (version B):
the header section, including message control data, sent as a
single frame,
Paragraph (version B):
optionally, the trailer section, if present, sent as a single
frame.
Paragraph (version B):
Receipt of an invalid sequence of frames MUST be treated as a of type
.  In particular, a frame before any frame, or a or frame after the
trailing frame, is considered invalid.  Other frame types, especially
unknown frame types, might be permitted subject to their own rules;
see extensions.
Paragraph (version B):
A server MAY send one or more frames before, after, or interleaved
with the frames of a response message.  These frames are not part of
the response; see server-push for more details.  frames are not
permitted on ; a pushed response that includes frames MUST be treated
as a of type .
Paragraph (version B):
Frames of unknown types (extensions), including reserved frames
(frame-reserved) MAY be sent on a request or before, after, or
interleaved with other frames described in this section.
Paragraph (version B):
The and frames might reference updates to the QPACK dynamic table.
While these updates are not directly part of the message exchange,
they must be received and processed before the message can be
consumed.  See header-formatting for more details.
Paragraph (version A):
When a stream is closed, this indicates the end of the final HTTP
message.  Because some messages are large or unbounded, endpoints
SHOULD begin processing partial HTTP messages once enough of the
message has been received to make progress.  If a client-initiated
stream terminates without enough of the HTTP message to provide a
complete response, the server SHOULD abort its response stream with
the error code H3_REQUEST_INCOMPLETE; see errors.
Paragraph (version A):
A server can send a complete response prior to the client sending an
entire request if the response does not depend on any portion of the
request that has not been sent and received.  When the server does
not need to receive the remainder of the request, it MAY abort
reading the request stream, send a complete response, and cleanly
close the sending part of the stream.  The error code H3_NO_ERROR
SHOULD be used when requesting that the client stop sending on the
request stream.  Clients MUST NOT discard complete responses as a
result of having their request terminated abruptly, though clients
can always discard responses at their discretion for other reasons.
If the server sends a partial or complete response but does not abort
reading the request, clients SHOULD continue sending the body of the
request and close the stream normally.
Paragraph (version A):
Once a request stream has been opened, the request MAY be cancelled
by either endpoint.  Clients cancel requests if the response is no
longer of interest; servers cancel requests if they are unable to or
choose not to respond.  When possible, it is RECOMMENDED that servers
send an HTTP response with an appropriate status code rather than
cancelling a request it has already begun processing.
Paragraph (version B):
When a stream is closed, this indicates the end of the final HTTP
message.  Because some messages are large or unbounded, endpoints
SHOULD begin processing partial HTTP messages once enough of the
message has been received to make progress.  If a client-initiated
stream terminates without enough of the HTTP message to provide a
complete response, the server SHOULD abort its response stream with
the error code .
Paragraph (version B):
A server can send a complete response prior to the client sending an
entire request if the response does not depend on any portion of the
request that has not been sent and received.  When the server does
not need to receive the remainder of the request, it MAY abort
reading the , send a complete response, and cleanly close the sending
part of the stream.  The error code SHOULD be used when requesting
that the client stop sending on the .  Clients MUST NOT discard
complete responses as a result of having their request terminated
abruptly, though clients can always discard responses at their
discretion for other reasons.  If the server sends a partial or
complete response but does not abort reading the request, clients
SHOULD continue sending the body of the request and close the stream
normally.
Paragraph (version B):
Once a has been opened, the request MAY be cancelled by either
endpoint.  Clients cancel requests if the response is no longer of
interest; servers cancel requests if they are unable to or choose not
to respond.  When possible, it is RECOMMENDED that servers send an
HTTP response with an appropriate status code rather than cancelling
a request it has already begun processing.
Paragraph (version A):
When the server cancels a request without performing any application
processing, the request is considered "rejected".  The server SHOULD
abort its response stream with the error code H3_REQUEST_REJECTED.
In this context, "processed" means that some data from the stream was
passed to some higher layer of software that might have taken some
action as a result.  The client can treat requests rejected by the
server as though they had never been sent at all, thereby allowing
them to be retried later.
Paragraph (version A):
Servers MUST NOT use the H3_REQUEST_REJECTED error code for requests
that were partially or fully processed.  When a server abandons a
response after partial processing, it SHOULD abort its response
stream with the error code H3_REQUEST_CANCELLED.
Paragraph (version A):
Client SHOULD use the error code H3_REQUEST_CANCELLED to cancel
requests.  Upon receipt of this error code, a server MAY abruptly
terminate the response using the error code H3_REQUEST_REJECTED if no
processing was performed.  Clients MUST NOT use the
H3_REQUEST_REJECTED error code, except when a server has requested
closure of the request stream with this error code.
Paragraph (version B):
When the server cancels a request without performing any application
processing, the request is considered "rejected".  The server SHOULD
abort its response stream with the error code . In this context,
"processed" means that some data from the stream was passed to some
higher layer of software that might have taken some action as a
result.  The client can treat requests rejected by the server as
though they had never been sent at all, thereby allowing them to be
retried later.
Paragraph (version B):
Servers MUST NOT use the error code for requests that were partially
or fully processed.  When a server abandons a response after partial
processing, it SHOULD abort its response stream with the error code .
Paragraph (version B):
Client SHOULD use the error code to cancel requests.  Upon receipt of
this error code, a server MAY abruptly terminate the response using
the error code if no processing was performed.  Clients MUST NOT use
the error code, except when a server has requested closure of the
with this error code.
Paragraph (version A):
A request or response that is defined as having content when it
contains a Content-Length header field (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):
Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a malformed
request or response.  Malformed requests or responses that are
detected MUST be treated as a stream error (errors) of type
H3_MESSAGE_ERROR.
Paragraph (version A):
For malformed requests, a server MAY send an HTTP response indicating
the error prior to closing or resetting the stream.  Clients MUST NOT
accept a malformed response.  Note that these requirements are
intended to protect against several types of common attacks against
HTTP; they are deliberately strict because being permissive can
expose implementations to these vulnerabilities.
Paragraph (version B):
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):
Intermediaries that process HTTP requests or responses (i.e., any
intermediary not acting as a tunnel) MUST NOT forward a request or
response.  Malformed requests or responses that are detected MUST be
treated as a of type .
Paragraph (version B):
For requests, a server MAY send an HTTP response indicating the error
prior to closing or resetting the stream.  Clients MUST NOT accept a
response.  Note that these requirements are intended to protect
against several types of common attacks against HTTP; they are
deliberately strict because being permissive can expose
implementations to these vulnerabilities.
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 malformed (malformed).
Paragraph (version A):
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):
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):
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 .
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 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 HTTP, or
their messages will be treated by other HTTP/3 endpoints as .
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 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 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):
Pseudo-header fields are only valid in the context in which they are
defined.  Pseudo-header fields defined for requests MUST NOT appear
in responses; pseudo-header fields defined for responses MUST NOT
appear in requests.  Pseudo-header fields MUST NOT appear in trailer
sections.  Endpoints MUST treat a request or response that contains
undefined or invalid pseudo-header fields as malformed (malformed).
Paragraph (version A):
All pseudo-header fields MUST appear in the header section before
regular header fields.  Any request or response that contains a
pseudo-header field that appears in a header section after a regular
header field MUST be treated as malformed (malformed).
Paragraph (version B):
Pseudo-header fields are only valid in the context in which they are
defined.  Pseudo-header fields defined for requests MUST NOT appear
in responses; pseudo-header fields defined for responses MUST NOT
appear in requests.  Pseudo-header fields MUST NOT appear in trailer
sections.  Endpoints MUST treat a request or response that contains
undefined or invalid pseudo-header fields as .
Paragraph (version B):
All pseudo-header fields MUST appear in the header section before
regular header fields.  Any request or response that contains a
pseudo-header field that appears in a header section after a regular
header field MUST be treated as .
Paragraph (version A):
An HTTP request that omits mandatory pseudo-header fields or contains
invalid values for those pseudo-header fields is malformed
(malformed).
Paragraph (version B):
An HTTP request that omits mandatory pseudo-header fields or contains
invalid values for those pseudo-header fields is .
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
malformed (see malformed).
Paragraph (version B):
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 A):
The request stream remains open at the end of the request to carry
the data to be transferred.  A CONNECT request that does not conform
to these restrictions is malformed; see malformed.
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 HTTP.
Paragraph (version A):
All DATA frames on the stream correspond to data sent or received on
the TCP connection.  The payload of any DATA frame sent by the client
is transmitted by the proxy to the TCP server; data received from the
TCP server is packaged into DATA frames by the proxy.  Note that the
size and number of TCP segments is not guaranteed to map predictably
to the size and number of HTTP DATA or QUIC STREAM frames.
Paragraph (version A):
Once the CONNECT method has completed, only DATA frames are permitted
to be sent on the stream.  Extension frames MAY be used if
specifically permitted by the definition of the extension.  Receipt
of any other known frame type MUST be treated as a connection error
of type H3_FRAME_UNEXPECTED; see errors.
Paragraph (version A):
The TCP connection can be closed by either peer.  When the client
ends the request stream (that is, the receive stream at the proxy
enters the "Data Recvd" state), the proxy will set the FIN bit on its
connection to the TCP server.  When the proxy receives a packet with
the FIN bit set, it will close the send stream that it sends to the
client.  TCP connections that remain half closed in a single
direction are not invalid, but are often handled poorly by servers,
so clients SHOULD NOT close a stream for sending while they still
expect to receive data from the target of the CONNECT.
Paragraph (version A):
A TCP connection error is signaled by abruptly terminating the
stream.  A proxy treats any error in the TCP connection, which
includes receiving a TCP segment with the RST bit set, as a stream
error of type H3_CONNECT_ERROR; see errors.
Paragraph (version B):
The remains open at the end of the request to carry the data to be
transferred.  A CONNECT request that does not conform to these
restrictions is .
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 HTTP.
Paragraph (version B):
All frames on the stream correspond to data sent or received on the
TCP connection.  The payload of any frame sent by the client is
transmitted by the proxy to the TCP server; data received from the
TCP server is packaged into frames by the proxy.  Note that the size
and number of TCP segments is not guaranteed to map predictably to
the size and number of HTTP or QUIC STREAM frames.
Paragraph (version B):
Once the CONNECT method has completed, only frames are permitted to
be sent on the stream.  Extension frames MAY be used if specifically
permitted by the definition of the extension.  Receipt of any other
known frame type MUST be treated as a of type .
Paragraph (version B):
The TCP connection can be closed by either peer.  When the client
ends the (that is, the receive stream at the proxy enters the "Data
Recvd" state), the proxy will set the FIN bit on its connection to
the TCP server.  When the proxy receives a packet with the FIN bit
set, it will close the send stream that it sends to the client.  TCP
connections that remain half closed in a single direction are not
invalid, but are often handled poorly by servers, so clients SHOULD
NOT close a stream for sending while they still expect to receive
data from the target of the CONNECT.
Paragraph (version B):
A TCP is signaled by abruptly terminating the stream.  A proxy treats
any error in the TCP connection, which includes receiving a TCP
segment with the RST bit set, as a of type .
Paragraph (version A):
Each server push is assigned a unique push ID by the server.  The
push ID is used to refer to the push in various contexts throughout
the lifetime of the HTTP/3 connection.
Paragraph (version A):
The push ID space begins at zero and ends at a maximum value set by
the MAX_PUSH_ID frame; see frame-max-push-id.  In particular, a
server is not able to push until after the client sends a MAX_PUSH_ID
frame.  A client sends MAX_PUSH_ID frames to control the number of
pushes that a server can promise.  A server SHOULD use push IDs
sequentially, beginning from zero.  A client MUST treat receipt of a
push stream as a connection error of type H3_ID_ERROR (errors) when
no MAX_PUSH_ID frame has been sent or when the stream references a
push ID that is greater than the maximum push ID.
Paragraph (version A):
The push ID is used in one or more PUSH_PROMISE frames (frame-push-
promise) that carry the control data and header fields of the request
message.  These frames are sent on the request stream that generated
the push.  This allows the server push to be associated with a client
request.  When the same push ID is promised on multiple request
streams, the decompressed request field sections MUST contain the
same fields in the same order, and both the name and the value in
each field MUST be identical.
Paragraph (version A):
The push ID is then included with the push stream that ultimately
fulfills those promises; see push-streams.  The push stream
identifies the push ID of the promise that it fulfills, then contains
a response to the promised request as described in request-response.
Paragraph (version A):
Finally, the push ID can be used in CANCEL_PUSH frames; see frame-
cancel-push.  Clients use this frame to indicate they do not wish to
receive a promised resource.  Servers use this frame to indicate they
will not be fulfilling a previous promise.
Paragraph (version B):
Each server push is assigned a unique by the server.  The is used to
refer to the push in various contexts throughout the lifetime of the
HTTP/3 connection.
Paragraph (version B):
The space begins at zero and ends at a maximum value set by the
frame.  In particular, a server is not able to push until after the
client sends a frame.  A client sends frames to control the number of
pushes that a server can promise.  A server SHOULD use push IDs
sequentially, beginning from zero.  A client MUST treat receipt of a
as a of type when no frame has been sent or when the stream
references a that is greater than the maximum .
Paragraph (version B):
The is used in one or more frames that carry the control data and
header fields of the request message.  These frames are sent on the
that generated the push.  This allows the server push to be
associated with a client request.  When the same is promised on
multiple , the decompressed request field sections MUST contain the
same fields in the same order, and both the name and the value in
each field MUST be identical.
Paragraph (version B):
The is then included with the that ultimately fulfills those
promises.  The identifies the of the promise that it fulfills, then
contains a response to the promised request as described in request-
response.
Paragraph (version B):
Finally, the can be used in frames; see frame-cancel-push.  Clients
use this frame to indicate they do not wish to receive a promised
resource.  Servers use this frame to indicate they will not be
fulfilling a previous promise.
Paragraph (version A):
Clients SHOULD send a CANCEL_PUSH frame upon receipt of a
PUSH_PROMISE 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 A):
Each pushed response is associated with one or more client requests.
The push is associated with the request stream on which the
PUSH_PROMISE frame was received.  The same server push can be
associated with additional client requests using a PUSH_PROMISE frame
with the same push ID on multiple request streams.  These
associations do not affect the operation of the protocol, but they
MAY be considered by user agents when deciding how to use pushed
resources.
Paragraph (version A):
Ordering of a PUSH_PROMISE frame in relation to certain parts of the
response is important.  The server SHOULD send PUSH_PROMISE frames
prior to sending HEADERS or DATA frames that reference the promised
responses.  This reduces the chance that a client requests a resource
that will be pushed by the server.
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 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 (QUIC-
TRANSPORT) to limit the amount of data a server may commit to the
pushed stream.  Clients SHOULD abort reading and discard data already
read from push streams if no corresponding PUSH_PROMISE frame is
processed in a reasonable amount of time.
Paragraph (version A):
Push stream data can also arrive after a client has cancelled a push.
In this case, the client can abort reading the stream with an error
code of H3_REQUEST_CANCELLED.  This asks the server not to transfer
additional data and indicates that it will be discarded upon receipt.
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 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):
Each pushed response is associated with one or more client requests.
The push is associated with the on which the frame was received.  The
same server push can be associated with additional client requests
using a frame with the same on multiple .  These associations do not
affect the operation of the protocol, but they MAY be considered by
user agents when deciding how to use pushed resources.
Paragraph (version B):
Ordering of a frame in relation to certain parts of the response is
important.  The server SHOULD send frames prior to sending or frames
that reference the promised responses.  This reduces the chance that
a client requests a resource that will be pushed by the server.
Paragraph (version B):
Due to reordering, data can arrive before the corresponding frame.
When a client receives a new with an as-yet-unknown , 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 . The client can use stream flow control (QUIC-TRANSPORT) to
limit the amount of data a server may commit to the pushed stream.
Clients SHOULD abort reading and discard data already read from if no
corresponding frame is processed in a reasonable amount of time.
Paragraph (version B):
Push stream data can also arrive after a client has cancelled a push.
In this case, the client can abort reading the stream with an error
code of . This asks the server not to transfer additional data and
indicates that it will be discarded upon receipt.
Paragraph (version A):
Even when a connection is not idle, either endpoint can decide to
stop using the connection and initiate a graceful connection close.
Endpoints initiate the graceful shutdown of an HTTP/3 connection by
sending a GOAWAY frame (frame-goaway).  The GOAWAY frame contains an
identifier that indicates to the receiver the range of requests or
pushes that were or might be processed in this connection.  The
server sends a client-initiated bidirectional stream ID; the client
sends a push ID (server-push).  Requests or pushes with the indicated
identifier or greater are rejected (request-cancellation) by the
sender of the GOAWAY.  This identifier MAY be zero if no requests or
pushes were processed.
Paragraph (version A):
The information in the GOAWAY frame enables a client and server to
agree on which requests or pushes were accepted prior to the shutdown
of the HTTP/3 connection.  Upon sending a GOAWAY frame, the endpoint
SHOULD explicitly cancel (see Sections request-cancellation and
frame-cancel-push) any requests or pushes that have identifiers
greater than or equal to the one indicated, in order to clean up
transport state for the affected streams.  The endpoint SHOULD
continue to do so as more requests or pushes arrive.
Paragraph (version A):
Endpoints MUST NOT initiate new requests or promise new pushes on the
connection after receipt of a GOAWAY frame from the peer.  Clients
MAY establish a new connection to send additional requests.
Paragraph (version A):
Upon receipt of a GOAWAY frame, if the client has already sent
requests with a stream ID greater than or equal to the identifier
contained in the GOAWAY frame, those requests will not be
processed.  Clients can safely retry unprocessed requests on a
different HTTP connection.  A client that is unable to retry
requests loses all requests that are in flight when the server
closes the connection.
Paragraph (version A):
Requests on stream IDs less than the stream ID in a GOAWAY frame
from the server might have been processed; their status cannot be
known until a response is received, the stream is reset
individually, another GOAWAY is received with a lower stream ID
than that of the request in question, or the connection
terminates.
Paragraph (version A):
If a server receives a GOAWAY frame after having promised pushes
with a push ID greater than or equal to the identifier contained
in the GOAWAY frame, those pushes will not be accepted.
Paragraph (version A):
Servers SHOULD send a GOAWAY frame when the closing of a connection
is known in advance, even if the advance notice is small, so that the
remote peer can know whether or not a request has been partially
processed.  For example, if an HTTP client sends a POST at the same
time that a server closes a QUIC connection, the client cannot know
if the server started to process that POST request if the server does
not send a GOAWAY frame to indicate what streams it might have acted
on.
Paragraph (version A):
An endpoint MAY send multiple GOAWAY frames indicating different
identifiers, but the identifier in each frame MUST NOT be greater
than the identifier in any previous frame, since clients might
already have retried unprocessed requests on another HTTP connection.
Receiving a GOAWAY containing a larger identifier than previously
received MUST be treated as a connection error of type H3_ID_ERROR;
see errors.
Paragraph (version A):
Even when a GOAWAY indicates that a given request or push will not be
processed or accepted upon receipt, the underlying transport
resources still exist.  The endpoint that initiated these requests
can cancel them to clean up transport state.
Paragraph (version B):
Even when a connection is not idle, either endpoint can decide to
stop using the connection and initiate a graceful connection close.
Endpoints initiate the graceful shutdown of an HTTP/3 connection by
sending a frame.  The frame contains an identifier that indicates to
the receiver the range of requests or pushes that were or might be
processed in this connection.  The server sends a client-initiated
bidirectional stream ID; the client sends a (server-push).  Requests
or pushes with the indicated identifier or greater are rejected
(request-cancellation) by the sender of the .  This identifier MAY be
zero if no requests or pushes were processed.
Paragraph (version B):
The information in the frame enables a client and server to agree on
which requests or pushes were accepted prior to the shutdown of the
HTTP/3 connection.  Upon sending a frame, the endpoint SHOULD
explicitly cancel (see Sections request-cancellation and frame-
cancel-push) any requests or pushes that have identifiers greater
than or equal to the one indicated, in order to clean up transport
state for the affected streams.  The endpoint SHOULD continue to do
so as more requests or pushes arrive.
Paragraph (version B):
Endpoints MUST NOT initiate new requests or promise new pushes on the
connection after receipt of a frame from the peer.  Clients MAY
establish a new connection to send additional requests.
Paragraph (version B):
Upon receipt of a frame, if the client has already sent requests
with a stream ID greater than or equal to the identifier contained
in the frame, those requests will not be processed.  Clients can
safely retry unprocessed requests on a different HTTP connection.
A client that is unable to retry requests loses all requests that
are in flight when the server closes the connection.
Paragraph (version B):
Requests on stream IDs less than the stream ID in a frame from the
server might have been processed; their status cannot be known
until a response is received, the stream is reset individually,
another is received with a lower stream ID than that of the
request in question, or the connection terminates.
Paragraph (version B):
If a server receives a frame after having promised pushes with a
greater than or equal to the identifier contained in the frame,
those pushes will not be accepted.
Paragraph (version B):
Servers SHOULD send a frame when the closing of a connection is known
in advance, even if the advance notice is small, so that the remote
peer can know whether or not a request has been partially processed.
For example, if an HTTP client sends a POST at the same time that a
server closes a QUIC connection, the client cannot know if the server
started to process that POST request if the server does not send a
frame to indicate what streams it might have acted on.
Paragraph (version B):
An endpoint MAY send multiple frames indicating different
identifiers, but the identifier in each frame MUST NOT be greater
than the identifier in any previous frame, since clients might
already have retried unprocessed requests on another HTTP connection.
Receiving a containing a larger identifier than previously received
MUST be treated as a of type .
Paragraph (version B):
Even when a indicates that a given request or push will not be
processed or accepted upon receipt, the underlying transport
resources still exist.  The endpoint that initiated these requests
can cancel them to clean up transport state.
Paragraph (version A):
Once all accepted requests and pushes have been processed, the
endpoint can permit the connection to become idle, or it MAY initiate
an immediate closure of the connection.  An endpoint that completes a
graceful shutdown SHOULD use the H3_NO_ERROR error code when closing
the connection.
Paragraph (version A):
If a client has consumed all available bidirectional stream IDs with
requests, the server need not send a GOAWAY frame, since the client
is unable to make further requests.
Paragraph (version B):
Once all accepted requests and pushes have been processed, the
endpoint can permit the connection to become idle, or it MAY initiate
an immediate closure of the connection.  An endpoint that completes a
graceful shutdown SHOULD use the error code when closing the
connection.
Paragraph (version B):
If a client has consumed all available bidirectional stream IDs with
requests, the server need not send a frame, since the client is
unable to make further requests.
Paragraph (version A):
Before closing the connection, a GOAWAY frame MAY be sent to allow
the client to retry some requests.  Including the GOAWAY frame in the
same packet as the QUIC CONNECTION_CLOSE frame improves the chances
of the frame being received by clients.
Paragraph (version B):
Before closing the connection, a frame MAY be sent to allow the
client to retry some requests.  Including the frame in the same
packet as the QUIC CONNECTION_CLOSE frame improves the chances of the
frame being received by clients.
Paragraph (version A):
If a connection terminates without a GOAWAY frame, clients MUST
assume that any request that was sent, whether in whole or in part,
might have been processed.
Paragraph (version B):
If a connection terminates without a frame, clients MUST assume that
any request that was sent, whether in whole or in part, might have
been processed.
Paragraph (version A):
All client-initiated bidirectional streams are used for HTTP requests
and responses.  A bidirectional stream ensures that the response can
be readily correlated with the request.  These streams are referred
to as request streams.
Paragraph (version A):
This means that the client's first request occurs on QUIC stream 0,
with subsequent requests on streams 4, 8, and so on.  In order to
permit these streams to open, an HTTP/3 server SHOULD configure non-
zero minimum values for the number of permitted streams and the
initial stream flow-control window.  So as to not unnecessarily limit
parallelism, at least 100 request streams SHOULD be permitted at a
time.
Paragraph (version A):
HTTP/3 does not use server-initiated bidirectional streams, though an
extension could define a use for these streams.  Clients MUST treat
receipt of a server-initiated bidirectional stream as a connection
error of type H3_STREAM_CREATION_ERROR (errors) unless such an
extension has been negotiated.
Paragraph (version B):
All client-initiated bidirectional streams are used for HTTP requests
and responses.  A bidirectional stream ensures that the response can
be readily correlated with the request.  These streams are referred
to as .
Paragraph (version B):
This means that the client's first request occurs on QUIC stream 0,
with subsequent requests on streams 4, 8, and so on.  In order to
permit these streams to open, an HTTP/3 server SHOULD configure non-
zero minimum values for the number of permitted streams and the
initial stream flow-control window.  So as to not unnecessarily limit
parallelism, at least 100 SHOULD be permitted at a time.
Paragraph (version B):
HTTP/3 does not use server-initiated bidirectional streams, though an
extension could define a use for these streams.  Clients MUST treat
receipt of a server-initiated bidirectional stream as a of type
unless such an extension has been negotiated.
Paragraph (version A):
Two stream types are defined in this document: control streams
(control-streams) and push streams (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) 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 A):
Each endpoint needs to create at least one unidirectional stream for
the HTTP control stream.  QPACK requires two additional
unidirectional streams, and other extensions might require further
streams.  Therefore, the transport parameters sent by both clients
and servers MUST allow the peer to create at least three
unidirectional streams.  These transport parameters SHOULD also
provide at least 1,024 bytes of flow-control credit to each
unidirectional stream.
Paragraph (version A):
Note that an endpoint is not required to grant additional credits to
create more unidirectional streams if its peer consumes all the
initial credits before creating the critical unidirectional streams.
Endpoints SHOULD create the HTTP control stream as well as the
unidirectional streams required by mandatory extensions (such as the
QPACK encoder and decoder streams) first, and then create additional
streams as allowed by their peer.
Paragraph (version A):
If the stream header indicates a stream type that is not supported by
the recipient, the remainder of the stream cannot be consumed as the
semantics are unknown.  Recipients of unknown stream types MUST
either abort reading of the stream or discard incoming data without
further processing.  If reading is aborted, the recipient SHOULD use
the H3_STREAM_CREATION_ERROR error code or a reserved error code
(http-error-codes).  The recipient MUST NOT consider unknown stream
types to be a connection error of any kind.
Paragraph (version B):
Each endpoint needs to create at least one unidirectional stream for
the HTTP . QPACK requires two additional unidirectional streams, and
other extensions might require further streams.  Therefore, the
transport parameters sent by both clients and servers MUST allow the
peer to create at least three unidirectional streams.  These
transport parameters SHOULD also provide at least 1,024 bytes of
flow-control credit to each unidirectional stream.
Paragraph (version B):
Note that an endpoint is not required to grant additional credits to
create more unidirectional streams if its peer consumes all the
initial credits before creating the critical unidirectional streams.
Endpoints SHOULD create the HTTP as well as the unidirectional
streams required by mandatory extensions (such as the QPACK encoder
and decoder streams) first, and then create additional streams as
allowed by their peer.
Paragraph (version B):
If the stream header indicates a stream type that is not supported by
the recipient, the remainder of the stream cannot be consumed as the
semantics are unknown.  Recipients of unknown stream types MUST
either abort reading of the stream or discard incoming data without
further processing.  If reading is aborted, the recipient SHOULD use
the error code or a reserved error code (http-error-codes).  The
recipient MUST NOT consider unknown stream types to be a of any kind.
Paragraph (version A):
A control stream is indicated by a stream type of 0x00.  Data on this
stream consists of HTTP/3 frames, as defined in frames.
Paragraph (version A):
Each side MUST initiate a single control stream at the beginning of
the connection and send its SETTINGS frame as the first frame on this
stream.  If the first frame of the control stream is any other frame
type, this MUST be treated as a connection error of type
H3_MISSING_SETTINGS.  Only one control stream per peer is permitted;
receipt of a second stream claiming to be a control stream MUST be
treated as a connection error of type H3_STREAM_CREATION_ERROR.  The
sender MUST NOT close the control stream, and the receiver MUST NOT
request that the sender close the control stream.  If either control
stream is closed at any point, this MUST be treated as a connection
error of type H3_CLOSED_CRITICAL_STREAM.  Connection errors are
described in errors.
Paragraph (version A):
Because the contents of the control stream are used to manage the
behavior of other streams, endpoints SHOULD provide enough flow-
control credit to keep the peer's control stream from becoming
blocked.
Paragraph (version B):
A is indicated by a stream type of 0x00.  Data on this stream
consists of HTTP/3 frames, as defined in frames.
Paragraph (version B):
Each side MUST initiate a single at the beginning of the connection
and send its frame as the first frame on this stream.  If the first
frame of the is any other frame type, this MUST be treated as a of
type . Only one per peer is permitted; receipt of a second stream
claiming to be a MUST be treated as a of type .  The sender MUST NOT
close the , and the receiver MUST NOT request that the sender close
the .  If either is closed at any point, this MUST be treated as a of
type .  Connection errors are described in errors.
Paragraph (version B):
Because the contents of the are used to manage the behavior of other
streams, endpoints SHOULD provide enough flow-control credit to keep
the peer's from becoming blocked.
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 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):
Only servers can push; if a server receives a client-initiated push
stream, this MUST be treated as a connection error of type
H3_STREAM_CREATION_ERROR; see errors.
Paragraph (version A):
A client SHOULD NOT abort reading on a push stream prior to reading
the push stream header, as this could lead to disagreement between
client and server on which push IDs have already been consumed.
Paragraph (version A):
Each push ID MUST only be used once in a push stream header.  If a
client detects that a push stream header includes a push ID that was
used in another push stream header, the client MUST treat this as a
connection error of type H3_ID_ERROR; see errors.
Paragraph (version B):
A is indicated by a stream type of 0x01, followed by the 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 B):
Only servers can push; if a server receives a client-initiated , this
MUST be treated as a of type .
Paragraph (version B):
A client SHOULD NOT abort reading on a prior to reading the header,
as this could lead to disagreement between client and server on which
push IDs have already been consumed.
Paragraph (version B):
Each MUST only be used once in a header.  If a client detects that a
header includes a that was used in another header, the client MUST
treat this as a of type .
Paragraph (version A):
The payload and length of the stream are selected in any manner the
sending implementation chooses.  When sending a reserved stream type,
the implementation MAY either terminate the stream cleanly or reset
it.  When resetting the stream, either the H3_NO_ERROR error code or
a reserved error code (http-error-codes) SHOULD be used.
Paragraph (version A):
HTTP frames are carried on QUIC streams, as described in stream-
mapping.  HTTP/3 defines three stream types: control stream, request
stream, and push stream.  This section describes HTTP/3 frame formats
and their permitted stream types; see stream-frame-mapping for an
overview.  A comparison between HTTP/2 and HTTP/3 frames is provided
in h2-frames.
Paragraph (version A):
The SETTINGS frame can only occur as the first frame of a Control
stream; this is indicated in stream-frame-mapping with a (1).
Specific guidance is provided in the relevant section.
Paragraph (version B):
The payload and length of the stream are selected in any manner the
sending implementation chooses.  When sending a reserved stream type,
the implementation MAY either terminate the stream cleanly or reset
it.  When resetting the stream, either the error code or a reserved
error code (http-error-codes) SHOULD be used.
Paragraph (version B):
HTTP frames are carried on QUIC streams, as described in stream-
mapping.  HTTP/3 defines three stream types: , , and . This section
describes HTTP/3 frame formats and their permitted stream types; see
stream-frame-mapping for an overview.  A comparison between HTTP/2
and HTTP/3 frames is provided in h2-frames.
Paragraph (version B):
The frame can only occur as the first frame of a Control stream; this
is indicated in stream-frame-mapping with a (1).  Specific guidance
is provided in the relevant section.
Paragraph (version A):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a connection
error of type H3_FRAME_ERROR; see errors.  In particular, redundant
length encodings MUST be verified to be self-consistent; see frame-
parsing.
Paragraph (version A):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a connection error of type
H3_FRAME_ERROR; see errors.  Streams that terminate abruptly may be
reset at any point in a frame.
Paragraph (version A):
DATA frames (type=0x00) convey arbitrary, variable-length sequences
of bytes associated with HTTP request or response content.
Paragraph (version A):
DATA frames MUST be associated with an HTTP request or response.  If
a DATA frame is received on a control stream, the recipient MUST
respond with a connection error of type H3_FRAME_UNEXPECTED; see
errors.
Paragraph (version A):
The HEADERS frame (type=0x01) is used to carry an HTTP field section
that is encoded using QPACK.  See QPACK for more details.
Paragraph (version A):
HEADERS frames can only be sent on request or push streams.  If a
HEADERS frame is received on a control stream, the recipient MUST
respond with a connection error of type H3_FRAME_UNEXPECTED; see
errors.
Paragraph (version A):
The CANCEL_PUSH frame (type=0x03) is used to request cancellation of
a server push prior to the push stream being received.  The
CANCEL_PUSH frame identifies a server push by push ID (see server-
push), encoded as a variable-length integer.
Paragraph (version A):
When a client sends a CANCEL_PUSH frame, it is indicating that it
does not wish to receive the promised resource.  The server SHOULD
abort sending the resource, but the mechanism to do so depends on the
state of the corresponding push stream.  If the server has not yet
created a push stream, it does not create one.  If the push stream is
open, the server SHOULD abruptly terminate that stream.  If the push
stream has already ended, the server MAY still abruptly terminate the
stream or MAY take no action.
Paragraph (version A):
A server sends a CANCEL_PUSH frame to indicate that it will not be
fulfilling a promise that was previously sent.  The client cannot
expect the corresponding promise to be fulfilled, unless it has
already received and processed the promised response.  Regardless of
whether a push stream has been opened, a server SHOULD send a
CANCEL_PUSH frame when it determines that promise will not be
fulfilled.  If a stream has already been opened, the server can abort
sending on the stream with an error code of H3_REQUEST_CANCELLED.
Paragraph (version A):
Sending a CANCEL_PUSH frame has no direct effect on the state of
existing push streams.  A client SHOULD NOT send a CANCEL_PUSH frame
when it has already received a corresponding push stream.  A push
stream could arrive after a client has sent a CANCEL_PUSH frame,
because a server might not have processed the CANCEL_PUSH.  The
client SHOULD abort reading the stream with an error code of
H3_REQUEST_CANCELLED.
Paragraph (version A):
A CANCEL_PUSH frame is sent on the control stream.  Receiving a
CANCEL_PUSH frame on a stream other than the control stream MUST be
treated as a connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
The CANCEL_PUSH frame carries a push ID encoded as a variable-length
integer.  The Push ID field identifies the server push that is being
cancelled; see server-push.  If a CANCEL_PUSH frame is received that
references a push ID greater than currently allowed on the
connection, this MUST be treated as a connection error of type
H3_ID_ERROR.
Paragraph (version A):
If the client receives a CANCEL_PUSH frame, that frame might identify
a push ID that has not yet been mentioned by a PUSH_PROMISE frame due
to reordering.  If a server receives a CANCEL_PUSH frame for a push
ID that has not yet been mentioned by a PUSH_PROMISE frame, this MUST
be treated as a connection error of type H3_ID_ERROR.
Paragraph (version A):
The SETTINGS frame (type=0x04) conveys configuration parameters that
affect how endpoints communicate, such as preferences and constraints
on peer behavior.  Individually, a SETTINGS parameter can also be
referred to as a "setting"; the identifier and value of each setting
parameter can be referred to as a "setting identifier" and a "setting
value".
Paragraph (version A):
SETTINGS frames always apply to an entire HTTP/3 connection, never a
single stream.  A SETTINGS frame MUST be sent as the first frame of
each control stream (see control-streams) by each peer, and it MUST
NOT be sent subsequently.  If an endpoint receives a second SETTINGS
frame on the control stream, the endpoint MUST respond with a
connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
SETTINGS frames MUST NOT be sent on any stream other than the control
stream.  If an endpoint receives a SETTINGS frame on a different
stream, the endpoint MUST respond with a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
SETTINGS parameters are not negotiated; they describe characteristics
of the sending peer that can be used by the receiving peer.  However,
a negotiation can be implied by the use of SETTINGS: each peer uses
SETTINGS to advertise a set of supported values.  The definition of
the setting would describe how each peer combines the two sets to
conclude which choice will be used.  SETTINGS does not provide a
mechanism to identify when the choice takes effect.
Paragraph (version B):
Each frame's payload MUST contain exactly the fields identified in
its description.  A frame payload that contains additional bytes
after the identified fields or a frame payload that terminates before
the end of the identified fields MUST be treated as a of type .  In
particular, redundant length encodings MUST be verified to be self-
consistent; see frame-parsing.
Paragraph (version B):
When a stream terminates cleanly, if the last frame on the stream was
truncated, this MUST be treated as a of type . Streams that terminate
abruptly may be reset at any point in a frame.
Paragraph (version B):
frames (type=0x00) convey arbitrary, variable-length sequences of
bytes associated with HTTP request or response content.
Paragraph (version B):
frames MUST be associated with an HTTP request or response.  If a
frame is received on a , the recipient MUST respond with a of type .
Paragraph (version B):
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):
frames can only be sent on or .  If a frame is received on a , the
recipient MUST respond with a of type .
Paragraph (version B):
The frame (type=0x03) is used to request cancellation of a server
push prior to the being received.  The frame identifies a server push
by (see server-push), encoded as a variable-length integer.
Paragraph (version B):
When a client sends a frame, it is indicating that it does not wish
to receive the promised resource.  The server SHOULD abort sending
the resource, but the mechanism to do so depends on the state of the
corresponding .  If the server has not yet created a , it does not
create one.  If the is open, the server SHOULD abruptly terminate
that stream.  If the has already ended, the server MAY still abruptly
terminate the stream or MAY take no action.
Paragraph (version B):
A server sends a frame to indicate that it will not be fulfilling a
promise that was previously sent.  The client cannot expect the
corresponding promise to be fulfilled, unless it has already received
and processed the promised response.  Regardless of whether a has
been opened, a server SHOULD send a frame when it determines that
promise will not be fulfilled.  If a stream has already been opened,
the server can abort sending on the stream with an error code of .
Paragraph (version B):
Sending a frame has no direct effect on the state of existing . A
client SHOULD NOT send a frame when it has already received a
corresponding .  A could arrive after a client has sent a frame,
because a server might not have processed the . The client SHOULD
abort reading the stream with an error code of .
Paragraph (version B):
A frame is sent on the .  Receiving a frame on a stream other than
the MUST be treated as a of type .
Paragraph (version B):
The frame carries a encoded as a variable-length integer.  The Push
ID field identifies the server push that is being cancelled; see
server-push.  If a frame is received that references a greater than
currently allowed on the connection, this MUST be treated as a of
type .
Paragraph (version B):
If the client receives a frame, that frame might identify a that has
not yet been mentioned by a frame due to reordering.  If a server
receives a frame for a that has not yet been mentioned by a frame,
this MUST be treated as a of type .
Paragraph (version B):
The frame (type=0x04) conveys configuration parameters that affect
how endpoints communicate, such as preferences and constraints on
peer behavior.  Individually, a parameter can also be referred to as
a "setting"; the identifier and value of each setting parameter can
be referred to as a "setting identifier" and a "setting value".
Paragraph (version B):
frames always apply to an entire HTTP/3 connection, never a single
stream.  A frame MUST be sent as the first frame of each (see
control-streams) by each peer, and it MUST NOT be sent subsequently.
If an endpoint receives a second frame on the , the endpoint MUST
respond with a of type .
Paragraph (version B):
frames MUST NOT be sent on any stream other than the .  If an
endpoint receives a frame on a different stream, the endpoint MUST
respond with a of type .
Paragraph (version B):
parameters are not negotiated; they describe characteristics of the
sending peer that can be used by the receiving peer.  However, a
negotiation can be implied by the use of : each peer uses to
advertise a set of supported values.  The definition of the setting
would describe how each peer combines the two sets to conclude which
choice will be used.  does not provide a mechanism to identify when
the choice takes effect.
Paragraph (version A):
The same setting identifier MUST NOT occur more than once in the
SETTINGS frame.  A receiver MAY treat the presence of duplicate
setting identifiers as a connection error of type H3_SETTINGS_ERROR.
Paragraph (version A):
The payload of a SETTINGS frame consists of zero or more parameters.
Each parameter consists of a setting identifier and a value, both
encoded as QUIC variable-length integers.
Paragraph (version B):
The same setting identifier MUST NOT occur more than once in the
frame.  A receiver MAY treat the presence of duplicate setting
identifiers as a of type .
Paragraph (version B):
The payload of a frame consists of zero or more parameters.  Each
parameter consists of a setting identifier and a value, both encoded
as QUIC variable-length integers.
Paragraph (version A):
Setting identifiers of the format "0x1f * N + 0x21" for non-negative
integer values of "N" are reserved to exercise the requirement that
unknown identifiers be ignored.  Such settings have no defined
meaning.  Endpoints SHOULD include at least one such setting in their
SETTINGS frame.  Endpoints MUST NOT consider such settings to have
any meaning upon receipt.
Paragraph (version B):
Setting identifiers of the format "0x1f * N + 0x21" for non-negative
integer values of "N" are reserved to exercise the requirement that
unknown identifiers be ignored.  Such settings have no defined
meaning.  Endpoints SHOULD include at least one such setting in their
frame.  Endpoints MUST NOT consider such settings to have any meaning
upon receipt.
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 connection error of type H3_SETTINGS_ERROR.
Paragraph (version B):
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 A):
All settings begin at an initial value.  Each endpoint SHOULD use
these initial values to send messages before the peer's SETTINGS
frame has arrived, as packets carrying the settings can be lost or
delayed.  When the SETTINGS frame arrives, any settings are changed
to their new values.
Paragraph (version A):
This removes the need to wait for the SETTINGS frame before sending
messages.  Endpoints MUST NOT require any data to be received from
the peer prior to sending the SETTINGS frame; settings MUST be sent
as soon as the transport is ready to send data.
Paragraph (version A):
For clients using a 1-RTT QUIC connection, the initial value of each
server setting is the default value.  1-RTT keys will always become
available prior to the packet containing SETTINGS being processed by
QUIC, even if the server sends SETTINGS immediately.  Clients SHOULD
NOT wait indefinitely for SETTINGS to arrive before sending requests,
but they SHOULD process received datagrams in order to increase the
likelihood of processing SETTINGS before sending the first request.
Paragraph (version A):
When a 0-RTT QUIC connection is being used, the initial value of each
server setting is the value used in the previous session.  Clients
SHOULD store the settings the server provided in the HTTP/3
connection where resumption information was provided, but they MAY
opt not to store settings in certain cases (e.g., if the session
ticket is received before the SETTINGS frame).  A client MUST comply
with stored settings - or default values if no values are stored -
when attempting 0-RTT.  Once a server has provided new settings,
clients MUST comply with those values.
Paragraph (version B):
All settings begin at an initial value.  Each endpoint SHOULD use
these initial values to send messages before the peer's frame has
arrived, as packets carrying the settings can be lost or delayed.
When the frame arrives, any settings are changed to their new values.
Paragraph (version B):
This removes the need to wait for the frame before sending messages.
Endpoints MUST NOT require any data to be received from the peer
prior to sending the frame; settings MUST be sent as soon as the
transport is ready to send data.
Paragraph (version B):
For clients using a 1-RTT QUIC connection, the initial value of each
server setting is the default value.  1-RTT keys will always become
available prior to the packet containing being processed by QUIC,
even if the server sends immediately.  Clients SHOULD NOT wait
indefinitely for to arrive before sending requests, but they SHOULD
process received datagrams in order to increase the likelihood of
processing before sending the first request.
Paragraph (version B):
When a 0-RTT QUIC connection is being used, the initial value of each
server setting is the value used in the previous session.  Clients
SHOULD store the settings the server provided in the HTTP/3
connection where resumption information was provided, but they MAY
opt not to store settings in certain cases (e.g., if the session
ticket is received before the frame).  A client MUST comply with
stored settings - or default values if no values are stored - when
attempting 0-RTT.  Once a server has provided new settings, clients
MUST comply with those values.
Paragraph (version A):
A server MAY accept 0-RTT and subsequently provide different settings
in its SETTINGS frame.  If 0-RTT data is accepted by the server, its
SETTINGS frame MUST NOT reduce any limits or alter any values that
might be violated by the client with its 0-RTT data.  The server MUST
include all settings that differ from their default values.  If a
server accepts 0-RTT but then sends settings that are not compatible
with the previously specified settings, this MUST be treated as a
connection error of type H3_SETTINGS_ERROR.  If a server accepts
0-RTT but then sends a SETTINGS frame that omits a setting value that
the client understands (apart from reserved setting identifiers) that
was previously specified to have a non-default value, this MUST be
treated as a connection error of type H3_SETTINGS_ERROR.
Paragraph (version A):
The PUSH_PROMISE frame (type=0x05) is used to carry a promised
request header section from server to client on a request stream, as
in HTTP/2.
Paragraph (version A):
A server MUST NOT use a push ID that is larger than the client has
provided in a MAX_PUSH_ID frame (frame-max-push-id).  A client MUST
treat receipt of a PUSH_PROMISE frame that contains a larger push ID
than the client has advertised as a connection error of H3_ID_ERROR.
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 sections 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 field sections match
exactly, the client SHOULD associate the pushed content with each
stream on which a PUSH_PROMISE frame was received.
Paragraph (version A):
Allowing duplicate references to the same push ID is primarily to
reduce duplication caused by concurrent requests.  A server SHOULD
avoid reusing a push ID over a long period.  Clients are likely to
consume server push responses and not retain them for reuse over
time.  Clients that see a PUSH_PROMISE frame that uses a push ID that
they have already consumed and discarded are forced to ignore the
promise.
Paragraph (version A):
If a PUSH_PROMISE frame is received on the control stream, the client
MUST respond with a connection error of type H3_FRAME_UNEXPECTED; see
errors.
Paragraph (version A):
A client MUST NOT send a PUSH_PROMISE frame.  A server MUST treat the
receipt of a PUSH_PROMISE frame as a connection error of type
H3_FRAME_UNEXPECTED; see errors.
Paragraph (version A):
The GOAWAY frame (type=0x07) is used to initiate graceful shutdown of
an HTTP/3 connection by either endpoint.  GOAWAY allows an endpoint
to stop accepting new requests or pushes while still finishing
processing of previously received requests and pushes.  This enables
administrative actions, like server maintenance.  GOAWAY by itself
does not close a connection.
Paragraph (version A):
The GOAWAY frame is always sent on the control stream.  In the
server-to-client direction, it carries a QUIC stream ID for a client-
initiated bidirectional stream encoded as a variable-length integer.
A client MUST treat receipt of a GOAWAY frame containing a stream ID
of any other type as a connection error of type H3_ID_ERROR.
Paragraph (version A):
In the client-to-server direction, the GOAWAY frame carries a push ID
encoded as a variable-length integer.
Paragraph (version A):
The GOAWAY frame applies to the entire connection, not a specific
stream.  A client MUST treat a GOAWAY frame on a stream other than
the control stream as a connection error of type H3_FRAME_UNEXPECTED;
see errors.
Paragraph (version A):
See connection-shutdown for more information on the use of the GOAWAY
frame.
Paragraph (version A):
The MAX_PUSH_ID frame (type=0x0d) is used by clients to control the
number of server pushes that the server can initiate.  This sets the
maximum value for a push ID that the server can use in PUSH_PROMISE
and CANCEL_PUSH frames.  Consequently, this also limits the number of
push streams that the server can initiate in addition to the limit
maintained by the QUIC transport.
Paragraph (version A):
The MAX_PUSH_ID frame is always sent on the control stream.  Receipt
of a MAX_PUSH_ID frame on any other stream MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
A server MUST NOT send a MAX_PUSH_ID frame.  A client MUST treat the
receipt of a MAX_PUSH_ID frame as a connection error of type
H3_FRAME_UNEXPECTED.
Paragraph (version A):
The maximum push ID is unset when an HTTP/3 connection is created,
meaning that a server cannot push until it receives a MAX_PUSH_ID
frame.  A client that wishes to manage the number of promised server
pushes can increase the maximum push ID by sending MAX_PUSH_ID frames
as the server fulfills or cancels server pushes.
Paragraph (version A):
The MAX_PUSH_ID frame carries a single variable-length integer that
identifies the maximum value for a push ID that the server can use;
see server-push.  A MAX_PUSH_ID frame cannot reduce the maximum push
ID; receipt of a MAX_PUSH_ID frame that contains a smaller value than
previously received MUST be treated as a connection error of type
H3_ID_ERROR.
Paragraph (version B):
A server MAY accept 0-RTT and subsequently provide different settings
in its frame.  If 0-RTT data is accepted by the server, its frame
MUST NOT reduce any limits or alter any values that might be violated
by the client with its 0-RTT data.  The server MUST include all
settings that differ from their default values.  If a server accepts
0-RTT but then sends settings that are not compatible with the
previously specified settings, this MUST be treated as a of type . If
a server accepts 0-RTT but then sends a frame that omits a setting
value that the client understands (apart from reserved setting
identifiers) that was previously specified to have a non-default
value, this MUST be treated as a of type .
Paragraph (version B):
The frame (type=0x05) is used to carry a promised request header
section from server to client on a , as in HTTP/2.
Paragraph (version B):
A server MUST NOT use a that is larger than the client has provided
in a frame (frame-max-push-id).  A client MUST treat receipt of a
frame that contains a larger than the client has advertised as a of .
Paragraph (version B):
A server MAY use the same in multiple 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 sections
for resources promised multiple times.  If a client receives a that
has already been promised and detects a mismatch, it MUST respond
with a of type . If the decompressed field sections match exactly,
the client SHOULD associate the pushed content with each stream on
which a frame was received.
Paragraph (version B):
Allowing duplicate references to the same is primarily to reduce
duplication caused by concurrent requests.  A server SHOULD avoid
reusing a over a long period.  Clients are likely to consume server
push responses and not retain them for reuse over time.  Clients that
see a frame that uses a that they have already consumed and discarded
are forced to ignore the promise.
Paragraph (version B):
If a frame is received on the , the client MUST respond with a of
type .
Paragraph (version B):
A client MUST NOT send a frame.  A server MUST treat the receipt of a
frame as a of type .
Paragraph (version B):
The frame (type=0x07) is used to initiate graceful shutdown of an
HTTP/3 connection by either endpoint.  allows an endpoint to stop
accepting new requests or pushes while still finishing processing of
previously received requests and pushes.  This enables administrative
actions, like server maintenance.  by itself does not close a
connection.
Paragraph (version B):
The frame is always sent on the .  In the server-to-client direction,
it carries a QUIC stream ID for a client-initiated bidirectional
stream encoded as a variable-length integer.  A client MUST treat
receipt of a frame containing a stream ID of any other type as a of
type .
Paragraph (version B):
In the client-to-server direction, the frame carries a encoded as a
variable-length integer.
Paragraph (version B):
The frame applies to the entire connection, not a specific stream.  A
client MUST treat a frame on a stream other than the as a of type .
Paragraph (version B):
See connection-shutdown for more information on the use of the frame.
Paragraph (version B):
The frame (type=0x0d) is used by clients to control the number of
server pushes that the server can initiate.  This sets the maximum
value for a that the server can use in and frames.  Consequently,
this also limits the number of that the server can initiate in
addition to the limit maintained by the QUIC transport.
Paragraph (version B):
The frame is always sent on the .  Receipt of a frame on any other
stream MUST be treated as a of type .
Paragraph (version B):
A server MUST NOT send a frame.  A client MUST treat the receipt of a
frame as a of type .
Paragraph (version B):
The maximum is unset when an HTTP/3 connection is created, meaning
that a server cannot push until it receives a frame.  A client that
wishes to manage the number of promised server pushes can increase
the maximum by sending frames as the server fulfills or cancels
server pushes.
Paragraph (version B):
The frame carries a single variable-length integer that identifies
the maximum value for a that the server can use; see server-push.  A
frame cannot reduce the maximum ; receipt of a frame that contains a
smaller value than previously received MUST be treated as a of type .
Paragraph (version A):
Frame types that were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (iana-frames).  These frame
types MUST NOT be sent, and their receipt MUST be treated as a
connection error of type H3_FRAME_UNEXPECTED.
Paragraph (version A):
When a stream cannot be completed successfully, QUIC allows the
application to abruptly terminate (reset) that stream and communicate
a reason; see QUIC-TRANSPORT.  This is referred to as a "stream
error".  An HTTP/3 implementation can decide to close a QUIC stream
and communicate the type of error.  Wire encodings of error codes are
defined in http-error-codes.  Stream errors are distinct from HTTP
status codes that indicate error conditions.  Stream errors indicate
that the sender did not transfer or consume the full request or
response, while HTTP status codes indicate the result of a request
that was successfully received.
Paragraph (version B):
Frame types that were used in HTTP/2 where there is no corresponding
HTTP/3 frame have also been reserved (iana-frames).  These frame
types MUST NOT be sent, and their receipt MUST be treated as a of
type .
Paragraph (version B):
When a stream cannot be completed successfully, QUIC allows the
application to abruptly terminate (reset) that stream and communicate
a reason; see QUIC-TRANSPORT.  This is referred to as a "".  An
HTTP/3 implementation can decide to close a QUIC stream and
communicate the type of error.  Wire encodings of error codes are
defined in http-error-codes.  Stream errors are distinct from HTTP
status codes that indicate error conditions.  Stream errors indicate
that the sender did not transfer or consume the full request or
response, while HTTP status codes indicate the result of a request
that was successfully received.
Paragraph (version A):
If an entire connection needs to be terminated, QUIC similarly
provides mechanisms to communicate a reason; see QUIC-TRANSPORT.
This is referred to as a "connection error".  Similar to stream
errors, an HTTP/3 implementation can terminate a QUIC connection and
communicate the reason using an error code from http-error-codes.
Paragraph (version A):
An endpoint MAY choose to treat a stream error as a connection error
under certain circumstances, closing the entire connection in
response to a condition on a single stream.  Implementations need to
consider the impact on outstanding requests before making this
choice.
Paragraph (version A):
Because new error codes can be defined without negotiation (see
extensions), use of an error code in an unexpected context or receipt
of an unknown error code MUST be treated as equivalent to
H3_NO_ERROR.  However, closing a stream can have other effects
regardless of the error code; for example, see request-response.
Paragraph (version B):
If an entire connection needs to be terminated, QUIC similarly
provides mechanisms to communicate a reason; see QUIC-TRANSPORT.
This is referred to as a "".  Similar to stream errors, an HTTP/3
implementation can terminate a QUIC connection and communicate the
reason using an error code from http-error-codes.
Paragraph (version B):
An endpoint MAY choose to treat a as a under certain circumstances,
closing the entire connection in response to a condition on a single
stream.  Implementations need to consider the impact on outstanding
requests before making this choice.
Paragraph (version B):
Because new error codes can be defined without negotiation (see
extensions), use of an error code in an unexpected context or receipt
of an unknown error code MUST be treated as equivalent to .  However,
closing a stream can have other effects regardless of the error code;
for example, see request-response.
Paragraph (version A):
Error codes of the format "0x1f * N + 0x21" for non-negative integer
values of "N" are reserved to exercise the requirement that unknown
error codes be treated as equivalent to H3_NO_ERROR (extensions).
Implementations SHOULD select an error code from this space with some
probability when they would have sent H3_NO_ERROR.
Paragraph (version B):
Error codes of the format "0x1f * N + 0x21" for non-negative integer
values of "N" are reserved to exercise the requirement that unknown
error codes be treated as equivalent to (extensions).
Implementations SHOULD select an error code from this space with some
probability when they would have sent .
Paragraph (version A):
Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements.  Implementations MUST discard data or
abort reading on unidirectional streams that have unknown or
unsupported types.  This means that any of these extension points can
be safely used by extensions without prior arrangement or
negotiation.  However, where a known frame type is required to be in
a specific location, such as the SETTINGS frame as the first frame of
the control stream (see control-streams), an unknown frame type does
not satisfy that requirement and SHOULD be treated as an error.
Paragraph (version A):
Extensions that could change the semantics of existing protocol
components MUST be negotiated before being used.  For example, an
extension that changes the layout of the HEADERS frame cannot be used
until the peer has given a positive signal that this is acceptable.
Coordinating when such a revised layout comes into effect could prove
complex.  As such, allocating new identifiers for new definitions of
existing protocol elements is likely to be more effective.
Paragraph (version B):
Implementations MUST ignore unknown or unsupported values in all
extensible protocol elements.  Implementations MUST discard data or
abort reading on unidirectional streams that have unknown or
unsupported types.  This means that any of these extension points can
be safely used by extensions without prior arrangement or
negotiation.  However, where a known frame type is required to be in
a specific location, such as the frame as the first frame of the (see
control-streams), an unknown frame type does not satisfy that
requirement and SHOULD be treated as an error.
Paragraph (version B):
Extensions that could change the semantics of existing protocol
components MUST be negotiated before being used.  For example, an
extension that changes the layout of the frame cannot be used until
the peer has given a positive signal that this is acceptable.
Coordinating when such a revised layout comes into effect could prove
complex.  As such, allocating new identifiers for new definitions of
existing protocol elements is likely to be more effective.
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 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 (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 malformed
(malformed).  Valid characters are defined by the "field-content"
ABNF rule in HTTP.
Paragraph (version A):
Pushed responses do not have an explicit request from the client; the
request is provided by the server in the PUSH_PROMISE frame.
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 (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):
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):
Pushed responses do not have an explicit request from the client; the
request is provided by the server in the frame.
Paragraph (version A):
The number of PUSH_PROMISE frames is constrained in a similar
fashion.  A client that accepts server push SHOULD limit the number
of push IDs it issues at a time.
Paragraph (version B):
The number of frames is constrained in a similar fashion.  A client
that accepts server push SHOULD limit the number of push IDs it
issues at a time.
Paragraph (version A):
The ability to send undefined protocol elements that the peer is
required to ignore can be abused to cause a peer to expend additional
processing time.  This might be done by setting multiple undefined
SETTINGS parameters, unknown frame types, or unknown stream types.
Note, however, that some uses are entirely legitimate, such as
optional-to-understand extensions and padding to increase resistance
to traffic analysis.
Paragraph (version B):
The ability to send undefined protocol elements that the peer is
required to ignore can be abused to cause a peer to expend additional
processing time.  This might be done by setting multiple undefined
parameters, unknown frame types, or unknown stream types.  Note,
however, that some uses are entirely legitimate, such as optional-to-
understand extensions and padding to increase resistance to traffic
analysis.
Paragraph (version A):
An endpoint that does not monitor such behavior exposes itself to a
risk of denial-of-service attack.  Implementations SHOULD track the
use of these features and set limits on their use.  An endpoint MAY
treat activity that is suspicious as a connection error of type
H3_EXCESSIVE_LOAD (errors), but false positives will result in
disrupting valid connections and requests.
Paragraph (version B):
An endpoint that does not monitor such behavior exposes itself to a
risk of denial-of-service attack.  Implementations SHOULD track the
use of these features and set limits on their use.  An endpoint MAY
treat activity that is suspicious as a of type , but false positives
will result in disrupting valid connections and requests.
Paragraph (version A):
An endpoint can use the SETTINGS_MAX_FIELD_SECTION_SIZE (header-size-
constraints) setting to advise peers of limits that might apply on
the size of field sections.  This setting is only advisory, so
endpoints MAY choose to send field sections that exceed this limit
and risk having the request or response being treated as malformed.
This setting is specific to an HTTP/3 connection, so any request or
response could encounter a hop with a lower, unknown limit.  An
intermediary can attempt to avoid this problem by passing on values
presented by different peers, but they are not obligated to do so.
Paragraph (version B):
An endpoint can use the (header-size-constraints) setting to advise
peers of limits that might apply on the size of field sections.  This
setting is only advisory, so endpoints MAY choose to send field
sections that exceed this limit and risk having the request or
response being treated as .  This setting is specific to an HTTP/3
connection, so any request or response could encounter a hop with a
lower, unknown limit.  An intermediary can attempt to avoid this
problem by passing on values presented by different peers, but they
are not obligated to do so.