- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 2 Mar 2026 16:04:51 +1300
- To: ietf-http-wg@w3.org
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. > 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. HTH Amos
Received on Monday, 2 March 2026 03:04:59 UTC