[Webtransport] Re: WebTransport over WebSocket

[Marten Richter <[e-mail]>]

Hi,

I have written a WebTransport over WebSocket draft some time ago:

draft-richter-webtransport-websocket-03 - WebTransport over WebSocket
<https://datatracker.ietf.org/doc/draft-richter-webtransport-websocket/>but 
so far no response.

including a polyfill:
fails-components/webtransport: Http/3 webtransport support for node 
<https://github.com/fails-components/webtransport>

It is basically http/2 capsule translated to a Websocket frame, 
including support for backpressure and most capsules. (And also 
partially sending of websocket frames).
(Only problem is that my current implementation has swapped ids, which I 
intend to fix:
The logic in stream ID direction detection seems wrong · Issue #381 · 
fails-components/webtransport 
<https://github.com/fails-components/webtransport/issues/381>
if the Mozilla devs have finished finding other bugs in my http/2 
implementation).

Code of the parser is here.
webtransport/main/lib/http2/node/websocketparser.js at master · 
fails-components/webtransport 
<https://github.com/fails-components/webtransport/blob/master/main/lib/http2/node/websocketparser.js>

Marten

Am 06.09.2025 um 01:48 schrieb Alan Frindell:
>
> CC: QMux enthusiast Kazuho
>
> Hi Luke, thanks for sharing this work.  On the one hand, I want to 
> help the world move from on from WebSockets to WebTransport.  On the 
> other hand, I see your practical problem, and I want to help the world 
> access MoQ too.
>
> I think QMux, whenever it comes to fruition, should be directly 
> runnable on top of WebSockets, so I don’t think a separate draft is 
> needed.  There’s ongoing discussion of what the shape of QMux will be, 
> but “Just send WebTransport capsules” is one possibility.
>
> -Alan
>
> *From: *Luke Curley <[e-mail]>
> *Date: *Friday, September 5, 2025 at 3:02 PM
> *To: *WebTransport <[e-mail]>
> *Subject: *[Webtransport] WebTransport over WebSocket
>
> Hey WebTransport, As some of you might know, I've been working 
> full-time on a MoQ startup/app (hang. live). I finally got around to 
> the elephant in the room: Safari support.   And not just Safari, but a 
> TCP fallback in general. Some networks
>
> Hey WebTransport,
>
> As some of you might know, I've been working full-time on a MoQ 
> startup/app (hang.live). I finally got around to the elephant in the 
> room: Safari support.
>
> And not just Safari, but a TCP fallback in general. Some networks 
> block QUIC/UDP and there are many platforms that don't support 
> WebTransport yet (ex. Cloudflare Workers).
>
> My solution is more-or-less QMux over WebSocket. It works today and 
> supports any existing WebSocket service/library. It's also open source 
> <https://github.com/kixelated/web-transport/tree/main/web-transport-ws> 
> and available in both Rust and Typescript. I've also got a Typescript 
> client that performs Happy Eyeballs 
> <https://github.com/kixelated/moq/blob/f10f854e5c9cedf889c434e3e898eff0d10f10ca/js/moq/src/connection.ts#L51>.
>
> I know this is the intended purpose of WebTransport over HTTP/2. 
> However, adoption feels like an uphill battle as every client/server 
> needs to explicitly support it at the HTTP layer. I think a TCP 
> fallback needs to have widespread adoption, and layering on top of 
> WebSockets accomplishes that.
>
> I was wondering if anybody would be interested in writing a draft, 
> especially anybody involved in QMux. Or just send WebTransport 
> capsules over WebSocket; that would work too.
>
>
-- 
------------------------------------------------------------
Dr. Marten Richter
Institut für Theoretische Physik
Technische Universität Berlin
Hardenbergstr. 36 Sekr. EW 7-1
D-10623 Berlin
Germany
------------------------------------------------------------
email:[e-mail]
Tel: [phone] (office)
Fax: [phone]
http://www.tu.berlin/agknorr/

------------------------------------------------------------