Client aborts are essentially client-closed connections, so they aren't detected until you try to write to that connection and TCP reports failure.
https://www.php.net/manual/en/features.connection-handling.php

> A1) If we do a simple echo of the payload and a flush()
> the client waits until 9) (until the php-script has total
> finished). A client abort, with above functions, is never
> detected.
You have to send output, then check connection_aborted().

> A2) After thousand days of trail and error we noticed that at
> least a content-length header has to be set by the php-script
> to "release the client". So 7) close connection to client
> does work. But again no chance to detect a client abort.
Correct: without a Content-Length the client has no idea how long the response is going to be. It will hang on until the connection is closed, or
with a chunked Transfer-Encoding (IIRC what PHP does by default) until it receives a 0-length chunk indicating the end of the response.

If you were using php-fpm (which Apache itself recommends) then you'd have access to fastcgi_finish_request().
https://cwiki.apache.org/confluence/display/HTTPD/Php-fcgid
https://www.php.net/manual/en/function.fastcgi-finish-request.php

> A3) After thousand days of trail and error we noticed that 
> after a content-length and an echo payload and a flush()
> and at least a echo {SPACE} after the flush => detects
> a client abort.
...which satisfies the "have to send output" requirement.

> Analysed with wireshark the {SPACE} fortunately
> gets lost in TCP and not sent to the client.
PHP should not be dropping the space, so presumably your web server is.

> B1) The same thing with mod_fcgid would not work.
I'm not familiar with mod_fcgid but I suspect you're running into FcgidOutputBufferSize.
https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidoutputbuffersize

If mod_fcgid is buffering output then PHP won't know about problems until the buffer gets flushed. Even then, I don't know how CGI/mod_fcgid handles client aborts.

Thank you for your quick response.


>> A1) If we do a simple echo of the payload and a flush()
>> the client waits until 9) (until the php-script has total
>> finished). A client abort, with above functions, is never
>> detected.
> You have to send output, then check connection_aborted().

I know but that is not working as expected, considering
(with configuration as mentioned above):

1) Client requests
2) Client is disconnected (closed):

3) PHP:
header('Content-length: ' . strlen(payload));
echo {payload};
flush();
connection_aborted(); => false
connection_status(); => CONNECTION_NORMAL

I did send something to the client but the
abort is not detected by PHP, if I do:

1) Client requests
2) Client is disconnected (closed):

3) PHP:
header('Content-length: ' . strlen(payload));
echo {payload};
flush();
echo " "; <= !!!
connection_aborted(); => true
connection_status(); => !CONNECTION_NORMAL


That is weird for me.


> I'm not familiar with mod_fcgid but I suspect you're running into FcgidOutputBufferSize.
> https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html#fcgidoutputbuffersize

Thank you for that one. I am new to work with mod_fcgid
(mod_fcgid got necessary because of an unstable
combination of Apache - SSL - mod_php). So I will test
that.


It is a pitty that connection handling is no straigth
forward work and not consistent across different
servers and mechanisms.


Regards,
AH

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Re-Opened". Thank you.