php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60586 ignore_user_abort=true has no effect on IIS with FastCGI
Submitted: 2011-12-21 15:07 UTC Modified: 2012-12-07 01:27 UTC
Votes:39
Avg. Score:4.5 ± 1.0
Reproduced:31 of 34 (91.2%)
Same Version:19 (61.3%)
Same OS:21 (67.7%)
From: sauvant at aspera dot com Assigned:
Status: Open Package: IIS related
PHP Version: 5.3.8 OS: Windows Server 2008 R2
Private report: No CVE-ID:
View Add Comment Developer Edit
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
45 - 37 = ?
Subscribe to this entry?

 
 [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
 
PHP Copyright © 2001-2017 The PHP Group
All rights reserved.
Last updated: Tue Aug 29 15:01:52 2017 UTC