php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Doc Bug #60586 ignore_user_abort=true has no effect on IIS with FastCGI
Submitted: 2011-12-21 15:07 UTC Modified: 2021-12-13 18:07 UTC
Votes:44
Avg. Score:4.5 ± 1.0
Reproduced:34 of 38 (89.5%)
Same Version:20 (58.8%)
Same OS:22 (64.7%)
From: sauvant at aspera dot com Assigned:
Status: Verified Package: IIS related
PHP Version: 7.4 OS: Windows Server 2008 R2
Private report: No CVE-ID: None
Have you experienced this issue?
Rate the importance of this bug to you:

 [2011-12-21 15:07 UTC] sauvant at aspera dot com
Description:
------------
ignore_user_abort=true does not to work in an IIS FastCGI environment: The process is stopped when sending output after the browser was closed.

Expected result:
----------------
The process should continue to run, even with the browser window being closed and the script sending output.

Actual result:
--------------
The process stops.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2012-06-25 02:51 UTC] futbolsalas15 at gmail dot com
I have the same issue, but in nginx server
 [2012-06-25 05:27 UTC] laruence@php.net
How did you identify it doesn't work?

I mean, could you give us a more specific description?
 [2012-06-25 05:29 UTC] laruence@php.net
btw: I can not reproduce this with nginx
 [2012-06-25 05:29 UTC] laruence@php.net
-Status: Open +Status: Feedback
 [2012-06-25 14:45 UTC] lars_teuber at gmx dot de
Please find reproduce script below. The script stops whenever there is output send to a browser that is no longer listening. It will continue to run until you send anything. Best regards, Lars.

<?php
# reproduce for https://bugs.php.net/bug.php?id=60586
ignore_user_abort(true);
$path = sys_get_temp_dir() . '\\ignore_user_abort_' . date('Ymd_His', time());
echo $path;
flush();

$seconds = 30;
$time = time();
$i = 0;
while (time() - $time < $seconds) {
    echo '. ';
    flush();
    $i++;
}

write_file($path, 'finished (' . $i . ' iterations)');

function write_file($path, $message)
{
    $handle = fopen($path, 'wb');
    if (!$handle) {
        throw new Exception('fopen() failed');
    }
    if (fwrite($handle, $message) === false) {
        fclose($handle);
        throw new Exception('fwrite() failed');
    }
    if (!fclose($handle)) {
        throw new Exception('fclose() failed');
    }
}
?>
 [2012-06-25 14:54 UTC] laruence@php.net
you mean IIS or nginx?  thanks :)
 [2012-06-25 15:00 UTC] lars_teuber at gmx dot de
Microsoft-IIS/7.5. Best regards, Lars.
 [2012-07-10 12:32 UTC] sauvant at aspera dot com
There is a thread at the IIS forum, too: http://forums.iis.net/t/1190270.aspx
No feedback at all :-(

Is the issue described PHP or IIS related? 
Any opinions?
Anybody able to reproduce?

Best regards
Keith
 [2012-12-06 12:43 UTC] rainer at dueckerhoff dot de
This bug still persists in the latest 5.3 version after about a year of this bug 
report.
Any chance that it could be fixed or any explanation on why it doesn't work with 
IIS but with Apache (and thus cannot be fixed)? Or at least a workaround?

Cheers,
Rainer
 [2012-12-07 01:27 UTC] aharvey@php.net
A pull request or patch would be much appreciated, I'm sure. :)
 [2012-12-07 01:27 UTC] aharvey@php.net
-Status: Feedback +Status: Open
 [2013-09-11 21:41 UTC] curibe at microsoft dot com
We investigated this issue from an IIS perspective by reproducing the issue using the sample page listed in this bug and setting ignore_user_abort=true we saw the following behavior:
Shortly after the browser disconnects, we get a failure on the named pipe connection to the php-cgi.exe process indicating that pipe was disconnected.  That takes us to a path that terminates that process.  We do this because, once the FastCGI process has disconnected, we can no longer manage it.  To prevent it from consuming system resources, we terminate it.  This is all by design, and it may be different on other web servers if they allow processes to run after they’ve disconnected.
We also verified that we are not closing the pipe on our side prior to terminating the process.  It is definitely getting closed on the FastCGI process side.
 [2017-08-23 20:46 UTC] gudang at gmail dot com
Hello, i'm still having this issue even on newer PHP versions
 [2021-09-28 15:09 UTC] cmb@php.net
-Status: Open +Status: Verified -Assigned To: +Assigned To: cmb
 [2021-09-28 15:09 UTC] cmb@php.net
-PHP Version: 5.3.8 +PHP Version: 7.4
 [2021-10-05 12:36 UTC] cmb@php.net
-Assigned To: cmb +Assigned To:
 [2021-12-13 18:01 UTC] cmb@php.net
-Type: Bug +Type: Documentation Problem -Assigned To: +Assigned To: cmb
 [2021-12-13 18:01 UTC] cmb@php.net
> We also verified that we are not closing the pipe on our side
> prior to terminating the process.  It is definitely getting closed
> on the FastCGI process side.

No, PHP does not close the pipe; at least current versions do not,
and I don't think this has changed over the years.  Actually, PHP
detects an aborted connection because writing to the pipe failed,
not by receiving an FCGI_ABORT_REQUEST record (PHP does not read
from the pipe while processing a request, after the initial
reads).  So apparently, the server sends an FCGI_ABORT_REQUEST
record, but since PHP does not respond (it is still busy executing
the request), IIS kills the unresponsive process.

Now, consider if PHP would actually respond to FCGI_ABORT_REQUEST
records by sending an FCGI_END_REQUEST record.  That would imply
that PHP terminates its processing, so ignore_user_abort would not
work in that case, either.

So, it comes down to ignore_user_abort being very special wrt. the
FCGI protocol at least, and there is nothing we can fix.  So we
should document that ignore_user_abort is not supported for all
SAPIs/Webservers, and might consider to drop this "feature"
altogether.  The clean way to handle such needs, would be to use
some kind of message queue.
 [2021-12-13 18:07 UTC] cmb@php.net
-Assigned To: cmb +Assigned To:
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Fri Jul 01 16:05:45 2022 UTC