For the last couple of days of my X-mas holidays, I have been struggling with an UnathorizedAccessException when trying to READ a XML file on a remote share through my ASP.NET application using an implementation of the IHttpAsyncHandler a long with the IRequiresSessionState.
After much headache, and concluding that the code OUTSIDE the handler worked flawlessly (see: access granted), I thought it might be some threading issue, so I changed the IHttpAsyncHandler to IHttpHandler, and the problem disappears.
What is troubling me here is, that for test purposes, I did not actually make use if the IHttpAsyncHandler implementation (hence, I did not use BeginProcessRequest and EndProcessRequest - only the sync. version, ProcessRequest.
Can anyone try to explain the issue at hand?
There are some beneficial matters in using the handler asynchronously, as I could pre-cache the values to be delivered later in the application, but for that to work, I have to get pass the security issues that seems to only manifest when implementing the IHttpAsyncHandler.
Thanks in advance for your kind help - and happy holidays :-)
The ASP.NET infrastructure calls an async handler differently (regardless if the impl is truly async). Is it possible that you were relying on impersonation to access the network resource? My guess would be that the necessary WindowsIdentity didn't flow to the threadpool thread that actually handled the request (I've never tried using impersonation + async handler, but I've gotten nailed with other thread state flow issues in the past).
Regardless, a true async handler is expensive to implement correctly. Unless you're building on top of a lot of other async infrastructure (async file i/o, async DB client, etc), it doesn't do you any good (in fact, even in the best cases, async handlers hurt raw performance). I'd look to see if your performance needs really justify the extra hassle and overhead of an async handler (eg, you need to service many more concurrent requests than threads in the process, etc).