4 ms·
I wonder why they did not extend the existing websocket API. Now if you want to be HTTP/1 or HTTP/2 backward compatible, you have to add another abstraction ont
by ktpsns 11mo ago
I wonder why they did not extend the existing websocket API. Now if you want to be HTTP/1 or HTTP/2 backward compatible, you have to add another abstraction ontop of these two because WebTransports is HTTP/3 only.
- silverwind 11mo agoYeah, I don't see this or HTTP/3 gaining any widespread adoption because HTTP/3 needs obscure DNS records and messing with firewalls.
- kaoD 11mo agoHTTP/3 does not need obscure DNS records (but it's greatly enhanced by them). Messing with firewalls in what way?
- baggy_trough 11mo agoAll it really needs is a UDP port 443 hole punch. The DNS stuff is an optional optimization.
- CharlesW 11mo agoI can't find 2025 stats, but HTTP/3 adoption was already widespread two years ago. https://blog.apnic.net/2023/09/25/why-http-3-is-eating-the-world/ https://blog.apnic.net/2023/09/25/why-http-3-is-eating-the-w...
- deleted 11mo ago[deleted]
- chrismorgan 11mo agoWebSocket and WebTransport are pretty wildly incompatible in an API sense. One provides a single reliable bidirectional stream. The other provides arbitrarily many unreliable and reliable unidirectional and bidirectional streams, according to your own orchestration. It’s like saying “I had a violin, why didn’t they make this new ‘orchestra’ thing behave the same way?” If you’re willing to limit yourself to a single reliable bidirectional stream, abstracting over both WebTransport and WebSocket will be easy. WebTransport, in its fullness, also pretty clearly depends on HTTP/3. Any implementation based on HTTP/1 or HTTP/2 (which is in progress) will lack unreliable delivery and independence of streams (due to using TCP), and possibly more features.
- advisedwang 11mo agoThere is a proposal to do this: https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-http2 https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ht...
- KPGv2 11mo agoThe websocket RFC is designed around TCP, and "extending" WS to work over UDP would essentially be a new protocol. Which is what this is. You can think about this with HTTP/1 vs HTTP/3: HTTP/3 isn't an extension of HTTP/1. It's radically different.