v158 · webtransport · receive streams
The subclass, member by member
The whole feature is one interface with one method. That makes its shape precisely checkable: WebTransportReceiveStream.prototype must chain to ReadableStream.prototype, must own exactly getStats as its addition, and must refuse new — instances only ever come from a live session.
Chrome targets this interface for Chrome 158 behind the WebTransportReceiveStream runtime flag — launch with --enable-blink-features=WebTransportReceiveStream, or flip chrome://flags/#enable-experimental-web-platform-features and relaunch. On a build without it, every check below reports the absence explicitly.
The prototype chain, walked for real
- press the button
| check | result | why it matters |
|---|
Where instances come from
You never construct one. On a live session, each chunk of incomingUnidirectionalStreams is a WebTransportReceiveStream, and so is every bidirectional stream's .readable. The container streams exist before any connection — this build's real objects:
The chunks inside those containers are the part that needs an established HTTP/3 session, which this showcase cannot reach — so chunk-level typing stays an honestly unexecuted claim here, pinned by the conformance suite's manual assertion instead of a faked one.
code path
// Shape checks that need no server:
const wtrs = globalThis.WebTransportReceiveStream;
Object.getPrototypeOf(wtrs.prototype) === ReadableStream.prototype; // true
Object.prototype.hasOwnProperty.call(wtrs.prototype, "getStats"); // true
"getStats" in ReadableStream.prototype; // false
new wtrs(); // TypeError: illegal constructor
// Instance sources (live session only):
transport.incomingUnidirectionalStreams; // ReadableStream OF receive streams
bidi.readable; // a WebTransportReceiveStream itself