On Thu, Oct 29, 2026 at 2:12 AM Reza Jahanbakhshi via Boost < boost@lists.boost.org> wrote:
HTTP/2 and HTTP/3 are out of scope for taar, by design. Beast is HTTP/1.1 only, and the expected deployment puts a reverse proxy or load balancer in front that terminates TLS and h2/h3. That's how we run it in production too. REST, JSON-RPC, MCP (Streamable HTTP), SSE and WebSocket all work fine over HTTP/1.1.
It was on the roadmap but the reasoning wasn't written down, so I just added a design note:
https://rjahanbakhshi.github.io/boost.taar/boost_taar/design.html#boost_taar...
The handler and protocol layers don't care how the bytes arrive, so in theory, if an HTTP/2 transport shows up in Beast or Http later, the same handlers should run on it.
Right. I think this is actually even more reason why you shouldn't necessarily pursue this. You have to look at the trade-offs you're making. You have a header-only library using Asio and Beast, so it's slow to compile and the binary bloat can be tremendously large. What's more, you're also using an entirely memory unsafe language in a security-critical context. Then even worse, you're deliberately eschewing performance at a protocol level by only using HTTP/1. When in all reality, users can just use an off-the-shelf memory safe language which _does_ support modern protocols. Following up on this, real servers demand a ton of different functionality like handling cookies, JWTs, OAuth 2.0, etc. There's just so much a user would actually need to write a real server here and unfortunately, I think C++ is woefully deficient here. If one was going to use C++, it'd actually demand best-in-class performance across the board and telling people to terminate multiplexed streams into a sequential protocol I think is a non-starter when you look at all the other pieces that are in play here. In short, what would a user even gain here over just using Node, Go, C#, Kotlin, Rust, Python, Java? - Christian