Force close HTTP request/response about http HOT 12 CLOSED

There are some attempts in comments: https://www.php.net/manual/en/features.connection-handling.php

For such long-term running cases, I usually render ordinary response and from browser then, invoke WebSockets/Ajax request with ignore_user_abort() on server side.

from http.

You mean fastcgi_finish_request?

from http.

@JanTvrdik Maybe yes, but this function can be sometimes unavailable:

from http.

Then I don't understand this issue. You cannot implement this in userland.

from http.

ping @janbarasek

from http.

@dg I'm not sure this is Nette's responsibility, but it would be nice to be able to control all the output to the browser via the Http\Response object.

For example, a user invokes a long-running task in the Presenter, so I send him a quick response (Latte template), but the task continues to run in the background even after the user closes the connection and all headers are sent correctly.

This allows, for example, to respond to a request very quickly, but to write data to the database only after the user does not have to wait for it.

If this does not make sense, please close the issue. Thanks.

from http.

The question is, how to implement it? Is there a function for that?

from http.

Before any output is sent

ignore_user_abort(true);

When connection should be closed, output sent and script continue:

if (connection_aborted() === 0) {
	ob_flush();
	flush();
	if (session_status() === PHP_SESSION_ACTIVE) {
		session_write_close();
	}
}

It should do the trick, but be beware of possible issues:

• IIS + fastcgi doesn't work at all https://bugs.php.net/bug.php?id=60586#1378935714
• it should be checked whether session is written into or output is sent after connection was closed
• I found a note that current working directory is changed after connection is closed, but never really tested it.
• Time limit is a must-have, in case of ini_get('max_execution_time') === '0' would be an exception thrown on connection abort welcome

@milo Good job, you was faster :D

from http.

But ignoring the implementation question - there are imho better options for non-blocking processing like message queues, swoole and possibly fibers in the near future.
I am kinda worried about constantly running into race conditions because this behavior is global and e.g. depending on Doctrine EntityManager->flush() auto-called on script termination is quite often. Whether sql transaction or redirect finished first could create quite unexpected behavior, at least for less advanced users

from http.

Wouldn't it be better to write a feature request on PHP?

from http.

@mabar I think the magic is only in Content-Length header.

from http.

Cannot be solved in PHP.

from http.