v158 · webtransport · reliability
Transport strategy picker
The enum exists so an application can pick a wire strategy: lossy-but-fresh datagrams when the path supports them, sequence-numbered reliable streams when it does not. This page runs that decision code against a real session's reliability value — and shows what the identical code would decide for each value the enum can take.
Chrome targets this for Chrome 158 behind WebTransportReliability — launch with --enable-blink-features=WebTransportReliability or flip chrome://flags/#enable-experimental-web-platform-features. This showcase has no HTTP/3 endpoint, so a live session here never leaves "pending" (or reports the attribute missing on a pre-158 build); the strategy table is driven by whatever the browser really returns.
Ask a real session
The same decision code, across the whole enum
One switch statement, four branches — the three spec values plus the branch every robust reader needs for a value it does not recognise. The row matching the live session's real read is outlined.
| value read | what it means | what the code does |
|---|---|---|
"pending" | No connection established yet — the mode is simply not known. | Wait on transport.ready before committing to a strategy; queue early messages reliably. |
"supports-unreliable" | HTTP/3 path: unreliable datagrams are available alongside reliable streams. | Send position/voice deltas as datagrams; keep chat and state sync on reliable streams. |
"reliable-only" | HTTP/2 fallback path: streams only, no datagrams on the wire. | Route everything over reliable streams; drop the freshness optimisations rather than fake them. |
| anything else | A future spec revision or a value this code predates. | Log the actual string and fall back to reliable streams — never bucket an unknown value into "unsupported". |
The connect-time companion: requireUnreliable
The read-side enum has a write-side partner that predates it: the requireUnreliable constructor option. With it set, the spec forbids the user agent from falling back to a reliable-only connection — the session fails to establish instead of silently losing datagrams. Together they bracket the contract: requireUnreliable demands a capability up front, reliability reports what was actually negotiated.
// refuse a reliable-only fallback instead of discovering it later
const t = new WebTransport(url, { requireUnreliable: true });
await t.ready; // rejects if only HTTP/2 was possible
console.assert(t.reliability === "supports-unreliable");