github.com-cloudflare-pingora

Upgrade body mode on 101 Previously the body reader would initialize to HTTP/1.0 mode when the upgrade request header is found. Now the reader is only converted to that mode when both the upgrade header and 101 is received.

Fix chunked trailer end parsing httparse itself does not treat the terminating chunk (0 + CRLF) any differently when parsing its chunk size, and the body reader does not validate the following CRLF required to close the body. Additionally, that current parsing scheme will not consider trailers before the end CRLF. Now the trailers are considered but simply discarded. The CRLFs between the trailers (and now, the CRLFs after the body payloads) are validated, however.

Subrequest sessions, clear body headers if no input Subrequests are now a separate server Session type, instantiated with corresponding SubrequestHandles that can send or receive HttpTasks to or from the subrequest. This makes it possible to communicate with created subrequests. Additionally the subrequest ctx now has a BodyMode input. If unset the background subrequest will clear request headers related to the request body to prevent issues where the upstream might expect body.

Add cancel-safe body and header writer primitives Add BodyWriter task API (send_body_task, write_current_body_task, send_finish_task, write_current_finish_task) and HeaderWriter for cancel-safe writes that can be used in tokio::select! loops.

transfer-encoding parsing robustness

Add cancel-safe proxy task API for Subrequest server sessions Implement the same proxy task API functionality for subrequest server sessions as HTTP/1. Also fix the regular subrequest header write path so upgrade state is only marked after the 101 task is sent.

Year 2026

Avoid close delimit mode on http/1.0 req RFC9112 is now extra explicit about the close delimiting applying exclusively to response messages for HTTP/1.0. Also disables reuse explicitly when close delimiting on the response side as defense-in-depth that shouldn't have behavioral diff.

Validate invalid content-length on v1 resp by default Rejecting bad upstream content-length by default to avoid forwarding ambiguously framed messages. An option still exists to allow this in the peer options, if needed, and treat these responses as close-delimited though this is non-RFC-compliant. The content-length is now also removed on the response if transfer-encoding is present, per RFC.

Discard extra upstream body and disable keepalive Explicitly disable keepalive on upstream connection when excess body (content-length) is detected.

Add a system for specifying and using service-level dependencies

Default to close on downstream response before body finish For v1, this represents a safe default to prevent the next request after an unfinished request write from appearing as and being rejected as a pipelined request on the same connection.

Reject invalid content-length v1 requests If a content-length is present RFC9112 indicates we must reject invalid forms of that content-length header. This eliminates situations where we might be dealing with ambiguous request framing.

Don't init body reader on HEAD 1xx This prevents headers like 100-continue from ending the stream and causing hangs while the downstream is waiting.

Mark previously too large chunked assets as cacheable Too large assets without content-length could previously be skipped as uncacheable indefinitely by the cacheable predictor. This change moves the max file size tracking outside of the miss handler itself such that it can also be used to track body bytes after caching was disabled. This also adjusts the cache inner structs such that cache key and the cacheable predictor are accessible, so that an asset can be remembered as cacheable even if caching was disabled. Additional safeguards are also in place to ensure that the NeverEnabled reason is not overridden when disabling cache, as it does not make sense to disable cache when it was never enabled in the first place.

Require WritePermit to release lock, fix dangling detection Dangling cache locks could occur when there were simply many readers at once waiting for the lock, the reason being the available permits could immediately be used up upon unlocking and before the WritePermit is dropped, resulting in a false positive dangling lock. Instead, just mark the WritePermit as finished when the cache key lock is unlocked as a result of having the permit. The most intuitive way to do this is to "turn in" the WritePermit back to the CacheKeyLock that created it when unlocking, so that the CacheKeyLock can mark it as finished.

Add a mechanism for signalling between old and new processes when doing graceful upgrades

Add cache lock wait timeout for readers Currently the lock timeout expressed by the CacheKeyLock is actually a lock age timeout. A reader wait timeout should be separately configurable, especially since a reader can wait on multiple different writers which are each considered separate locks. This wait timeout is made configurable by cache key (standard CacheLock API for this TBD). Also reacquire cache locks for the standard CacheLock when Timeouts occur (indicating lock age expiry).

Pipe subrequests utility Creates a pipe subrequest state machine utility to be able to treat the subrequest as a "pipe" (sending request body and writing response tasks directly from the subrequest). Also adds a handler to be able to propagate the downstream / final proxy error that a subrequest server session encounters to the pipe state machine. The subrequest pipe is also allowed to receive a preset input body, which may also be created from a previously captured downstream session body. In this case the captured session body may be reused for multiple "chained" subrequests. Co-authored-by: Matthew Gumport <mbg@cloudflare.com>

Shard connection pool and use a true global LRU rather than ThreadLocal to avoid stale entries in LRU, address other outstanding TODOs