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


> On Mar 1, 2026, at 7:04 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
> On 26/02/2026 11:56, Guoye Zhang wrote:
>> 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.
> 
> That is not true. Some do this, some do not.
> Some only do it for pipelined messages.
> 
> Squid for example only buffers until the request headers are received and validated. The content/body is allowed to incrementally forward.

That’s good to know!
> 
> 
> 
>> 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
> 
> This is the purpose of the HTTP "Idempotent" property (<https://www.rfc-editor.org/rfc/rfc9110#section-9.2.2>) for methods. With modification by some headers/features of HTTP.
> 
> A proxy MAY replay Idempotent requests.
> 
> A proxy MUST NOT automatically retry non-idempotent requests.
> 
> 
> The requirements are slightly different for "client" agents. But your use-case was specifically about middleware so those exceptions do not apply.

I agree that a non-idempotent request cannot be retried after a generic failure, but the examples I gave (REQUEST_REJECTED/REFUSED_STREAM) are specifically defined in the protocol as never being processed

    The client can treat requests rejected by the server as though they had never been sent at all, thereby allowing them to be retried later.

They are used during a graceful connection shutdown, allowing requests with any methods to be retired on a new connection.

Guoye
> 
> 
> HTH
> Amos
> 
>

Received on Monday, 2 March 2026 07:48:59 UTC