Page 1 of 1

Continuing execution after page is sent down

Posted: Thu May 20, 2004 10:45 am
by twindagger
I posted a topic a while back regarding continuing execution of a php script after all information has been sent down to a client. It's nowhere to be found here, so I'm guessing that it was lost when the forum database crashed. Anyway, I found a solution so I figured that I would share it with everyone.


What I ended up doing was adding a background image in my style file on my body tag, like this:

Code: Select all

<style>

body
{
/*other body styles here */
background-image : url(somescript.php);
}

</style>
Then in somescript.php, you do your processing and send down a blank image file (or you could send down a real background image if you like).

Here's how I did it

Code: Select all

<?php
//do processing up here that you don't need output from
header("Expires: Mon, 26 Jul 1997 05:00:00 GMT"); 

// always modified 
header("Last-Modified: " . gmdate("D, d M Y H:i:s") . " GMT"); 

// HTTP/1.1 no caching
header("Cache-Control: no-store, no-cache, must-revalidate"); 
header("Cache-Control: post-check=0, pre-check=0", false); 

// HTTP/1.0 no caching
header("Pragma: no-cache"); 

// tell it that this is a gif
header("Content-Type: image/gif");

readFile("images/blank.gif");

?>
Note that somescript.php is called when the client's browser reads the stylesheet and requests the background image from your server.

There are a couple of disadvantages to this, as it requires that a user have css and images enabled in their browser. Also, if you're using it for running a task at specified intervals like I am, the task will not get run unless someone is actively browsing the site. That being said, it works for my purposes so it might work for yours.

Posted: Thu May 20, 2004 10:52 am
by launchcode
That's an interesting way of doing it - although I'm curious as to why you have to do this and not just call the contents of "somescript" when you reach the bottom of your currently executing one?

Posted: Thu May 20, 2004 11:30 am
by twindagger
launchcode-

I do it this way because somescript.php can take a long time and I wanted to send the page down before processing the script.

Posted: Thu May 20, 2004 11:37 am
by feyd
launchcode's idea should work, as long as you flush() just before doing the long end processing.

Posted: Thu May 20, 2004 11:47 am
by twindagger
Actually, that doesn't work, since some webservers (IIS 5.0 in particular) do not send any content down to the client until the script has finished executing, even with flush (see http://us3.php.net/manual/en/function.flush.php). Also, some browsers will not show content until a certain amount of data is received. This application will be distributed to many kinds of webservers so I can't rely on it being installed on an Apache webserver.

Posted: Thu May 20, 2004 11:54 am
by launchcode
True - although you're relying on the user having a browser that supports CSS/images instead :)

Posted: Thu May 20, 2004 1:13 pm
by twindagger
Point taken

Also, I just wanted to mention that you could apply the same principle to other things that the browser downloads after the page is received as well. So, if you're coding an application that doesn't require users to have css or images enabled, but does require javascript to be enabled, then you could put a script tag at the end of each page that points to somescript.php and change the content-type header appropriately. With javascript, you could even have it output any errors with an alert or some DHTML scripting.

Posted: Thu May 20, 2004 1:24 pm
by launchcode
Or you could just speed up the "slow" script? :)

Posted: Thu May 20, 2004 1:32 pm
by twindagger
I wish. It's actually connecting to a pop3 server and retrieving any new messages and then storing them in the database. The speed problem on it is on the POP3 server's side. Wish it could be faster but unfortunately it's not.

Posted: Thu May 20, 2004 1:41 pm
by launchcode
Thinking about it - you could always use exec() to call your script and providing the output was redirected to a file (or another output stream) it'd run quite happily "in the background" while your main script carried on its merry way.

Posted: Thu May 20, 2004 1:55 pm
by twindagger
But then you have to know the correct path to the PHP executable (on the server) and the path to the code, neither of which I will be able to know for sure.

Posted: Thu May 20, 2004 1:59 pm
by launchcode
The path to the code is easy enough to figure out and the path to PHP can be obtained via a simple shellcmd (where php).