v158 · webtransport · keying material
Three RangeError gates, tested before the network
The spec's algorithm order matters: label length, context length, and output length are validated before the session's state is consulted. So a label of 256 bytes must reject with RangeError even on a session that is still connecting — or already dead. Dial the three sizes below and fire real calls on a real session to a dead endpoint; argument validation needs no server at all.
Chrome targets exportKeyingMaterial() for Chrome 158 behind the WebTransportExportKeyingMaterial runtime flag (--enable-blink-features=WebTransportExportKeyingMaterial, or chrome://flags/#enable-experimental-web-platform-features). On a pre-158 build the method is absent, and this page says so instead of pretending to validate — the "spec says" column is the contract, the "this browser did" column is only ever real output.
The validation lab
spec: > 255 → RangeError
spec: > 255 → RangeError
spec: 0, or above the impl ceiling (≥ 4096; Chromium: 4096) → RangeError
| label / context / length | spec says | this browser did | match |
|---|---|---|---|
| No call yet. | |||
The four gates, one press each
Each preset fills the fields with a canonical boundary case and fires.
code path
// The spec's order of checks, verbatim:
// 1. label.byteLength > 255 → reject RangeError
// 2. context.byteLength > 255 → reject RangeError
// 3. outputLength == 0 or > impl ceiling → reject RangeError (ceiling ≥ 4096)
// 4. [[State]] "closed"/"failed" → reject InvalidStateError
// 5. otherwise: run in parallel; abort to InvalidStateError on failure
const t = new WebTransport("https://127.0.0.1:44443/never"); // never establishes
await t.exportKeyingMaterial(new Uint8Array(256), ctx, 32);
// → RangeError, immediately — gate 1 fires before the state is even looked at