https://bz.apache.org/bugzilla/show_bug.cgi?id=56188
--- Comment #9 from Luca Toscano <[email protected]> --- So while reading http://www.mit.edu/~yandros/doc/specs/fcgi-spec.html#S5.4 I came across this: > A Web server aborts a FastCGI request when an HTTP client closes its > transport connection while the FastCGI request is running on behalf of that > client. > The Web server sends a FCGI_ABORT_REQUEST record to abort a request. After > receiving {FCGI_ABORT_REQUEST, R}, the application responds as soon as > possible with {FCGI_END_REQUEST, R, {FCGI_REQUEST_COMPLETE, appStatus}}. This > is truly a response from the application, not a low-level acknowledgement > from the FastCGI library. As far as I can see the patch breaks out of the main while after sending the FCGI ABORT, not waiting for the FCGI_END_REQUEST response. I tried to change it a bit to allow this flow, but from my test I never get FCGI_END_REQUEST because mod_proxy_fcgi stops before it finding out that the client dropped the connection (probably when it tries to flush the output). I also didn't manage to see the FCGI backend stopping after the FCGI ABORT is sent, but maybe I am missing something trivial. I'll try to work on this code more during the next days. Jason: just want to make it clear, your patch looks good, I just want to make sure that we don't miss any corner case :) Thanks! -- You are receiving this mail because: You are the assignee for the bug. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
