Bug #48280 [Com]: http stream timeout is doubled
Edit report at http://bugs.php.net/bug.php?id=48280edit=1
ID: 48280
Comment by: james dot mk dot green at gmail dot com
Reported by:php at bouchery dot fr
Summary:http stream timeout is doubled
Status: Open
Type: Bug
Package:Streams related
Operating System: Windows XP SP2
PHP Version:5.2SVN-2009-12-22
Block user comment: N
Private report: N
New Comment:
This remains a bug in 5.3.5 on Linux. Setting the timeout to 2 results
in a 4s timeout, setting it to 4 results in an 8s timeout.
Previous Comments:
[2009-12-22 10:51:29] php at bouchery dot fr
No, result is already :
Code #1: Duration = 4
Code #2: Duration = 6
Code #3: Duration = 8
[2009-05-20 13:29:13] php at bouchery dot fr
I did it on localhost and on a remote machine:
sleep-flush.php
?php
echo 'start';
flush();
sleep(20);
echo 'sleep';
?
sleep.php
?php
sleep(20);
echo 'sleep';
?
[2009-05-20 12:59:15] j...@php.net
And where are the sources for those server side scripts?
[2009-05-14 11:59:39] php at bouchery dot fr
Description:
When I perform a HTTP timeout using stream_context_create,
stream_set_timeout or default_socket_timeout, timeout is doubled.
I did it on :
- Windows XP SP2 + PHP-Cli 5.1.6
- Windows XP SP2 + PHP-Cli 5.2.9-2
- Debian 5 + PHP 5.2.0-8+etch13 (cli)
Reproduce code:
---
?php
$time = time();
// sleep-flush.php flush a text before sleeping 20 seconds
$f = @fopen('http://localhost/sleep-flush.php', 'r');
if( $f !== false ) {
stream_set_timeout($f, 2);
$content = stream_get_contents( $f );
fclose($f);
}
echo 'Code #1: Duration = ', (time() - $time), \n;
$context = stream_context_create(array('http' = array('timeout' =
3)));
$time = time();
// sleep do not flush text before sleeping 20 seconds
$f = @fopen('http://localhost/sleep.php', 'r', false, $context);
if( $f !== false ) {
$content = stream_get_contents( $f );
fclose($f);
}
echo 'Code #2: Duration = ', (time() - $time), \n;
ini_set('default_socket_timeout', '4');
$time = time();
// sleep do not flush text before sleeping 20 seconds
$f = @fopen('http://localhost/sleep.php', 'r');
if( $f !== false ) {
$content = stream_get_contents( $f );
fclose($f);
}
echo 'Code #3: Duration = ', (time() - $time), \n;
?
Expected result:
Code #1: Duration = 2
Code #2: Duration = 3
Code #3: Duration = 4
Actual result:
--
Code #1: Duration = 4
Code #2: Duration = 6
Code #3: Duration = 8
--
Edit this bug report at http://bugs.php.net/bug.php?id=48280edit=1
[PHP-BUG] Bug #54062 [NEW]: PHP does not notice user abort
From:
Operating system: Linux/Windows
PHP version: Irrelevant
Package: Network related
Bug Type: Bug
Bug description:PHP does not notice user abort
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called should
the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function which
says the user is still connected, despite my pressing the browser stop
button immediately after placing the request.
I have tested this on Windows using Lighttpd with PHP 5.2, and on Ubuntu
with Apache preforking PHP 5.3. Both exhibit the same behaviour.
These tests were conducted with ignore_user_abort(true) and (false) - no
difference observed so I removed it.
Test script:
---
?php
syslog(LOG_DEBUG, 'Connection opened');
register_shutdown_function('shutdown');
$usleep = 200;
for ($i=0; $i 100; $i++) {
$str[$i] = '';
for ($x=0; $x 1000; $x++) {
$str[$i] .= 'flubber';
}
}
if (isset($_REQUEST['usleep'])) {
$usleep = (int) $_REQUEST['usleep'];
}
usleep($usleep);
syslog(LOG_DEBUG, 'Completed usleep()');
echo Thanks for waiting\n;
print_r($str);
ob_end_flush();
syslog(LOG_DEBUG, 'ob_end_flush() called');
flush();
syslog(LOG_DEBUG, 'Have flushed()');
// We get to this part regardless of having already pressed STOP
function shutdown()
{
echo Thanks for waiting\n;
flush();
syslog(LOG_DEBUG, 'Echo completed');
//sleep(1);
syslog(LOG_DEBUG, 'Have slept');
syslog(LOG_DEBUG, 'Shutdown detected.');
syslog(LOG_DEBUG, The result of connection_status() is: .
connection_status());
// The above is almost always 0
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
// This almost always happens!
syslog(LOG_DEBUG, 'The connection remains');
}
}
Expected result:
syslog entries should stop when PHP writes to the client socket and notes
that the client has sent an abort signal. Then, the shutdown function
should show that the connection_status() is no longer 0, and that the
connection_aborted() method returns true.
Actual result:
--
syslog entries continue to Have flushed(), then show that The result of
connection_status() is: 0. and The connection remains.
This should not be the case. Perhaps Apache is not sending the appropriate
signal, yet neither is Lighttpd..?
--
Edit bug report at http://bugs.php.net/bug.php?id=54062edit=1
--
Try a snapshot (PHP 5.2):
http://bugs.php.net/fix.php?id=54062r=trysnapshot52
Try a snapshot (PHP 5.3):
http://bugs.php.net/fix.php?id=54062r=trysnapshot53
Try a snapshot (trunk):
http://bugs.php.net/fix.php?id=54062r=trysnapshottrunk
Fixed in SVN:
http://bugs.php.net/fix.php?id=54062r=fixed
Fixed in SVN and need be documented:
http://bugs.php.net/fix.php?id=54062r=needdocs
Fixed in release:
http://bugs.php.net/fix.php?id=54062r=alreadyfixed
Need backtrace:
http://bugs.php.net/fix.php?id=54062r=needtrace
Need Reproduce Script:
http://bugs.php.net/fix.php?id=54062r=needscript
Try newer version:
http://bugs.php.net/fix.php?id=54062r=oldversion
Not developer issue:
http://bugs.php.net/fix.php?id=54062r=support
Expected behavior:
http://bugs.php.net/fix.php?id=54062r=notwrong
Not enough info:
http://bugs.php.net/fix.php?id=54062r=notenoughinfo
Submitted twice:
http://bugs.php.net/fix.php?id=54062r=submittedtwice
register_globals:
http://bugs.php.net/fix.php?id=54062r=globals
PHP 4 support discontinued: http://bugs.php.net/fix.php?id=54062r=php4
Daylight Savings:http://bugs.php.net/fix.php?id=54062r=dst
IIS Stability:
http://bugs.php.net/fix.php?id=54062r=isapi
Install GNU Sed:
http://bugs.php.net/fix.php?id=54062r=gnused
Floating point limitations:
http://bugs.php.net/fix.php?id=54062r=float
No Zend Extensions:
http://bugs.php.net/fix.php?id=54062r=nozend
MySQL Configuration Error:
http://bugs.php.net/fix.php?id=54062r=mysqlcfg
Bug #54062 [Com]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Comment by: james dot mk dot green at gmail dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
The script attached is a test case. The real script that triggered
this report does not use sleep or similar. And yes, on two-three
attempts out of several dozen I have seen a client has aborted message.
However, statistically this is beyond unreliable.
Further to the original report I have spoken in ##php on Freenode and
tried their suggestions without any luck.
The real script does quite a lot of backend processing while a
software client waits. If the client then times out waiting, the server
script continues to send back the data processed and says that the
client remains connected at the very end (within the shutdown callback).
This led me to my testing of connection handling and this test case.
Previous Comments:
[2011-02-21 16:19:04] ceo at l-i-e dot com
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit to really really really END
the script, bypassing any other shutdown functions.
[2011-02-21 15:44:03] james dot mk dot green at gmail dot com
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called
should the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function
which says the user is still connected, despite my pressing the browser
stop button immediately after placing the request.
I have tested this on Windows using Lighttpd with PHP 5.2, and on Ubuntu
with Apache preforking PHP 5.3. Both exhibit the same behaviour.
These tests were conducted with ignore_user_abort(true) and (false) - no
difference observed so I removed it.
Test script:
---
?php
syslog(LOG_DEBUG, 'Connection opened');
register_shutdown_function('shutdown');
$usleep = 200;
for ($i=0; $i 100; $i++) {
$str[$i] = '';
for ($x=0; $x 1000; $x++) {
$str[$i] .= 'flubber';
}
}
if (isset($_REQUEST['usleep'])) {
$usleep = (int) $_REQUEST['usleep'];
}
usleep($usleep);
syslog(LOG_DEBUG, 'Completed usleep()');
echo Thanks for waiting\n;
print_r($str);
ob_end_flush();
syslog(LOG_DEBUG, 'ob_end_flush() called');
flush();
syslog(LOG_DEBUG, 'Have flushed()');
// We get to this part regardless of having already pressed STOP
function shutdown()
{
echo Thanks for waiting\n;
flush();
syslog(LOG_DEBUG, 'Echo completed');
//sleep(1);
syslog(LOG_DEBUG, 'Have slept');
syslog(LOG_DEBUG, 'Shutdown detected.');
syslog(LOG_DEBUG, The result of connection_status() is: .
connection_status());
// The above is almost always 0
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
// This almost always happens!
syslog(LOG_DEBUG, 'The connection remains');
}
}
Expected result:
syslog entries should stop when PHP writes to the client socket and
notes that the client has sent an abort signal. Then, the shutdown
function should show that the connection_status() is no longer 0, and
that the connection_aborted() method returns true.
Actual result:
--
syslog entries continue to Have flushed(), then show that The result of
connection_status() is: 0. and The connection remains.
This should not be the case. Perhaps Apache is not sending the
appropriate signal, yet neither is Lighttpd..?
--
Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
Bug #54062 [Com]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Comment by: james dot mk dot green at gmail dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
Feb 21 16:28:57 blofeld apache2: The connection remains
Feb 21 16:29:41 blofeld apache2: Connection opened
Feb 21 16:29:43 blofeld apache2: Completed usleep()
Feb 21 16:29:43 blofeld apache2: ob_end_flush() called
Feb 21 16:29:43 blofeld apache2: Have flushed()
Feb 21 16:29:43 blofeld apache2: Echo completed
Feb 21 16:29:43 blofeld apache2: Have slept
Feb 21 16:29:43 blofeld apache2: Shutdown detected.
Feb 21 16:29:43 blofeld apache2: The result of connection_status() is:
0
Feb 21 16:29:43 blofeld apache2: The connection remains
That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache
2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10.
All I do is type in the url of my disconnect.php, hit enter then
immediately hit the stop button.
Previous Comments:
[2011-02-21 17:11:06] cataphr...@php.net
Works fine here:
Normal circumstances:
Feb 21 16:06:33 damnation apache2: Connection opened
Feb 21 16:06:35 damnation apache2: Completed usleep()
Feb 21 16:06:35 damnation apache2: ob_end_flush() called
Feb 21 16:06:35 damnation apache2: Have flushed()
Feb 21 16:06:35 damnation apache2: Echo completed
Feb 21 16:06:35 damnation apache2: Have slept
Feb 21 16:06:35 damnation apache2: Shutdown detected.
Feb 21 16:06:35 damnation apache2: The result of connection_status() is:
0
Feb 21 16:06:35 damnation apache2: The connection remains
Stop button:
Feb 21 16:06:44 damnation apache2: Connection opened
Feb 21 16:06:46 damnation apache2: Completed usleep()
Feb 21 16:06:46 damnation apache2: ob_end_flush() called
Feb 21 16:06:46 damnation apache2: Have flushed()
ignore_user_abort(true) + Stop button:
Feb 21 16:07:59 damnation apache2: Connection opened
Feb 21 16:08:01 damnation apache2: Completed usleep()
Feb 21 16:08:01 damnation apache2: ob_end_flush() called
Feb 21 16:08:01 damnation apache2: Have flushed()
Feb 21 16:08:01 damnation apache2: Echo completed
Feb 21 16:08:01 damnation apache2: Have slept
Feb 21 16:08:01 damnation apache2: Shutdown detected.
Feb 21 16:08:01 damnation apache2: The result of connection_status() is:
1
Feb 21 16:08:01 damnation apache2: The connection has aborted
(Ubuntu 10.10, PHP 5.3.3-1ubuntu9.3, Apache/2.2.16)
[2011-02-21 16:50:09] james dot mk dot green at gmail dot com
The script attached is a test case. The real script that triggered
this report does not use sleep or similar. And yes, on two-three
attempts out of several dozen I have seen a client has aborted message.
However, statistically this is beyond unreliable.
Further to the original report I have spoken in ##php on Freenode and
tried their suggestions without any luck.
The real script does quite a lot of backend processing while a
software client waits. If the client then times out waiting, the server
script continues to send back the data processed and says that the
client remains connected at the very end (within the shutdown callback).
This led me to my testing of connection handling and this test case.
[2011-02-21 16:19:04] ceo at l-i-e dot com
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit to really really really END
the script, bypassing any other shutdown functions.
[2011-02-21 15:44:03] james dot mk dot green at gmail dot com
Description:
Referencing http://php.net/manual/en/features.connection-handling.php
I understand that providing PHP is writing to or reading from the web
server connection, a registered shutdown function should be called
should the client abort.
I have never known this to be the case.
I attach a simple script. It attempts to sleep then write back to the
client. It has a registered shutdown function that checks
connection_status() and connection_aborted(). According to my syslog
however, the full script executes followed by the shutdown function
which says
Bug #54062 [Com]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
Comment by: james dot mk dot green at gmail dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
Status: Feedback
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
johannes, it's been tested on a Windows server too (same behaviour).
Besides, cataphract seems to be using Ubuntu's PHP package too.
Perhaps it's something to do with web server configuration? I'm using
CGI on Windows, and mod_php on Ubuntu (Apache Prefork MPM). What might
cause this behaviour?
Previous Comments:
[2011-02-21 17:39:22] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please use vanilla PHP from php.net. We have no idea what kind of
patches Ubuntu applies and what they might break.
[2011-02-21 17:31:59] james dot mk dot green at gmail dot com
Feb 21 16:28:57 blofeld apache2: The connection remains
Feb 21 16:29:41 blofeld apache2: Connection opened
Feb 21 16:29:43 blofeld apache2: Completed usleep()
Feb 21 16:29:43 blofeld apache2: ob_end_flush() called
Feb 21 16:29:43 blofeld apache2: Have flushed()
Feb 21 16:29:43 blofeld apache2: Echo completed
Feb 21 16:29:43 blofeld apache2: Have slept
Feb 21 16:29:43 blofeld apache2: Shutdown detected.
Feb 21 16:29:43 blofeld apache2: The result of connection_status() is:
0
Feb 21 16:29:43 blofeld apache2: The connection remains
That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache
2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10.
All I do is type in the url of my disconnect.php, hit enter then
immediately hit the stop button.
[2011-02-21 17:11:06] cataphr...@php.net
Works fine here:
Normal circumstances:
Feb 21 16:06:33 damnation apache2: Connection opened
Feb 21 16:06:35 damnation apache2: Completed usleep()
Feb 21 16:06:35 damnation apache2: ob_end_flush() called
Feb 21 16:06:35 damnation apache2: Have flushed()
Feb 21 16:06:35 damnation apache2: Echo completed
Feb 21 16:06:35 damnation apache2: Have slept
Feb 21 16:06:35 damnation apache2: Shutdown detected.
Feb 21 16:06:35 damnation apache2: The result of connection_status() is:
0
Feb 21 16:06:35 damnation apache2: The connection remains
Stop button:
Feb 21 16:06:44 damnation apache2: Connection opened
Feb 21 16:06:46 damnation apache2: Completed usleep()
Feb 21 16:06:46 damnation apache2: ob_end_flush() called
Feb 21 16:06:46 damnation apache2: Have flushed()
ignore_user_abort(true) + Stop button:
Feb 21 16:07:59 damnation apache2: Connection opened
Feb 21 16:08:01 damnation apache2: Completed usleep()
Feb 21 16:08:01 damnation apache2: ob_end_flush() called
Feb 21 16:08:01 damnation apache2: Have flushed()
Feb 21 16:08:01 damnation apache2: Echo completed
Feb 21 16:08:01 damnation apache2: Have slept
Feb 21 16:08:01 damnation apache2: Shutdown detected.
Feb 21 16:08:01 damnation apache2: The result of connection_status() is:
1
Feb 21 16:08:01 damnation apache2: The connection has aborted
(Ubuntu 10.10, PHP 5.3.3-1ubuntu9.3, Apache/2.2.16)
[2011-02-21 16:50:09] james dot mk dot green at gmail dot com
The script attached is a test case. The real script that triggered
this report does not use sleep or similar. And yes, on two-three
attempts out of several dozen I have seen a client has aborted message.
However, statistically this is beyond unreliable.
Further to the original report I have spoken in ##php on Freenode and
tried their suggestions without any luck.
The real script does quite a lot of backend processing while a
software client waits. If the client then times out waiting, the server
script continues to send back the data processed and says that the
client remains connected at the very end (within the shutdown callback).
This led me to my testing of connection handling and this test case.
[2011-02-21 16:19:04] ceo at l-i-e dot com
I have never known this to be the case.
...
$usleep = 200;
...
usleep($usleep);
...
if (connection_aborted()) {
// This almost never happens!
syslog(LOG_DEBUG, 'The connection has aborted');
} else {
almost never or never?
Not really the same...
Not sure PHP even processes and abort in the middle of usleep.
2 seconds is a long time in a normal request.
Try shorter usleep.
And when you *do* get an abort, call exit
Bug #54062 [Fbk-Opn]: PHP does not notice user abort
Edit report at http://bugs.php.net/bug.php?id=54062edit=1
ID: 54062
User updated by:james dot mk dot green at gmail dot com
Reported by:james dot mk dot green at gmail dot com
Summary:PHP does not notice user abort
-Status: Feedback
+Status: Open
Type: Bug
Package:Network related
Operating System: Linux/Windows
PHP Version:Irrelevant
Block user comment: N
Private report: N
New Comment:
As unlikely as it sounds this may be an issue within Firefox.
I pasted the code from Rasmus onto the web server next door to mine.
Fired it up
in Firefox and PHP detected the user abort. Repeated my script but again
it did
not work. Slowly I worked the code from Rasmus directly in to my script
but
still no joy. At this point all that was different was the name of the
shutdown
function. Then tried using wget as the client and both scripts work.
Repeated
Rasmus' script from Firefox and it no longer detected user abort.
So we have a bug within the client - as far as I can tell. I am least
happy I
can work with this, thanks for all the tests and sorry for wasting
people's
time!
Previous Comments:
[2011-02-21 19:40:41] ras...@php.net
By the way, why so complicated a test?
Try the simple case:
?php
ignore_user_abort(false);
for($i=0;$i1000;$i++) {
sleep(1);
$str = Line $i\n;
echo $str;
flush();
file_put_contents(/tmp/heartbeat.log, $str, FILE_APPEND);
}
Things that might get in the way of this working for you would be if you
have
some sort of reverse proxy cache in front of your web server. Like a
Cloudflare,
for example. Or your own setup. You could also have multiple levels of
output
buffering going on. You could check that case with an ob_get_level()
call.
[2011-02-21 19:21:05] ras...@php.net
Works fine for me on a Debian box running mod_php with Apache prefork,
and a
Centos box running nginx and php-fpm.
[2011-02-21 17:42:42] james dot mk dot green at gmail dot com
johannes, it's been tested on a Windows server too (same behaviour).
Besides, cataphract seems to be using Ubuntu's PHP package too.
Perhaps it's something to do with web server configuration? I'm using
CGI on Windows, and mod_php on Ubuntu (Apache Prefork MPM). What might
cause this behaviour?
[2011-02-21 17:39:22] johan...@php.net
Please try using this snapshot:
http://snaps.php.net/php5.3-latest.tar.gz
For Windows:
http://windows.php.net/snapshots/
Please use vanilla PHP from php.net. We have no idea what kind of
patches Ubuntu applies and what they might break.
[2011-02-21 17:31:59] james dot mk dot green at gmail dot com
Feb 21 16:28:57 blofeld apache2: The connection remains
Feb 21 16:29:41 blofeld apache2: Connection opened
Feb 21 16:29:43 blofeld apache2: Completed usleep()
Feb 21 16:29:43 blofeld apache2: ob_end_flush() called
Feb 21 16:29:43 blofeld apache2: Have flushed()
Feb 21 16:29:43 blofeld apache2: Echo completed
Feb 21 16:29:43 blofeld apache2: Have slept
Feb 21 16:29:43 blofeld apache2: Shutdown detected.
Feb 21 16:29:43 blofeld apache2: The result of connection_status() is:
0
Feb 21 16:29:43 blofeld apache2: The connection remains
That's what I get using Firefox with PHP 5.3.3-1ubuntu9.3 on apache
2.2.16-1ubuntu3.1 using ubuntu Ubuntu 10.10.
All I do is type in the url of my disconnect.php, hit enter then
immediately hit the stop button.
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
http://bugs.php.net/bug.php?id=54062
--
Edit this bug report at http://bugs.php.net/bug.php?id=54062edit=1
