|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #25266 connection_status() ( see bug #22072 ).
Submitted: 2003-08-26 22:05 UTC Modified: 2004-01-28 21:33 UTC
Avg. Score:5.0 ± 0.0
Reproduced:4 of 4 (100.0%)
Same Version:2 (50.0%)
Same OS:2 (50.0%)
From: avarnals at zigg dot net Assigned:
Status: Not a bug Package: Apache2 related
PHP Version: 4CVS-2004-01-12 OS: Linux 2.4.21
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: avarnals at zigg dot net
New email:
PHP Version: OS:


 [2003-08-26 22:05 UTC] avarnals at zigg dot net
See bug #22072.

Since the above is now closed, I am creating this entry. Please accept my apologies if it would have been better added to 22072 instead.

I wasn't aware of this potential problem until I saw it in the change log for 4.3.3, so I thought I'd test it. Something is still not right. I'm using PHP 4.3.3 with Apache 2.0.47.

My first test was to see whether ignore_user_abort() works as expected. I used the very simple:

  ignore_user_abort ( false );
  while ( 1 );

This makes it easy to spot in the process list using 'top'. I tested both using PHP as a dynamically loaded Apache module and the CGI binary. The latter had safe mode enabled, the former didn't; I don't know whether this can/should make any difference. In both cases the script continued to execute after I clicked on the browser's stop button and until its PHP enforced time limit was reached.

I then went on to test ( using only the Apache module ) using the code suggested in bug report 22072:

As rather expected now, this continued to execute after I'd used the stop button.

I went on to test by modifying the code as follows:

  - I set set_time_limit(15); so it would eventually be
      aborted by this limit.
  - I made $m very large.
  - Have the result of connection_status() written to a
      file each time round the loop.
  - I removed the sleep() call.

I ran the script and used the stop button while it was running. It continued to execute until it had used 15 seconds of CPU time. Log file shows: httpd: PHP Fatal error:  Maximum execution time of 15 seconds exceeded in...
The final ( large ) output file contained all zeros and a final 2.

So, it seems that PHP correctly detects and reports the case of a timeout, but not an abort.

I noticed one other possibly odd thing while doing this. If PHP has output buffering enabled, the call to flush() results in the script being immediately shut down ( execution doesn't get to the line following flush() ). The result of connection_status() when called in exitfp() is then 1. If the flush() call is removed, the results as previously described are the same whether or not output buffering is enabled.

I hope someone can make sense of all this! Do let me know if you would like any further information.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2004-01-28 21:33 UTC]
Thank you for taking the time to write to us, but this is not
a bug. Please double-check the documentation available at and the instructions on how to report
a bug at

Apache provides a way for PHP to detect if connection was 
aborted ONLY and ONLY when PHP is either reading data from 
the user or writing back data. So, in a script such as in 
your example neither Apache 1 or 2 will abort php operation 
because there is no output.  
When you do have output but have buffering enabled, the 
abort will only 'appear' when the PHP buffer is full and is 
being sent to Apache. At this point Apache will tell PHP 
that the connection was aborted and PHP will stop 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Mon Jul 15 17:01:30 2024 UTC