flush() halts script after fastcgi_finish_request()

[MyNameIsRoman]

Description

FPM/FastCGI Apache 2.4.54

<?php

fastcgi_finish_request();
flush(); // script halts after calling this function somewhere or here
file_put_contents(__DIR__.'/test.txt', microtime(TRUE), FILE_APPEND | LOCK_EX);
?>

PHP Version

PHP 7.4.30

Operating System

Linux 3.10.0-1062.12.1.el7.x86_64 Apache 2.4.54

[cmb69]

PHP 7.4.30

PHP 7.4 is no longer actively supported. Does this also happen with PHP 8?

[MyNameIsRoman]

sorry, my hosting support only 7.4.30 version, if someone else can check this bug

[KapitanOczywisty]

You're missing ignore_user_abort(true);, without that any data sent to the browser after closing connection causes script to end.

PHP will not detect that the user has aborted the connection until an attempt is made to send information to the client. Simply using an echo statement does not guarantee that information is sent, see flush().

• https://www.php.net/manual/en/function.ignore-user-abort

I feel there could be a notice about ignore_user_abort in the manual for fastcgi_finish_request.

[MyNameIsRoman]

Ok, but error_get_last() is NULL in shutdown function (script execution fails, and no errors, in logs also). I think it is very important to report that the execution was aborted like in the case of "max_execution_time". Many young developers will spent many time to find why scripts halts.

<?php
register_shutdown_function('errHandler');

function errHandler()
{
file_put_contents(__DIR__.'/shutdown.txt', var_export(error_get_last()), FILE_APPEND | LOCK_EX);
}

fastcgi_finish_request();
flush();
file_put_contents(__DIR__.'/test.txt', microtime(TRUE), FILE_APPEND | LOCK_EX);
?>

[bukka]

I will change this to feature as adding a new error would not be added as a bug fix. It might need more consideration if it is actually right thing to do. In any case I don't see this as a bug. And I agree the the docs should get also updated.

[bukka]

Actually I think it needs more investigating to see if there is potentially some bug or unexpected behaviour so will leave it as a bug. The proper investigation will show what this should be... :)

[bukka]

After thinking about this, it should be handled a feature. I agree it might be worth to add a notice for this and also update docs.

[kkmuffme]

Adding a notice when something is output after the connection terminated, similar to what already exists when using header() after headers are already sent probably makes most sense here.