Re: Should an incremental proxying middleware be able to replay HTTP request bodies?

Yes, a small amount of buffering could be helpful. Does anyone have implementation experience of how much and for how long? A degenerative case is if the origin server sends HTTP_1_1_REQUIRED error code for a particular request to downgrade h2 to h1, but it always happens past the end of the buffer so the request fails, and retrying would keep hitting the same error.

For an HTTP client that can take redirects and handle authentication challenges, it must be able to restart request body transmission even if it has previously sent the entire body. But there is no standard way for a proxy to ask its client to restart the request body.

Guoye

On Feb 26, 2026, at 7:04 AM, Ben Schwartz <bemasc@meta.com> wrote:

I don't think there's  any special interaction between these features.  The proxy could buffer and replay some or all of the request, if it is identifiably safe as you noted, but it is never obligated to do so.

Obviously, unbounded buffering in the proxy would be dangerous, but I can imagine some scenarios where a small amount of buffering would be affordable and occasionally useful.

--Ben
________________________________
From: Guoye Zhang <guoye_zhang@apple.com>
Sent: Wednesday, February 25, 2026 5:56 PM
To: ietf-http-wg@w3.org <ietf-http-wg@w3.org>
Subject: Should an incremental proxying middleware be able to replay HTTP request bodies?



Hi everyone,

We are discussing requirements for an HTTP client used by a proxying middleware. Traditional HTTP middleware buffers the entire request body before forwarding the request upstream, so request bodies can be replayed. However, incremental proxies are able to stream the request body and might not want to keep the entire request in memory.

How does a streaming proxy handle the situation where the request body has to be replayed? Examples are that the upstream server sends a GOAWAY frame + REQUEST_REJECTED/REFUSED_STREAM, or if the request itself is idempotent and retryable after a network failure.

Guoye Zhang