HTTP/3 requires TLS. Wouldn't this make it drastically less economical to run a reverse-proxy? Are 4 unnecessary cryptographic operations per request not significant? What about the bandwidth overhead of rounding up the length of responses like `HTTP 200 OK\r\nContent-Length: 2\r\n\r\n{}` which make up a majority of all traffic to the nearest encrypted block?

I mean, HTTP2 "requires" TLS, but it's a separate layer so H2C is a strong standard with a very obvious definition. QUIC doesn't really work without TLS, so I'm not sure how an unencrypted version would even work, or whether anyone will support it.

Reverse proxy is mostly done with HTTP/1.1 i guess. It's only from client to server. App receives its classic requests. Also, it's probably possible to do with disabling certificates check and us a self signed.

When we are talking about efficiency, I’d start with optimizing \r\n to \n.

@lorentz I believe unencrypted is explicitly out of spec for quic

@BordedDev yeah, and I'm wondering why that would seem like a good idea when it's redundant for some contexts. Reverse proxies benefit from feature parity between the downstream and upstream protocol, which is why H2C is used.

I think it’s clearly designed (only) for infrastructure at scale. Your proxy would be running QUIC and internally it might be calling to any number of different servers over insecure HTTP/2 or maybe 1. It’s a bit dumb though, not every website is horizontally scaled or needs to be. QUIC definitely seems to fuck the middle class web server.

I'll just leave this one here, as I've _just_ read it.

Source: https://commitstrip.com/en/2018/... .

Soo, I might be wrong and feel free to whack me butttt...

Reverse proxy isn't HTTP tho, it just reroutes requests to a different server, it doesn't use a specific internet protocol by itself, it's just a "man in the middle" tranfering messages from you to the real server

@SoldierOfCode I was talking about the connection between the RP and the app server. With HTTP/2, you could use H2C on the backend and have full support for all the cool features like server push without paying the performance cost of encryption. With HTTP/3, you either encrypt that backend connection, or use H2C on the backend and miss out on all the even cooler new features, because there isn't an unencrypted but otherwise equivalent protocol like H2C for HTTP/2 that open-source web frameworks and reverse proxies can implement.