php.net |  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
Votes:4
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
 [2003-08-26 22:05 UTC] avarnals at zigg dot net
Description:
------------
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:

  http://www.mpfreescene.com/test/?option=source

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.



Patches

Add a Patch

Pull Requests

Add a Pull Request

History

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

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 
execution. 
 
PHP Copyright © 2001-2020 The PHP Group
All rights reserved.
Last updated: Sun Nov 29 08:01:23 2020 UTC