https://bz.apache.org/bugzilla/show_bug.cgi?id=56188
--- Comment #11 from Luca Toscano <[email protected]> --- I believe that I have a better understanding of the issue, that can be probably summarized in two things: 1) mod_proxy_fcgi should detect as early as possible that the client connection dropped taking appropriate actions, for example sending FCGI_ABORT to the backend and cleaning its state. 2) The FCGI backend needs to react after receiving a FCGI ABORT appropriately. About 1), I have some ideas still to verify: - Rather than creating a new apr_pollfd_t, the client aborted use case might be handled by something simpler like the following (missing the FCGI_ABORT bit): Index: modules/proxy/mod_proxy_fcgi.c =================================================================== --- modules/proxy/mod_proxy_fcgi.c (revision 1775858) +++ modules/proxy/mod_proxy_fcgi.c (working copy) @@ -481,6 +481,12 @@ * cause timeout errors. */ apr_socket_timeout_get(conn->sock, &timeout); + if (r->connection->aborted) { + ap_log_rerror(APLOG_MARK, APLOG_TRACE1, rv, r, + "The client aborted the connection."); + break; + } + rv = apr_poll(&pfd, 1, &n, timeout); if (rv != APR_SUCCESS) { if (APR_STATUS_IS_EINTR(rv)) { - The FCGI specs seems to indicate that after sending a FCGI ABORT, mod_proxy_fcgi should need to wait for a related FCGI_END_REQUEST before wrapping up (we are not doing it in the various patches). I am going to do some more research during the next days, but if anybody has more knowledge then me related to FCGI please let me know. I am far from a expert in the field and it would be great to deliver this patch as quickly as possible. -- 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]
