- From: DYER Kevin <Kevin.DYER@3ds.com>
- Date: Fri, 27 Feb 2026 10:52:28 +0000
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <611421f552af41ff81fada11ab24627a@3ds.com>
As a reverse proxy or load balancer there is precedence, the BEA Weblogic plugin would, by default, resubmit the entire request to the next available server in the configured pool if the initial origin server took too long or was deemed offline/unavailable. I have observed the following client behavior while working with customers over the last 10 years. if a response has not been started/committed to the client a 307/308 return code does cause some HTTP clients to resubmit the entire request to the Location URL. As part of this discussion should a new 3XX return code be defined? One that instructs the client to resubmit the entire request to an absolute/relative URL provided? From: Guoye Zhang <guoye_zhang@apple.com> Sent: Thursday, February 26, 2026 11:59 PM To: Ben Schwartz <bemasc@meta.com> Cc: ietf-http-wg@w3.org Subject: 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 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<mailto: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<mailto:guoye_zhang@apple.com>> Sent: Wednesday, February 25, 2026 5:56 PM To: ietf-http-wg@w3.org<mailto:ietf-http-wg@w3.org> <ietf-http-wg@w3.org<mailto: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 This email and any attachments are intended solely for the use of the individual or entity to whom it is addressed and may be confidential and/or privileged. If you are not one of the named recipients or have received this email in error, (i) you should not read, disclose, or copy it, (ii) please notify sender of your receipt by reply email and delete this email and all attachments, (iii) Dassault Systèmes does not accept or assume any liability or responsibility for any use of or reliance on this email. Please be informed that your personal data are processed according to our data privacy policy as described on our website. Should you have any questions related to personal data protection, please contact 3DS Data Protection Officer https://www.3ds.com/privacy-policy/contact/
Received on Friday, 27 February 2026 10:52:37 UTC