Intent to Ship: WebTransport Application Protocol Negotiation

[Chromestatus]

Contact emails

vas...@chromium.org

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

Web Feature ID

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?

Yeshttps://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.

[Alex Russell]

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

[Victor Vasiliev]

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.