Research HTTP/2 support and protocol negotiation #455

Context

The current HTTP stack enables only the http1 features in Cargo.toml and constructs its connector with enable_http1() in src/http.rs. HTTP/1.1 is widely interoperable, but HTTP/2 can improve connection reuse, multiplexing, and header compression, and some services or protocols require it.

Adding HTTP/2 also has costs and design questions. It introduces more code and dependencies into every statically linked application, and the host currently creates a new Hyper client for each request, which limits the benefit of multiplexing and connection pooling.

Research questions

Investigate and document:

• actual interoperability or performance needs for HTTP/2 in basic-cli applications;
• binary-size, compile-time, memory, and runtime costs on every supported target;
• supporting HTTP/1.1 and HTTP/2 through TLS ALPN negotiation versus exposing an explicit protocol choice;
• whether cleartext HTTP/2 (h2c) is in scope;
• whether the HTTP client should be shared across requests to make connection pooling and HTTP/2 multiplexing useful;
• request, response, timeout, and error behavior that may differ by protocol;
• tests for HTTP/1.1 fallback, successful HTTP/2 negotiation, and protocol-specific failures.

Desired outcome

Record whether basic-cli should support HTTP/2, with a recommendation and measured tradeoffs. If support is recommended, define an implementation plan that preserves HTTP/1.1 compatibility and keeps the public API and runtime behavior explicit.

Keep the public runtime documentation updated with the chosen behavior.

Related work

• Document supported targets and host runtime behavior #448 documents the current HTTP/1-only behavior.
• Add configurable limits for HTTP response bodies #436 tracks bounded HTTP response bodies.
• Make Http.TransportErr match host error behavior #438 tracks stable HTTP transport error classification.