LGTM3 On Wednesday, October 21, 2026 at 8:49:10 AM UTC-7 Daniel Bratell wrote:
> LGTM2 > > /Daniel > On 2026-10-21 17:31, Yoav Weiss (@Shopify) wrote: > > LGTM1 > > On Tuesday, October 20, 2026 at 11:08:15 PM UTC+2 Chromestatus wrote: > >> *Contact emails* >> [email protected] >> >> *Explainer* >> https://github.com/w3c/webtransport/issues/544 >> https://github.com/w3c/webtransport/pull/574 >> >> *Specification* >> https://w3c.github.io/webtransport/#web-transport-configuration >> >> *Summary* >> Allows WebTransport applications to indicate how many incoming streams >> they expect to have open at once. Constructor hints configure the initial >> QUIC stream allowance, reducing the risk that a server that needs high >> stream concurrency is blocked by the initial stream limit. >> >> *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> >> >> *Motivation* >> Some WebTransport applications expect a server to open many streams at >> once. If the initial QUIC stream allowance is too low, the server must wait >> for more stream credit before opening additional streams, adding avoidable >> latency or limiting the number of open streams. Constructor hints let the >> application state its expected stream count when creating the connection, >> so the browser can advertise an appropriate initial allowance. Values above >> the required minimum are preserved; values below 100 do not reduce the >> effective allowance because the specification requires clients to initially >> permit at least 100 streams of each type. >> >> *Initial public proposal* >> *No information provided* >> >> *TAG review* >> This is a small incremental addition to an existing feature which is >> already standardized. >> >> *TAG review status* >> Not applicable >> >> *Goals for experimentation* >> None >> >> *Risks* >> >> >> *Interoperability and Compatibility* >> Compatibility risk is low because this is an additive API. Existing sites >> that do not use the new names are unaffected. Interoperability risk is low >> to moderate: WebKit implements these specific members, while Firefox >> supports WebTransport but does not currently expose them. >> >> *Gecko*: Positive (https://bugzilla.mozilla.org/show_bug.cgi?id=2007825) >> Firefox >> supports WebTransport, but not these two anticipated-incoming-stream >> members. Implementation work is in progress, no shipping milestone is >> announced. >> >> *WebKit*: Shipped/Shipping (https://commits.webkit.org/303419@main) >> Implemented >> in WebKit revision 303419@main and shipped in Safari 26.4, including Safari >> on iOS. >> >> *Web developers*: Positive ( >> https://github.com/web-platform-tests/interop/issues/1121) The Interop >> 2026 WebTransport proposal received 28 positive reactions. Developers also >> reported active WebTransport use and significant cross-engine differences. >> >> *Other signals*: >> >> *Ergonomics* >> The constructor options are nullable unsigned-short hints and default to >> null. The corresponding attributes expose the currently stored values. >> [EnforceRange] rejects values outside the unsigned-short range. Values >> below 100 remain visible through the attributes but cannot reduce the >> effective initial stream allowance below the specification-required minimum. >> >> *Activation* >> No permission or user activation is required beyond the existing >> WebTransport requirements. A site opts in by supplying either constructor >> option. >> >> *Security* >> This does not grant a new capability or expose application data. It lets >> a site request a bounded initial stream allowance for its existing >> secure-context WebTransport connection. Stream credit does not eagerly >> allocate all streams. >> >> *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? >> Low. The change is additive and does not modify behavior for applications >> that do not use the new options or attributes. The implementation uses the >> existing cross-platform WebTransport connection stack. >> >> >> *Debuggability* >> The hints can be inspected through the JavaScript attributes. Existing >> DevTools and NetLog support for WebTransport and QUIC remains applicable. >> >> *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/anticipated-concurrent-incoming-streams.https.any.html?label=experimental&label=master >> >> *Flag name on about://flags* >> enable-experimental-web-platform-features >> >> *Finch feature name* >> WebTransportAnticipatedConcurrentIncomingStreams >> >> *Rollout plan* >> Will ship enabled for all users >> >> *Requires code in //chrome?* >> False >> >> *Tracking bug* >> https://issues.chromium.org/issues/565837025 >> >> *Availability expectation* >> The API is part of the W3C WebTransport specification and is implemented >> by WebKit/Safari. Firefox supports WebTransport but does not yet expose >> these specific members. Cross-browser availability is expected to improve >> as implementations converge on the current WebTransport specification. >> >> *Adoption expectation* >> Adoption is expected among WebTransport applications whose servers need >> to create more than the minimum number of streams concurrently, including >> real-time communication, media, gaming, remote interaction, and multiplexed >> application protocols. Broader adoption will follow overall WebTransport >> usage. >> >> *Adoption plan* >> No dedicated outreach campaign is planned. Adoption is expected through >> WebTransport documentation, examples, and client/server library support. >> >> *Non-OSS dependencies* >> >> Does the feature depend on any code or APIs outside the Chromium open >> source repository and its open-source dependencies to function? >> No. >> >> *Estimated milestones* >> Shipping on desktop 158 >> DevTrial on desktop 151 >> Shipping on Android 158 >> DevTrial on Android 151 >> Shipping on WebView 158 >> >> *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 known for these constructor options or attributes. The wider >> WebTransport specification continues to progress, but no known open issue >> requires a breaking change to these members before launch. >> >> *Link to entry on the Chrome Platform Status* >> https://chromestatus.com/feature/5089961022980096?gate=5533718100967424 >> >> 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/516c776b-5496-4a8a-afcb-475ab294ae7cn%40chromium.org > > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/516c776b-5496-4a8a-afcb-475ab294ae7cn%40chromium.org?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/41e3de23-300a-4f00-abc1-ed2c697837ean%40chromium.org.
