On Mon, Jan 30, 2017 at 7:17 PM, Luca Toscano <toscano.l...@gmail.com> wrote: > > The use case that I had (the one that caused me to check the original > bugzilla task/patch and work on it) was a long running PHP script (running > on HHVM) that wasn't returning anything until the end of the job (minutes), > causing mod-proxy-fcgi to keep waiting even if the client disconnected. In > the beginning I also thought that there was a way to "signal" the FCGI > backend to stop whatever was doing (FCGI_ABORT), but it turned out to be not > widely implemented (at least from what I have checked, more info in > bugzilla). Timeout and ProxyTimeout could be a good compromise for this > particular issue, but it is a "one size fits all" solution that some users > didn't like (providing a patch with the pollset solution).
I think that's what CGIDScriptTimeout or ProxyTimeout are for: avoid waiting too much for the script or backend (above some reasonably configured limit). > > If we remove the above use case (I fixed it in my Production environment > with a long Timeout value), would it be fine to rely on something like the > conn->aborted flag (afaics set by the output filter's chain while writing to > the client's conn)? It would simplify a lot the problem :) AFAICT, if forwarding data to the client fails (e.g. socket disconnected), ap_pass_brigade() returns an error and the loop exits. Maybe what is missing is nonblocking reads on the backend side, and on EAGAIN flush on the client side to detect potential socket errors?
