HTTP/2 Support

Meridian accepts HTTP/2 connections from downstream clients and translates them to HTTP/1.1 for upstream backends. This is the most common deployment pattern — modern browsers and clients use HTTP/2, while many backend services still speak HTTP/1.1.

Protocol Negotiation

HTTP/2 is negotiated via ALPN (Application-Layer Protocol Negotiation) during the TLS handshake. Meridian advertises both h2 and http/1.1. After the handshake, the negotiated protocol determines which connection handler runs:

• ALPN = h2 → handle_h2_connection (HTTP/2 handler)
• ALPN = http/1.1 or none → handle_connection (HTTP/1.1 handler)

HTTP/2 over plain TCP (h2c) is also supported for testing and internal deployments.

Stream Multiplexing

Unlike HTTP/1.1 which processes requests sequentially, HTTP/2 multiplexes multiple streams on a single connection. Each stream is handled in its own Tokio task:

Client ──── h2 connection ───── Meridian
               ├── stream 1 ──→ task 1 ──→ upstream A (HTTP/1.1)
               ├── stream 2 ──→ task 2 ──→ upstream B (HTTP/1.1)
               └── stream 3 ──→ task 3 ──→ upstream A (HTTP/1.1)

Protocol Translation (h2 → h1)

For each HTTP/2 stream, the handler:

1. Extracts the request — method, URI, headers from the h2 HEADERS frame
2. Reads the body — from the h2 RecvStream with flow control
3. Translates headers — :authority pseudo-header becomes the Host header, hop-by-hop headers are stripped
4. Forwards as HTTP/1.1 — standard request line + headers + body to the upstream
5. Reads the HTTP/1.1 response — status, headers, body from upstream
6. Translates back to h2 — builds an h2 Response, sends HEADERS + DATA frames

Flow Control

The h2 crate handles HTTP/2 flow control automatically. When the client sends body data, the handler releases flow control capacity after reading each chunk, allowing the client to send more data.

Connection Reuse

The h2 handler uses the same connection pool as HTTP/1.1. Upstream connections are checked out from the pool before each request and returned after the response, regardless of which downstream protocol the client used.