Firefox 160 ships a breaking change to WebTransport

Firefox 160 ships today, 10 November, with several changes to the WebTransport API, one of them breaking. exportKeyingMaterial() used to take an optional context argument and always return 32 bytes. In Firefox 160, context is required, and a new outputLength argument controls how many bytes you get back. Code that called the method with no arguments, or with only one, needs updating.

The same release adds a headers option to the WebTransport() constructor, so you can attach custom HTTP headers to the extended CONNECT request a session opens with, and read the server’s response headers back via WebTransport.responseHeaders. Two non-standard datagram properties, incomingHighWaterMark and outgoingHighWaterMark, are removed in favour of the standard incomingMaxBufferedDatagrams and outgoingMaxBufferedDatagrams. A new datagramsReadableType option can also turn transport.datagrams.readable into a readable byte stream, so you can reuse buffers with ReadableStreamBYOBReader instead of allocating a fresh Uint8Array per datagram.

const transport = new WebTransport(url, {
  headers: { Authorization: 'Bearer ...' },
  datagramsReadableType: 'bytes',
});

Why it matters: WebTransport is still young enough that most of its API surface can move without much warning, and this release is a reminder of that. Anyone using exportKeyingMaterial() for session-bound key derivation will see a hard failure until they pass both arguments. The headers option is the more useful addition day to day, since it closes a real gap: until now there was no way to authenticate a WebTransport session at the HTTP layer during setup.