asp.net-web-api – 当启用CORS时,ASP.NET Web API中的异常处理程序永远不会达到顶级

前端之家收集整理的这篇文章主要介绍了asp.net-web-api – 当启用CORS时,ASP.NET Web API中的异常处理程序永远不会达到顶级前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我创建了一个自定义的Web API全局异常处理程序,像这样:
public class MyGlobalExceptionHandler : ExceptionHandler
{
    public override void Handle(ExceptionHandlerContext context)
    {
        // here I handle them all,no matter sync or not
    }

    public override Task HandleAsync(ExceptionHandlerContext context,CancellationToken cancellationToken)
    {
        // not needed,but I left it to debug and find out why it never reaches Handle() method
        return base.HandleAsync(context,cancellationToken);
    }

    public override bool ShouldHandle(ExceptionHandlerContext context)
    {
        // not needed,but I left it to debug and find out why it never reaches Handle() method
        return context.CatchBlock.IsTopLevel;
    }
}

注册它在我的Global.asax Application_Start:

GlobalConfiguration.Configuration.Services.Replace(typeof(IExceptionHandler),new MyGlobalExceptionHandler());

一切工作正常,无论我抛出异常 – 内部控制器方法或我的自定义属性上面的控制器方法,无论我从AJAX请求或直接从浏览器调用它。

但是有一天,我需要CORS支持我的AJAX请求。我按照文章Enabling Cross-Origin Requests in ASP.NET Web API中所述启用了CORS

var cors = new EnableCorsAttribute("*","*","*"); // * is just for debugging purpose
config.EnableCors(cors);

起初一切似乎都OK,CORS按预期工作,服务器响应OPTIONS请求。

但问题开始时,我想检查我的身份验证。突然,异常被吞下,我得到一个空的JSON {}响应,而不是我的自定义JSON格式化的异常,我在我的MyGlobalExceptionHandler的Handle()方法中创建。

在调试时,我惊讶地发现,现在对于AJAX请求ShouldHandle()方法调用IsTopLevel = false,因此异常从不冒泡,从来没有达到我的Handle()方法。一旦我禁用CORS,一切再次正常(除了跨域请求,当然)。

为什么IsTopLevel从不是真的,当我启用CORS?我应该如何解决这个问题?

另一个副作用如下。如果禁用CORS,那么如果我在Handle()方法中抛出任何异常,它会到达Global.asax中的Application_Error处理程序。但是如果我启用CORS并抛出异常在我的处理程序方法,这些异常从来没有达到Application_Error。

更多详细信息:

看来,我发现这正是发生的时间。

如果在启用CORS时在控制器方法中抛出异常,那么CORS根本不会踢,并且不发送Access-Control-Allow-Origin头。当浏览器没有收到头,它立即中断请求,这种中断似乎也影响异常处理程序 – 它从来没有到达ShouldHandle()方法与IsTopLevel = true。
Chrome和Mozilla的行为就像这样,即使我运行AJAX请求从本地html文件到我的websiet在IIS Express localhost。

但情况在IE 11上有所不同。当我打开html文件在那里,它首先要求我有权限启用脚本。在我同意,然后IE 11忽略的事实,没有CORS头存在,它不会中断请求,因此我的异常处理程序接收IsTopLevel = true,并能够返回一个自定义错误响应。

我想,这应该固定在Web API核心 – 即使我抛出异常,CORS应该仍然能够踢和发送其标题,所以浏览器接受响应。我创建了一个最小的测试用例应用程序,我将它发送到ASP.NET团队的CodePlex。
Link to the test project.(项目zip文件将被标记,只需点击下载并忽略该文件夹中的所有其他文件)

解决方法

我发现了混乱的根源。

看来,WebAPI默认情况下是使用这个异常处理程序:

https://aspnetwebstack.codeplex.com/SourceControl/latest#src/System.Web.Http/ExceptionHandling/DefaultExceptionHandler.cs

它与本文中建议的异常处理有很大的不同:

http://www.asp.net/web-api/overview/web-api-routing-and-actions/web-api-global-error-handling

参见“附录:基类细节”一章,其中给出了默认异常基类的代码

在这个例子中,它检查IsOutmostCatchBlock(现在似乎被移动到exceptionContext.CatchBlock.IsTopLevel),看看是否是时候处理异常。当启用CORS时,由于上述原因,此方法将不起作用。 ASP.NET团队说,这种行为是通过设计,他们不会改变任何东西。

我希望有经验的人会写一个最新的文章,说明如何处理异常处理与CORS和没有CORS的正确方式。

目前我看到两种方法解决这个在我的代码

>不从System.Web.Http.ExceptionHandling.ExceptionHandler继承我的自定义异常处理程序,但直接实现IExceptionHandler
>如果从System.Web.Http.ExceptionHandling.ExceptionHandler继承,覆盖
ShouldHandle方法并返回true总是因为CatchBlock.IsTopLevel可能永远不具有真值。

我试过两个apporaches,他们似乎工作正常。

猜你在找的asp.Net相关文章