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
