Page 1 of 1

Fastcgi disconnect - anyone know if this is 'good'?

Posted: Thu Apr 24, 2008 2:18 pm
by dumbo11
I've been looking for a way to 'really, really' disconnect from a webserver during a query (to start a slow-running process and send the browser elsewhere).

Reading through sapi/cgi/cgi_main.c - I think this works, does anyone know if it's going to cause any problems?

Usage would be:

echo "hiya";
fastcgi_disconnect();
// webserver is no longer listening, client's browser terminates the connection
do_something_really_slow();

Code: Select all

 
1232a1233,1257
> PHP_FUNCTION(fastcgi_disconnect)
> {
>         if(!fcgi_is_fastcgi()) RETURN_FALSE;
> 
>         zend_try {
>                 php_end_ob_buffers((zend_bool)(SG(request_info).headers_only?0:1) TSRMLS_CC);
>         } zend_end_try();
> 
>         /* 4. Send the set HTTP headers (note: This must be done AFTER php_end_ob_buffers() !!) */
>         zend_try {
>                 sapi_send_headers(TSRMLS_C);
>         } zend_end_try();
> 
>         fcgi_request *request = (fcgi_request*) SG(server_context);
>         fcgi_finish_request(request);
>         RETURN_TRUE;
> }
> 
> static zend_function_entry fastcgi_functions[] = {
>         PHP_FE(fastcgi_disconnect, NULL)
>         {NULL, NULL, NULL}
> };
> 
> 
> 
1240c1265,1269
<   NULL, 
---
> #if PHP_FASTCGI
>   fastcgi_functions, 
> #else
>         NULL,
> #endif
 

Re: Fastcgi disconnect - anyone know if this is 'good'?

Posted: Sat Apr 26, 2008 6:39 pm
by Ambush Commander
How about an asynchronous request (done with Js) and setting ignore_user_abort() to true?

Re: Fastcgi disconnect - anyone know if this is 'good'?

Posted: Sun Apr 27, 2008 6:16 am
by dumbo11
Ambush Commander wrote:How about an asynchronous request (done with Js) and setting ignore_user_abort() to true?
If the connection isn't terminated correctly, then the AJAX request would surely suffer the same problem (the response wouldn't be available until the connection has timed out).

I also use this for 'backend processes' e.g. SOAP where the connection source is PHP/.net/whatever. (you can 'fake' something reliable using raw sockets with a bit of work - but it's very messy).

Re: Fastcgi disconnect - anyone know if this is 'good'?

Posted: Sun Jul 03, 2011 4:39 am
by NT Man
What difference between fastcgi_finish_request and fastcgi_disconnect?

Re: Fastcgi disconnect - anyone know if this is 'good'?

Posted: Sun Jul 03, 2011 11:57 am
by Weirdan
NT Man wrote:What difference between fastcgi_finish_request and fastcgi_disconnect?
There are some:
  1. fastcgi_disconnect() function is only provided in this patch - it's not a core thing like fastcgi_finish_request()
  2. fastcgi_disconnect() (as evidenced by the path) is intended for use with CGI (and original FastCGI) SAPI, while fastcgi_finish_request() is for FPM SAPI.
  3. this thread is two years old while php-fpm sapi is very much alive.
So if you're using php-fpm your natural choice would be to use fastcgi_finish_request().

Re: Fastcgi disconnect - anyone know if this is 'good'?

Posted: Thu Jul 14, 2011 5:08 am
by Jenk
Surely a better method is to fork() a process to churn the query, then return HTTP 200 to say "ok, received"?

Re: Fastcgi disconnect - anyone know if this is 'good'?

Posted: Wed Jul 20, 2011 4:51 am
by smassey
I found just the solution to this problem and had it tested and working with firefox 4/5 (win/linux) and IE 8/9 (havn't tested anything else).
My solution consists of sending the right headers (Content-length: XXX, Connection: close). I have this posted on my blog with 2 examples:

How to kill an HTTP connection and continue processing

Re: Fastcgi disconnect - anyone know if this is 'good'?

Posted: Wed Jul 20, 2011 4:54 am
by smassey
Jenk wrote:Surely a better method is to fork() a process to churn the query, then return HTTP 200 to say "ok, received"?
I also experimented with forking and killing the parent process, unfortunatly it's a no go when using mod_php + apache. Only cgi's will succesfully break the connection. Another disadvantage is with HA servers, this causes bursts of memory usage (twice the load) during the process of copying the parent stack into a child stack. Even though the parent died immediatly, there was a 1 ms in between where the server needs double the memory.