With the apparent lack of built-in support for IHttpAsyncHandler timeouts, presumably you must manage your own timeout. Perhaps this is by design; after all you are choosing an asynchronous pattern - who does MSFT think they are trying to set a default timeout for your long running task?
What I would do is use ThreadPool.RegisterWaitForSingleObject to manage your polling with an appropriate timeout. Here is a code sample I use to avoid waiting on a web service that never returns:
private const int REQUEST_TIMEOUT = 30000; // miliseconds (30 sec)
private void CallService()
{
try {
string url = "somewebservice.com";
WebRequest request = WebRequest.Create(url);
// Asynchronously fire off the request
IAsyncResult result = request.BeginGetResponse(new AsyncCallback(MyRoutineThatUsesTheResults), request);
// Handle timed-out requests
ThreadPool.RegisterWaitForSingleObject(result.AsyncWaitHandle, new WaitOrTimerCallback(RequestTimeout), request, REQUEST_TIMEOUT, true);
}
catch (Exception ex) {
_logger.Error("Error during web service request.", ex);
}
private void RequestTimeout(object state, bool timedOut)
{
if (timedOut) {
WebRequest request = (WebRequest)state;
_logger.WarnFormat("Request to {0} timed out (> {1} sec)", request.RequestUri.ToString(), REQUEST_TIMEOUT / 1000);
request.Abort();
}
}
You will need an IAsyncResult to work with this approach but that's an established pattern you shouldn't have trouble running down samples about.
Also, you will run into issues when IIS decides to recycle your app pool / tear down your app domain while your polling is still running. If that's a condition you want to handle, you can use HostingEnvironment.RegisterObject.