Closed Bug 1818754 Opened 1 year ago Closed 1 year ago

Pref on WebTransport by default


(Core :: Networking: HTTP, task, P2)




113 Branch
Tracking Status
firefox113 --- fixed


(Reporter: jesup, Assigned: jesup)


(Blocks 1 open bug)


(Keywords: dev-doc-complete, Whiteboard: [necko-triaged])


(2 files)

No description provided.
Depends on: 1818502
Severity: -- → N/A
Type: enhancement → task
Priority: -- → P2
Whiteboard: [necko-triaged]
Depends on: 1818332
Depends on: 1818828
Pushed by
Enable WebTransport by default r=necko-reviewers,kershaw
Pushed by
Enable WebTransport by default r=smaug,saschanaz
Pushed by
Fix serviceworker webtransport missing edit r=saschanaz CLOSED TREE
Flags: needinfo?(rjesup)
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 113 Branch

Are we going to want to relnote this? Please nominate if so.

Flags: needinfo?(rjesup)

Note it's nightly-only for now. When we change that I'll add it to relnotes-needed

Flags: needinfo?(rjesup)

FWIW, we can add Nightly-only relnotes to encourage wider testing and improved visibility of what we're working on. Feel free to nominate any time you feel that would be useful, even if the feature isn't ready to ride the trains yet.

Did you want to add this to the Nightly relnotes for now?

Flags: needinfo?(rjesup)

Release Note Request (optional, but appreciated)
[Why is this notable]: Major new web api
[Affects Firefox for Android]: yes
[Suggested wording]: We've preffed on the WebTransport API in nightly, including RFC 9297 support, in Firefox 113. It's expected to ride the trains to release soon. Various major players on the web are planning to use WebTransport for media delivery and other things. WebTransport is built on top of QUIC/HTTP3, and provides reliable streams and reliable and unreliable datagrams.
[Links (documentation, blog post, etc)]:

relnote-firefox: --- → ?
Flags: needinfo?(rjesup)

Added to the Fx113 Nightly relnotes.

MDN Docs work for this can be tracked in

  1. There is a data compatibility in WebTransport that indicates Chrome supports BYOB readers. Does FF also support these readers? Yes. We appear to support WebTransportReceiveStream

  2. I tried to get some clarification of how serverCertificateHashes work in - a useful response that did not answer my questions. Can you help?
    Specifically, the user of this API sets the set of certificate hashes when they create the WebTransport:

    • My assumption is that these get passed to the browser, and it is the browser that does any comparison of the hash to the certificate and decides that TLS connection can proceed. I.e. the user of this API never actually needs to see the certificate if they have the hash. Is that correct?
    • Assuming I'm right, what then is the workflow for an app that allows them to get these hashes in the first place and then keep them updated? My assumption is that the hash would have to be supplied via some separate path in the first place, and the user would have to keep logging in to get code with uploaded versions. Otherwise the server and the downloaded content would get out of sync with respect to the hashes that the downloaded code has.
  3. Is there an example of how the value might be set? I.e. this is an ArrayBuffer or ArrayBufferView. As above I am assuming the developer of the website might give the user a hash in a string, and that has to be passed into the code somehow. ChatGPT offers the following :-): WOuld this work, or is there a recommended way?

    //String containing SHA from website
    const sha256String = "a94a8fe5ccb19ba61c4c0873d391e987982fbbd3"; 
    // Convert SHA-256 string to Uint8Array
    const sha256Array = new Uint8Array(sha256String.match(/.{1,2}/g).map(byte => parseInt(byte, 16)));
    const transport = new WebTransport(url, {
     serverCertificateHashes: [
         algorithm: "sha-256",
         value: sha256Array 
  4. WebTransportReceiveStream states in spec

    A WebTransportReceiveStream is a ReadableStream providing incoming streaming features with an incoming unidirectional or bidirectional WebTransport stream."

    Really? It seems to only be returned by the WebTransport.incomingUnidirectionalStreams property? The incomingBidirectionalStreams returns a different object. Is this a typo in the spec or is it that WebTransport.incomingUnidirectionalStreams will include a read stream for the incomingBidirectionalStreams as well (i.e. you could read from a bidirectional stream using either the WebTransportREceiveStream, or the WebTransportBidirectionalStream?)

  5. Any chance of a technical review of the newly documented methods: ?

Note, changing needinfo as no response from

Flags: needinfo?(rjesup)
Flags: needinfo?(valentin.gosu)

@jib for the certificate hash question -- note that we don't support the server certificate hash part of the API currently

  1. WebTransportReceiveStreams are also part of bidirectional streams -- WebTransportBidirectionalStream has a ReceiveStream and a SendStream:
interface WebTransportBidirectionalStream {
  readonly attribute WebTransportReceiveStream readable;
  readonly attribute WebTransportSendStream writable;

@jib - can you also look at since a lot of these questions are about the intended API?

Flags: needinfo?(rjesup) → needinfo?(jib)

@rjesup - thanks for getting back to me. Is the server hash part of the API the only thing that is omitted? If not, what else - because that wasn't obvious to me from the bug reports.

PS Note, I added this as dev-doc-complete, but still need answers :-)

Flags: needinfo?(rjesup)

You can see most of what we've implemented in, however that doesn't cover all of the spec (for example, SendOrder isn't tested at all).

The buglist attached to the webtransport bug is probably the most complete.

We don't support the certificate hash stuff, SendOrder is in review right now (chrome hasn't implemented it yet last I knew), expiration times for Datagrams, getStats() (chrome doesn't implement last I knew). Probably some minor issues as well

Flags: needinfo?(rjesup)

Comment 17 sounds correct.

Flags: needinfo?(jib)

The was included in the Fx114 relnotes after being enabled by default in bug 1831073.

relnote-firefox: ? → ---
See Also: → 1831073
You need to log in before you can comment on or make changes to this bug.