Close http connection but continue execution?

[Colin McKinnon]

Hi All,

I'm trying to work out how to close the connection to the browser at a
defined point within my code, but go on to do some time-consuming
processing with PHP.

Although it *should* be possible to do this by moving the slow stuff into a
function registered with register_shutdo wn_function, it appears that in
many cases, the connection is not closed before calling the shutdown
function - there are also issues with calling other functions from the
registered function.

I can't close stdout since I don't have a handle for it.

While I can get the desired result by creating a sort of 'proxy' which posts
on to the real script without waiting for the latter to finish this will be
rather difficult to implement in the operational context.

TIA,

C.

[Kevin Thorpe]

Colin McKinnon wrote:

Hi All,

I'm trying to work out how to close the connection to the browser at a
defined point within my code, but go on to do some time-consuming
processing with PHP.

I'm not sure if this is going to be possible for you but I do this sort
of thing with a process daemon.

The initiating script dumps a record into an SQL table to schedule a job
start. I then have a small perl daemon process watching this table for
jobs and then exec's the relevant php process. The php process updates
the current status field in the table as it runs so I can have a script
to display the job queue. I also have space for the offline process to
enter a link into the job queue to collect the process output.

[Colin McKinnon]

Kevin Thorpe wrote:

The initiating script dumps a record into an SQL table to schedule a job
start. I then have a small perl daemon process watching this table for
jobs and then exec's the relevant php process. The php process updates
the current status field in the table as it runs so I can have a script
to display the job queue. I also have space for the offline process to
enter a link into the job queue to collect the process output.

Yes, I thought about doing that but to get turnaround I require I would need
to poll the queue ever three seconds. Then I have the complication of
locking the requests that are being processed from the queue if I do it via
'cron' and care/feeding of homegrown daemons poses a number of problems
too.

grr.

I guess I could do `at now php -q script.php $params` too - but that
requires me to rewrite a LOT of code.

I've now created a proxy script in PHP which relays POST/GET requests to
another script collects the headers, and any output up until it sees a
specific string in the output then closes the connection and returns the
headers and content to the client. Only problem is that even an explicit
flush() in the backend script doesn't have the desired effect. (no...not
using mod_gzip, nor do I think I'm using anything else which might be
buffering the output in Apache).

Any more suggestions?

C.

[Colin McKinnon]

Colin McKinnon wrote:

I've now created a proxy script in PHP which relays POST/GET requests to
another script collects the headers, and any output up until it sees a
specific string in the output then closes the connection and returns the
headers and content to the client. Only problem is that even an explicit
flush() in the backend script doesn't have the desired effect. (no...not
using mod_gzip, nor do I think I'm using anything else which might be
buffering the output in Apache).

Solved - added a print "\n"; before flush()

happy me :)