CODEWITHSUNDEEP
http
bharal
bharal

Reputation: 16244

Should POST data have a re-try on timeout condition or not?

When POSTing data - either using AJAX or from a mobile device or what have you - there is often a "retry" condition, so that should something like a timeout occue, the data is POSTed again.

Is this actually a good idea?

POST data is meant to be idempotent, so if you

  1. make a POST to the server,
  2. the server receives the request,
  3. takes time to execute and
  4. then sends the data back

if the timeout is hit sometime after 3. then the next retry will send data that was meant to be idempotent.

The question then is that should a retry (when calling from the client side) be set for POST data, or should the server be designed to always handle POST data appropriately (with tokens and so on), or am i missing something?

update as per the questions - this is for a mobile app. As it happens, during testing it was noticed that with too short a timeout, the app would retry. Meanwhile, the back-end server had in fact accepted and processed the initial request, and got v. upset when the new (otherwise identical) re-request came in.

Upvotes: 1

Views: 426

Answers (4)

Chris Broski
Chris Broski

Reputation: 2550

If your requests are failing enough to instigate something like this, you have major problems that have nothing to do with implementing a retry condition. I have never seen a Web app that needed this type of functionality. Programming your app to automatically beat an overloaded sever with the F5 hammer is not the solution to anything.

If this ajax request is triggered from a button click, disable that button until it returns, successful or not. If it failed, let the user click it again.

Upvotes: 0

Wrikken
Wrikken

Reputation: 70540

nonce's are a (partial) solution to this. The server generates a nonce and gives it to the client. The client sends the POST including the nonce, the server checks if the nonce is valid and unused and if so, acts on the POST and invalidates the nonce, if not, it reports back that the nonce is used and discards the data. Also very usefull to avoid the 'double post' problem by users clicking a submit button twice.

However, it is moving the problem from the client to a different one on the server. If you invalidate the nonce before the action, the action might still fail / hang, if you invalidate it after, the nonce is still valid for requests during the processing. So, a possible scenario on the server becomes on receiving.

  1. Lock nonce
  2. Do action
  3. On any processing error preventing action completion, rollback, release lock on nonce.
  4. On no errors, invalidate / remove nonce.

Semaphores on the server side are most helpfull with this, most backend languages have libraries for these.

So, implementing all these:

  1. It is safe to retry, if the action is already performed it won't be done again.
  2. A reply that the nonce has already been used can be understood as a a confirmation that the original POST has been acted upon.
  3. If you need the result of an action where the second requests shows that the first came through, a short-lived cache would be needed server-sided.
  4. Up to you to set a sane limit on subsequent tries (what if the 2nd fails? or the 3rd?).

Upvotes: 1

Nir Alfasi
Nir Alfasi

Reputation: 53565

If you can't avoid the long wait until the server responds, a better practice would be to return an immediate response (200OK with the message "processing") and have the client, later on, send a new request that checks if the action was performed.

AJAX was not designed to be used in such a way ("heavy" actions). By the way, the default HTTP timeout is 7200 secs so I don't think you'll reach it easily - but regardless, you should avoid having the user wait for long periods of time.

Providing more information about the process (like what exactly you're trying to do) would help in suggesting ways to avoid such obstacles.

Upvotes: 0

Matt S
Matt S

Reputation: 15394

The issue with automatic retries is the server needs to know if the prior POST was successfully processed to avoid unintended consequences. For example, if each POST inserts a DB record, but the last POST timed out after the insert, the automatic re-POST will cause a duplicate DB record, which is probably not what you want.

In a robust setup you may be able to catch that there was a timeout and rollback any POSTed updates. That would safely allow an automatic re-POST. But many (most?) web systems aren't this elaborate, so you'll typically require human intervention to determine if the POST should happen again.

Upvotes: 0

Related Questions