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

> 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.