Bug 49405 - Handling proxy backends sending RST
Summary: Handling proxy backends sending RST
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_proxy_http (show other bugs)
Version: 2.2.3
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2010-06-08 09:59 UTC by Ville Sulko
Modified: 2010-06-25 11:47 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Ville Sulko 2010-06-08 09:59:50 UTC
Current mod_proxy_http implementation tries to send the whole proxied request to the backend server before even trying to read the response. Some http server implementations however think they can send a response and close the connection (both directions with RST) before the whole request has been read. Servers implemented using java can cause this very easily, by calling socket.close().

To give an example, request might need authentication, and HTTP 401 is returned. In a way, sending RST makes sense. The request might be big one (say, a http PUT-request with 2MB file transfer). If the whole request needs to be read before the connection can be closed, the whole file needs to be sent twice. This is more of a application design issue, agreed, but this is how applications work today.

One example of a http server which sends RSTs is jetty. It is also very common to "hide" many applications behind a mod_proxy/rewrite frontend, often also offloading SSL-handling to apache. In these scenarios we get a lot of proxy 502 errors.

If possible, I would say that mod_proxy_http should try to read any possible response received from the backend, even if the request sending fails. And if a sane response can be read, it should be passed to the client and no 502 error should be given. I'm not sure how TCP stacks behave. If tcp stacks drop any traffic received after rst, there's of course not much that can be done, except maybe async reading.
Comment 1 William A. Rowe Jr. 2010-06-25 11:47:18 UTC
If the response isn't handled, the back end is in violation of the spec.

Accepting serious spec violations is addressed in the Watchfire request
smuggling report http://www.cgisecurity.com/lib/HTTP-Request-Smuggling.pdf
and providing the behavior you describe would make request injection much

Closing as invalid and won't change.