Hi Alex, WebTransport provides web developers with a networking abstraction that is semantically similar to having a QUIC connection; because of that, all of the user data within a WebTransport session is sent on independent data streams that may arrive in arbitrary order.
Normally, this is to the advantage of the applications that are built on top of QUIC or WebTransport. However, one thing that applications often want to do is negotiate the protocol version at the start; in the multistream world, this is difficult, since you don't know upfront which stream actually has the version negotiation info (they can arrive out of order). Protocols that are built on top of QUIC directly solve this problem by negotiating versions inside the handshake that happens before any actual application data is exchanged, using a mechanism called TLS ALPN (this actually works for TCP too, this is how a Web server can, for instance, support HTTP/1.1 and HTTP/2 at the same TCP port). The feature in question adds a similar mechanism to WebTransport, by performing an ALPN-like negotiation inside the WebTransport handshake. Thanks, Victor. On Mon, Sep 22, 2025 at 2:49 PM Alex Russell <[email protected]> wrote: > Hey Victor, > > As there's no explainer, can you outline what the use-cases for protocol > negotiation are? The linked part of the spec does not provide clarity as to > why this is valuable, who it's valuable to, or why we should support it. > That is, we are always trying to understand "*does this feature solve an > important problem well?*" it isn't clear (yet) in this case. > > Best, > > Alex > > On Monday, September 22, 2025 at 12:38:46 AM UTC-7 Chromestatus wrote: > >> *Contact emails* >> [email protected] >> >> *Explainer* >> None >> >> *Specification* >> https://w3c.github.io/webtransport/#dom-webtransportoptions-protocols >> >> *Summary* >> WebTransport Application Protocol Negotiation allows negotiation of the >> protocol used by the web application within the WebTransport handshake. A >> web application can specify a list of application protocols offered when >> constructing a WebTransport object, which are then conveyed to the server >> via HTTP headers; if the server picks one of those protocols, it can >> indicate that within response headers, and that reply is available within >> the WebTransport object. >> >> *Blink component* >> Blink>Network>WebTransport >> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ENetwork%3EWebTransport%22> >> >> *Web Feature ID* >> webtransport <https://webstatus.dev/features/webtransport> >> >> *TAG review* >> None >> >> *TAG review status* >> Not applicable >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> The feature was designed to work cleanly with existing servers that do >> not support protocol negotiation. If the server does not support >> application protocol negotiation, or does not accept any of the protocols >> offered, the API will return null as the selected protocol. >> >> *Gecko*: Positive ( >> https://github.com/mozilla/standards-positions/issues/167) Firefox has >> been positive on WebTransport, and Mozilla representatives have been >> involved in the discussion regarding this flag (and have told me in the >> past that I don't need to file new standards position for every spec >> feature). >> >> *WebKit*: Support ( >> https://github.com/WebKit/standards-positions/issues/18) Safari has >> expressed support for WebTransport in general; we've not reached out >> regarding this individual feature, given that Safari has not shipped >> WebTransport itself. >> >> *Web developers*: Positive ( >> https://github.com/moq-wg/moq-transport/pull/499) IETF MOQ relies on >> this feature for version negotiation; I've been repeatedly pinged by >> multiple people there asking when Chrome is going to ship this. >> >> *Other signals*: >> >> *WebView application risks* >> >> Does this intent deprecate or change behavior of existing APIs, such that >> it has potentially high risk for Android WebView-based applications? None >> >> >> *Debuggability* >> Since the negotiation is done via HTTP headers, those should be visible >> through DevTools. >> >> *Will this feature be supported on all six Blink platforms (Windows, Mac, >> Linux, ChromeOS, Android, and Android WebView)?* >> Yes >> >> *Is this feature fully tested by web-platform-tests >> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >> Yes >> https://wpt.fyi/results/webtransport/connect.https.any.html?label=experimental&label=master&aligned >> >> *Flag name on about://flags* >> None >> >> *Finch feature name* >> WebTransportApplicationProtocol >> >> *Rollout plan* >> Will ship enabled for all users >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://issues.chromium.org/u/1/issues/416080492 >> >> *Estimated milestones* >> Shipping on desktop 142 >> Shipping on Android 142 >> >> *Anticipated spec changes* >> >> Open questions about a feature may be a source of future web compat or >> interop issues. Please list open issues (e.g. links to known github issues >> in the project for the feature specification) whose resolution may >> introduce web compat/interop risk (e.g., changing to naming or structure of >> the API in a non-backward-compatible way). None >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/6521719678042112?gate=4663773843161088 >> >> This intent message was generated by Chrome Platform Status >> <https://chromestatus.com>. >> >> -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMafVW4J4SsDL6UFy-Gpmcm4wke_PjmbyicR6CJ%2BEK1cqrQ%40mail.gmail.com.
