Bug->Doc #60586 [Ver]: ignore_user_abort=true has no effect on IIS with FastCGI
[email protected] Mon, 13 Dec 2021 18:01:57 +0000
| Newsgroups | php.doc.bugs |
|---|---|
| Message-ID | <[email protected]> |
Edit report at https://bugs.php.net/bug.php?id=60586&edit=1 ID: 60586 Updated by: [email protected] Reported by: sauvant at aspera dot com Summary: ignore_user_abort=true has no effect on IIS with FastCGI Status: Verified -Type: Bug +Type: Documentation Problem Package: IIS related Operating System: Windows Server 2008 R2 PHP Version: 7.4 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: > 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. Previous Comments: ------------------------------------------------------------------------ [2017-08-23 20:46:50] gudang at gmail dot com Hello, i'm still having this issue even on newer PHP versions ------------------------------------------------------------------------ [2013-09-11 21:41:54] 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. ------------------------------------------------------------------------ [2012-12-07 01:27:57] [email protected] A pull request or patch would be much appreciated, I'm sure. :) ------------------------------------------------------------------------ [2012-12-06 12:43:25] 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-07-10 12:32:43] 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 ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=60586 -- Edit this bug report at https://bugs.php.net/bug.php?id=60586&edit=1