Hi everybody, in https://bz.apache.org/bugzilla/show_bug.cgi?id=56188 some users brought up an interesting use case for mod-proxy-fcgi, namely what it should do when a client drops its connection to httpd meanwhile the FCGI backend is still processing the request (for example, long running jobs).
While reviewing the (first) patch provided, I was a bit puzzled by how the FCGI specs describe the FCGI_ABORT functionality (assumption #1 - I am not aware of any official RFCs): https://web.archive.org/web/20150215150311/http://www.fastcg i.com/devkit/doc/fcgi-spec.html#S5.4 Since mod-proxy-fcgi does not support FCGI request multiplexing (assumption #2 - I am not aware of any FCGI backend that supports it), it seems to me that the following sentences should be the only relevant ones: "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. " "When a Web server is not multiplexing requests over a transport connection, the Web server can abort a request by closing the request's transport connection. But with multiplexed requests, closing the transport connection has the unfortunate effect of aborting all the requests on the connection." The other sentences seems to be related to the use case in which the client explicitly wants to abort a request, waiting for an answer. In the particular use case of the PR, the client has already dropped its connection to httpd, so nobody will care about the FCGI's final response status. I still haven't found any good/clear motivation to send the FCGI_ABORT record (just before dropping the connection), but I am probably missing some good point or my assumptions could be wrong. Any comment or suggestion would be really welcome :) Thanks and sorry for the long email! Luca
