IHttpAsyncHandler 导致 UnathorizedAccessException
在圣诞节假期的最后几天，当我尝试使用 IHttpAsyncHandler 的实现和 IRequiresSessionState 来通过我的 ASP.NET 应用程序读取远程共享上的 XML 文件时，我一直在与 UnathorizedAccessException 作斗争。
经过一番头痛之后，并得出结论，处理程序外部的代码工作完美（请参阅：授予访问权限），我认为这可能是一些线程问题，因此我将 IHttpAsyncHandler 更改为 IHttpHandler，问题就消失了。
这里令我困扰的是，出于测试目的，我实际上并没有使用 IHttpAsyncHandler 实现（因此，我没有使用 BeginProcessRequest 和 EndProcessRequest - 仅使用同步版本 ProcessRequest。
任何人都可以尝试解释手头的问题吗？ 。
异步使用处理程序有一些好处，因为我可以预先缓存稍后在应用程序中传递的值，但为了实现这一点，我必须解决似乎只在实现时才会出现的安全问题 IHttpAsyncHandler。
提前感谢您的帮助 - 祝节日快乐:-)
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 :-)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
ASP.NET 基础结构以不同方式调用异步处理程序（无论 impl 是否真正异步）。您是否有可能依靠模拟来访问网络资源？我的猜测是，必要的 WindowsIdentity 没有流向实际处理请求的线程池线程（我从未尝试过使用模拟 + 异步处理程序，但我过去已经解决了其他线程状态流问题）。
无论如何，正确实现真正的异步处理程序的成本很高。除非您构建在许多其他异步基础设施（异步文件 I/O、异步数据库客户端等）之上，否则它对您没有任何好处（事实上，即使在最好的情况下，异步处理程序也会损害原始数据）表现）。我想看看您的性能需求是否真的证明了异步处理程序的额外麻烦和开销是合理的（例如，您需要服务的并发请求比进程中的线程多得多，等等）。
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).