v158 · network · webtransport

WebTransport reliability attributes

A WebTransport session can run over HTTP/3 — where unreliable datagrams exist — or fall back to a reliable-only HTTP/2 path where they do not. Chrome 158 adds two ways to ask which world you are in: the per-session reliability attribute ("pending" while connecting, then "supports-unreliable" or "reliable-only") and the static WebTransport.supportsReliableOnly boolean, which says whether this browser can do reliable-only WebTransport at all.

concepts

  1. Reliability, read across a session's lifetime

    Read the static supportsReliableOnly answer straight off the constructor, then open a real session attempt and sample reliability at construction, at failure, and after close — a timestamped timeline of what the attribute actually returned at each moment.

  2. Transport strategy picker

    The product question the enum exists for: datagrams or reliable streams? Feed a real session's reliability value into a strategy table, and see what the same decision code would do for each of the three enum values — plus how requireUnreliable changes the contract at connect time.

  3. Readonly, static, and the unknown-value edge

    Where the two attributes actually live: property-descriptor dumps for the prototype accessor and the static, a strict-mode write that must throw on a supporting build, the instance lookup that must come back undefined, and an enum reader that refuses to bucket values it does not know.

why it shipped

Games, real-time collaboration, and interactive media pick different wire strategies depending on whether unreliable datagrams are available: lossy-but-fresh position updates over datagrams, or sequence-numbered deltas over reliable streams. Before this feature an application had no principled way to ask — it either assumed HTTP/3, or probed by sending a datagram and guessing from silence. The reliability attribute makes the answer part of the session object itself, and supportsReliableOnly lets code decide before connecting whether a reliable-only fallback is even possible in this browser.

In Chromium the current answers are specific: WebTransport runs over HTTP/3 only, so supportsReliableOnly returns false, and any session that establishes reports "supports-unreliable". Firefox exposes reliability but not the static; WebKit implements both and — running a reliable-only WebTransport today — returns true for supportsReliableOnly. The same code reading the same spec surface gets three different, correct answers.

the API

// Before connecting: can this browser do reliable-only WebTransport at all?
if (WebTransport.supportsReliableOnly) {
  // an HTTP/2 fallback path exists in this user agent
}

const transport = new WebTransport("https://example.com:4433/game");
console.log(transport.reliability);   // "pending" — nothing established yet

await transport.ready;
switch (transport.reliability) {
  case "supports-unreliable": /* datagrams available */ break;
  case "reliable-only":       /* streams only — HTTP/2 fallback */ break;
}

reliability is a readonly attribute returning the WebTransportReliabilityMode enum: "pending" until a connection is established, then "supports-unreliable" for HTTP/3 or "reliable-only" for HTTP/2. supportsReliableOnly is a static readonly boolean on the constructor, not on instances.

references