php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

Bug #64644 Client-side abortion should be detected regardless of sending output
Submitted: 2013-04-13 18:55 UTC Modified: 2013-04-14 01:35 UTC
Votes:1
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:1 (100.0%)
Same OS:1 (100.0%)
From: matteosistisette at gmail dot com Assigned:
Status: Not a bug Package: *General Issues
PHP Version: 5.3.24 OS: Linux
Private report: No CVE-ID: None
View Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
If you reported this bug, you can edit this bug over here.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: matteosistisette at gmail dot com
New email:
PHP Version: OS:

 

 [2013-04-13 18:55 UTC] matteosistisette at gmail dot com 
Description:
------------
PHP Version 5.3.3-7+squeeze14 (for some reason it is not in the dropdown)

I have read and deeply understood these: 
http://www.php.net/manual/en/features.connection-handling.php 
http://www.php.net/manual/en/function.register-shutdown-function.php

However, neither in 5.1.6 nor in 5.3.3 do things work even close to described 
there:

- connection_status() always return true, even after the client has closed the 
connection.
- execution of the script keeps going on after the client has closed the 
connection, even though ignore_user_abort is 0
- a function registered with register_shutdown_function() is not run until the 
script reaches ends. The script is NOT interrupted (and hence the function not 
called) when the client aborts the connection.

So basically PHP just doesn't detect the client's disconnection AT ALL.

Note that this is NOT as if ignore_user_abort was set to 1: if that was the case 
then connection_status() would return 1 even though the script would keep 
running and the shutdown function would not be called until the end. That is not 
the case.

ini_get("ignore_user_abort") returns 0, as expected.

I'm observing this both on PHP 5.1.6 on CentOS 5.9, and on PHP 5.3 on Debian 
6.0.3 


Steps to reproduce: 
- put the script below in the public_html folder
- tail -f /path/to/error_log
- visit the url of the php script from a browser or client
- hit the stop button in the browser or abort connection from the client
- watch the error_log




Test script:
---------------
<?php

function myShutdown() {
	error_log("myShutdown ".connection_status()." ".ini_get("ignore_user_abort"));
}

register_shutdown_function(myShutdown);

echo "Hi!";
error_log(" *** test/test *** ");
for ($i=0; $i<10; $i++) {
	sleep(1);
	error_log(".");
	echo ".";
}
?>


Expected result:
----------------
Expected:
at the moment when the client abort connection, you should stop seeing new "." in 
the log, and you should see immediately: myShutdown 1 0


Actual result:
--------------
Observed:
Exactly 10 dots (".") appear one at every second, even if the client aborts 
connection before the 10th dot is reached, and only at the end you see 
"myShutdown 0 0"


This differs with the documented behavior. Everything consistently behaves as if 
connection from the client was NEVER aborted.

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2013-04-13 21:52 UTC] rasmus@php.net
-Status: Open +Status: Not a bug
 [2013-04-13 21:52 UTC] rasmus@php.net 
What you are missing is that your single-character output is getting buffered. 
There is no way to detect a client abort until you actually try to send something 
to the client either by filling the output buffer and having it send 
automatically or by forcing it by calling flush() after your echo. So in your 
test case, add a flush() call after your echo "." and you will see it works as 
documented.
 [2013-04-13 21:56 UTC] matteosistisette at gmail dot com
-Summary: Client-side abortion is not detected at all +Summary: Client-side abortion should be detected regardless of sending output -Status: Not a bug +Status: Open
 [2013-04-13 21:56 UTC] matteosistisette at gmail dot com 
Ok, I see. The problem is that I hadn't disabled gzip in Apache, so the output 
wasn't being flushed until the end. As documented:

"""PHP will not detect that the user has aborted the connection until an attempt 
is made to send information to the client. Simply using an echo statement does 
not guarantee that information is sent, see flush()."""

However, this is a huge design flaw. PHP definitely should be able to detect the 
client's abortion when it happens and not the next time it attempts to actually 
send output. Having to change the way output is handled just in order to be able 
to detect client disconnection is ridiculous (and not always feasible).

I don't know if the server API currently provides a way for the server (i.e. 
Apache) to inform PHP of the client's disconnection, but if there is not it must 
be provided.
 [2013-04-13 21:59 UTC] rasmus@php.net
-Status: Open +Status: Not a bug
 [2013-04-13 21:59 UTC] rasmus@php.net 
Apache handles the communication with the client browser and provides no 
mechanism for PHP to discover a client abort except on an actual write.
 [2013-04-13 22:15 UTC] matteosistisette at gmail dot com 
Unbelievable. Then the huge design flaw is in Apache.
 [2013-04-13 23:41 UTC] matteosistisette at gmail dot com 
Response from Apache developers: 
https://issues.apache.org/bugzilla/show_bug.cgi?id=54842#c1

I'm not sure I fully understand it but it seems they say there actually IS a way 
PHP can figure out if the connection is closed without attempting to write.
 [2013-04-14 00:42 UTC] rasmus@php.net 
They are basically saying that we could try to hack around Apache and try to 
write directly to do direct socket ops on a socket opened and managed by Apache. 
Very bad idea. I don't know of any environment that attempts to do this. See 
this conversation about the same issue in Django, for example:

http://stackoverflow.com/questions/6019145/how-do-i-detect-an-aborted-
connection-in-django

This isn't something we are going to address with hacks in PHP.
 [2013-04-14 01:23 UTC] matteosistisette at gmail dot com 
Sh**, my last comment got silently discarded somehow!!

Please talk to apache developers directly!
If I were developing PHP, I would feel the urge to fix this issue (or call it 
"implement this feature" if you want, a basic vital feature whose lack is a huge 
issue) and if this is not possible due to a bug (or design flaw) in Apache I 
would strive to have them fix it.
 [2013-04-14 01:35 UTC] rasmus@php.net 
If you need this feature I would suggest you work on it and submit a patch. I 
doubt anybody here is going to. We work on things we need ourselves. Usually for 
any long-running things like this we farm it off to something like a Gearman job 
and check for progress via AJAX. Having a frontend Apache process tied up with 
something where super accurate client disconnect detection is relevant tends to 
be too inefficient.
 
PHP Copyright © 2001-2025 The PHP Group
All rights reserved. 		Last updated: Sat May 03 17:01:27 2025 UTC