as shown here. This document follows terminology defined in Section 1.2 of OVERVIEW.  2. When a client requests a QuicTransport to be created, the user agent establishes a QUIC connection to the specified address.  It verifies <del> that the the server is a QuicTransport endpoint using ALPN, and that the client is allowed to connect to the specified endpoint using "web_accepted_origins" transport parameter.  Once the verification succeeds and the QUIC connection is ready, the client can send and receive streams and datagrams. </del>  WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation <del> RFC7301.  The user agent MUST request the ALPN value of "wq" and it MUST NOT establish the session unless that value is accepted. </del>  3.2. <del> In order to verify that the client is authorized to access a specific WebTransport server, QuicTransport has a mechanism to verify the origin RFC6454 associated with the client.  The server MUST send a "web_accepted_origins" transport parameter which SHALL be one of the following: </del>  <del> A value "*", indicating that any origin is accepted. </del>  <del> A comma-separated list of accepted origins, serialized as described in Section 6 of RFC6454. </del>  <del> In the latter case, the user agent MUST verify that one of the origins is identical (as defined in Section 5 of RFC6454) to the origin of the client; otherwise, it MUST abort the session establishment. </del>  3.3. handshake will fail.  It will also fail unless the "web_accepted_origins" is present. <del> QuicTransport uses a QUIC transport parameter to provide the user agent with an origin whitelist.  The origin is not sent explicitly, as TLS ClientHello messages are sent in cleartext; instead, the server provides the user agent with a whitelist of origins that are allowed to connect to it. </del>  In order to avoid the use of QuicTransport, the user agents MUST NOT allow the clients to distinguish different connection errors before The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: <del> The "wq-draft01" label identifies QUIC used as a protocol for </del>  WebTransport: QuicTransport <del> 0x77 0x71 0x2d 0x64 0x72 0x61 0x66 0x74 0x30 0x31 ("wq-draft01") </del>  This document 8.2. <del> The following entry is added to the "QUIC Transport Parameter Registry" registry established by QUIC-TRANSPORT: </del>  <del> The "web_accepted_origins" parameter allows the server to indicate origins that are permitted to connect to it: </del>  <del> 0xffc8 </del>  <del> web_accepted_origins </del>  <del> This document </del>

What is the uri-scheme used in an origin? ( It may be discussed as a separate issue.
Well, the origin sent here is the origin of the webpage that created QuicTransport; so, for instance, if connects using QuicTransport to , the origin send would be . I don't think a QuicTransport connection can be an origin by itself. We are currently considering giving it its own URL scheme, but a URL can only act as an origin if a user can to it, or if the URL has storage attached to it (which QuicTransport doesn't, since it doesn't support HTTP cookies).
I misunderstood the URI schema as that of QuicTransport itself Your kind explanation made me understand. thanks

as shown here. This document follows terminology defined in Section 1.2 of OVERVIEW. <ins> The diagrams describe encoding following the conventions described in Section 1.3 of QUIC-TRANSPORT. </ins> 2. When a client requests a QuicTransport to be created, the user agent establishes a QUIC connection to the specified address.  It verifies  <ins> that the the server is a QuicTransport endpoint using ALPN, and sends a _client indication_ containing the origin of the initiating website to the server.  At that point, the connection is ready from the client's perspective.  The server MUST wait until the indication is received before processing any application data. </ins> WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation  <ins> RFC7301.  The user agent MUST request the ALPN value of "wq-vvv-01" and it MUST close the connection unless the server confirms that ALPN value. </ins> 3.2.  <ins> In order to verify that the client's origin is allowed to connect to the server in question, the user agent has to communicate the origin to the server.  This is accomplished by sending a special message, called _client indication_, on stream 2, which is the first client- initiated unidirectional stream. </ins>  <ins> The client indication is a sequence of key-value pairs that are formatted in the following way: </ins>  <ins> The pair includes the following fields: </ins>  <ins> Indicates the field that is being expressed. Indicates the length of the value (the length of the key and the length itself are not included). The value of the field, the semantics of which are determined by the key. A FIN on the stream 2 SHALL indicate that the message is complete. The client MUST send the entirety of the client indication and a FIN immediately after opening the connection.  The server MUST NOT process any application data before receiving the entirety of the client indication.  The total length of the client indication MUST NOT exceed 65,535 bytes. The server MUST ignore the fields it does not recognize.  All of the fields MUST be unique; the server MAY close the connection if any of the keys is used more than once. 3.2.1. In order to allow the server to enforce the origin policy, the user agent has to communicate the origin in the client indication.  This can be accomplished using the "Origin" field: Origin 0x0000 The origin RFC6454 of the client initiating the connection. The user agent MUST send the Origin field.  The origin field MUST be set to the origin of the client initiating the connection, serialized as described in serializing a request origin [1] of FETCH. </ins> 3.3. handshake will fail.  It will also fail unless the "web_accepted_origins" is present.  <ins> QuicTransport uses a unidirectional QUIC stream to provide the server with the origin of the client. </ins> In order to avoid the use of QuicTransport, the user agents MUST NOT allow the clients to distinguish different connection errors before The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301:  <ins> The "wq-vvv-01" label identifies QUIC used as a protocol for </ins> WebTransport: QuicTransport  <ins> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x31 ("wq-vvv-01") </ins> This document 8.2.  <ins> IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the following fields: </ins>  <ins> The name of the field. </ins>  <ins> The 16-bit uniquie identifier that is used on the wire. </ins>  <ins> A brief description of what the parameter does. </ins>  <ins> The document that describes the parameter. The IANA policy, as descrbied in RFC8126, SHALL be Standards Action for values between 0x0000 and 0x03ff; Specification Required for values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff. 9.  References 9.1.  URIs [1] https://fetch.spec.whatwg.org/#serializing-a-request-origin </ins>


multiplex HTTP requests over a QUIC connection.  This document defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a manner that conforms with the WebTransport protocol requirements and <del> semantics OVERVIEW.  Using the mechanism described here, multiple </del>  WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/3 connection.

Noticed we had a few oddly long lines, so I hit the rewrap button.
This was Sublime, but many others will attempt to do the same :)
What tool do you use that has a rewrap button?

multiplex HTTP requests over a QUIC connection.  This document defines a mechanism for multiplexing non-HTTP data with HTTP/3 in a manner that conforms with the WebTransport protocol requirements and  <ins> semanticsOVERVIEW.  Using the mechanism described here, multiple </ins> WebTransport instances can be multiplexed simultaneously with regular HTTP traffic on the same HTTP/3 connection.


from the one used by the server. In addition to the setting above, the server MUST send a <del> SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter indicating the maximum </del>  number of concurrent sessions it is willing to receive.  The default <del> value for the SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter is "0", </del>  meaning that the server is not willing to receive any WebTransport sessions. 3.4. <del> This document defines a SETTINGS_MAX_WEBTRANSPORT_SESSIONS parameter </del>  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

Fix up references to setting names
The draft uses both but I presume they refer to the same thing, so lets pick one.
Ah, left over from a previous change, I believe. is the correct form, can update to match.
Yep sgtm

from the one used by the server. In addition to the setting above, the server MUST send a  <ins> SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter indicating the maximum </ins> number of concurrent sessions it is willing to receive.  The default  <ins> value for the SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter is "0", </ins> meaning that the server is not willing to receive any WebTransport sessions. 3.4.  <ins> This document defines a SETTINGS_WEBTRANSPORT_MAX_SESSIONS parameter </ins> 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


When a client requests a QuicTransport session to be created, the user agent establishes a QUIC connection to the specified address. It verifies that the the server is a QuicTransport endpoint using <del> ALPN, and additionally sends a client indication containing the </del>  requested path and the origin of the initiating website to the server.  At that point, the connection is ready from the client's <del> perspective.  The server MUST wait until the client indication is received before processing any application data. </del>  WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams In order to establish a QuicTransport session, a QUIC connection must be established.  From the client perspective, the session becomes established when the client both have received a TLS Finished message <del> from the server and has sent a client indication.  From the server perspective, the session is established after the client indication has been successfully processed. </del>  3.1. In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation <del> RFC7301.  The user agent MUST request the ALPN value of "wq-vvv-01" </del>  and it MUST close the connection unless the server confirms that ALPN value. In order to verify that the client's origin is allowed to connect to the server in question, the user agent has to communicate the origin <del> to the server.  This is accomplished by sending a special message, called client indication, on stream 2, which is the first client- initiated unidirectional stream. </del>  <del> The client indication is a sequence of key-value pairs that are formatted in the following way: </del>  <del> The pair includes the following fields: </del>  <del> Indicates the field that is being expressed. </del>  <del> Indicates the length of the value (the length of the key and the length itself are not included). </del>  <del> The value of the field, the semantics of which are determined by the key. </del>  <del> A FIN on the stream 2 SHALL indicate that the message is complete. The client MUST send the entirety of the client indication and a FIN immediately after opening the connection.  The server MUST NOT process any application data before receiving the entirety of the client indication.  The total length of the client indication MUST NOT exceed 65,535 bytes. </del>  <del> In order to ensure that the user agent can send the client indication immediately, the server MUST set "initial_max_streams_uni" transport </del>  parameter to at least "1".  The user agent MUST close the connection <del> if the server sets "initial_max_streams_uni" to "0". </del>  The server MUST ignore any field it does not recognize.  All of the fields MUST be unique; the server MAY close the connection if any of 3.2.1. In order to allow the server to enforce its origin policy, the user <del> agent has to communicate the origin in the client indication.  This can be accomplished using the "Origin" field: </del>  Origin <del> 0x0000 </del> The origin RFC6454 of the client initiating the connection. The user agent MUST send the "Origin" field.  The "Origin" field MUST serialized as described in the "serializing a request origin" section of FETCH.  3.2.2. In order to allow multiplexing multiple application on the same host- port tuple, QuicTransport allows specifying extra routing information in the path component of the URI.  That component is communicated <del> using the "Path" field in the client indication: </del>  Path <del> 0x0001 </del> The path component of the QuicTransport URI. The user agent MUST send a non-empty "Path" field.  When the abempty" is empty, the value sent SHALL be "/". Unlike HTTP, the "authority" portion of the URL is not communicated <del> in the client indication.  As QuicTransport has its own connection dedicated to it, the host name portion can be retrieved from the "server_name" TLS extension RFC6066. </del>  The server MAY use the value of the "Path" field in any way defined by the target application. QuicTransport URI SHALL be: The "path-abempty" and the "query" portions of the URI are <del> communicated to the server in the client indication as described in path-field.  The "quic-transport" URI scheme supports the "/.well- known/" path prefix defined in RFC8615. </del>  This document does not assign any semantics to the "fragment" portion of the URI.  Any QuicTransport implementation MUST ignore those until The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: <del> The "wq-vvv-01" label identifies QUIC used as a protocol for </del>  WebTransport: QuicTransport <del> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x31 ("wq-vvv-01") </del>  This document 9.2. <del> IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the following fields: </del>  The name of the field. <del> The 16-bit unique identifier that is used on the wire. </del> A brief description of what the parameter does. The document that describes the parameter. <del> The IANA policy, as described in RFC8126, SHALL be Standards Action for values between 0x0000 and 0x03ff; Specification Required for values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff. </del>  9.3.

We currently use 16-bit integers for header names. There probably won't ever be more than 65,000 headers, but this does not let users add their own custom headers easily. Thus, this commit changes uint16 to string. We currently provide a way for a server to explicitly reject client's origin, but no way to explicitly accept it. This commit solves this by turning the client indication stream into a bidirectional handshake stream. Server confirms the handshake by sending a FIN on its end of the handshake stream.
Reviewing , NAME wrote: I do agree that this is annoying, but at the same time adding a field that's redundant 90% of the time feels... weird? We should think more seriously about how to make header size limits work at some point (maybe using ALPS or something like that).
Closing this issue because the QuicTransport draft has been removed from this repository.
In WebTransport over QUIC, when an invalid Client Indication is received, the server treats the connection as an error(). This is an error that occurred in a layer above the QUIC, so I think the connection should be closed with CONNECTION_CLOSE (0x1d) indicating an error in the application using the QUIC. I think it is valuable to define an error code for WebTransport over QUIC. ( saids "the management of application error codes is left to application protocols." ) and, by specifying the error code that the endpoint uses when it close the connection, the specification becomes clear. for example
I realized that using Error Code is related to the . Do not conflict with error codes used by applications above WebTransport. so, I createted URL . Please point it out if there are any mistakes in my opinion. thanks
I agree, CONNECTION_CLOSE should provide an error code indicating why the connection was refused.
I seem to remember seeing non-zero error codes from other endpoints when interoperating. If so, I have no clue what those codes were supposed to mean. I think it would be useful to have some defined in the next draft version.
I think the non-zero error codes probably were random HTTP/3 error codes, because those are the only codes that Google's QUIC library supports (that's a known bug). I see three options for reporting handshake error: 1) An application CONNECTIONCLOSE, 2) A RESETSTREAM on the handshake stream, 3) An error status code on the handshake stream. If we go with 1, we would have to reserve some of the application error code space. If we go with 2 or 3, we would have to describe how the server has to keep the connection open for some time in order to allow for retransmission of the RESET_STREAM/response error header.
Closing this issue because the QuicTransport draft has been removed from this repository.

When a client requests a QuicTransport session to be created, the user agent establishes a QUIC connection to the specified address. It verifies that the the server is a QuicTransport endpoint using  <ins> ALPN, and additionally sends a set of headers containing the </ins> requested path and the origin of the initiating website to the server.  At that point, the connection is ready from the client's  <ins> perspective.  The server MUST wait until it processes client headers before processing any other application data. </ins> WebTransport streams are provided by creating an individual unidirectional or bidirectional QUIC stream.  WebTransport datagrams In order to establish a QuicTransport session, a QUIC connection must be established.  From the client perspective, the session becomes established when the client both have received a TLS Finished message  <ins> from the server and has sent its headers.  From the server perspective, the session is established after the client headers have been successfully processed. </ins> 3.1. In order to identify itself as a WebTransport application, QuicTransport relies on TLS Application-Layer Protocol Negotiation  <ins> RFC7301.  The user agent MUST request the ALPN value of "wq-vvv-03" </ins> and it MUST close the connection unless the server confirms that ALPN value. In order to verify that the client's origin is allowed to connect to the server in question, the user agent has to communicate the origin  <ins> to the server.  This is accomplished by performing a handshake on the first client-initiated bidirectional stream, stream 0.  The handshake is performed as follows: </ins>  <ins> The client sends its headers on stream 0. </ins>  <ins> The client sends FIN on stream 0.  This indicates that all headers have been sent, and the server can now process them. The server processes the headers and makes access control decision based on the origin.  Before this happens, the server MUST NOT process any non-header application data receiver from the client, or send its own header block. The server sends its header block on stream 0, followed by a FIN indicating that the handshake has been successfully completed. </ins>  <ins> The QuicTransport header stream payload SHALL be a header block.  A header block is a sequence of key-value pairs that are formatted in the following way: The pair includes the following fields: </ins>  <ins> Indicates the name of the field that is being expressed.  The name of the field is case-insensitive, and when encoded on the wire, it MUST consist of ASCII characters in range from "a" to "z", "0" to "9", "-", or ".".  It MUST begin with an alphanumeric character. </ins>  <ins> The value of the header field, the semantics of which are determined by the name. </ins>  <ins> A FIN on the stream 0 SHALL indicate that the message is complete. The client MUST send the entirety of the header block and a FIN immediately after opening the connection.  Before receiving the entirety of the headers, the server MUST NOT process any datagrams or any data on streams other than 0.  The total length of a header block MUST NOT exceed 1,048,576 bytes; implementations MAY impose additional limit on the header block size. </ins>  <ins> In order to ensure that the user agent can send the headers immediately, the server MUST set "initial_max_streams_bidi" transport </ins> parameter to at least "1".  The user agent MUST close the connection  <ins> if the server sets "initial_max_streams_bidi" to "0". </ins> The server MUST ignore any field it does not recognize.  All of the fields MUST be unique; the server MAY close the connection if any of 3.2.1. In order to allow the server to enforce its origin policy, the user  <ins> agent has to communicate the origin in the handshake.  This can be accomplished using the "Origin" field: </ins> Origin  The origin RFC6454 of the client initiating the connection. The user agent MUST send the "Origin" field.  The "Origin" field MUST serialized as described in the "serializing a request origin" section of FETCH. <ins> The server indicates that it accepts the origin by sending its header block and a FIN on the stream 0.  If the server does not accept the origin, it MUST close the connection. </ins> 3.2.2. In order to allow multiplexing multiple application on the same host- port tuple, QuicTransport allows specifying extra routing information in the path component of the URI.  That component is communicated  <ins> using the "Path" header: </ins> Path  The path component of the QuicTransport URI. The user agent MUST send a non-empty "Path" field.  When the abempty" is empty, the value sent SHALL be "/". Unlike HTTP, the "authority" portion of the URL is not communicated  <ins> in the headers.  As QuicTransport has its own connection dedicated to it, the host name portion can be retrieved from the "server_name" TLS extension RFC6066. </ins> The server MAY use the value of the "Path" field in any way defined by the target application. QuicTransport URI SHALL be: The "path-abempty" and the "query" portions of the URI are  <ins> communicated to the server in the headers as described in path-field. The "quic-transport" URI scheme supports the "/.well-known/" path prefix defined in RFC8615. </ins> This document does not assign any semantics to the "fragment" portion of the URI.  Any QuicTransport implementation MUST ignore those until The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301:  <ins> The "wq-vvv-03" label identifies QUIC used as a protocol for </ins> WebTransport: QuicTransport  <ins> 0x77 0x71 0x2d 0x76 0x76 0x76 0x2d 0x30 0x33 ("wq-vvv-03") </ins> This document 9.2.  <ins> IANA SHALL add a registry for "QuicTransport Header Fields" registry. Every entry in the registry SHALL include the following fields: </ins> The name of the field.  A brief description of what the parameter does. The document that describes the parameter.  <ins> The IANA policy, as described in RFC8126, SHALL be Expert Review. </ins> 9.3.


6.  QuicTransport supports most of WebTransport features as described in properties. <del> 7. </del>  QuicTransport satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework opened.  The server MAY limit the amount of connections open by the same client. <del> 8. </del>  <del> 8.1. </del>  The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: This document <del> 8.2. </del>  IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff. <del> 9.  References </del>  <del> 9.1.  URIs </del>  [1] https://fetch.spec.whatwg.org/#serializing-a-request-origin  4.3.  In order to create a new Http3Transport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field MUST be set to "webtransport".  The ":scheme" field MUST be "https".  Both logically independent of each other even if some transports can share same connection underneath. <del> A transport protocol (WebTransprot protocol in context where this </del>  might be ambiguos) is a protocol that can be used to back a transport on the wire.  It can provide the transport features described in this document, and is expected to fulfill all of the Any transport protocol used MUST provide a way for the server to filter the clients that can access it by the origin RFC6454.  3. WebTransport session establishment is in general asynchronous,

This defines a new URL scheme for QuicTransport, and clarifies the use of "https" for Http3Transport.

6. <ins> NOTE: the URI scheme defintion in this section is provisional and subject to change, especially the name of the scheme. QuicTransport uses the "quic-transport" URI scheme for identifying QuicTransport servers. The syntax definition below uses Augmented Backus-Naur Form (ABNF) RFC5234.  The definitions of "host", "port", "path-abempty", "query" and "fragment" are adopted from RFC3986.  The syntax of a QuicTransport URI SHALL be: This document does not define any semantics to "path-abempty", "query" or "fragment" portions of the URI, nor does it delegate those to the host owners.  Any QuicTransport implementation MUST ignore those until a subsequent specification assigns semantics to those. The "host" component MUST NOT be empty.  If the "port" component is missing, the port SHALL be assumed to be 0. NOTE: this effectively requires the port number to be specified. This specification may include an actually usable default port number in the future. In order to connect to a QuicTransport server identified by a given URI, the user agent SHALL establish a QUIC connection to the specified "host" and "port" as described in connection.  It MUST immediately signal an error to the client if the port value is 0. 7. </ins> QuicTransport supports most of WebTransport features as described in properties.  <ins> 8. </ins> QuicTransport satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework opened.  The server MAY limit the amount of connections open by the same client.  <ins> 9. </ins>  <ins> 9.1. </ins> The following entry is added to the "Application Layer Protocol Negotiation (ALPN) Protocol IDs" registry established by RFC7301: This document  <ins> 9.2. </ins> IANA SHALL add a registry for "QuicTransport Client Indication Fields" registry.  Every entry in the registry SHALL include the values between 0x0400 and 0xefff; and Private Use for values between 0xf000 and 0xffff.  <ins> 9.3. </ins>  <ins> This document contains the request for the registration of the URI scheme "quic-transport".  The registration request is in accordance with RFC7595. quic-transport Permanent QuicTransport IETF Chair chair@ietf.org [2] IESG iesg@ietf.org [3] uri of this document. 10.  References 10.1.  URIs </ins> [1] https://fetch.spec.whatwg.org/#serializing-a-request-origin <ins> [2] mailto:chair@ietf.org [3] mailto:iesg@ietf.org </ins> 4.3. <ins> As Http3Transport sessions are established over HTTP/3, they are identified using the "https" URI scheme RFC7230. </ins> In order to create a new Http3Transport session, a client can send an HTTP CONNECT request.  The ":protocol" pseudo-header field MUST be set to "webtransport".  The ":scheme" field MUST be "https".  Both logically independent of each other even if some transports can share same connection underneath.  <ins> A transport protocol (WebTransport protocol in context where this </ins> might be ambiguos) is a protocol that can be used to back a transport on the wire.  It can provide the transport features described in this document, and is expected to fulfill all of the Any transport protocol used MUST provide a way for the server to filter the clients that can access it by the origin RFC6454. <ins> Any transport protocol used MUST provide a way for a server endpoint location to be described using a URI RFC3986.  They can be used for integration with various Web platform features that represent resources as URIs, such as Content Security Policy CSP. </ins> 3. WebTransport session establishment is in general asynchronous,


in their SETTINGS frame.  The SETTINGS_ENABLE_WEBTRANSPORT parameter value SHALL be either "0" or "1", with "0" being the default; an endpoint that receives a value other than "0" or "1" MUST close the <del> connection with the H3_SETTINGS_ERROR error code.  Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated. </del>  If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating <del> QUIC DATAGRAM extension SHALL result in a H3_SETTINGS_ERROR error. </del>  HTTP3 requires client's "initial_max_bidi_streams" transport parameter to be set to zero.  Existing implementation might enforce

Requires the server to defer the processing of any incoming WebTransport sessions until the relevant settings have been received from the client. This makes versioning WebTransport extension possible.
How necessary is to wait for SETTINGSENABLEWEBTRANSPORT from the client? If we are a server, and we receive a request with set to , this seems like a pretty solid indication of support. From the current language in the draft, though, the server has to pause the processing of the request in question until the SETTINGS are there (which is really annoying to implement). One counterpoint I can see is that we could use settings to negotiate a specific version of WebTransport over HTTP/3, and in that case we do need to wait for settings from both parties.
I really do not like the idea of delaying the processing of requests on the server side, as it seems bug/attack prone. Given the client has to initiate the webtransport session, and there's no guarantee the client's SETTINGs will arrive before the servers(without something like ALPS), why not only have the server send the setting? For example, websockets in H2 only requires a setting from server to client.
One tricky thing here is that whatever we do here, it has to also work with the H3_DATAGRAM setting.
I'd suggest adding some requirements like: 1) The server MUST indicate support for both WebTransport and H3 datagram, or the connection MUST be closed. 2) The server MUST assume that if the client uses protocol "webtransport", that it supports both WebTransport and H3 datagram, and sending the SETTING is optional. But you make a good point that this could crop up in CONNECT-UDP and a few other uses of H3-Datagram. If the client is always responsible for initiating the datagram flow(s), then the SETTING for h3-datagram only needs to be sent server to client.
Discussed at the May 2021 interim. The agreement in the room seemed to be that this is unavoidable if we want to use SETTINGS for determining the version of WebTransport to use by the server.

in their SETTINGS frame.  The SETTINGS_ENABLE_WEBTRANSPORT parameter value SHALL be either "0" or "1", with "0" being the default; an endpoint that receives a value other than "0" or "1" MUST close the  <ins> connection with the H3_SETTINGS_ERROR error code. The client MUST NOT send a WebTransport request until it has received the setting indicating WebTransport support from the server. Similarly, the server MUST NOT process any incoming WebTransport requests until the client settings have been received, as the client may be using a version of WebTransport extension that is different from the one used by the server. </ins> If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating  <ins> HTTP/3 DATAGRAM support SHALL result in a H3_SETTINGS_ERROR error. </ins> HTTP3 requires client's "initial_max_bidi_streams" transport parameter to be set to zero.  Existing implementation might enforce


WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by <del> replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del>  From the client's perspective, a WebTransport session is established <del> when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. </del>  WebTransport over HTTP/3 does not support 0-RTT. 3.4.

This makes our behavior consistent with the regular CONNECT method.
The spec currently explicitly requires . suggests that any 2xx code should work. Should we change the text accordingly?
I'd suggest server MUST send 200 and client MUST accept any 2XX. That way future extensions can apply meaning to other 2XX codes.
What would happen if we require client to reject 2xx other than 200?

WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by  <ins> 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. </ins> From the client's perspective, a WebTransport session is established  <ins> when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. </ins> WebTransport over HTTP/3 does not support 0-RTT. 3.4.


4.3.  Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.4. </del>  In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data session. This document.

cc NAME
If we are going to let the API users supply their own stream reset code, we should figure out how this is represented on the wire. We could potentially use the error codes as-is and say they mean different things for WebTransport streams than what they mean for normal streams, but I am not sure this is sound as we don't always know that a stream is a WebTransport stream at the time we process the reset (also this sounds like a pain to implement). One possibility would be to reserve a block within HTTP/3 error code space. However, since HTTP/3 error codes contain GREASE code-points throughout, we might end up having to "de-grease" and "re-grease" them as the largest continuous block only has 255 codepoints available. Alternatively, if we decide to just send RESET_STREAM as a part of CONNECT stream due to issues in , we could just send the error code there, and keep one single code for user-initiated termination. Whatever we decide here should probably work for H/2 as well. cc NAME
Are application developers asking for custom reset error codes? Making reset unreliable and non-customizable would be much easier if that's sufficient for everyone's needs.
Reset error codes are special in the sense that they are reliably delivered by the transport (unlike the data, which all can be lost to a reset). So I imagine an application would want to be able to tell apart a regular reset (e.g. due to stream TTL expiring), vs reset due to an error. NAME might have opinions on this, since he filed .
We went through a concerted effort to reduce the number of H3 error codes. Partly because knowing when to use the right code (from an implementation persepctive) can be hard. H2's space is small, I don't know if the experts would allow one application to reserve a large block. At a minimum we probably need a WEBTRANSNOERROR. Maybe there are some error codes for "Web transport wire protocol error". Anticipating more specific error codes for apps using webtransport is hard. Some motivating use cases might help.
It's 32-bit, so I think we could probably get 16 bits worth of error codes.
Ah quire right, I was getting mixed up with frame type which is 8 bits. But still, reserving half the code points for one usage of H2 seems overboard. Given that H2 suffices with about a dozen error codes I really wonder what WebTransport thinks it can achieve by using so many. Maybe the ask is for a "retire stream with a status"? In which case an alternate design would be to add a control frame for webstransport that contains your own space or possibly a reason phrasr and then a generic error code such as WEBTRANSSTREAMABORT to disambiguate it from other H3 errors.
I think it's 1/65536th of the error space, not 1/2. WebTransport by itself does not need that many error codes (I have so far three or four in the code that I will write a PR as soon as I'm done); the question here is what do applications running on top of it want.
The exposes connection error codes, so it's something the transport would need to support. I think removing them would be a W3C conversation. Actually for my application, we wanted to signal when the connection was terminated gracefully versus an unexpected error. We tried using CONNECTION_CLOSE with application error codes but the QuicTransport implementation in Chrome always raised "Connection Lost" regardless of the code. We had to resort to making a new stream and our own, high priority message when the connection was closed. This also meant waiting for the message to be acknowledged before actually closing the connection, otherwise the message would be lost. So yeah, I think immediately closing a connection with an error code is useful functionality, hence why it's in QUIC as well.
Would it work to just defer that the registration to applications over WebTransport? I appreciate it's nice to have a contiguous block but there's hardly much churn in that registry and I don't know what practical benefit a contiguous range adds for distinct uses of WebTransport. I'm confused if you're attempting to reserve a block that is then allocated via some sub-protocol negotiation, or if you intend to run a registration scheme inside your reserved block. Or something else.
Are you suggesting that we should let WebTransport applications send arbitrary HTTP/3 error codes? That could work, but I am not sure what are the security consequences of that. If we only reserve a block, the error codes outside of that block are "privileged", i.e. only the browser (but not the untrusted web application) can send them.
That's a good point and puts more weight behind reserving a block that can only be used by the WebTransport API.
NAME could you elaborate on how your application reacts differently to graceful termination of a stream vs unexpected error? I'm just curious to know what you use this for.
Sure, we're doing live video streaming. We want to distinguish when the connection is closed because the live stream has ended (show an "thanks for watching" screen), versus an unexpected error (show an error screen with debug code).
Makes sense, though this is for an entire session (see ). Here we're discussing individual streams.
I'm finding the mention of CONNECTIONCLOSE slightly confusing since this thread is about stream resets. The JS API doesn't mention if CONNECTIONCLOSE is a transport-level or application-level close, it really should. The HTTP-based WebTransports support graceful connection close via GOAWAY. Applications built on WebTransport might be able to harness these properties, or they might need to create a control channel per session that could then behave exactly how they want, without the overhead of IETF registries.
Oh sorry, for some reason I thought this was for the entire connection. Resetting a stream with an error code is less useful, but again it's in the . RESET_STREAM is useful for my application because the streams transfer a large amount of data, which may be blocked on the network, but I don't have a use-case for application error codes at the moment.
Just to close the loop here. We talked about this in the context of W3C and decided that we'd like to have some number of error code points just for web transport. 256 was the initial suggestion; 100 might work; 31 was considered too small. NAME pointed out that we can play FizzBuzz and step carefully around the reserved greasing points so that a contiguous block is presented to applications even if the underlying code points are not contiguous.
FWIW, where I said there is already an issue for it URL
We discussed this at May 2021 interim, and there appeared to be an agreement in the room that we should do that. I'll write up a PR with some set of 256 points.
If a peer receives a RESETSTREAM message before it receives the first few bytes of the stream, then it is unable associate the RESETSTREAM with a protocol or session. This can occur if the STREAM packet is lost but the RESET_STREAM is not. As a consequence, if a WebTransport client closes a stream with an error code, then it's not guaranteed to be received by the server. Worse yet, a reset client-initiated bidirectional stream may be confused for a HTTP/3 request and cause intended consequences.
Can you give a more concrete example of when this is a problem? You are saying the client opened a unidirectional or bidirectional WT stream, sent some data, then reset it. The server receives only the reset, or some fraction of the data but not enough to figure out which session the stream belongs to. I think this is fine and the server just discards any partial data on this stream. If the application needs to receive the data (even just an error code) in the stream, then the client shouldn't reset it, but instead, send some application level close signal that is delivered reliably on the stream. I don't see how an H3 server could act on any stream data from the client without seeing the beginning of the stream, so I don't think there's much concern about this being served as an H3 request.
Sure. I suppose the problem is the reliable delivery of error codes. If the application closes a stream with an integer code via the , then I would expect that code to be reliably delivered to the other peer. This ambiguous RESET_STREAM case opens the possibility of the code not being associated with a WebTransport session, and thus not delivered, depending on packet loss.
Iiuc the problem is if the stream is reset before the Web Transport frame is processed (as far the current spec says). That frame associates the stream to the web transport session. A peer that receives the RESET_STREAM know something was cancelled but not whether it was a normal request or a webtransport stream. This highlights a challenge with retconning what bidirectional streams mean for a H3 stack.
I can construct an application where it's important that the peer knows about every stream that gets created, even if it is reset before anything interesting happens, but it strikes me as a bit fringy. Can you give a concrete example where the WT endpoint missing the reset stream entirely is problematic?
The only example I can think of relates to session pooling and wanting different concurrency limits in sessions. Since we decided to focus on single sessions for now, my example I'd moot. I'd be interested to know Luke's example
Ironically, the best example is an application implementing a replacement for MAX_STREAMS. Peers can't set a cumulative limit if they disagree on the number of streams created. ex. peer A creates and resets a stream, so it thinks 10 have been created in total, but packet loss could cause peer B to think only 9 have been created in total. This can eventually cause a deadlock. And yeah, it's pretty easy to imagine an application that uses stream resets. The WebTransport API makes stream closure seem reliable, when really there's a small chance that it gets silently dropped.
This seems like another case of where a "session layer" over QUIC would assist. The trouble is, in my limited understanding of the W3C WebTransport API, that it wants to use a QUIC transport feature to manage WebTransport sessions. It is going to be let down by the fact the transport behaves differently than it wishes. draft-ietf-webtrans-http3-00 defines the WEBTRANSPORT_STREAM HTTP/3 frame for initiating WebTransport streams. So it probably needs an equivalent frame for closing WebTransport streams. This could be sent on the stream itself, on a new "webtransport session control stream", or on the global control stream.
By 'on the stream itself', do you mean on the CONNECT stream that established the session? The current draft disables framing on WT streams. It could be a message like QPACK, where streams that are cancelled have an application level signal.
No. If I understand (and that's a big if) the design of draft-ietf-webtrans-http3-00 requires step 1) use extended CONNECT on client bidi stream to create a WebTransport session step 2) create WebTransport stream on different client bidi stream using WEBTRANSPORT_STREAM frame URL My suggestion wasn't about retiring WebTransport sessions, but retiring streams robustly at the application layer. If you created a stream using an H3 frame, retire it with an H3 frame. Although we adopted draft-ietf-webtrans-http3-00, I;m not sure how much of the design is appropriate/relevant to the non-pooling constraints we have added. So i guess my current understanding could be subject to change.
The current draft uses a 'TV' frame on streams created in step 2) that makes sending additional frames on those streams impossible. I'm suggesting we could use the stream created in step 1) as a "webtransport session control stream", if needed.
Ah yes, I overlooked that. In that case I agree
I was thinking about how to make those more reliable. One way would be to send a capsule with something like "stream X associated with this transport has been reset". That doesn't work, because the peers don't have consistent stream IDs across possible HTTP proxies. I think the approach we should probably go with is "stream resets are usually not reliable". As an API caveat, we should make sure that when the connection is dedicated, all resets with WebTransport error codes are followed to the client, since those are unambiguous.
This was fixed in .

4.3. <ins> A WebTransport endpoint may send a RESET_STREAM or a STOP_SENDING frame for a WebTransport data stream.  Those signals are propagated by the WebTransport implementation to the application. A WebTransport application SHALL provide an error code for those operations.  Since WebTransport shares the error code space with HTTP/3, WebTransport application errors for streams are limited to an unsigned 8-bit integer, assuming values between 0x00 and 0xff. WebTransport implementations SHALL remap those error codes into an error range where 0x00 corresponds to 0x52e4a40fa8db, and 0xff corresponds to 0x52e4a40fa9e2.  Note that there are code points inside that range of form "0x1f * N + 0x21" that are reserved by Section 8.1 of HTTP3; those have to be accounted for when mapping the error codes by skipping them (i.e. the two HTTP/3 error codepoints adjacent to a GREASE codepoint would map to two adjacent WebTransport application error codepoints).  An example pseudocode can be seen in fig-remap-errors. WebTransport data streams are associated with sessions through a header at the beginning of the stream; resetting a stream may result in that data being discarded.  Because of that, WebTransport application error codes are best effort, as the WebTransport stack is not always capable of associating the reset code with a session.  The only exception is the situation where there is only one session on a given HTTP/3 connection, and no intermediaries between the client and the server. WebTransport implementations SHALL forward the error code for a stream associated with a known session to the application that owns that session; similarly, the intermediaries SHALL reset the streams with corresponding error code when receiving a reset from the peer. If a WebTransport implementation intentionally allows only one session over a given HTTP/3 connection, it SHALL forward the error codes within WebTransport application error code range to the application that owns the only session on that connection. 4.4. </ins> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies.  <ins> 4.5. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data session. This document. <ins> In addition, the following range of entries is registered: H3_WEBTRANSPORT_APPLICATION_00 ... H3_WEBTRANSPORT_APPLICATION_FF 0x52e4a40fa8db to 0x52e4a40fa9e2 inclusive, with the exception of 0x52e4a40fa8f9, 0x52e4a40fa918, 0x52e4a40fa937, 0x52e4a40fa956, 0x52e4a40fa975, 0x52e4a40fa994, 0x52e4a40fa9b3, and 0x52e4a40fa9d2. WebTransport application error codes. This document. </ins>


Both client and server can create a unidirectional stream using a special stream type. <del> A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM. </del>  An WebTransport session is terminated when the CONNECT stream that created it is closed. in their SETTINGS frame.  The SETTINGS_ENABLE_WEBTRANSPORT parameter value SHALL be either "0" or "1", with "0" being the default; an endpoint that receives a value other than "0" or "1" MUST close the <del> connection with the H3_SETTINGS_ERROR error code.  Endpoints MUST NOT use any WebTransport-related functionality unless the parameter has been negotiated. If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating QUIC DATAGRAM extension SHALL result in a H3_SETTINGS_ERROR error. HTTP3 requires client's "initial_max_bidi_streams" transport parameter to be set to zero.  Existing implementation might enforce this requirement before negotiating settings; thus, the client MUST send a non-zero MAX_STREAMS for client-initiated bidirectional streams after receiving an appropriate SETTINGS frame from the server. </del>  3.2. WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by <del> replying with status code 200.  The WebTransport server MUST verify the "Origin" header to ensure that the specified origin is allowed to access the server in question. </del>  From the client's perspective, a WebTransport session is established <del> when the client receives a 200 response.  From the server's perspective, a session is established once it sends a 200 response. </del>  WebTransport over HTTP/3 does not support 0-RTT.  3.4. From the flow control perspective, WebTransport sessions count encoded using the QUIC variable length integer scheme described in RFC9000.  4.1. Once established, both endpoints can open unidirectional streams. 4.3. <del> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow Identifier is set to the session ID.  In other words, the format of datagrams SHALL be the session ID, followed by the user-specified payload (fig-datagram). </del>  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 MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies. <del> 4.4. </del>  In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data 5. <del> An WebTransport session over HTTP/3 is terminated when either endpoint closes the stream associated with the CONNECT request that initiated the session.  Upon learning about the session being terminated, the endpoint MUST stop sending new datagrams and reset all of the streams associated with the session. </del>  6. session. This document.

NAME NAME NAME Updated the PR; please take another look.
I think I addressed all issues; please tell me if I'm missing anything, if not, I'll merge this soon. cc NAME NAME NAME
Since the API was based off QuicTransport, the API document currently has a method to close the session, with both an error code and a reason string (modeled off QUIC CONNECTION_CLOSE): . We could attempt to reset the CONNECT stream, but that would imply that it's always reset, and will not let us supply a reason string. I think the easiest way would be to send trailers on the CONNECT stream.
If we want to allow trailers (or any non DATA frames) on the CONNECT stream, we need to add text allowing that. From the H3 spec: 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.
Issue also discusses adding a GOAWAY-type frame on the CONNECT stream. If we did that we could add an error and reason there as an alternative to trailers.
Just minor nits, looking good!

Both client and server can create a unidirectional stream using a special stream type.  <ins> A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM. </ins> An WebTransport session is terminated when the CONNECT stream that created it is closed. in their SETTINGS frame.  The SETTINGS_ENABLE_WEBTRANSPORT parameter value SHALL be either "0" or "1", with "0" being the default; an endpoint that receives a value other than "0" or "1" MUST close the  <ins> connection with the H3_SETTINGS_ERROR error code. The client MUST NOT send a WebTransport request until it has received the setting indicating WebTransport support from the server. Similarly, the server MUST NOT process any incoming WebTransport requests until the client settings have been received, as the client may be using a version of WebTransport extension that is different from the one used by the server. </ins> 3.2. WebTransport server associated with the specified ":authority" and ":path" values.  If it does not, it SHOULD reply with status code 404 (Section 6.5.4, RFC7231).  If it does, it MAY accept the session by  <ins> 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. </ins> From the client's perspective, a WebTransport session is established  <ins> when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. </ins> WebTransport over HTTP/3 does not support 0-RTT. <ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM. </ins> 3.4. From the flow control perspective, WebTransport sessions count encoded using the QUIC variable length integer scheme described in RFC9000. <ins> If at any point a session ID is received that cannot a valid ID for a client-initiated bidirectional stream, the recepient MUST close the connection with an H3_ID_ERROR error code. </ins> 4.1. Once established, both endpoints can open unidirectional streams. 4.3.  <ins> A WebTransport endpoint may send a RESET_STREAM or a STOP_SENDING frame for a WebTransport data stream.  Those signals are propagated by the WebTransport implementation to the application. A WebTransport application SHALL provide an error code for those operations.  Since WebTransport shares the error code space with HTTP/3, WebTransport application errors for streams are limited to an unsigned 8-bit integer, assuming values between 0x00 and 0xff. WebTransport implementations SHALL remap those error codes into an error range where 0x00 corresponds to 0x52e4a40fa8db, and 0xff corresponds to 0x52e4a40fa9e2.  Note that there are code points inside that range of form "0x1f * N + 0x21" that are reserved by Section 8.1 of HTTP3; those have to be accounted for when mapping the error codes by skipping them (i.e. the two HTTP/3 error codepoints adjacent to a GREASE codepoint would map to two adjacent WebTransport application error codepoints).  An example pseudocode can be seen in fig-remap-errors. WebTransport data streams are associated with sessions through a header at the beginning of the stream; resetting a stream may result in that data being discarded.  Because of that, WebTransport application error codes are best effort, as the WebTransport stack is not always capable of associating the reset code with a session.  The only exception is the situation where there is only one session on a given HTTP/3 connection, and no intermediaries between the client and the server. WebTransport implementations SHALL forward the error code for a stream associated with a known session to the application that owns that session; similarly, the intermediaries SHALL reset the streams with corresponding error code when receiving a reset from the peer. If a WebTransport implementation intentionally allows only one session over a given HTTP/3 connection, it SHALL forward the error codes within WebTransport application error code range to the application that owns the only session on that connection. 4.4. Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT HTTP Datagram Format Type (see value in iana-format-type).  When using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport datagram payload is sent unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.  When sending a registration capsule using the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format Additional Data" field SHALL be empty. </ins> 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 MTUs can vary.  TODO: Describe how the path MTU can be computed, specifically propagation across HTTP proxies.  <ins> 4.5. </ins> In WebTransport over HTTP/3, the client MAY send its SETTINGS frame, as well as multiple WebTransport CONNECT requests, WebTransport data 5.  <ins> A WebTransport session over HTTP/3 is considered terminated when either of the following conditions is met: the CONNECT stream is closed, either cleanly or abruptly, on either side; or a CLOSE_WEBTRANSPORT_SESSION capsule is either sent or received. Upon learning that the session has been terminated, the endpoint MUST reset all of the streams associated with the session; it MUST NOT send any new datagrams or open any new streams. To terminate a session with a detailed error message, an application MAY send an HTTP capsule HTTP-DATAGRAM of type CLOSE_WEBTRANSPORT_SESSION (0x2843).  The format of the capsule SHALL be as follows: CLOSE_WEBTRANSPORT_SESSION has the following fields: A 32-bit error code provided by the application closing the connection. A UTF-8 encoded error message string provided by the application closing the connection.  The message takes up the remainer of the capsule, and its length MUST NOT exceed 1024 bytes. A CLOSE_WEBTRANSPORT_SESSION capsule MUST be followed by a FIN on the sender side.  If any additional stream data is received on the CONNECT stream after CLOSE_WEBTRANSPORT_SESSION, the stream MUST be reset with code H3_MESSAGE_ERROR.  The recipient MUST close the stream upon receiving a FIN.  If the sender of CLOSE_WEBTRANSPORT_SESSION does not receive a FIN after some time, it SHOULD send STOP_SENDING on the CONNECT stream. Cleanly terminating a CONNECT stream without a CLOSE_WEBTRANSPORT_SESSION capsule SHALL be semantically equivalent to terminating it with a CLOSE_WEBTRANSPORT_SESSION capsule that has an error code of 0 and an empty error string. </ins> 6. session. This document. <ins> In addition, the following range of entries is registered: H3_WEBTRANSPORT_APPLICATION_00 ... H3_WEBTRANSPORT_APPLICATION_FF 0x52e4a40fa8db to 0x52e4a40fa9e2 inclusive, with the exception of 0x52e4a40fa8f9, 0x52e4a40fa918, 0x52e4a40fa937, 0x52e4a40fa956, 0x52e4a40fa975, 0x52e4a40fa994, 0x52e4a40fa9b3, and 0x52e4a40fa9d2. WebTransport application error codes. This document. 7.6. This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM. </ins>


Both client and server can create a unidirectional stream using a special stream type. <del> A datagram can be sent using a QUIC DATAGRAM frame QUIC-DATAGRAM. </del>  An WebTransport session is terminated when the CONNECT stream that created it is closed. may be using a version of WebTransport extension that is different from the one used by the server. <del> If SETTINGS_ENABLE_WEBTRANSPORT is negotiated, support for the QUIC DATAGRAMs within HTTP/3 MUST be negotiated as described in HTTP3-DATAGRAM; negotiating WebTransport support without negotiating HTTP/3 DATAGRAM support SHALL result in a H3_SETTINGS_ERROR error. </del> 3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by perspective, a session is established once it sends a 2xx response. WebTransport over HTTP/3 does not support 0-RTT.  3.4. From the flow control perspective, WebTransport sessions count 4.4. <del> Datagrams can be sent using the DATAGRAM frame as defined in QUIC- DATAGRAM and HTTP3-DATAGRAM.  For all HTTP/3 connections in which the SETTINGS_ENABLE_WEBTRANSPORT option is negotiated, the Flow Identifier is set to the session ID.  In other words, the format of datagrams SHALL be the session ID, followed by the user-specified payload (fig-datagram). </del>  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 WebTransport application error codes. This document.

This PR keeps WebTransport in sync with the latest changes in draft-ietf-masque-h3-datagram.

Both client and server can create a unidirectional stream using a special stream type.  <ins> A datagram can be sent using HTTP Datagrams HTTP-DATAGRAM. </ins> An WebTransport session is terminated when the CONNECT stream that created it is closed. may be using a version of WebTransport extension that is different from the one used by the server.  3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by perspective, a session is established once it sends a 2xx response. WebTransport over HTTP/3 does not support 0-RTT. <ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM. </ins> 3.4. From the flow control perspective, WebTransport sessions count 4.4.  <ins> Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT HTTP Datagram Format Type (see value in iana-format-type).  When using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport datagram payload is sent unmodified in the "HTTP Datagram Payload" field of an HTTP Datagram.  When sending a registration capsule using the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format Additional Data" field SHALL be empty. </ins> 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 WebTransport application error codes. This document. <ins> 7.6. This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM. </ins>


6.  WebTransport over HTTP/3 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework for client-server communication in cases when the within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <del> 7. </del>  <del> 7.1. </del>  The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230: This document and <del> 7.2. </del>  The following entry is added to the "HTTP/3 Settings" registry established by HTTP3: This document <del> 7.3. </del>  The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3: This document <del> 7.4. </del>  The following entry is added to the "HTTP/3 Stream Type" registry established by HTTP3: Both <del> 7.5. </del>  The following entry is added to the "HTTP/3 Error Code" registry established by HTTP3: This document. <del> 7.6. </del>  This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM.

This change both describes the existing mechanism (SETTINGS). It also adds a header in the unlikely scenario that we would need to change capsule stream format (instead of just defining new capsules).

6. <ins> [[RFC editor: please remove this section before publication.]] WebTransport over HTTP/3 uses two different mechanisms to negotiate versions for the different parts of the draft. The hop-by-hop wire format aspects of the protocol are negotiated by changing the codepoint used for the SETTINGS_ENABLE_WEBTRANSPORT parameter.  Because of that, any WebTransport endpoint MUST wait for the peer's SETTINGS frame before sending or processing any WebTransport traffic.  When multiple versions are supported by both of the peers, the most recent version supported by both is selected. The data exchanged over the CONNECT stream is transmitted across intermediaries, and thus cannot be versioned using a SETTINGS parameter.  To indicate support for different versions of the protocol defined in this draft, the clients SHALL send a header for each version of the draft supported.  The header corresponding to the version described in this draft is "Sec-Webtransport-Http3-Draft02"; its value SHALL be "1".  The server SHALL reply with a "Sec- Webtransport-Http3-Draft" header indicating the selected version; its value SHALL be "draft02" for the version described in this draft. 7. </ins> WebTransport over HTTP/3 satisfies all of the security requirements imposed by OVERVIEW on WebTransport protocols, thus providing a secure framework for client-server communication in cases when the within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  <ins> 8. </ins>  <ins> 8.1. </ins> The following entry is added to the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" registry established by RFC7230: This document and  <ins> 8.2. </ins> The following entry is added to the "HTTP/3 Settings" registry established by HTTP3: This document  <ins> 8.3. </ins> The following entry is added to the "HTTP/3 Frame Type" registry established by HTTP3: This document  <ins> 8.4. </ins> The following entry is added to the "HTTP/3 Stream Type" registry established by HTTP3: Both  <ins> 8.5. </ins> The following entry is added to the "HTTP/3 Error Code" registry established by HTTP3: This document.  <ins> 8.6. </ins> This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM.


4.4. <del> Datagrams can be sent using HTTP Datagrams, using the WEB_TRANSPORT HTTP Datagram Format Type (see value in iana-format-type).  When using the WEB_TRANSPORT HTTP Datagram Format Type, the WebTransport </del>  datagram payload is sent unmodified in the "HTTP Datagram Payload" <del> field of an HTTP Datagram.  When sending a registration capsule using the "Datagram Format Type" set to WEB_TRANSPORT, the "Datagram Format Additional Data" field SHALL be empty. </del>  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 WebTransport application error codes. This document. <del> 8.6. This document will request IANA to register WEB_TRANSPORT in the "HTTP Datagram Format Types" registry established by HTTP-DATAGRAM. </del>

This PR updates draft-ietf-webtrans-http3 to account for the MASQUE HTTP Datagram Design Team changes that landed in draft-ietf-masque-h3-datagram-06.
h3-datagram provides an ability to multiplex multiple datagram contexts over a single flow of datagrams associated with a stream. This feature is optional; an endpoint can disable contexts by sending a register-without-context capsule. We currently do not have a use for multiple contexts; there are potential extensions that could utilize those (e.g. multiple datagram queues with different priorities), but those would not make it into the first version of the spec. There are roughly two approaches we could potentially take here: Require WebTransport servers to handle multiple contexts correctly even if we don't use those currently. Allow WebTransport servers to reject any kind of context registration other than register-without-context, unless there's an extension negotiated via a header. The first option has the drawback of complexity that would not benefit most server implementers. The downside of the second option is that if we go with it, we would need to wait for the headers from the server before sending any datagrams. cc NAME who can probably add more
(no hats) Since you've isolated some potential extensions that could benefit from contexts, I strongly believe that WebTransport should not preclude them. Having just implemented this, the complexity is honestly very minor. I'll also note that this complexity will be inside the QUIC/h3 library and not inside the WebTransport-server code. Multi-purpose QUIC/h3 libraries will support contexts for CONNECT-UDP. So I strongly prefer the first option.
There's not much difference one context with an ID and one context without an ID. If you want to profile something on top of H3 datagram down to a single context, just say that like "we only define how to use one context, endpoints have no means to use more, extensions could change that".
NAME I think Victor was proposing to allow servers to not have to implement REGISTERDATAGRAMCONTEXT. I think we should not do that. WebTransport without extensions will use either no context or a single context, but servers need to support both.
Yeah I don't like that idea, it breaks future use.. Support both register capsule but limit the number to one if you want that today.
YAGNI says if you don't know that you need it, you don't build it. I would reserve use of these for future use, but say that in this version they aren't used.
NAME the trickiness there is around negotiation of extensions. Capsules and context IDs are end-to-end, so we can't negotiate a new context-using extension via SETTINGS. If we rely on HTTP headers for negotiating extensions, we waste a round trip before being able to send core protocol datagrams. The benefit of the current design (where contexts are optional to use but mandatory to implement) is that it allows a client to immediately start using datagrams with or without contexts before it's received the response headers.
I'm not sure this would be a significant problem in practice. Most protocols usually perform some kind of negotiation first, meaning that the first flight is most likely to be just stream data (CONNECT-UDP is the only exception to this as far as I know).
I would prefer to not expose contexts because it causes the API to diverge from QUIC transport. And so far, the API is modeled very close on that API. I believe that's been a good choice. If you want multiple streams of datagrams, you can open multiple WebTransport sessions or potentially use H3-datagram directly if you only need datagrams.
NAME we're not suggesting exposing contexts to JavaScript. This is about the interaction between draft-ietf-webtrans-http3 and draft-ietf-masque-h3-datagram.
If we're not exposing it in Javascript, then it seems like it's not a core feature of WebTransport. On a practical note, we've decided that for the fallback options, we'll layer a QUIC-lite streaming + datagaram layer on top of H2 or H1. If we wanted to also support datagram contexts, I think we'd have to pull in all of HTTP/3, since that lives in h3 datagram, not datagram. I do not want to pull in all of H3 as well to add this currently unused functionality. Tell me if I'm missing something.
So I think that the question is a bigger one: is there sufficiently large set of protocols that would use context identifiers, such that they all might benefit from common machinery in support of them? This is a question for draft-ietf-masque-h3-datagram more than this document, but it's a question that I'm not confident about. This document very much doesn't need the mechanism, but - unfortunately - it has to engage with it, if only to get it out of the way.
NAME I think you're misunderstanding how contexts work, have you read the latest version of draft-ietf-masque-h3-datagram? () NAME let's take the conversation about contexts to draft-ietf-masque-h3-datagram.

4.4.  <ins> Datagrams can be sent using HTTP Datagrams.  The WebTransport </ins> datagram payload is sent unmodified in the "HTTP Datagram Payload"  <ins> field of an HTTP Datagram. </ins> 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 WebTransport application error codes. This document.


0x170d7b68 <del> WebTransport data stream reset because the associated WebTransport session has been closed. </del>  This document.

The draft says that all streams need to be closed when the WebTransport session is closed. This makes me wonder: Which error code to use for that? Should we mandate using the same error code that the WebTransport session was closed with? Stream tracking: If it's the WebTransport implementation's responsibility to reset all the stream, this means that I need to keep another list / map of streams (outside of my QUIC stack). The interesting question is how to garbage collect closed streams from that list. It seems like the only way to do so is by introducing a callback for my QUIC stack to signal that a stream was closed / reset in both directions, so I can clean it up on the WebTransport layer.
Regarding the first issue, I was going to add a separate error code, but forgot to. Wrote to address this. Regarding the second issue, I am not sure what the question here. In Chromium, we keep a list of stream IDs for every WebTransport session, and call Reset() on all stream once the CONNECT stream is closed.
NAME gentle ping
fixes the issue. Regarding my second point, I assume that most implementations will actually keep a second map of streams around, but that's an implementation detail that we probably don't need to address in the spec.
The draft currently states: It's clear that without a CONNECT stream that new streams cannot be created and datagrams cannot be sent, but WT streams that were opened for that session could continue operating normally. This is how push streams are handled in H2 and H3 -- the push stream continues even if the associated stream is terminated. An endpoint always has the option to reset/stop sending WT streams when the session terminates. This is somewhat related to the graceful drain issue ()
Discussed at IETF 110. We should keep the current behavior for now, and revisit once we have more implementation experience.
Chair: discussed at 113, consensus in room to have close of CONNECT stream close all webtransport streams and datagrams. NAME will double-check that this is what the draft currently says
Draft says: That should be sufficient (I've opened to add an error code)
QuicTransport identifies itself using an ALPN and both peers agree to transfer additional configuration via a client-initiated stream (ID 2). I think it would be an improvement if this origin indication was moved into the QUIC transport parameters and exchanged via the TLS ClientHello. There would be a few benefits (in no particular order): A server can terminate an invalid origin/path prior to performing the expensive TLS handshake. A server does not need to buffer stream data (inbound and outbound) waiting until stream 2 has arrived. A load balancer can route new connections to the correct server based on the path in the ClientHello. Currently, a load balancer must terminate TLS and buffer all streams until it can parse stream 2 prior to making a routing decision. QUIC stream IDs could be exposed to the application without the asterisks that stream 2 has already been used. The first client packet (ClientHello) must already be padded to 1200 bytes. The origin and path parameters would replace some of that padding and overall reduce the bandwidth for a new connection. There would be a few downsides: Long paths and origins could cause fragment the ClientHello message into multiple packets. Requires and . QUIC libraries need to expose or support the new transport parameters.
One more downside: The path and origin won't be encrypted. This leaks more information than SNI alone and would especially be a problem if ESNI is the future. Yeah, unfortunately I think this alone is a reason to stick with the stream 2 approach. Thanks for letting me think out loud!
Yeah, that's pretty much the reason why stream 2 exists (we tried a few ways to limit ourselves to transport params, but those didn't work out). It's possible that we could use for this, but ALPS is still in very early stage, so it's hard to tell if it will be useful.

0x170d7b68  <ins> WebTransport data stream aborted because the associated WebTransport session has been closed. </ins> This document.


datagram SHALL be dropped.  It is up to an implementation to choose what stream or datagram to discard.  5. A WebTransport session over HTTP/3 is considered terminated when

If a connection carrying WebTransport sessions receives a GOAWAY, is the sender allowed to continue 1) sending datagrams 2) creating new WT streams 3) receiving new WT streams I assume it's ok to continue sending data on already open WT streams and the CONNECT stream, but clarification would be good. Also, are the rules any different after sending a GOAWAY? Can the sender continue doing the above?
I'll just note that because in H2 WT streams are contained to a single stream, they are implicitly allowed there unless we forbid them.
Chair: discussed at IETF 113, consensus to have GOAWAY not prevent opening new WT streams on existing WT sessions. NAME will write a PR

datagram SHALL be dropped.  It is up to an implementation to choose what stream or datagram to discard. <ins> 4.6. HTTP/3 defines a graceful shutdown mechanism (Section 5.2 of HTTP3) that allows a peer to send a GOAWAY frame indicating that it will no longer accept any new incoming requests or pushes.  This mechanism applies to the CONNECT requests for new WebTransport sessions.  A GOAWAY frame does not affect data streams for existing WebTransport sessions; those can continue to be opened even after the GOAWAY frame has been sent or received. </ins> 5. A WebTransport session over HTTP/3 is considered terminated when


has been sent or received. To drain a WebTransport session, either endpoint can send a <del> DRAIN_WEBTRANSPORT_SESSION capsule.  An endpoint SHOULD NOT initiate new WebTransport streams or datagram flows after sending or receiving a DRAIN_WEBTRANSPORT_SESSION capsule.  Both endpoints can continue sending data on existing streams and datagram flows, but SHOULD attempt to gracefully terminate the session as quickly as possible. </del>  5.

FYI, the API PR for a client receiving a DRAINWEBTRANSPORTSESSION capsule is here: URL A separate issue has been opened for the client sending a DRAINWEBTRANSPORTSESSION capsule: URL After receiving a DRAINWEBTRANSPORTSESSION capsule from the server, the PR prevents the application from opening new unidirectional or bidirectional streams, but doesn't prevent it from continuing to send datagrams. Is that appropriate, or should the application treat receipt of the DRAINWEBTRANSPORTSESSION capsule more like a hint (e.g. it probably shouldn't open new unidirectional or bidirectional streams but it's not prohibited from doing so)?
Section 4.6 of WebTransport over HTTP/3 (URL) now covers the HTTP/3 GOAWAY frame. When sent from the server -> client this indicates that client attempts to construct additional WebTransport objects will fail. Does receipt of a GOAWAY frame need to be indicated to the application, or can it just deal with a (future) constructor error? The DRAINWEBTRANSPORTSESSION capsule PR has been merged, but the draft including the merged PR has not been published yet.
An HTTP/3 server needs the ability to gracefully drain existing connections. For HTTP/3, this involves sending a GOAWAY frame indicating that future requests should use a new HTTP/3 connection. However, the behavior of GOAWAY is partially undefined with WebTransport sessions. After receiving a GOAWAY, the client is no longer able to make new CONNECT requests. This means that any new WebTransport sessions will need to use a new HTTP/3 connection. This is great. However, it's not clear how existing sessions should behave after receiving a GOAWAY frame. Are they prohibited from creating new streams? How does this interact with the stream ID sent in the GOAWAY frame? Should the application expose the receipt of a GOAWAY to start a shutdown process?
Thanks for opening this issue -- it's been on my mind as well. I think it's important that we think through all the graceful draining scenarios, including when there are multiple proxies between the WT client and server, and one of the proxies initiates the drain. We already have a use-case which requires a session to be able to create new streams after the receipt of a connection level GOAWAY. We've been exploring using a GOAWAY with MAXINT to signal the peer to stop creating new sessions, but continuing to all new streams within existing sessions. I don't think this totally jives with the definition of GOAWAY in the H3 spec, and I don't think it would work if there were 3 or more intermediaries. What would happen if WebTransport defined a GOAWAY frame that could be sent on the CONNECT stream to signal the intent to drain a session, but not the connection?
I think we should inform application of GOAWAY signal, and possibly add a GOAWAY on the CONNECT stream for intermediation between proxies.
Chair notes from IETF 112 meeting: no clear consensus in the room to do this. NAME has volunteered to write a PR proposal with justification of use-case to help motivate this.
Let me see if I can do the justification here, then draft the PR. Having a first class mechanism to "make-before-break" is a key reliability feature in HTTP/2 and HTTP/3. Intermediaries that carry WebTransport sessions but do not originate originate them need a mechanism to tell the application endpoints that draining is happening, so it can't be built exclusively into the application protocols HTTP/3 GOAWAY is too broad when multiple sessions pooled and multiple proxy hops are involved It's cheap to add a message that carries this signal on the CONNECT stream, and it's cheap to ignore it if you want to. As a concrete proposal within the current draft using capsules: I don't think we need to include any stream information in the Capsule, such as the highest peer initiated uni and bidi stream IDs received by this endpoint. Since the signal is delivered to the application endpoints, they can react and generate their own application level signal, if desired. The signal is only useful if it can be delivered to the application. If we agree this is valuable, should we open an issue for W3C? Writing this up made me realize that the WT over HTTP/3 draft doesn't describe how it interacts with GOAWAY. I opened to track that.
Chair: discussed in the room at IETF113, NAME will write a PR

has been sent or received. To drain a WebTransport session, either endpoint can send a  <ins> DRAIN_WEBTRANSPORT_SESSION capsule.  After sending or receiving a DRAIN_WEBTRANSPORT_SESSION capsule, an endpoint MAY continue using the session but SHOULD attempt to gracefully terminate the session as soon as possible. </ins> 5.


encoded using the QUIC variable length integer scheme described in RFC9000.  If at any point a session ID is received that cannot a valid ID for a client-initiated bidirectional stream, the recipient MUST close the connection with an H3_ID_ERROR error code. 4.1. <del> Once established, both endpoints can open unidirectional streams. The HTTP/3 unidirectional stream type SHALL be 0x54.  The body of the </del>  stream SHALL be the stream type, followed by the session ID, encoded as a variable-length integer, followed by the user-specified stream data (fig-unidi).

In order to save a round-trip on connection establishment, a client could optimistically open streams just after sending the CONNECT request, before it has received a reply from the server. As both unidirectional and bidirectional streams are identified by the session ID, the server will be able to associate these streams with the WebTransport session as soon as it has processed the CONNECT request. In case the server rejects the CONNECT request, the client should probably reset / cancel these streams. Note that this doesn't require any additional logic on the server side, as the server needs to be prepared to receive streams for sessions that it didn't establish anyway (a malicious client might open streams with arbitrary session IDs, and a server should better be prepared for that). Currently, the spec forbids opening unidirectional streams before the session is established: There's no such restriction for bidirectional stream.
I believe this is a left-over from the older text of the draft. We've agreed in that both types of streams should be sent immediately, and as far as I remember, that is what the Chrome implementation does.
That's great! I'll write up a PR. How does that work? I tried it out, but it seems like waits for the response to the CONNECT request. This is my JS code: Removing the also doesn't work, then I'm getting this error: Any hint would be highly appreciated.
Good question. I am not sure the current API state machine allows this; when I said "what the Chrome implementation does", I meant that it supports receiving streams before it considers them confirmed (for the client, it means that streams received before HTTP 200 for the CONNECT stream are buffered instead of dropped). We should probably figure out how to allow this on the client side, but that's a W3C issue.
From my reading of the W3C spec this is already allowed: URL So maybe this is just a bug in Chrome that it returns the ?
Sounds like we need an editorial PR to clarify that this is allowed
adds some text to clarify that opening streams as well as sending datagrams is permitted as soon as the CONNECT request has been sent out.
We need to pick one. The main two options are and . We've discussed this separately within W3C (see w3c/webtransport), and the conclusion there was that it would make more sense to just use URIs. We should discuss this at the upcoming IETF meeting.
(No hats) I think using https would be the simplest option here, so I'd be inclined to go with that
Discussed at IETF 110. Consensus in the room was for using .
Consensus confirmed on the list, the scheme in the draft is already . Closing this.
(no hats)

encoded using the QUIC variable length integer scheme described in RFC9000. <ins> The client MAY optimistically open unidirectional and bidirectional streams, as well as send datagrams, for a session that it has sent the CONNECT request for, even if it has not yet received the server's response to the request.  On the server side, opening streams and sending datagrams is possible as soon as the CONNECT request has been received. </ins> If at any point a session ID is received that cannot a valid ID for a client-initiated bidirectional stream, the recipient MUST close the connection with an H3_ID_ERROR error code. 4.1.  <ins> WebTransport endpoints can initiate unidirectional streams.  The HTTP/3 unidirectional stream type SHALL be 0x54.  The body of the </ins> stream SHALL be the stream type, followed by the session ID, encoded as a variable-length integer, followed by the user-specified stream data (fig-unidi).


From the client's perspective, a WebTransport session is established when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response. <del> WebTransport over HTTP/3 does not support 0-RTT. </del>  The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM.

There is this sentence about 0-RTT: I think this needs a better explanation. I expect that CONNECT requests can be sent during 0-RTT period, but WebTranpsort streams cannot be open before response to the CONNECT requests is received. Clients may remember that WebTransport was supported by a server and may try to negotiate sessions during 0-RTT.
CONNECT is considered by HTTP semantics, so the current specs state that it be sent in 0-RTT. We could override those however and explicitly state that 0-RTT is allowed for this specific kind of CONNECT request, but I'm not sure we should? If a server implementation makes creation of a WebTransport session expensive, then this could be used as a DoS vector. That said, servers could protect themselves by either disabling 0-RTT on that origin, or by returning 425 if their intermediaries support the Early-Data header. All this to say: here there be dragons, and if we want to add this feature we'll need to write guidance for implementors.
The MUST NOT only applies in absence of other indications; an API flag could be such indication. That said, I am not sure it's worth investing into designing WebTransport 0-RTT support at this point.
I agree we do not need to allow 0RTT for WebTransport. Since WebTransport does not support 0RTT what will happen to the SETTINGSENABLEWEBTRANSPORT setting when 0RTT is used on a HTTP/3 connection and in the previous session WebTransport support was negotiated? There is some explanation in the HTTP/3 draft: SETTINGS frame MUST NOT reduce any limits or alter any values that might be violated by the client with its 0-RTT data. In the WebTransport case 0RTT data is not relevant, but there may be a small window when a client has 1RTT keys but still do not have the settings from a server. We can allow the client to remember WebTransport setting or WebTransport setting needs to be negotiated in each session therefore the client must wait for the settings from the server before confirming that WebTransport is supported. I am fine with either way, but I think the WebTransport draft needs a couple of sentences to explain the behavior.
HTTP/3 draft says: This obviously only works for SETTINGSENABLEWEBTRANSPORT if the server is not allowed to go from 1 to 0 while accepting 0-RTT; we should probably clarify this explicitly.

From the client's perspective, a WebTransport session is established when the client receives a 2xx response.  From the server's perspective, a session is established once it sends a 2xx response.  <ins> Clients cannot initiate WebTransport in 0-RTT packets, as the CONNECT method is not considered safe; see Section 10.9 of HTTP3.  However, WebTransport-related SETTINGS parameters may be retained from the previous session as described in Section 7.2.4.2 of HTTP3.  If the server accepts 0-RTT, the server MUST NOT reduce the limit of maximum open WebTransport sessions from the one negotiated during the previous session; such change would be deemed incompatible, and MUST result in a H3_SETTINGS_ERROR connection error. </ins> The "webtransport" HTTP Upgrade Token uses the Capsule Protocol as defined in HTTP-DATAGRAM.


within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams.  8. 8.1.

Porting URL originally posted to W3C WT NAME New connections should be throttled to avoid being a DoS vector. Maybe we will just have some language in the standard to permit and encourage throttling, and leave the details to browsers.
Shouldn't the throttling be performed at the W3C layer? If throttling happens, should the W3C API let the caller know?
I think this is a back-to-front way of suggesting that WebTransport include something like the guidance in URL (which I found , linked from URL
Oh thanks for finding that. I'm supportive of adding something like that.
I'm actually not sure that the specific requirement in WebSocket spec is useful, compared to just recommending throttling (or other forms of resource limits) in general.
The WebSocket throttling in RFC6455 requires you to implement it close to the socket layer (in particular, after DNS lookup), which is messy in practice. I think it may be sufficient to leave the details of the throttling to the implementation. If we want to ensure it is interoperable, a per-network-partitiion delay based on the number of pending and recently-failed connections should be sufficient.
So given that this is over HTTP/3, what is the anticipated throttling? Is it really just trying to tell HTTP clients to not make lots of requests? Is WebTransport sufficiently more expensive than other types of requests? I'm struggling to see language we would include here that is needed over language we have in QUIC or HTTP/3 already
Generally a browser will only make one HTTP/3 connection per server, regardless of how many resources the page requests. So servers don't need to worry about a well-behaved browser initiating large numbers of simultaneous QUIC handshakes. However, when WebTransport connections are not pooled, it is valid to make several at the same time. If there were no restrictions, a badly-behaved web page could request thousands of WebTransport connections simultaneously, DoSing the server.
Thanks Adam. I think phrasing thing as a design deviation from HTTP/3's recommendation to use one connection is good idea.
From what I can read from this discussion, there isn't that much in terms of design here, and this mostly requires writing up that throttling is up to the implementation.

within connection gets a reasonable share of controlled resources; this applies both to sending data and to opening new streams. <ins> A client could attempt to exhaust resources by opening too many WebTransport sessions at once.  In cases when the client is untrusted, the user agent SHOULD limit the number of outgoing sessions the client can open. </ins> 8. 8.1.


3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by <del> the SETTINGS_ENABLE_CONNECT_PROTOCOL parameter.  That parameter is only defined for HTTP/2.  This document does not create a new multi- purpose parameter to indicate support for extended CONNECT in HTTP/3; instead, the SETTINGS_ENABLE_WEBTRANSPORT setting implies that an endpoint supports extended CONNECT. </del>  3.3.

currently states: That is not well-defined: it relies on which only discusses HTTP/2, and the relevant changes between HTTP/2 and HTTP/3 are subtle. Since we have that is now in the RFC Editor Queue, WebTransport needs to instead refer to that and require servers to send .
This sounds like an obvious way forward. That said, I would personally prefer to wait until we make another breaking wire protocol change.
Sounds good to me, there's no rush here - in my personal opinion we just need to get this in before WGLC
More generally, it looks like we may want to remove any implied support and just require endpoints to explicitly signal support for each "layer" of capabilities that we're relying on.
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

3.2. RFC8441 defines an extended CONNECT method in Section 4, enabled by  <ins> the SETTINGS_ENABLE_CONNECT_PROTOCOL setting.  That setting is defined for HTTP/3 by RFC9220.  An endpoint supporting WebTransport over HTTP/3 MUST send both the SETTINGS_ENABLE_WEBTRANSPORT setting and the SETTINGS_ENABLE_CONNECT_PROTOCOL setting with values set to "1". </ins> 3.3.


HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) MUST be set to "webtransport".  The ":scheme" field MUST be "https". Both the ":authority" and the ":path" value MUST be set; those fields <del> indicate the desired WebTransport server.  An "Origin" header RFC6454 MUST be provided within the request. </del>  Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP/3 server can check if it has a

This is vaguely based on the similar text in the WebSocket RFC.
In draft 03 the following requirement is made WebTransport's closest equivalent in this regard is WebSockets, which doesn't mandate the origin header; see URL This requirement makes it weird to use for user agents that have no concept of an origin model. So the MUST level seems a bit overzealous.
It is not just the user agent. Take for example the proposed use of . That application does not have any concept of "origin" -- indeed, there is no mention of the word "origin" in that draft.

HTTP CONNECT request.  The ":protocol" pseudo-header field (RFC8441) MUST be set to "webtransport".  The ":scheme" field MUST be "https". Both the ":authority" and the ":path" value MUST be set; those fields  <ins> indicate the desired WebTransport server.  If the WebTransport session is coming from a browser client, an "Origin" header RFC6454 MUST be provided within the request; otherwise, the header is OPTIONAL. </ins> Upon receiving an extended CONNECT request with a ":protocol" field set to "webtransport", the HTTP/3 server can check if it has a