4 ms·

Yes, we're currently on HTTP/1.1, but I'm sure we'll be looking at later versions. Unfortunately the Rust web server library we're using doesn't currently suppo

by gmac 3y ago

Yes, we're currently on HTTP/1.1, but I'm sure we'll be looking at later versions. Unfortunately the Rust web server library we're using doesn't currently support HTTP/3, but we could potentially e.g. put an nginx proxy in front of it for this purpose. A key point of our WebSocket and http transports is to support environments where TCP connections aren't available. Are there environments that would let us send and receive binary data following an http CONNECT that wouldn't simply allow an ordinary TCP connection?

toomim 3y ago
Try HTTP/2. You don't need /3.
KingMob 3y ago
As toomim also replied, HTTP/2 is fine, and honestly, is probably preferable for your use case, since you won't also have to deal with QUIC/UDP, and can keep using TCP. (HTTP/3 is ~90% the same as HTTP/2, just over a different transport layer, and ditching HTTP/2 prioritization mechanisms which you probably won't care about.) > A key point of our WebSocket and http transports is to support environments where TCP connections aren't available. Are there environments that would let us send and receive binary data following an http CONNECT that wouldn't simply allow an ordinary TCP connection? Based on the network diagram in your article, it looks like the edge functions speak HTTP to the proxy, upgrade that to WS, and then the proxy routes raw TCP to the conn pool/db. If so, CONNECT would be the same. The edge function sends an HTTP CONNECT request, the proxy would set it up, and afterwards, both hops are using the same transports as with websockets. The edge function would send HTTP/2 DATA frames wrapping the raw bytes, the proxy would unwrap those bytes, and then route the bytes over TCP to the conn pool/db. If I understand your setup correctly, HTTP/2 CONNECT would be applicable everywhere WS is.

4 ms·

Yes, we're currently on HTTP/1.1, but I'm sure we'll be looking at later versions. Unfortunately the Rust web server library we're using doesn't currently suppo

by gmac 3y ago

toomim 3y ago
Try HTTP/2. You don't need /3.
KingMob 3y ago
As toomim also replied, HTTP/2 is fine, and honestly, is probably preferable for your use case, since you won't also have to deal with QUIC/UDP, and can keep using TCP. (HTTP/3 is ~90% the same as HTTP/2, just over a different transport layer, and ditching HTTP/2 prioritization mechanisms which you probably won't care about.) > A key point of our WebSocket and http transports is to support environments where TCP connections aren't available. Are there environments that would let us send and receive binary data following an http CONNECT that wouldn't simply allow an ordinary TCP connection? Based on the network diagram in your article, it looks like the edge functions speak HTTP to the proxy, upgrade that to WS, and then the proxy routes raw TCP to the conn pool/db. If so, CONNECT would be the same. The edge function sends an HTTP CONNECT request, the proxy would set it up, and afterwards, both hops are using the same transports as with websockets. The edge function would send HTTP/2 DATA frames wrapping the raw bytes, the proxy would unwrap those bytes, and then route the bytes over TCP to the conn pool/db. If I understand your setup correctly, HTTP/2 CONNECT would be applicable everywhere WS is.