LGTM2
On 10/15/25 10:46 a.m., Rick Byers wrote:
Thanks for the explainer. This seems like a small and clearly
beneficial extension to WebTransport to me without any red flags. LGTM1
On Tue, Oct 14, 2025 at 5:33 PM 'Victor Vasiliev' via blink-dev
<[email protected]> wrote:
Hi Alex,
Sorry for the late reply; I've been travelling/OOO for a couple of
weeks.
The explainer is at
<https://github.com/w3c/webtransport/blob/main/explainers/subprotocol_negotiation.md>.
Thanks,
Victor.
On Wed, Sep 24, 2025 at 11:13 AM Alex Russell
<[email protected]> wrote:
Hey Victor,
I appreciate you taking the time to outline this here. I have
some background on Web Transport (was co-TL for Project Fugu),
but it would be great for this to be in a separate Explainer
document using the usual template, as it isn't clear what
we're winning, which applications this enables, and how it
actually interacts with ALPN and the other parts of the
various handshakes involved. Our overriding question from the
API OWNERS perspective is "/does this problem solve an
important problem well?/".
When we're the leading implementation on a feature (which is
the usual case these days), we need to provide some arguments
and evidence that the use-cases are meaningful to developers,
and input from developers about how this is necessary and
useful to them. Explainers provide a format for structuring
those arguments and explaining the motivating use-cases.
Thanks again,
Alex
On Tuesday, September 23, 2025 at 3:10:54 AM UTC-7 Victor
Vasiliev wrote:
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>?*
Yeshttps://wpt.fyi/results/webtransport/connect.https.any.html?label=experimental&label=master&aligned
<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/CAAZdMaf9K4z1XWiQFpXq%3DAVG_WXr1UMRQSjQ7Q6qk2S8jZRMjg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAAZdMaf9K4z1XWiQFpXq%3DAVG_WXr1UMRQSjQ7Q6qk2S8jZRMjg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/CAFUtAY9sxSxZavPHSSsK9bWgXvSFkMfx7pagXLUUsAwun2vAzg%40mail.gmail.com
<https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY9sxSxZavPHSSsK9bWgXvSFkMfx7pagXLUUsAwun2vAzg%40mail.gmail.com?utm_medium=email&utm_source=footer>.
--
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/ba0ad0fb-8f32-4f41-b438-ed36bd8d751f%40chromium.org.
