Contact emails [email protected]
Explainer https://github.com/w3c/webtransport/issues/372 https://github.com/w3c/webtransport/pull/395 Specification https://w3c.github.io/webtransport/#webtransportreceivestream Summary Adds the standardized WebTransportReceiveStream interface, a ReadableStream subclass used for incoming unidirectional streams and the readable side of bidirectional streams. Its getStats() method returns per-stream byte counters: bytesReceived reports bytes received from the network, while bytesRead reports bytes delivered to the application. Blink component Blink>Network>WebTransport Web Feature ID webtransport Motivation Incoming WebTransport streams have historically been exposed as generic ReadableStream objects in Chromium. The WebTransport specification defines a dedicated WebTransportReceiveStream subclass with stream-specific statistics. Applications that receive large or latency-sensitive streams need to distinguish bytes received by the browser from bytes actually consumed by JavaScript. This helps diagnose application backpressure, buffering, and slow-consumer behavior. Exposing the standardized subclass also aligns the runtime type of incoming streams with the WebTransport specification and other browser engines. Initial public proposal No information provided TAG review No information provided TAG review status Not applicable Goals for experimentation None Risks Interoperability and Compatibility Enabling this feature changes incoming unidirectional streams and the readable side of bidirectional streams from plain ReadableStream objects to WebTransportReceiveStream objects. Reading remains compatible, and the objects remain instanceof ReadableStream, but applications that compare the exact constructor or prototype may observe a change. Firefox and Safari already expose WebTransportReceiveStream, so this aligns Chrome's stream type with those browsers. Gecko: Under consideration (https://searchfox.org/mozilla-central/source/dom/webidl/WebTransportSendReceiveStream.webidl) Partial implementation. Firefox ships WebTransportReceiveStream and exposes getStats(), but getStats() currently rejects with NotSupportedError, so receive stream statistics are not implemented. Implementation https://searchfox.org/mozilla-central/source/dom/webtransport/api/WebTransportReceiveStream.cpp WebKit: Shipped/Shipping (https://commits.webkit.org/300850@main) WebKit-7624.1.16 implements WebTransportReceiveStream and pipes real receive-stream statistics through WebCore and the network process. WebTransport shipped in Safari 26.4. Implementation - https://github.com/WebKit/WebKit/blob/WebKit-7624.1.16/Source/WebCore/Modules/webtransport/WebTransportReceiveStream.cpp#L54-L65 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 getStats() asynchronously returns a snapshot with bytesReceived and bytesRead. bytesRead is expected to be less than or equal to bytesReceived. Chromium preserves final counters when streams finish, are reset or cancelled, or when the Mojo connection disconnects. The interface is not constructible directly; applications obtain it from incomingUnidirectionalStreams or from the readable side of a bidirectional stream. Chromium's IDL currently types WebTransportBidirectionalStream.readable as ReadableStream because Blink cannot conditionally change an IDL attribute type behind a runtime flag, although the returned object is a WebTransportReceiveStream when the feature is enabled. Activation Activation is automatic for sites using incoming WebTransport streams; no server change or opt-in is required. Existing code that treats these objects as ReadableStream continues to work because WebTransportReceiveStream is a subclass. The runtime type and prototype are observably different, so code that relies on an exact ReadableStream constructor or prototype could behave differently. Feature detection using "getStats" in stream is recommended. Security The API adds no network capability and exposes no peer address, credentials, or payload contents. It reports byte counters for a stream already available to the calling origin. These values reveal only the amount of data received by the browser and consumed by that application. 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. This is an additive API on existing WebTransport streams and does not change connection establishment or network behavior. WebView code that does not inspect the stream's exact runtime type is unaffected. Debuggability Developers can inspect incoming streams and call getStats() from the DevTools Console. The returned bytesReceived and bytesRead values help distinguish network delivery from application consumption. DevTools does not currently provide a dedicated per-WebTransport-stream statistics UI. 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? Yes https://wpt.fyi/results/webtransport/receive-stream-stats.https.any.html Flag name on about://flags enable-experimental-web-platform-features Finch feature name WebTransportReceiveStream Rollout plan Will ship enabled for all users Requires code in //chrome? False Tracking bug https://issues.chromium.org/issues/568317222 Availability expectation The interface is defined in the W3C WebTransport specification. WebKit implements WebTransportReceiveStream and real receive-stream statistics. Firefox exposes WebTransportReceiveStream, but its getStats() implementation currently rejects with NotSupportedError. Implementations are expected to converge through the Interop 2026 WebTransport focus area. Adoption expectation Expected to be adopted by WebTransport applications that monitor per stream throughput, buffering, or slow-consumer behavior. Code that only reads from incoming streams does not need to change. Adoption plan Adoption is expected to occur organically through WebTransport documentation, examples, and client library support. Developers can progressively enhance existing code by feature-detecting getStats(). 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 155 Shipping on Android 158 DevTrial on Android 155 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 (eg links to known github issues in the project for the feature specification) whose resolution may introduce web compat/interop risk (eg, changing to naming or structure of the API in a non-backward-compatible way). None known for the WebTransportReceiveStream interface or the bytesReceived and bytesRead members. Link to entry on the Chrome Platform Status https://chromestatus.com/feature/5109912169480192?gate=6063689550659584 This intent message was generated by Chrome Platform Status. -- 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/6ad96768.a6e82b8f.de7e0.02cf.GAE%40google.com.
