1818754 - Pref on WebTransport by default

Status: RESOLVED FIXED

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

Comment 1

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 1818754: Enable WebTransport by default r=#necko-reviewers

Comment 2

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/ab9d49132a9b
Enable WebTransport by default r=necko-reviewers,kershaw

Comment 3

[Sandor Molnar[:smolnar]]

Backed out for causing mochitest failures in dom/serviceworkers/test/test_serviceworker_<...>

Backout link: https://hg.mozilla.org/integration/autoland/rev/1df09fc365e784f79faa075a729c554ae7879255

Push with failures

Failure log -> TEST-UNEXPECTED-FAIL | dom/serviceworkers/test/test_serviceworker_interfaces.html | undefined: If this is failing: DANGER, are you sure you want to expose the new interface WebTransport to all webpages as a property on self?

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/212aae381780
Enable WebTransport by default r=smaug,saschanaz

Comment 5

[Randell Jesup [:jesup] (needinfo me)]

Attachment: Bug 1818754: Fix serviceworker webtransport missing edit r=saschanaz

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cef0252b516d
Fix serviceworker webtransport missing edit r=saschanaz CLOSED TREE

Comment 7

[Atila Butkovits]

https://hg.mozilla.org/mozilla-central/rev/212aae381780
https://hg.mozilla.org/mozilla-central/rev/cef0252b516d

Comment 8

[Ryan VanderMeulen [:RyanVM]]

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

Comment 9

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 10

[Ryan VanderMeulen [:RyanVM]]

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.

Comment 11

[Ryan VanderMeulen [:RyanVM]]

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

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

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)]: https://w3c.github.io/webtransport https://datatracker.ietf.org/doc/draft-ietf-webtrans-overview/ https://datatracker.ietf.org/doc/draft-ietf-webtrans-http3/

Comment 13

[Ryan VanderMeulen [:RyanVM]]

Added to the Fx113 Nightly relnotes.

Comment 14

[Hamish Willee]

MDN Docs work for this can be tracked in https://github.com/mdn/content/issues/26153

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 https://github.com/w3c/webtransport/issues/508 - 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: https://github.com/mdn/content/pull/26529#issue-1691765529 ?

Note, changing needinfo as no response from [e-mail]

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

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

4. 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 https://github.com/mdn/content/pull/26529#issue-1691765529 since a lot of these questions are about the intended API?

Comment 16

[Hamish Willee]

@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 :-)

Comment 17

[Randell Jesup [:jesup] (needinfo me)]

You can see most of what we've implemented in https://wpt.fyi/results/webtransport?label=experimental&label=master&aligned, 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

Comment 18

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Comment 17 sounds correct.

Comment 19

[Ryan VanderMeulen [:RyanVM]]

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