6

What happens when a user sends an asynchronous request to a server to update its database that may take a couple minutes, but then leaves the webpage before the update is done?

Will the server still record the update to the database or stop?

I'm using angularjs to make async calls to a LAMP stack.

Fernando Carvalhosa
  • 1,098
  • 1
  • 15
  • 23
user1424508
  • 3,231
  • 13
  • 40
  • 66
  • 2
    If the client sent an ajax request and then was closed before the response came back will the server-side still run? Of course. – david brainerd May 26 '14 at 03:06
  • What if they switch to another page? Will the server continue processing the update or can it simultaenously server another page to the user – user1424508 May 26 '14 at 03:13
  • Could you imagine a web server that can only serve one page to one user at a time. I think that's called a browser. A server should be able to handle multiple requests at once. – Andrew May 26 '14 at 03:29
  • Edited my answer. I strongly recommend you to read it – Fernando Carvalhosa May 26 '14 at 23:47

1 Answers1

3

Assuming that:

  • the server received that request
  • the server can process it without erros
  • there is a database update logic in that request handler

Then no, the server will not record the update to the database.

As @AD7six pointed out and according to this php manual reference:

Why:

The default behaviour is however for your script to be aborted when the remote client disconnects.

If you do not tell PHP to ignore a user abort and the user aborts, your script will terminate.

Options:

You can decide whether or not you want a client disconnect to cause your script to be aborted. Sometimes it is handy to always have your scripts run to completion even if there is no remote browser receiving the output.

How:

This behaviour can be set via the ignore_user_abort php.ini directive as well as through the corresponding php_value ignore_user_abort Apache httpd.conf directive or with the ignore_user_abort() function.


There is a TIMEOUT abort as well:

Why:

Your script can also be terminated by the built-in script timer. The default timeout is 30 seconds.

If you do not tell PHP to ignore a user abort and the user aborts, your script will terminate.

Options:

It can be changed using the max_execution_time php.ini directive or the corresponding php_value max_execution_time Apache httpd.conf directive as well as with the set_time_limit() function.


This is the basic client-server communication flow:

The client (the webpage, browser..) send a request (sync/async) to a server and
the server responds with a reponse to the client.

The server can handle connection timeouts and abort as well as the client.

Community
  • 1
  • 1
Fernando Carvalhosa
  • 1,098
  • 1
  • 15
  • 23
  • 3
    That's an overly simplistic answer, otherwise [options like this](http://www.php.net/manual/en/function.ignore-user-abort.php) wouldn't exist. See [connection handling](http://php.net/manual/en/features.connection-handling.php). – AD7six May 26 '14 at 06:21
  • Good point. Edited the answerd. Feel free to edit it as well to make it more complete. Although this line in the manual got me confused: `PHP will still note the fact that a user may have broken the connection, but the script will keep running. If it then hits the time limit it will be aborted and your shutdown function, if any, will be called.` Is "the script" the one the client requested or the built-in script timer? – Fernando Carvalhosa May 26 '14 at 23:51
  • It's still, "simply", not that simple. You can configure a script to _not_ exit on user abort, otherwise it depends greatly on what is happening server side e.g. [The "ignore_user_abort" flag is only checked when PHP receive an error trying to output something to the user. So, in my understanding, there is no way to interrupt code which doesn't produce any output.](http://stackoverflow.com/a/5997140/761202). "the script" effectively means the php process on the server; php has no direct knowledge of what is happening, if anything, in a browser. – AD7six May 27 '14 at 07:46