You've probably heard of the setting in php.ini
ignore_user_abort, and how it allows you to ignore a user aborting page load and thus terminating your script mid way through. Today I found out that didn't quite mean what I thought that meant.
I was under the impression that when the user hit stop, the script stopped. Which is: bad, and wrong. PHP doesn't detect that the user has terminated the connection, it has no clue, it obligingly continues processing along, until it attempts to send information to the user. Now, just because you have an echo statement, doesn't mean that information is necessarily being sent to the user, buffering (not necessarily output buffering, PHP and your web server also implement some buffering) will probably catch it. It's not until that buffer is filled, or you call something like
flush() that information is actually sent, and thus PHP would know the user has aborted.
When might you want to ignore a user abort? Well, simply put, any situation where you're executing a series of sequential actions and stopping in the middle would leave your application in a bad state (transactions are the database solution for this, they're simply rolled back if you disconnect without committing (unless you're using a persistent connection)).
In short, the user aborts when they close their browser, hit stop, etc. PHP however doesn't know the user has aborted until it actually attempts to send them data.
Tracked: Oct 03, 08:26
If you’re looking for a way to keep a PHP script running on the server even after the user navigates from the page or hits the stop button, you can use the “ignore_user_abort” flag in the php.ini file or set it using ini_set function...
Tracked: Oct 03, 10:26