php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #41672 connection_status/connection_abort issue
Submitted: 2007-06-12 19:58 UTC Modified: 2007-06-25 19:00 UTC
From: mfshop at comcast dot net Assigned:
Status: Not a bug Package: Unknown/Other Function
PHP Version: 4CVS-2007-06-12 (snap) OS: Windows 2003 Server
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: mfshop at comcast dot net
New email:
PHP Version: OS:

 

 [2007-06-12 19:58 UTC] mfshop at comcast dot net 
Description:
------------
Running IIS6 on Windows 2003 Server and the latest PHP 4.4.8-dev from snaps.php.net.  The problem also exists on PHP 4.4.7.  Running as an ISAPI module.

connection_status() and connection_abort() always return 0.  Setting ignore_user_abort(true) or ignore_user_abort(false) also seems to have no effect.  In the example script below, changing ignore_user_abort(true) to ignore_user_abort(false) produces the exact same results.

This seems to be similar or the same as Bug #30301 but for a PHP 4 instead (also that bug report seems to have been ignored/closed due to no feedback status).

Reproduce code:
---------------
function script_end()
{
	global $fd;
	$clientstate = connection_aborted();
	$clientstate2 = connection_status();
	fwrite($fd, "Final: $clientstate, $clientstate2\n");
	fclose($fd);
	exit();
}

$fd=fopen("test.txt", "w"); // Change filename/dir to somewhere where the IIS User has proper permissions as necessary.
register_shutdown_function("script_end");
ignore_user_abort(true);
for ($i=0; $i<20; $i++)  {
	echo "$i<br>\n";
	Flush();
	$clientstate = connection_aborted();
	$clientstate2 = connection_status();
	fwrite($fd, "$i: $clientstate, $clientstate2\n");
	sleep(1);
}

Expected result:
----------------
Start loading the page and then hit the stop button before it finishes.  Look at the test.txt afterwards.  We expect to see the values returned by connection_aborted() and connection_status() to change/be something other than 0 or, depending on how ignore_user_abort() is set, we may expect to see the count not reach 20 (i.e. the script detecting user abort and terminating the script).

Actual result:
--------------
The test.txt file will always end up looking like so:

0: 0, 0
1: 0, 0
2: 0, 0
3: 0, 0
4: 0, 0
5: 0, 0
6: 0, 0
7: 0, 0
8: 0, 0
9: 0, 0
10: 0, 0
11: 0, 0
12: 0, 0
13: 0, 0
14: 0, 0
15: 0, 0
16: 0, 0
17: 0, 0
18: 0, 0
19: 0, 0
Final: 0, 0

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2007-06-12 20:24 UTC] mfshop at comcast dot net 
As a quick addendum.  If I set the loop size in the above example code to 60 then the results are the same except that the final line reads as I would expact: "Final: 1, 1".  Note that this seems to be related to time and not the amount of data sent as keeping the loop count at 20 but attempting to echo out a lot more text to the browser repeats the original results.  This seems to indicate that connection_status() and connection_aborted() at least return the proper values when called within a registered shutdown function AND enough time has passed.  However, the functions still return 0 outside of the shutdown function and setting ignore_user_abort() one way or another has no effect.  In other words, the functions still can't be used to detect a browser abort and stop execution of the script at that point (after performing any required cleanup in the registered shutdown function).
 [2007-06-12 23:01 UTC] mfshop at comcast dot net 
More information:
Even though output buffer isn't on, including an ob_flush(); before the flush(); starts to send the data to the browser right away.  If the loop is long enough, approximately 30-40 seconds after hitting the stop button it will finally return 1 for connection_status and connection_abort (and setting ignore_user_abort(false) also seems to work at that point).  This only happens when doing BOTH ob_flush() AND flush().  Using flush() by itself, it takes considerably longer but eventually works (though it takes around 60-70 seconds, which may explain the behavior in my previous comment).

I am curious about the behavior of the ob_flush(); speeding things up (output buffering isn't on...).  In any case, it still seems like a long time to wait before detecting a closed/aborted connection.
 [2007-06-25 19:00 UTC] tony2001@php.net 
connection_aborted() & connection_status() rely on write operation, which SHOULD fail if the request was cancelled.
Unfortunately, it depends on your web-server. so it may or may not work depending on its behaviour.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat Nov 29 22:00:01 2025 UTC