0.14.0

Important Changes

• Breaking in 0.14.0: the deprecated HTTP/3-specific request-body limit has been removed. Configurations containing experimental.h3.request_max_body_size now fail to load with migration guidance in every feature build, including binaries compiled without HTTP/3 support. Remove that key and use the top-level request_max_body_size, which is now the sole request-body limit for HTTP/1.1, HTTP/2, and HTTP/3. Programmatic users must also remove the public ProxyConfig.h3_request_max_body_size field. The top-level integer, binary-suffix, 0, and "unlimited" semantics are unchanged.
• Breaking in 0.14.0: cleartext requests are never forwarded to an application that requires client authentication. The default behavior is unchanged for applications with HTTPS redirection enabled: cleartext requests receive the normal 301 redirect. If an operator explicitly sets https_redirection = false for an application with client_ca_cert_path, cleartext requests resolved to that application now fail closed with status code 421 before any upstream contact. This also applies when the application is selected through plaintext default_app fallback.
• The per-virtual-host cache partitioning introduced in 0.13.3 has been withdrawn. With the cache feature compiled in, every request paid for the partitioning (capturing the client-visible scheme and building the client-facing URI) even when no cache was configured, and every cache hit built an extra synthetic request - a cost on the request-forwarding hot path that this proxy layer should not carry. Cache entries are again keyed on the request URI forwarded upstream (after the rewrite to the upstream target), as in releases before 0.13.3, so the partitioning by client-facing effective request URI described in the 0.13.3 notes is no longer current behavior. Correctness for cached responses that vary on forwarded attributes now relies on the origin declaring the variation, per the standard HTTP shared-cache contract: a backend that serves different content depending on the original (client-facing) host, scheme, or URI - notably when several virtual hosts are flattened onto one upstream via set_upstream_host or the default_app fallback - must emit an appropriate Vary header on such responses or mark them non-cacheable.
• Breaking in 0.14.0: the per-source-IP connection limit has been removed. The max_clients_per_ip setting counted TCP/QUIC connections, not individual HTTP/2 or HTTP/3 streams, and its usefulness depended on deployment topology and which layer had an authoritative view of the client address. Enforce source-IP admission at the network/L4 edge when required. A configuration that still contains max_clients_per_ip now fails to load with migration guidance instead of silently ignoring an operator-assumed control. Programmatic users must also remove the public ProxyConfig.max_clients_per_ip field. This removal is distinct from the global max_clients redesign described below.
• Breaking in 0.14.0: max_clients now provides one exact, shared cap for accepted HTTP/1.1 and HTTP/2 TCP connections. A slot is reserved immediately after TCP accept and retained through optional PROXY protocol parsing, the TLS handshake (including ACME TLS-ALPN challenges), and the complete Hyper connection lifetime, then released automatically when that path ends or is cancelled. This closes the previous gap where slow pre-HTTP work was outside the active-connection count and removes the separate PROXY-parser semaphores. max_clients = 0 rejects every HTTP/1.1 and HTTP/2 connection; programmatic ProxyConfig users can also use usize::MAX without overflow. The default TLS handshake timeout is reduced from 15 seconds to 5 seconds so incomplete handshakes retain a slot for less time. HTTP/3 no longer consumes this budget and instead uses the independent connection limit described below.
• Breaking in 0.14.0: HTTP/3 admission now limits connections per endpoint/listener instead of counting request streams process-wide. experimental.h3.max_concurrent_connections is now the authoritative H3 connection cap for each configured H3 endpoint/listener, covering handshakes through connection close; multiple listeners each receive the configured capacity. 0 rejects every H3 attempt, and the default is reduced from 4,096 to 512 connections. The existing bidirectional and unidirectional limits remain per connection. The obsolete H3 request-stream RequestCount and its atomic increment/decrement on every request are removed. Quinn explicitly refuses attempts above an endpoint-local RAII permit limit while retaining max_incoming as a distinct pending-attempt buffer; certificate reload now preserves the configured transport and buffer limits. s2n uses its native endpoint connection count, no longer misuses the active connection-ID-table setting, and composes the new cap with s2n's existing blocked/throttled-port protections.

What's Changed

• chore(deps): bump bytes from 1.12.0 to 1.12.1 by @dependabot[bot] in #650
• feat(revert): The per-virtual-host cache partitioning introduced in 0.13.3 has been withdrawn by @junkurihara in #652
• chore(deps): bump lru from 0.18.0 to 0.18.1 by @dependabot[bot] in #651
• feat(revert): remove per-IP counter due to the potential serious debt for throughput performance by @junkurihara in #653
• chore(deps): bump toml from 1.1.2+spec-1.1.0 to 1.1.3+spec-1.1.0 by @dependabot[bot] in #656
• feat(counter): max_clients now provides one exact, shared cap for accepted HTTP/1.1 and HTTP/2 TCP connections. by @junkurihara in #658
• feat(counter): Change HTTP/3 admission. now it limits connections per endpoint/listener instead of counting request streams process-wide by @junkurihara in #660
• chore(deps): bump clap from 4.6.1 to 4.6.2 by @dependabot[bot] in #661
• bump tokio from 1.52.3 to 1.52.4 by @dependabot[bot] in #662
• chore(deps): bump aws-lc-rs from 1.17.1 to 1.17.3 by @dependabot[bot] in #663
• chore(deps): bump tokio from 1.52.4 to 1.53.0 by @dependabot[bot] in #664
• chore: remove deprecated h3 body size key by @junkurihara in #666
• feat(mTLS): cleartext requests are never forwarded to an application with mTLS by @junkurihara in #667
• 0.14.0 by @junkurihara in #668

Full Changelog: 0.13.3...0.14.0