FCGI_ABORT behavior in mod-proxy-fcgi

[Luca Toscano <to...@gmail.com>]

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

Re: FCGI_ABORT behavior in mod-proxy-fcgi

[Jacob Champion <ch...@gmail.com>]

On 01/11/2017 10:37 AM, Luca Toscano wrote:
> 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 :)

My $0.02, copied from IRC for discussion on-list:

I don't think we should implement FCGI_ABORT until/unless we decide to 
implement FCGI multiplexing. I understand that the bug's OP is operating 
happily with an FCGI_ABORT patch, but until they respond to you to 
clarify what backend they're using, we don't know if their approach is 
correct even for their own use case.

I don't think we should send FCGI_ABORT and then immediately close the 
connection without waiting for the client to respond. In my mind, 
sending FCGI_ABORT is a contract: "we will accept and discard a 
reasonable number of messages for the current request ID while we wait 
for you to send FCGI_END_REQUEST".

I do think that closing the FCGI connection when the client closes 
theirs is valuable. Eric's suggestion on #httpd to hide this behind a 
directive is probably wise; we've broken enough FCGI backends recently...

--Jacob