I have the same issue, but in nginx server

How did you identify it doesn't work?

I mean, could you give us a more specific description?

btw: I can not reproduce this with nginx

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');
    }
}
?>

you mean IIS or nginx?  thanks :)

Microsoft-IIS/7.5. Best regards, Lars.

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

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

A pull request or patch would be much appreciated, I'm sure. :)

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.

Hello, i'm still having this issue even on newer PHP versions