Edit report at https://bugs.php.net/bug.php?id=24797&edit=1
ID: 24797
Comment by: sushantahirrao at gmail dot com
Reported by: spagmoid at yahoo dot com
Summary: feature request: way to close connection with
client?
Status: Not a bug
Type: Feature/Change Request
Package: Feature/Change Request
Operating System: WinXP
PHP Version: 4.3.2
Block user comment: N
Private report: N
New Comment:
Hello,
I am facing the same issue.
Following is the scenario,
1. User opens edit profile page
2. User puts an image file for uploading
3. User cancels request before any response from the server
4. Image file keeps being uploaded in the background even if the connection is
closed
Expected Result:
Image file should not be uploaded if client closes the connection
Actual Result:
User is still able to see newly uploaded pic even if he had closed connection
with the server.
Previous Comments:
------------------------------------------------------------------------
[2011-10-22 11:49:48] lucb1e at hotmail dot com
I would like to see this feature too, currently you'd need a very cumbersome
way to do this (as far as I know at least). This example is about an uploading
script, which also synchronises with other servers immediately (so no cronjob
which would otherwise do the job).
The user opens the uploading page, and gets an upload form together with an
invisible iframe. This iframe is a php script that opens a listening socket and
saves in a database table which port it is on (together with the client's IP
or, if available, session ID). This iframe-script also sets ignore_user_abort.
When the user uploads a file, the processing script will do the following:
- Put the file somewhere and generate a download link;
- Echo the downloadlink to the user;
- ob_flush in the hope that the browser is smart enough to display the page
already;
- Lookup the listening socket for this client in the database;
- Put the filename through to the iframe-script-which-has-listening-socket;
- die().
The 'iframe-script' then knows where the file is located which was just
uploaded, and without the user waiting for it, it can synchronise it with other
servers - or do whatever it would like to do.
This technique would theoratically work allright, but has a number of problems:
- Many webhosts do not support sockets at all;
- Listening sockets have even worse support as normal (client) sockets;
- Not all hosts allow you to set a custom maximum_execution_time, which is
needed to prevent the iframe-script from killing itself;
- I don't expect all hosts to support ignore_user_abort, though I didn't look
into that yet;
- It is unnessesarily complex compared to how easy it could be done with a
kill_client_connection() function.
------------------------------------------------------------------------
[2004-06-07 15:18:13] john_ramsden at sagitta-ps dot com
> Closing the connection itself from PHP is of course
> impossible, but if the remote client decides to close
> the connection then you can allow PHP to continue
> executing.
I have the same requirement as Spagmoid's, albeit for a different reason:
In my case it's a PHP script called by an SQL trigger - The script has to read
the updated records (to replicate them in another database); but the updated
records aren't available until the trigger completes, and the trigger can't
complete until the PHP script disconnects! DUH!
Like Spagmoid's, my script obviously wouldn't try to send data after the
disconnect, as this doesn't make sense.
I must say, the PHP developers seem a bit dogmatic about this issue. Why should
closing the connection from PHP be "of course impossible"? What is to stop PHP
having some interface to tell Apache to do that without terminating the script
itself?
I realize there's a simple workaround: the script can spawn an autonomous
background process to do "post processing". But I'm not aware of a portable PHP
call to do this; so for a platform-independent app, it would be lot cleaner if
"early disconnects", followed by post-processing, could be done in a single PHP
script.
------------------------------------------------------------------------
[2004-03-25 14:18:50] php at digdug dot cx
I am looking for the same feature.
Here is the scenario: A user submits a form into script.php. The script needs
to do two things:
1) Tell the user that the submission has been accepted. (It always is.)
2) Do some background processing on the submission and flag it if necessary.
This takes up to half a minute, so I don't want to make the user wait for it to
finish.
So here is what I am trying to do:
<? insert_submission_into_database($submission); ?>
<html><body>
<? echo("submission accepted"); ?>
</html></body>
<?
close_connection_to_browser(); // currently not possible
if (submission_bad()) flag_submission();
// no further info is sent to the browser
?>
------------------------------------------------------------------------
[2003-07-26 19:24:35] ras...@php.net
Sara already answered your request by pointing you at the connection handling
chapter in the manual. You are asking for a way to keep executing your script
after the connection has been closed. Closing the connection itself from PHP
is of course impossible, but if the remote client decides to close the
connection then you can allow PHP to continue executing.
Please stop re-opening this.
------------------------------------------------------------------------
[2003-07-26 18:42:42] spagmoid at yahoo dot com
I DO NOT WANT TO SEND DATA TO THE CLIENT AFTER THE CONNECTION IS CLOSED.
NOWHERE DID I SAY THAT. That is what you people keep trying to tell me to do.
I don't want to do that. I never wanted to do that. I will never want to do
that. That is ridiculous.
"The only time PHP can continue executing after the data stream has closed is
when the browser closes the connection itself."
I would be more inclined to believe this if you had understood any of the
question.
"The only signal PHP can send to the webserver is "I'm done executing." It
sends this "signal" by terminating."
There may be another way to send this signal, but I doubt if either of you are
in a position to tell me.
"explaining your question in detail and making an attempt at civility by not
attacking those who take the time to respond."
It was in detail. "A way to close the connection with the client, while
keeping the script running?" That's it, period. It's not a complicated issue.
Sending a form letter that doesn't even match the question is not "taking the
time to respond".
------------------------------------------------------------------------
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
https://bugs.php.net/bug.php?id=24797
--
Edit this bug report at https://bugs.php.net/bug.php?id=24797&edit=1
