Draft: draft-ietf-webtrans-http2

Commentary: Capsule design team output . Tries to avoid touching flow control so that we can tackle the open issues there separately , but converts the rest of HTTP/2 over to using capsules , as discussed . See also . Same content as , thank you to those who have already reviewed ! 
 I do n’t agree with this . A client can send a request body without awaiting a response . Always . Originally posted by in 
 Are those concerns orthogonal ? I do n't believe there is anything in the text that says you can not send data before the session is established . 
 Current text : Upon receiving an extended CONNECT request with a field set to , the HTTP server checks if the identified resource supports WebTransport sessions . If the resource does not , the server SHOULD reply with status code 404 ( { { Section 6.5.4 of ! RFC7231 } } ) . If it does , it MAY accept the session by replying with a 2xx series status code , as defined in Section 15.3 of { { ! SEMANTICS = I - D.ietf - httpbis - semantics } } . The WebTransport server MUST verify the header to ensure that the specified origin is allowed to access the server in question . Originally posted by in 
 The corresponding text in HTTP/3 appears to be : This is correct , though I am not sure how necessary it is . 
 Discussed in editor 's call : 406 sounds good 
 I am afraid that some implementations will oversee the fact that SETTINGSENABLEWEBTRANSPORT actually enables SETTINGSENABLECONNECT_PROTOCOL and thereby other functionalities , e.g.  . Therefore it may be better to explicitly send the setting . This section should also link to and hopefully that draft should have some text about handling the case when a particular extended - connect protocol is not supported . 
 WebTransport over HTTP/3 has the similar issue . 
 Or perhaps , WebTransport is evolving into something different enough that we do n't want to imply support for H2 extended CONNECT for websockets by virtue of supporting webtransport . 
 Yeah , I think that - based on discussion about what the setting means - we could reasonably say that supporting extended CONNECT is enough for h2 . For h3 , we definitely need the intermediary to signal support . HOWEVER , an intermediary that fowards HTTP/2 on to HTTP/3 without understanding the protocol contents ( which might be possible for some extended CONNECT usages , like websockets ) will fail fairly spectacularly when it comes to forwarding WebTransport from h2 to h3 . Because we decided that streams and datagrams need to use real streams and datagrams in h3 . That comes back to needing a clear signal of support .. UNLESS , if we assume that a server should not ever be in a position to expose an endpoint that speaks WebTransport without ensuring that the resource supports it . In which case , the error that arises from the h2 - h3 forwarding is perfectly OK . I think that I could live with any outcome here as long as these little wrinkles were properly acknowledged . I might prefer the minimal approach ( no setting for this protocol ) if I had to choose . Adding stuff later is much easier than taking them away . 
 Clarifying question about this part , too : Would n't we have HTTP/3 point to WebSockets over H3 , whereas here we 'd point to WebSockets over H2 ? 
 Now that we have SETTINGSMAXWEBTRANSPORT_SESSIONS in the , that should suffice . Keeping this pending that outcome and any updates we want to make for clarity . 
 After further discussion , it seems like teaching every layer about every other layer 's enablement signals is more painful than originally assumed . Let 's keep all the signals . 
 Discussed at IETF 115 , consensus in room to require all the relevant settings and transport parameters to be sent individually - for this issue means : require that SETTINGSENABLECONNECT_PROTOCOL be sent 
 If the CAPSULE frame defined in the HTTP/3 DATAGRAM draft is extended to HTTP/2 , then it probably makes more sense to use that , rather than a new WT_DATAGRAM frame . 
 Agreed , if this comes to HTTP/2 then reusing it seems better than minting yet - another - of - the - same thing . 
 We need to decide whether or not we 're using capsules , and if so , how do we shape it . 
 Chair notes from IETF 112 meeting : this is on hold pending output of MASQUE HTTP Datagrams design team 
 Chair : discussed at 113 , design team will be formed to discuss this issue , led by The chairs will email a call for volunteers on the mailing list 
 Design team output presented at IETF 114 , further updates coming for 115 . 
 A few things here , but overall this is good work and much appreciated . Thanks for doing the hard part  .
By relying only on generic HTTP semantics, this protocol might allow
deployment using any HTTP version.  However, this document only
defines negotiation for HTTP/2 H2 as the current most common TCP-
based fallback to HTTP/3.
By relying only on generic HTTP semantics, this protocol might allow
deployment using any HTTP version.  However, this document only
defines negotiation for HTTP/2 HTTP2 as the current most common TCP-
based fallback to HTTP/3.
When an HTTP/2 connection is established, both the client and server
have to send a SETTINGS_ENABLE_WEBTRANSPORT setting in order to
indicate that they both support WebTransport over HTTP/2.
When an HTTP/2 connection is established, both the client and server
have to send a SETTINGS_ENABLE_WEBTRANSPORT setting to indicate that
they both support WebTransport over HTTP/2.
The server also needs to send a SETTINGS_WEBTRANSPORT_MAX_SESSIONS
setting with a value greater than "0" to indicate the number of
concurrent sessions it is willing to receive.
A client initiates a WebTransport session by sending an extended
CONNECT request RFC8441.  If the server accepts the request, a
WebTransport session is established.  The stream that carries the
CONNECT request is used to exchange bidirectional data for the
session.  This stream will be referred to as a _CONNECT stream_.  The
stream ID of a CONNECT stream, which will be referred to as a
_Session ID_, is used to uniquely identify a given WebTransport
session within the connection.
After the session is established, endpoints exchange _WebTransport
frames_ using the bidirectional CONNECT stream.  Within this stream,
_WebTransport streams_ and _WebTransport datagrams_ are multiplexed.
In HTTP/2, WebTransport frames are carried in HTTP/2 DATA frames.
Multiple independent WebTransport sessions can share a connection if
the HTTP version supports that, as HTTP/2 does.
Stream creation and data flow on streams uses flow control mechanisms
modeled on those in QUIC.  Flow control is managed using the
WebTransport frames: , , , , , and . Flow control for the CONNECT
stream as a whole, as provided by the HTTP version in use, applies in
addition to any WebTransport-session-level flow control.
WebTransport streams can be aborted using a frame and a receiver can
request that a sender stop sending with a frame.
A client initiates a WebTransport session by sending an extended
CONNECT request RFC8441.  If the server accepts the request, a
WebTransport session is established.  The stream that carries the
CONNECT request is used to exchange bidirectional data for the
session.  This stream will be referred to as a _CONNECT stream_.  The
stream ID of a CONNECT stream, which will be referred to as a
_Session ID_, is used to uniquely identify a given WebTransport
session within the connection.  WebTransport using HTTP/2 uses
extended CONNECT with the same "webtransport" HTTP Upgrade Token as
WEBTRANSPORT-H3.  This Upgrade Token uses the Capsule Protocol as
defined in HTTP-DATAGRAM.
After the session is established, endpoints exchange WebTransport
messages using the Capsule Protocol on the bidirectional CONNECT
stream, the "data stream" as defined in Section 3.1 of HTTP-DATAGRAM.
Within this stream, _WebTransport streams_ and _WebTransport
datagrams_ are multiplexed.  In HTTP/2, WebTransport capsules are
carried in HTTP/2 DATA frames.  Multiple independent WebTransport
sessions can share a connection if the HTTP version supports that, as
HTTP/2 does.
Stream creation and data flow on streams uses flow control mechanisms
modeled on those in QUIC.  Flow control is managed using the
WebTransport capsules: , , , , , and . Flow control for the CONNECT
stream as a whole, as provided by the HTTP version in use, applies in
addition to any WebTransport-session-level flow control.
WebTransport streams can be aborted using a capsule and a receiver
can request that a sender stop sending with a capsule.
RFC8441 defines an extended CONNECT method in features, enabled by
the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint does not
need to send both SETTINGS_ENABLE_CONNECT_PROTOCOL and
SETTINGS_ENABLE_WEBTRANSPORT; the SETTINGS_ENABLE_WEBTRANSPORT
setting implies that an endpoint supports extended CONNECT.
RFC8441 defines an extended CONNECT method in features, enabled by
the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  An endpoint needs to
send both SETTINGS_ENABLE_CONNECT_PROTOCOL and
SETTINGS_ENABLE_WEBTRANSPORT for WebTransport to be enabled.
Upon receiving an extended CONNECT request with a ":protocol" field
set to "webtransport", the HTTP server checks if the identified
resource supports WebTransport sessions.  If the resource does not,
the server SHOULD reply with status code 404 (Section 6.5.4 of
RFC7231).  To accept a WebTransport session the server replies with
2xx status code.  Before accepting a session, a server MUST ensure
that it authorizes use of the session by the site identified in the
"Origin" header.
From the client's perspective, a WebTransport session is established
when the client receives a 200 response.  From the server's
perspective, a session is established once it sends a 200 response.
Both endpoints MUST NOT send any WebTransport frames on a given
session before that session is established.
"HTTP_STREAM_REFUSED" error code defined in RFC7540 indicates to
the receiving HTTP/2 stack that the request was not processed in
any way.
HTTP status code 429 indicates that the request was rejected due
to rate limiting RFC6585.  Unlike the previous method, this signal
is directly propagated to the application.
Upon receiving an extended CONNECT request with a ":protocol" field
set to "webtransport", the HTTP server checks if the identified
resource supports WebTransport sessions.  If the resource does not,
the server SHOULD reply with status code 404 (Section 6.5.4 of
RFC7231).  If it does, it MAY accept the session by replying with a
2xx series status code, as defined in Section 15.3 of SEMANTICS.  The
WebTransport server MUST verify the "Origin" header to ensure that
the specified origin is allowed to access the server in question.
From the client's perspective, a WebTransport session is established
when the client receives a 200 response.  From the server's
perspective, a session is established once it sends a 200 response.
Both endpoints MUST NOT send any WebTransport capsules on a given
session before that session is established.
Flow control governs the amount of resources that can be consumed or
data that can be sent.  WebTransport over HTTP/2 allows a server to
limit the number of sessions that a client can create on a single
connection; see flow-control-limit-sessions.
TCP flow control.
HTTP/2 connection flow control, which governs the total amount of
data in DATA frames for all HTTP/2 streams.
HTTP/2 stream flow control, which limits the data on a single
HTTP/2 stream.  For a WebTransport session, this includes all
capsules, including those that are exempt from session-level flow
control.
WebTransport session-level flow control, which limits the total
amount of stream data that can be sent or received on streams
within the WebTransport session.
WebTransport stream flow control, which limits data on individual
streams within a session.
TCP and HTTP/2 define the first three levels of flow control.  This
document defines the final two.
This document defines a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter
that allows the server to limit the maximum number of concurrent
WebTransport sessions on a single HTTP/3 connection.  The client MUST
NOT open more sessions than indicated in the server SETTINGS
parameters.  The server MUST NOT close the connection if the client
opens sessions exceeding this limit, as the client and the server do
not have a consistent view of how many sessions are open due to the
asynchronous nature of the protocol; instead, it MUST reply to the
CONNECT request with a status code 426, indicating that the client
attempted to open too many sessions.
WebTransport over HTTP/2 uses several capsules for flow control, and
all of these capsules define special intermediary handling as
described in Section 3.2 of HTTP-DATAGRAM.  These capsules, referred
to as the "flow control capsules" are , , , , , and .
Because flow control in WebTransport is hop-by-hop and does not
provide an end-to-end signal, intermediaries MUST consume flow
control signals and express their own flow control limits to the next
hop.  The intermediary can send these signals via HTTP/3 flow control
messages, HTTP/2 flow control messages, or as WebTransport flow
control capsules, where appropriate.  Intermediaries are responsible
for storing any data for which they advertise flow control credit if
that data cannot be immediately forwarded to the next hop.
In practice, an intermediary that translates flow control signals
between simlar WebTransport protocols, such as between two HTTP/2
connections, can often simply reexpress the same limits received on
one connection directly on the other connection.
An intermediary that does not want to be responsible for storing data
that cannot be immediately sent on its translated connection would
ensure that it does not advertise a higher flow control limit on one
connection than the corresponding limit on the translated connection.
Endpoints MUST send stream data in order.  As there is no ordering
mechanism available for the receiver to reassemble incoming data,
receivers assume that all data arriving in STREAM frames is
contiguous and in order.
DATAGRAM frames are delivered to the remote WebTransport endpoint
reliably, however this does not require that the receiving
implementation deliver that data to the application in a reliable
manner.
Endpoints MUST send stream data in order.  As there is no ordering
mechanism available for the receiver to reassemble incoming data,
receivers assume that all data arriving in capsules is contiguous and
in order.
DATAGRAM capsules are delivered to the remote WebTransport endpoint
reliably, however this does not require that the receiving
implementation deliver that data to the application in a reliable
manner.
Because WebTransport does not provide an acknowledgement mechanism
for WebTransport frames, it relies on the underlying transport's in
order delivery to inform stream state transitions.  Wherever QUIC
relies on receiving an ack for a packet to transition between stream
states, WebTransport performs that transition immediately.
WebTransport frames mirror their QUIC counterparts as closely as
possible to enable maximal reuse of any applicable QUIC
infrastructure by implementors.
A WebTransport frame begins with a Frame Type and Frame Length which
are followed by zero or more fields that are type-dependent.
The Frame Type field indicates the type of the frame, defining what
type-dependent fields will be present.
The Frame Length field indicates the length of the WebTransport
frame, including all type-dependent fields and other information.  It
does not include the size of the Frame Type or Frame Length fields
themselves.
Both of these fields use a variable-length integer encoding (see
Section 16 of RFC9000), with one exception.  To ensure simple and
efficient implementations of frame parsing, the frame type and length
MUST use the shortest possible encoding.  For example, for the frame
types defined in this document, this means a single-byte encoding,
even though it is possible to encode these values as a two-, four-,
or eight-byte variable-length integer.
A frame (type=0x00) has no semantic value.  PADDING frames can be
used to introduce additional data between other WebTransport frames
and can also be used to provide protection against traffic analysis
or for other reasons.
A WebTransport frame called is introduced for either endpoint to
abruptly terminate the sending part of a WebTransport stream.
An endpoint uses a frame (type=0x04) to abruptly terminate the
sending part of a stream.
After sending a , an endpoint ceases transmission of frames on the
identified stream.  A receiver of can discard any data that it
already received on that stream.
Because WebTransport does not provide an acknowledgement mechanism
for WebTransport capsules, it relies on the underlying transport's in
order delivery to inform stream state transitions.  Wherever QUIC
relies on receiving an ack for a packet to transition between stream
states, WebTransport performs that transition immediately.
WebTransport capsules mirror their QUIC frame counterparts as closely
as possible to enable maximal reuse of any applicable QUIC
infrastructure by implementors.
WebTransport capsules use the Capsule Protocol defined in Section 3.2
of HTTP-DATAGRAM.
A capsule is an HTTP capsule HTTP-DATAGRAM of type=0x190B4D38 and has
no semantic value.  capsules can be used to introduce additional data
between other HTTP datagrams and can also be used to provide
protection against traffic analysis or for other reasons.
A capsule is an HTTP capsule HTTP-DATAGRAM of type=0x190B4D39 and
allows either endpoint to abruptly terminate the sending part of a
WebTransport stream.
After sending a capsule, an endpoint ceases transmission of capsules
on the identified stream.  A receiver of a capsule can discard any
data that it already received on that stream.
Unlike the equivalent QUIC frame, this frame does not include a Final
Size field.  In-order delivery of frames ensures that the amount of
session-level flow control consumed by a stream is always known by
both endpoints.
A WebTransport frame called is introduced to communicate that
incoming data is being discarded on receipt per application request.
requests that a peer cease transmission on a stream.
Unlike the equivalent QUIC frame, this capsule does not include a
Final Size field.  In-order delivery of capsules ensures that the
amount of session-level flow control consumed by a stream is always
known by both endpoints.
An HTTP capsule HTTP-DATAGRAM called (type=0x190B4D3A) is introduced
to communicate that incoming data is being discarded on receipt per
application request.  requests that a peer cease transmission on a
WebTransport stream.
frames implicitly create a stream and carry stream data.
The Type field in the frame is either 0x0a or 0x0b.  This uses the
same frame types as a QUIC STREAM frame with the OFF bit clear and
the LEN bit set.  The FIN bit (0x01) in the frame type indicates that
the frame marks the end of the stream in one direction.  Stream data
consists of any number of 0x0a frames followed by a terminal 0x0b
frame.
Zero or more bytes of data for the stream.  Empty frames MUST NOT
be used unless they open or close a stream; an endpoint MAY treat
an empty frame that neither starts nor ends a stream as a session
error.
A WebTransport frame called is introduced to inform the peer of the
maximum amount of data that can be sent on the WebTransport session
as a whole.
All data sent in frames counts toward this limit.  The sum of the
lengths of Stream Data fields in frames MUST NOT exceed the value
advertised by a receiver.
A WebTransport frame called is introduced to inform a peer of the
maximum amount of data that can be sent on a stream.
capsules implicitly create a WebTransport stream and carry stream
data.
The Type field in the capsule is either 0x190B4D3B or 0x190B4D3C.
The least significant bit in the capsule type is the FIN bit (0x01),
indicating when set that the capsule marks the end of the stream in
one direction.  Stream data consists of any number of 0x190B4D3B
capsules followed by a terminal 0x190B4D3C capsule.
Zero or more bytes of data for the stream.  Empty capsules MUST
NOT be used unless they open or close a stream; an endpoint MAY
treat an empty capsule that neither starts nor ends a stream as a
session error.
An HTTP capsule HTTP-DATAGRAM called (type=0x190B4D3D) is introduced
to inform the peer of the maximum amount of data that can be sent on
the WebTransport session as a whole.
All data sent in capsules counts toward this limit.  The sum of the
lengths of Stream Data fields in capsules MUST NOT exceed the value
advertised by a receiver.
An HTTP capsule HTTP-DATAGRAM called (type=0x190B4D3E) is introduced
to inform a peer of the maximum amount of data that can be sent on a
WebTransport stream.
All data sent in frames for the identified stream counts toward this
limit.  The sum of the lengths of Stream Data fields in frames on the
identified stream MUST NOT exceed the value advertised by a receiver.
A WebTransport frame called is introduced to inform the peer of the
cumulative number of streams of a given type it is permitted to open.
A frame with a type of 0x12 applies to bidirectional streams, and a
frame with a type of 0x13 applies to unidirectional streams.
All data sent in capsules for the identified stream counts toward
this limit.  The sum of the lengths of Stream Data fields in capsules
on the identified stream MUST NOT exceed the value advertised by a
receiver.
An HTTP capsule HTTP-DATAGRAM called is introduced to inform the peer
of the cumulative number of streams of a given type it is permitted
to open.  A capsule with a type of 0x190B4D3F applies to
bidirectional streams, and a capsule with a type of 0x190B4D40
applies to unidirectional streams.
A sender SHOULD send a frame (type=0x14) when it wishes to send data
but is unable to do so due to WebTransport session-level flow
control.  frames can be used as input to tuning of flow control
algorithms.
A sender SHOULD send a frame (type=0x15) when it wishes to send data
but is unable to do so due to stream-level flow control.  This frame
is analogous to .
A sender SHOULD send a capsule (type=0x190B4D41) when it wishes to
send data but is unable to do so due to WebTransport session-level
flow control.  capsules can be used as input to tuning of flow
control algorithms.
A sender SHOULD send a capsule (type=0x190B4D42) when it wishes to
send data but is unable to do so due to stream-level flow control.
This capsule is analogous to .
A sender SHOULD send a frame (type=0x16 or 0x17) when it wishes to
open a stream but is unable to do so due to the maximum stream limit
set by its peer.  A frame of type 0x16 is used to indicate reaching
the bidirectional stream limit, and a STREAMS_BLOCKED frame of type
0x17 is used to indicate reaching the unidirectional stream limit.
A frame does not open the stream, but informs the peer that a new
stream was needed and the stream limit prevented the creation of the
stream.
The frame type (0x31) is used to carry datagram traffic.  Frame type
0x30 is also reserved to maintain parity with QUIC, but unused, as
all WebTransport frames MUST contain a length field.
The data in frames is not subject to flow control.  The receiver MAY
discard this data if it does not have sufficient space to buffer it.
An intermediary could forward the data in a frame over another
protocol, such as WebTransport over HTTP/3.  In QUIC, a datagram
frame can span at most one packet.  Because of that, the applications
have to know the maximum size of the datagram they can send.
However, when proxying the datagrams, the hop-by-hop MTUs can vary.
A sender SHOULD send a capsule (type=0x190B4D43 or 0x190B4D44) when
it wishes to open a stream but is unable to do so due to the maximum
stream limit set by its peer.  A capsule of type 0x190B4D43 is used
to indicate reaching the bidirectional stream limit, and a
STREAMS_BLOCKED capsule of type 0x190B4D44 is used to indicate
reaching the unidirectional stream limit.
A capsule does not open the stream, but informs the peer that a new
stream was needed and the stream limit prevented the creation of the
stream.
WebTransport over HTTP/2 uses the DATAGRAM capsule defined in
Section 3.5 of HTTP-DATAGRAM to carry datagram traffic.
The data in DATAGRAM capsules is not subject to flow control.  The
receiver MAY discard this data if it does not have sufficient space
to buffer it.
An intermediary could forward the data in a DATAGRAM capsule over
another protocol, such as WebTransport over HTTP/3.  In QUIC, a
datagram frame can span at most one packet.  Because of that, the
applications have to know the maximum size of the datagram they can
send.  However, when proxying the datagrams, the hop-by-hop MTUs can
vary.
Section 3.5 of HTTP-DATAGRAM indicates that intermediaries that
forward DATAGRAM capsules where QUIC datagrams DATAGRAM are available
forward the contents of the capsule as native QUIC datagrams, rather
than as HTTP datagrams in a DATAGRAM capsule.  Similarly, when
forwarding DATAGRAM capsules used as part of a WebTransport over
HTTP/2 session on a WebTransport session that natively supports QUIC
datagrams, such as WebTransport over HTTP/3 WEBTRANSPORT-H3,
intermediaries follow the requirements in WEBTRANSPORT-H3 to use
native QUIC datagrams.
An example of the server initiating a WebTransport Stream follows.
The only difference here is the endpoint that sends the first frame.
An example of the server initiating a WebTransport Stream follows.
The only difference here is the endpoint that sends the first
capsule.
The WebTransport framework OVERVIEW defines a set of optional
transport properties that clients can use to determine the presence
of features which might allow additional optimizations beyond the
common set of properties available via all WebTransport protocols.
Below are details about support in Http2Transport for those
properties.
The WebTransport capsulework OVERVIEW defines a set of optional
transport properties that clients can use to determine the presence
of features which might allow additional optimizations beyond the
common set of properties available via all WebTransport protocols.
Below are details about support in Http2Transport for those
properties.
The "SETTINGS_WEBTRANSPORT_MAX_SESSIONS" parameter indicates that the
specified HTTP/2 connection is WebTransport-capable and the number of
concurrent sessions it is willing to receive.  The default value for
the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", meaning that
the server is not willing to receive any WebTransport sessions.
The "PADDING" capsule.
The "WT_RESET_STREAM" capsule.
The "WT_STOP_SENDING" capsule.
The "WT_STREAM" capsule.
The "WT_MAX_DATA" capsule.
The "WT_MAX_STREAM_DATA" capsule.
The "WT_MAX_STREAMS" capsule.
The "WT_DATA_BLOCKED" capsule.
The "WT_STREAM_DATA_BLOCKED" capsule.
The "WT_STREAMS_BLOCKED" capsule.