How to control server side AJAX call timeout

Question

I am writing server code in ASP.NET and using the MVC framework. My client code is javascript.

Whether using JQuery or not to send an AJAX request from browser to server, you can set a timeout, and of course the browser also has a timeout it can enforce seperately. If either of those timeouts are reached, the failure method of the ajax invocation is called and one of the arguments specifies a timeout.

HOWEVER. I have recently discovered, it seems, that the server can timeout an AJAX call, and terminate with a 500 error code, which the client will receive as a 500 error code no different than any unexpected error. However, in this case, the underlying server worker process continues -- it is only the web server itself (IIS in my case) that interrupts and sends a 500 error code without letting the worker know, so that the worker continues on blissfully unaware that there is a problem.

Meanwhile, the client in the error handler for the AJAX call gets a status of 500, which it would naturally interpret as a failure of the worker process, perhaps an unhandled exception and ungraceful termination. As far as I can see, there is no way for the client to KNOW that the problem was a timeout, seperately from an unexpected exception. So the client code might incorrectly assume that the worker process is dead, when in fact it is very much alive.

So.... threefold question:

1. Is there a way in MVC ASP.NET to control the server timeout settings?
2. Is there a way for the worker process that the server thinks is taking too long to be informed if the server generates a timeout on its behalf?
3. Is there a way for the client side AJAX failure callback to know that this particular 500 error is not because the worker had an unexpected error, but because the wrapping server code decided it was taking too long?

wrt #3, I can see that the responseText property of the Ajax response does contain some html that if rendered would tell the user that there was a timeout, but programmatically parsing for that seems really messy and unreliable.

Anyone else run into this?

---

ADD / EDIT, 4pm PDT on 1/26:

Based on a comment immediately below suggesting that I might find a solution with this article , I implemented the suggested filter. It did not work. I was able to trigger the new filter by explicitly throwing an unhandled timeout exception from the worker process, so my filter as per that other SO article was clearly in play, but it wasn't triggered.

I should add that this application is running as a windows Azure web site. It is my belief from the the circumstantial evidence/data that I have been able to accumulate that IIS on the VM is itself interrupting the request and responding with a 500 error without even telling the underlying worker process or MVC app that it has summarily terminated the request.

So this almost seems like an IT issue of being able to configure IIS on that particular VM for that particular web site.

From my data, it appears that IIS is just canceling the request after 230 seconds.

Answer 1

Try this web.config entry:

<system.web>
<httpRuntime executionTimeout="your-timeout-in-seconds">
...
</system.web>