+1 for the theory, but I'm not sure if it's feasible or not. On Aug 2, 2013, at 5:28 AM, Thomas Eckert <[email protected]> wrote:
> So I've been seeing lots of "proxy: error reading status line from remote > server" by mod_proxy lately. Usually this is caused by the race condition > between checking the connection state and the backend closing the connection > due to the keep-alive timeout. As Covener pointed out to me in IRC, using > mod_proxy_http's env variable "proxy-initial-not-pooled" does offer a > solution to the problem albeit at the cost of performance. > > The call to ap_proxy_http_process_response() in mod_proxy_http.c eventually > boils down to ap_rgetline_core() which calls ap_get_brigade() on > r->input_filters. This looks to me like a simple input filter might do the > trick if it only checked for a possibility to read on the socket and reopens > the connection upon failure type "reset by peer". I took a short look at > core_create_proxy_req() in server/core.c to see how connections are set up > and I wonder if it's possible to recreate/reuse that logic in an input > filter. If so, this input filter would offer a nice alternative if hard > coding this behavior into mod_proxy/core is frowned upon. Simply make the > filter dependant on an env variable, just like proxy-initial-not-pooled. >
