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

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