I am not completely sure that this is possible from within PHP or even the HTTP protocol in depth. Is it possible to receive PHP script to run when it is requested but then the script drops the connection? Without replying?
Hopefully my question makes sense.
(I am using Apache)
When you serve php through Apache, there will always be a http response. Calling exit will just stop php from processing - not stop Apache. The proper thing to do in your case, is probably to send a http response-code other than 200 (OK). For example 404 or 500. Check the specs to find the one that applies to your situation.
You send a http response from within php, using:
<?php
header("HTTP/1.0 404 Not Found");
exit;
If you don't want to send any data at all, use a sleep in a loop. Eventually the client end will time out and close the connection.
You can use exit() or die() in the script to stop script execution, would that do what you want?
Why would you want to do this? Surely you should be sending some kind of HTTP error code instead?
That depends on the software you use. Apache for example terminates any scripts as soon as the connection closes.
Related
I want to replace the PHP script that currently handles receiving and processing data from my webpage (LAN only) by a NodeJS file. Currently, the JSON data is being sent in JS with an XMLHttpRequest:
var xhttp = new XMLHttpRequest();
var url = "/server.php";
xhttp.open("POST", url, true);
xhttp.setRequestHeader("Content-Type", "application/json");
xhttp.onreadystatechange = function () {
...
};
xhttp.send(content);
Obviously, server.php is the file I'm looking to replace. In this file, I receive the data like this:
$stringHttp = file_get_contents("php://input");
I have searched far and wide on how to do something like this in NodeJS, but everything I find uses this basic layout:
http.createServer((request, response) => {
...
}).listen(8091);
Now, since my webpage is hosted by Apache, it's probably not possible to create this server on the same port. At least, that's what I'm getting from the error message I get when I try to run the NodeJS file:
events.js:183
throw er; // Unhandled 'error' event
^
Error: listen EADDRINUSE :::8091
at Object._errnoException (util.js:992:11)
at _exceptionWithHostPort (util.js:1014:20)
at Server.setupListenHandle [as _listen2] (net.js:1355:14)
at listenInCluster (net.js:1396:12)
at Server.listen (net.js:1480:7)
at Object.<anonymous> (/var/www/apache/testNode.js:15:4)
at Module._compile (module.js:652:30)
at Object.Module._extensions..js (module.js:663:10)
at Module.load (module.js:565:32)
at tryModuleLoad (module.js:505:12)
So basically, I'm looking for a NodeJS replacement of file_get_contents("php://input").
Hence my question: Can you obtain POST data in NodeJS without creating a server?
No, it isn't.
In your PHP version, you have a server. It is Apache and it makes use of (for example) mod_php to execute the PHP.
If you are executing your program with Node.js, then you need some way to get the HTTP request to the program. That involves running a server.
it's probably not possible to create this server on the same port
No. You'd need to run it on a different port. (And then either post to it directly or configure Apache to act as a proxy in front of it).
Well, if you really just want to run a node.js script one and done to get a result, then you could keep a shell of your PHP script and have it run node and your script. You could either pass the node script the required data on the command line or you could send it in stdio and the node script would grab it from whichever.
Your node script would run and create the desired result and write it to stdout. The PHP script would then grab the stdout data and forward it as the http response.
Nobody is going to describe this a super optimal way to do things. HTTP response is sent to Apache, then fires up the PHP interpeter to run your PHP script which fires up node.js to run your node.js script. But, if it's a one-off thing just for this one use and there's some compelling reason that you use PHP elsewhere and need node.js for this one thing, then you could make it work.
It may even be possible to create a custom path for this one script that Apache could be configured to detect and then run your node script directly (like it does for PHP) without the PHP middleman. I don't know Apache well enough to advise exactly how to do that, but there are some references on doing it. Again, not optimal, but it could be made to work.
The best performance solution would be to actually create a node.js server on another port and have either Apache or some other proxy detect certain requests (usually based on the path) that you want redirected to your node.js server rather than sent through to PHP or post directly to the other port from the client (you'd have to enable CORS in your node.js server to allow that to work).
I am using this code header('Location: http://example.com/test.php?number='.$requestsDone.'');
But looks like it is not working, what is wrong here?
Let me know, if you need more information.
Producing a header in a command line script doesn't make any sense. The header is part of the HTTP protocol, there is no HTTP involved when the script is executed using the CLI version of PHP.
Accordingly, the header() function is not implemented in the CLI version of PHP. It exists, but it doesn't produce any output.
Also, the superglobals that contain information extracted from the HTTP request ($_GET[], $_POST[], $_REQUEST[], $_FILES[], $_COOKIE[] etc) exist but they are empty.
In order to pass arguments to a script using the command line, use the $argc and $argv[] variables.
I have a php script which needs to restart lighttpd. The php page never returns to the client. I believe that is because the call doesn't return. Here is my code:
<?php
exec("/etc/init.d/lighttpd restart");
echo "Restarted!";
?>
If I comment out the exec line it returns as expected.
How can I get this call to return?
Thanks,
EV
If you restart you httpd process your scripts will be terminated, no matter what you do!
You will never make any scripts to return a value directly from PHP. To make that work you should add a javascript and check for a 200 Status Code.
It's because your script kills the existing Lighthttpd process before it is able to return the result of the execution...
It is like having a process that kills himself and wondering why the process is not returning anything...
Suppose I make an AJAX HTTP Request from jQuery to a backend PHP script. The request is made, the PHP script starts running and doing its magic. Suppose I then change to another website, away from the site where the original AJAX Request was made. As well, I do this before the PHP script finishes and has time to do a HTTP Response back. Does the PHP script finish running and doing its thing even though I've switched to another website before I got the HTTP Response?
So the order is this.
I'm on website www.xyz.com
I have a jQuery handler that kicks off an AJAX request to blah.php
blah.php starts running
I go to website www.abc.com soon after without waiting for a response from blah.php
What's going on with blah.php? Is execution still going on? Did it stop? I mean it didn't get a chance to respond so...
This may depend on your server configuration, but in general the script will continue to execute despite a closed HTTP connection.
I have tested this with Apache 2 + PHP 5 as mod_php. I would expect similar behaviour with PHP as CGI and with other webservers but do not know for certain.
The best way to determine for certain on your configuration is, as #tdammers suggests: set up a test script something like the following and monitor the log.
<?php
error_log('Test script started.');
for ($i = 1; $i < 13; $i++) {
sleep(10);
error_log('Test script got to ' . (10 * $i) . ' seconds.');
}
error_log('Test script got to the end.');
?>
Access this script (at /test.php or whatever) then before you get any results, hit stop on your browser. This is equivalent to navigating away before your XHR returns. You could even have it as the target of an XHR and navigate away.
Then check your error log: you should have a start and then messages every 10 seconds for two minutes and an end. You can modify how high $i gets to ensure your script will reach its anticipated maximum execution time if you'd like to test that too.
You don't have to use error_log() - you could write to a file, or make some other persistent change on the server that can be checked without needing to keep the client connection open.
The script execution time may stop before then because of the max_execution_time php.ini directive - but in any case this should be distinct from when the webserver times out.
Try ignore_user_abort(true);
ignore_user_abort(true);
it should not abort proccessing of your code
You might want to check out the answers to This Question.
Basically when you make your ajax call to a php function which calls the exec() function as shown in the answers to that question, you'll get an ajax response almost immediately, since your php function doesn't actually need to process anything. This way, it shouldn't matter if the user leaves the page.
Here's a small example:
ajax call in html file: $.ajax({url: 'blah.php'});
blah.php file: exec('bash -c "exec nohup setsid php really_slow_script.php > /dev/null 2>&1 &"');
And then finally in really_slow_script.php, just include the actual code you want to run.
I successfully used this kind of logic to allow users to post an already uploaded video from their account on my website to youtube. (The video had to be sent to youtube, and since videos are generally large files, I didn't want the user to have to wait while the video was being uploaded to youtube)
Navigating away will trigger a disconnect message on the server. The implications of that entirely depends on what what your server has been configured to do.
By default, the server will be set up so that a disconnect will not interrupt the way that the program functions. It is possible, however, to make it so that a user disconnect will trigger the function which has been registered with register_shutdown_function, garbage collection will occur, and the script will terminate.
Because it is something which can be configured several different places, it might be easiest to just run a test, but this is a php.ini directive. If you want to configure this on a global level, you can set ignore_user_abort = Off in php.ini. If you want this on a site-specific level, you can use php_value ignore_user_abort off in the htaccess in the parent directory of the current site. Otherwise you can use ignore_user_abort(false);.
Of course, there is no guarantee on a shared server that you have control of htaccess or php.ini, so you might just need to use ignore_user_abort(false);.
if i call a php file via jquery ajax, that contains a script to do some stuff that takes a while — for instance uploading a big video — and then I close the page: does the php script keep loading the video or not?
See here:
http://php.net/manual/en/function.ignore-user-abort.php
int ignore_user_abort ([ bool $value ] )
Sets whether a client disconnect should cause a script to be aborted.
When running PHP as a command line script, and the script's tty goes away without the script being terminated then the script will die the next time it tries to write anything, unless value is set to TRUE
There also is a PHP configuration option of the same name:
http://php.net/manual/en/misc.configuration.php
By default, if you do nothing, according to the PHP manual the default is to abort the script.
http://php.net/manual/en/features.connection-handling.php
NECESSARY UPDATE
It seems I (unknowingly) tricked my way to "reputation points", because I did NOT supply the (correct) answer, but here it is now thanks to testing and continued nudging from "mellamokb":
Quote:
"Ok, I took a look at the PHP source code and, if I didn't miss anything, I now have the answer. The "ignore_user_abort" flag is only checked when PHP receive an error trying to output something to the user. So, in my understanding, there is no way to interrupt code which doesn't produce any output."
Okay, I wasn't totally off, but it is important to know that it all depends on whether or not your script produced any output!
If you read THIS, also DO check out the comments below.
A PHP Script running through a web server will not stop until:
someone kill the server
the server kill the php scrip
When the user abort the script, PHP will continue until it try to send something back to the browser.
For example still script will continue fore ever even if the user abort:
while(true){
echo 'go'.PHP_EOL;
}
It will go on forever because the "echo", will write into the buffer, and the buffer will not be sent to the browser until the script finish, which will never happen.
The following script will stop as soon as the user abort:
while(true){
echo 'go'.PHP_EOL;
flush();
ob_flush();
}
This script will stop, because flush() and ob_flush() will force PHP to send its buffer to the browser, which will stop the PHP script if the user has aborted.
The function ignore-user-abort() will force PHP to ignore the abort in this case.
Moreover if you are using PHP session, they are another tricky situation.
For example, if you are doing AJAX, and you actually send two AJAX request to a PHP script and that PHP script has need of session with session_start().
The first AJAX query will work normally, however the second one will have to wait until the first call is finish, because the first script has a locked on the session.
The first script could eventually prematurely release the session with session_write_close();
By default no. See Connection Handling documentation, especially:
You can decide whether or not you want
a client disconnect to cause your
script to be aborted. Sometimes it is
handy to always have your scripts run
to completion even if there is no
remote browser receiving the output.
The default behaviour is however for
your script to be aborted when the
remote client disconnects.
The script will run the time set by max_execution_time (default is 30s)
Warning This function has no effect when PHP is running in safe mode.
There is no workaround other than turning off safe mode or changing
the time limit in the php.ini.
Note: The set_time_limit() function and
the configuration directive max_execution_time only affect the
execution time of the script itself. Any time spent on activity that
happens outside the execution of the script such as system calls using
system(), stream operations, database queries, etc. is not included
when determining the maximum time that the script has been running.
This is not true on Windows where the measured time is real.
quote from http://php.net/manual/en/function.set-time-limit.php
you can test this by running
<?php
unlink('cocorico.txt');
while(true){
file_put_contents('cocorico.txt', microtime(true).PHP_EOL, FILE_APPEND);
}
and it will stop after 30s (despite you close your browser or not)
you can get you default exec time by echo ini_get('max_execution_time'); and can be set like set_time_limit(3);
The answer marked as accepted is only correct about the ignore_user_abort but don't panic that your "fail" scripts will run forever if you don't set max exec time to 0 - unlimited;
From my little understanding of how these stuff works. By the point of view of the HTTP protocol I would say yes, the script would keep running, because the browser just sends a request to the server asking for the page, then the server starts executing the script and does not sends or receives information from the browser untill the script is done loading and producing the html output, and just then the server sends the resulting output to the browser and has done the job.
See, there is no way for a browser to "tell" the server that the user is not viewing the page anymore through the HTTP protocol. However, the HTTP protocol runs on top of the TCP connection through stream sockets, the TCP connection is kept alive till one of the ends choses to abort the connection (or a certain timeout is reached), now I really don't know how the browser handles this. The browser could just open a connection, send a request and close the connection, then the server waits for the script and sends the response on another connection. Or the browser could open a connection, KEEP this connection alive till the server responds on the same connection. If the thing works that way then the server would really have a way to know if the user is not viewing the page anymore simply by checking if the connection is still alive or has been shutdown by the client. So that would be a no.
Dunno much about that tho.