Firefox 158 adds WebTransport stats: what about HTTP/2 and streaming uploads?

Did Firefox add statistics or a new connection route?

Firefox 158 was first offered to desktop Release channel users on October 13, 2026. MDN labels its developer notes Stable and lists new support for WebTransport.getStats(). The method returns statistics for the underlying connection and its datagrams, helping developers observe an existing transport.

WebTransport lets a web application establish a data-transport session with a server. Being able to read statistics does not add a new connection route. These release notes do not promise to repair a failed handshake, proxy connection or server configuration. Check the relevant API documentation for field units and permission conditions instead of guessing values from the method name.

What capability is missing when supportsReliableOnly is false?

The same developer notes add the static WebTransport.supportsReliableOnly property. It indicates whether the browser supports WebTransport sessions using exclusively reliable transports, such as HTTP/2. Firefox does not yet support WebTransport over HTTP/2, so this property always returns false.

That false does not mean WebTransport is unsupported altogether. It is also not the result of diagnosing a particular failed connection. It describes a transport capability, without establishing that a specific server, exit connection or network will work.

Consider an unexecuted compatibility-design example: if your service depends on WebTransport over HTTP/2, Firefox 158 still cannot satisfy that requirement through this update. Developers need to retain another application transport already verified for their use case. The appearance of getStats does not mean an automatic fallback has been implemented.

Why is streaming upload in the 158 notes but outside stable support?

Under Experimental web features, MDN lists Streaming request bodies and explicitly says Enabled in Nightly only. The feature allows a ReadableStream to be used as the body of Request() or Window.fetch(), uploading incrementally instead of waiting for the entire body to be available.

The documented experimental preference is dom.fetch.streaming_upload, but the channel restriction matters too. Seeing 158 in the page title or a preference name in the text does not establish default support for stable users. Changing one setting cannot be presented as a guarantee that a stable build gains this Nightly capability.

This restriction concerns streaming request bodies, rather than giving a universal answer about all file uploads. When investigating an upload problem, first determine whether the application actually uses a ReadableStream request body, then check the client channel and error. This article has not performed uploads in a user account or browser.

Does recording early WebSocket messages mean the connection was fixed?

The official release notes fix a Network Monitor issue that could miss WebSocket messages arriving immediately after a connection was established. The improvement concerns developer-tool recording. It does not announce that WebSocket connections, proxies or server transport have all been repaired.

For a follow-up check, open Network Monitor on your own test page before establishing a test connection. Compare the panel record with the messages the application actually receives. Retaining the browser version, recording start time and redacted error helps distinguish a missing panel record from missing application data. This is a suggested check, not a test performed by this article.

How much cache information does deliveryType provide?

Firefox 158 begins supporting PerformanceResourceTiming.deliveryType. Its initial supported value is cache, identifying a resource delivered from cache; the main release notes describe HTTP-cache delivery. Do not extend this one value into a claim that every delivery type, proxy cache or CDN hit is now fully observable.

A cache value gives a clue about how a resource was delivered. On its own, it does not establish a faster response, a healthy server or a successful network-path check. Read it alongside the application behavior and other available records. An absent cache value should not be presented as proof that every cache layer missed.

Check the desktop environment and channel before compatibility testing

The official 158 system requirements list Windows 10 or later and macOS 10.15 or later. Mac hardware can use an Intel x86 or Apple silicon processor. This article concerns desktop Release builds; that does not establish identical capabilities or update timing for Android, iOS or ESR.

The upstream GNU/Linux build requires glibc 2.17+, GTK+ 3.14+, libglib 2.42+, libstdc++ 4.8.1+ and X.Org 1.0+. On arm64, the glibc requirement is 2.28+ and libstdc++ is 6.0+. Distribution packages may have different requirements. Recommended components on the page are distinct from mandatory ones.

First record the actual Firefox version, Release or Nightly channel, operating system and architecture. Then check the APIs and server transport your application requires. A release date does not mean every machine has updated, and it does not replace the target application’s own support statement.

Check session establishment, readable statistics, developer-tool recording and streaming request bodies separately. Change one condition at a time and record expected and actual results. These release notes provide neither measured performance for those combinations nor a success guarantee across all network environments.