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 back! If you're the original bug submitter, here's where you can edit the bug or add additional notes.
If you forgot your password, you can retrieve your password here.
Password:
Status:
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