Using mod_proxy as a reverse proxy, if a client sends a request with Expect: 100-continue, mod_proxy forwards the Expect header upstream. Even if the upstream server responds with a final status code (e.g. 401 Unauthorized, or 413 Request Entity Too Large) instead of a 100 Continue, mod_proxy continues to send data to the upstream server. If the upstream server closes the connection after sending the final status code, httpd responds to the client with a 502 Bad Gateway message instead of the origin server's final status code. RFC 2616 (sec. 8.2.3) says that: >> If [a server] responds with a final status code, it MAY close >> the transport connection or it MAY continue to read and discard >> the rest of the request. httpd does not appear to be doing "the right thing" in the event that the origin server closes the upstream connection. If the upstream server continues to consume the request, then httpd will correctly return the final status code. Furthermore, sec. 8.2.4 says that: >> If at any point an error status is received, the client >> - SHOULD NOT continue and >> - SHOULD close the connection if it has not completed sending the request message. It seems that mod_proxy is not doing either of these things. And because mod_proxy does not send the final status code from the origin server to the client as it is received, the client also cannot abide by the requirements of 8.2.4. I've verified this behaviour in the Redhat-supplied httpd 2.2.15, but not in the latest httpd release.
I should clarify a couple of points: * Apache httpd will only return the final status code if the upstream server consumes the entire request *before* sending its response. If the response is sent before the input stream is consumed, httpd will discard the upstream response and return 502 Bad Gateway. * httpd returns a 100 Continue immediately to the client when it sees the Expect header, rather than waiting for the upstream server to respond.
Seeing this in 2.2.22. I would be curious for any workarounds. Thank you!
I'm experiencing this in 2.4.23 and 2.4.18
*** This bug has been marked as a duplicate of bug 60330 ***
We have APACHE version 2.4.6 and we still see this error. Where the backend server send 401 to Apache but it responds with 502 (Bad Gateway). Please confirm if the changes made in the bug 60330 is ported to 2.4.6 APACHE version. Scenario(Same as mentioned by jon.abourbih@gmail.com) : Using mod_proxy as a reverse proxy, client sends a request with Expect: 100-continue, mod_proxy forwards the Expect header upstream. Even if the upstream server responds with a final status code (e.g. 401 Unauthorized, or 413 Request Entity Too Large) instead of a 100 Continue, mod_proxy continues to send data to the upstream server. If the upstream server closes the connection after sending the final status code, httpd responds to the client with a 502 Bad Gateway message instead of the origin server's final status code.
We're also affected of this bug: Client <--> reverse-proxy Apache with mod_proxy <--> server The client sends a multi-megabyte request body. The server detects that the authentication information is stale, sends 403. The apache reverse-proxy converts the 403 into a 502. I'd like to mention another RFC: https://www.rfc-editor.org/rfc/rfc9110.html#name-response-correlation All responses, regardless of the status code (including interim responses) can be sent at any time after a request is received, even if the request is not yet complete.
httpd implements end-to-end 100-continue since version 2.4.40 (see bug 60330), including the forwarding of early final/non-interim responses. There is no way it can be backported to 2.4.6 upstream (versions are immutable here), though some distros name _their_ package after the upstream version shipped initially and keep updating it with fixes So your options are to upgrade to the latest upstream version (currently 2.4.57) or see with your distro if they want to ship the change in their package. *** This bug has been marked as a duplicate of bug 60330 ***