#669: WebTransport review request
Discussions
Comment by @yutakahirano Aug 25, 2021 (See Github)
I'm planning to send an intent to ship to blink-dev in mid September, and it'd be great if it's reviewed by then.
Comment by @jan-ivar Sep 29, 2021 (See Github)
Note the https://github.com/w3c/webtransport/blob/main/security-questionnaire.md has now been filled in.
Comment by @torgo Nov 17, 2021 (See Github)
Just noting that we seem to have completed a review in 2020. Sorry for the late reply here but can you clarify what has changed so we can try to expedite this and get it done at our upcoming virtual f2f.
Comment by @jan-ivar Nov 18, 2021 (See Github)
Sure thing, and thanks. Major changes since July 2020:
- The spec is now in the W3C, not WICG
- Removed the multiple-transport abstraction. HTTP/3 is now the sole transport, simplifying the model significantly
- We're still working on implicit HTTP/2 https://github.com/w3c/webtransport/issues/107 where HTTP/3 is unavailable
- Integrates with the fetch spec to obtain a connection; may be pooled but this has no implementations yet, so JS gets a dedicated server connection by default
- Connection URLs now use the “https" scheme, and must include the port
- SecureContext only, exposed on Window and DedicatedWorker
- WHATWG streams are used throughout, even for datagrams (where they provide local back-pressure sender-side)
- Fleshed out streams algorithms with underlying queues, back pressure, and error handling
- Removed custom network (QUIC) abort APIs and integrated with WHATWG stream abort semantics instead:
stream.abort(new WebTransportError({streamErrorCode})) // aborts stream with same code on client & server - Operates on BufferSource data, with (streams) semantics lower-level than WebSocket (message) semantics:
- Use single stream for data you need to arrive in order (but BYO framing)
- Use separate streams for data that should arrive in parallel but can arrive out of order
- Close code and message from server (not an error):
const {closeCode, reason} = await wt.closed - CSP
Unfortunately, the explainer is a bit outdated. I hope to get to that soon in https://github.com/w3c/webtransport/issues/319.
Comment by @yutakahirano Nov 18, 2021 (See Github)
Chrome shipped the API in 97.
Comment by @atanassov Dec 7, 2021 (See Github)
@plinss and I had a chance to review this during our Madripoor TAG f2f. Thank you for summarizing all changes since last review and updating the security questionnaire. Given most changes are about simplifications and feature completion, moving the capability into a most stable state, we are happy to sign off.
Thank you for your patience and working with us. Best of luck finishing the work at the WebTransportWG.
OpenedAug 19, 2021
Ciao TAG!
I'm requesting a review of the WebTransport API Specification.
WebTransport is an API that allows web applications to establish interactive, bidirectional, multiplexed network connections It fills gaps in the web platform, such as lack of UDP-like networking API and lack of WebSocket-like API without head-of-line blocking, by proving a web accessible interface to the WebTransport protocol being developed by the IETF WebTransport Working Group. It provides:
It's great for sending or receiving high-frequency, small messages that don't need to be reliable (like game state), sending or receiving low-latency media and transferring files.
Further details:
We'd prefer the TAG provide feedback as (please delete all but the desired option):
🐛 open issues in our GitHub repo for each point of feedback. Please prefix the title with [TAG] and we will triage appropriately.