> Unfortunately, the way browsers implement WebSocket it undermines TCP's flow control. It's trivial to crash a browser tab by opening a (larger than RAM) file and trying to stream it to a server using a tight loop sending on a WebSocket. WebSocket.bufferedAmount exists, but as of 2019 I failed to use it to solve this problem and had to implement application-level backpressure.
Before you were saying, "WebSockets lack flow control (backpressure) and multiplexing, so if you need them you either roll your own or use something similar to RSocket.", and now you're saying you can't roll your own? ;-)
> HTTP3 actually falls under my concern. There are still networks that block HTTP3, because it has really nice fallback to HTTP2/1.1, so there's no obvious impact on users.
Erm, HTTP2 & HTTP 1.1 have their own problems, some of which you yourself have identified. We actually rolled back from HTTP2 to HTTP 1.1 because of problems with HTTP2, particularly with mobile performance.
Our migration to HTTP3 has been all win so far. While UDP might be blocked for security reasons, there are security reasons to move to HTTP3.
That said, there are cases where only HTTP/1.0 is supported.
> The reason I care is that I'm currently developing a protocol that WebTransport is an excellent fit for. But I can't assume WebTransport will work because UDP might be blocked, so I'm having to implement WebSocket support as well, which is a lot more work.
I feel your pain. I've been using WebRTC, and the vast majority of the time UDP doesn't seem to be blocked anymore. That said, adoption of HTTP3 seems to be about half that of HTTP2 right now. Not bad for a brand new protocol, but I'd say we still have a significant amount of time to go before HTTP3 is the dominant protocol. I think the path forward is going to require some toil by the likes of you to support both, but no reason you can't support HTTP3 better! ;-)
> Before you were saying, "WebSockets lack flow control (backpressure) and multiplexing, so if you need them you either roll your own or use something similar to RSocket.", and now you're saying you can't roll your own? ;-)
You can, but you need to do it at the application level, which is a lot more involved. It would be nice if it were as simple as checking if bufferAmount > some threshold and then waiting on a promise before attempting to send again. That's essentially what you get with ReadableStream and WritableStream, which are provided by WebTransport.
> Erm, HTTP2 & HTTP 1.1 have their own problems, some of which you yourself have identified. We actually rolled back from HTTP2 to HTTP 1.1 because of problems with HTTP2, particularly with mobile performance.
Not sure if we're actually disagreeing here. In any case, we can both agree HTTP2 is not a panacea, and actually worse than HTTP/1.1 in some cases.
> That said, adoption of HTTP3 seems to be about half that of HTTP2 right now. Not bad for a brand new protocol, but I'd say we still have a significant amount of time to go before HTTP3 is the dominant protocol.
Here here. Overall I'm bullish on HTTP3 in the long run. I really just hope random enterprise networks don't decide to block it. In any case, it's going to be a big win for the places where it works.
Before you were saying, "WebSockets lack flow control (backpressure) and multiplexing, so if you need them you either roll your own or use something similar to RSocket.", and now you're saying you can't roll your own? ;-)
> HTTP3 actually falls under my concern. There are still networks that block HTTP3, because it has really nice fallback to HTTP2/1.1, so there's no obvious impact on users.
Erm, HTTP2 & HTTP 1.1 have their own problems, some of which you yourself have identified. We actually rolled back from HTTP2 to HTTP 1.1 because of problems with HTTP2, particularly with mobile performance.
Our migration to HTTP3 has been all win so far. While UDP might be blocked for security reasons, there are security reasons to move to HTTP3.
That said, there are cases where only HTTP/1.0 is supported.
> The reason I care is that I'm currently developing a protocol that WebTransport is an excellent fit for. But I can't assume WebTransport will work because UDP might be blocked, so I'm having to implement WebSocket support as well, which is a lot more work.
I feel your pain. I've been using WebRTC, and the vast majority of the time UDP doesn't seem to be blocked anymore. That said, adoption of HTTP3 seems to be about half that of HTTP2 right now. Not bad for a brand new protocol, but I'd say we still have a significant amount of time to go before HTTP3 is the dominant protocol. I think the path forward is going to require some toil by the likes of you to support both, but no reason you can't support HTTP3 better! ;-)