Network Computing is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

How to Handle Request Failures

This column is in response to a question from an NDCF reader. He wanted to know: Is there any way to handle 'in flight' HTTP request failures more transparently?" One example would be when a response to an HTTP request is sent fully from a Web server and the server crashes. The problem with this is that the request can fail at any point – both before and after it reaches the destination.

This is a very interesting question with a lot of nuances and shades of gray! The answer is neither a simple "yes" nor a "no."

The challenge in this kind of situation is that the surrounding components don't know how much of the request was digested and acted upon prior to the failure. As a result, it is possible that half a request was processed and some action started before the failure occurred. If a load balancer fronting the Web server were to send that request to another server after the failure, it is possible that an action gets duplicated. This could mean, for example, that a credit card gets billed twice.

In most Web applications, there are a few things that require a user's request to stay put:

  • The most common reason is that the application may not share user state across all of the servers.
  • The application may need to be written to handle the situation whereby a request that is half processed on one server can be continued on another. Things like database locks and interaction with third-party systems (for example, billing) would need to be accounted for.
  • The backup server may not know what, if any, traffic has already been returned to the end user. For all the backup server might know, the application had already sent all of its data and was about to close the connection.
  • Clients may either become impatient and press "reload," or the browsers might timeout altogether.

From a security standpoint, if an attacker figured out the magic sauce to make a Web application stall or break, the last thing you'd want is the load balancer to detect the server going down and retransmit the attacker's payload to every other Web server!

  • 1