Edit report at http://bugs.php.net/bug.php?id=54062&edit=1
ID: 54062
Updated by: ras...@php.net
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:
Works fine for me on a Debian box running mod_php with Apache prefork,
and a
Centos box running nginx and php-fpm.
Previous Comments:
[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.
[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.
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=54062&edit=1
