• 设为首页
  • 点击收藏
  • 手机版
    手机扫一扫访问
    迪恩网络手机版
  • 关注官方公众号
    微信扫一扫关注
    公众号
登陆 注册

ASP.NET Core应用的错误处理[4]：StatusCodePagesMiddleware中间件如何针对响应码呈现 ...

原作者: [db:作者] 来自: [db:来源] 收藏 邀请

StatusCodePagesMiddleware中间件与ExceptionHandlerMiddleware中间件比较类似，它们都是在后续请求处理过程中“出错”的情况下利用一个错误处理器来完成最终的请求处理与响应的任务。它们之间的差异在于对“错误”的界定上，对于ExceptionHandlerMiddleware中间件来说，它所谓的错误就是抛出异常，但是对于StatusCodePagesMiddleware中间件来说，则将介于400~599之间的响应状态码视为错误。如下面的代码片段所示，StatusCodePagesMiddleware中间件也采用“标准”的定义方式，针对它的配置选项通过一个对应的对象以Options模式的形式提供给它。 [本文已经同步到《ASP.NET Core框架揭秘》之中] 

class StatusCodePagesMiddleware
   2: {
public StatusCodePagesMiddleware(RequestDelegate next, IOptions<StatusCodePagesOptions> options);
public Task Invoke(HttpContext context);
   5: }

除了针对错误的界定，StatusCodePagesMiddleware和ExceptionHandlerMiddleware这两个中间件对于错误处理器的表达也不相同。我们知道ExceptionHandlerMiddleware中间件使用的错误处理器实际上就是一个类型为RequestDelegate的委托对象，但是错误处理器之于StatusCodePagesMiddleware中间件来说则是一个类型为Func<StatusCodeContext, Task>的委托对象。如下面的代码片段所示，为StatusCodePagesMiddleware中间件提供配置选项的StatusCodePagesOptions对象的唯一目的就是提供这个作为错误处理器的委托对象。 

class StatusCodePagesOptions
   2: {
public Func<StatusCodeContext, Task> HandleAsync { get; set; }
   4: }

我们知道一个RequestDelegate对象相当于一个类型为Func<HttpContext, Task>类型的委托对象，而一个StatusCodeContext对象实际上也是对一个HttpContext对象的封装，所以StatusCodePagesMiddleware中间件和ExceptionHandlerMiddleware中间件所使采用的错误处理器并没有本质上的不同。如下面的代码片段所示，除了从StatusCodeContext对象中获取代表当前请求上下文的HttpContext对象之外，我们还可以通过其Next属性得到一个RequestDelegate对象，它代表由后续中间件组成的请求处理管道。至于另一个属性Options，很明显它返回我们在创建StatusCodePagesMiddleware中间件所指定的StatusCodePagesOptions对象。 

class StatusCodeContext
   2: {    
public HttpContext             HttpContext { get; }
public RequestDelegate         Next { get; }
public StatusCodePagesOptions  Options { get; }
   6:  
public StatusCodeContext(HttpContext context, StatusCodePagesOptions options, RequestDelegate next);
   8: }

由于采用了针对响应状态码的错误处理策略，所以实现在StatusCodePagesMiddleware中间件中的所有错误处理操作只会发生在当前响应状态码在400~599之间的情况，如下所示的代码片段体现了这一点。从下面给出的代码片段可以看出，StatusCodePagesMiddleware中间件在决定是否执行错误处理操作时除了会查看当前响应状态码之外，还会查看响应内容以及媒体类型，如果已经包含了响应内容或者设置了媒体类型，该中间件将不会执行任何操作。 

class StatusCodePagesMiddleware
   2: {
private  RequestDelegate            _next;
private  StatusCodePagesOptions     _options;
   5:  
public StatusCodePagesMiddleware(RequestDelegate next, 
   7:     IOptions<StatusCodePagesOptions> options)
   8:     {
   9:         _next         = next;
  10:         _options      = options.Value;
  11:     }
  12:  
public async Task Invoke(HttpContext context)
  14:     {          
  15:         await _next(context);
  16:         var response = context.Response;
string.IsNullOrEmpty(response.ContentType))
  18:         {
new StatusCodeContext(context, _options, _next));
  20:         }
  21:     }
  22: }

StatusCodePagesMiddleware中间件针对错误的处理非常简单，它只需要从StatusCodePagesOptions对象中提取出作为错误处理器的这个Func<StatusCodeContext, Task>对象，然后创建一个StatusCodeContext对象作为输入参数调用这个委托对象即可。

二、阻止异常处理

如果当前响应已经被写入了内容，或者响应的媒体类型已经被预先设置，那么StatusCodePagesMiddleware中间件将不会再执行任何的错误处理操作。这种情况实际上代表由后续中间件构成的管道可能需要自行控制当前的响应，所以StatusCodePagesMiddleware中间件不应该再做任何的干预。从这个意义上来讲，StatusCodePagesMiddleware中间件仅仅是作为一种后备的错误处理机制而已。

更进一步来将，如果后续的某个中间件返回了一个状态码在400~599之间的响应，并且这个响应只有报头集合没有主体（媒体类型自然也不会设置），那么按照我们在上面给出的错误处理逻辑，StatusCodePagesMiddleware中间件还是会按照自己的策略来处理并响应请求。为了解决这种情况下，我们必须赋予后续中间件一个能够阻止StatusCodePagesMiddleware中间件进行错误处理的能力。

阻止StatusCodePagesMiddleware中间件进行错误处理的机制是借助于一个名为StatusCodePagesFeature的特性来实现的。StatusCodePagesFeature对应如下这个IStatusCodePagesFeature接口，它具有唯一的布尔类型的属性成员Enabled。默认使用的StatusCodePagesFeature类型实现了这个接口，默认情况下这个开关是开启的。 

interface IStatusCodePagesFeature
   2: {
bool Enabled { get; set; }
   4: }
   5:  
class StatusCodePagesFeature : IStatusCodePagesFeature
   7: {
true ;
   9: }

StatusCodePagesMiddleware中间件在将请求交付给后续管道之前，它会创建一个StatusCodePagesFeature特性对象并将其添加到当前HttpContext之中。当最终决定是否执行错误处理操作的时候，它还会通过这个特性检验是否某个后续的中间件不希望自己“画蛇添足”地进行不必要的错误处理，如下的代码片段很好的体现了这一点。 

class StatusCodePagesMiddleware
   2: {
   3:     …
public async Task Invoke(HttpContext context)
   5:     {
new StatusCodePagesFeature();
   7:         context.Features.Set<IStatusCodePagesFeature>(feature);
   8:  
   9:         await _next(context);
  10:         var response = context.Response;
string.IsNullOrEmpty(response.ContentType) &&
feature.Enabled)
  13:         {
new StatusCodeContext(context, _options, _next));
  15:         }
  16:     }
  17: }

我们通过一个简单的实例来演示如果利用这个StatusCodePagesFeature特性来屏蔽StatusCodePagesMiddleware中间件。在下面这个应用中，我们将针对请求的处理定义在Invoke方法中，该方法会返回一个状态码为“401 Unauthorized”的响应。我们通过随机数让这个方法会在50%的情况下利用StatusCodePagesFeature特性来阻止StatusCodePagesMiddleware中间件自身对错误的处理。我们通过调用扩展方法UseStatusCodePages注册的StatusCodePagesMiddleware中间件会直接响应一个内容为“Error occurred!”的字符串。 

class Program
   2: {
void Main()
   4:     {
new WebHostBuilder()
   6:             .UseKestrel()
   7:             .Configure(app => app
))
   9:                 .Run(Invoke))
  10:             .Build()
  11:             .Run();
  12:     }
  13:  
new Random();
static Task Invoke(HttpContext context)
  16:     {
  17:         context.Response.StatusCode = 401;
  18:  
if (_random.Next() % 2 == 0)
  20:         {
false;
  22:         }
return Task.CompletedTask;
  24:     }
  25: }

对于针对该应用的请求来说，我们会得到如下两种不同的响应。没有主体内容响应是通过Invoke方法产生的，这种情况下发生在StatusCodePagesMiddleware中间件通过StatusCodePagesFeature特性被屏蔽的时候。具有主体内容的响应则来源于StatusCodePagesMiddleware中间件。 

   1: HTTP/1.1 401 Unauthorized
   2: Date: Sun, 18 Dec 2016 01:59:37 GMT
   3: Server: Kestrel
   4: Content-Length: 15
   5:  
   6: Error occurred!
   7:  
   8:  
   9: HTTP/1.1 401 Unauthorized
  10: Date: Sun, 18 Dec 2016 01:59:38 GMT
  11: Content-Length: 0
  12: Server: Kestrel

三、注册StatusCodePagesMiddleware中间件

我们在大部分情况下都会调用ApplicationBuilder相应的扩展方法来注册StatusCodePagesMiddleware中间件。对于StatusCodePagesMiddleware中间件的注册来说，除了我们已经很熟悉的UseStatusCodePages方之外，还具有额外一些扩展方法供我们选择。

UseStatusCodePages

我们可以调用如下三个UseStatusCodePages方法重载来注册StatusCodePagesMiddleware中间件。不论我们调用那个重载，系统最终都会根据提供的StatusCodePagesOptions对象调用构造函数来创建这个中间件对象，而且这个StatusCodePagesOptions必须具有一个作为错误处理器的Func<StatusCodeContext, Task>对象。如果没有指定任何参数，StatusCodePagesOptions对象需要以Options模式的形式注册为服务。 

class StatusCodePagesExtensions
   2: {   
this IApplicationBuilder app)
   4:     {      
return app.UseMiddleware<StatusCodePagesMiddleware>();
   6:     }
   7:  
this IApplicationBuilder app, StatusCodePagesOptions options)
   9:     {
return app.UseMiddleware<StatusCodePagesMiddleware>(Options.Create(options));
  11:     }  
  12:     
this IApplicationBuilder app, Func<StatusCodeContext, Task> handler)
  14:     {       
new StatusCodePagesOptions
  16:         {
  17:             HandleAsync = handler
  18:         });
  19:     }
  20: }

由于StatusCodePagesMiddleware中间件最终的目的还是将定制的错误信息响应给客户端，所以我们可以在注册该中间件的时候直接指定响应的内容和媒体类型，这样的注册方式可以通过调用如下这个UseStatusCodePages方法来完成。从如下所示的代码片段我们不难看出，我们通过bodyFormat方法指定的实际上是一个模板，它可以包含一个表示响应状态的占位符（“{0}”）。 

class StatusCodePagesExtensions
   2: {   
string bodyFormat)
   4:     {
return app.UseStatusCodePages(context =>
   6:         {
string.Format(CultureInfo.InvariantCulture, bodyFormat, context.HttpContext.Response.StatusCode);
   8:             context.HttpContext.Response.ContentType = contentType;
return context.HttpContext.Response.WriteAsync(body);
  10:         });
  11:     }
  12: }

UseStatusCodePagesWithRedirects

如果我们调用UseStatusCodePagesWithRedirects方法，可以让注册的StatusCodePagesMiddleware中间件向指定的路径发送一个客户端重定向。从如下所示的实现代码可以看出，这个作为参数locationFormat的重定向地址也是一个模板，它可以包含一个表示响应状态的占位符（“{0}”）。我们可以指定一个完整的地址，也可以指定一个相对于PathBase的相对路径，后者需要包含表示基地址的“~/”前缀。 

class StatusCodePagesExtensions
   2: {       
string locationFormat)
   4:     {
))
   6:         {
   7:             locationFormat = locationFormat.Substring(1);
return app.UseStatusCodePages(context =>
   9:             {
string.Format(CultureInfo.InvariantCulture, locationFormat, context.HttpContext.Response.StatusCode);
  11:                 context.HttpContext.Response.Redirect(context.HttpContext.Request.PathBase + location);
return Task.CompletedTask;
  13:             });
  14:         }
else
  16:         {
return app.UseStatusCodePages(context =>
  18:             {
string.Format(CultureInfo.InvariantCulture, locationFormat, context.HttpContext.Response.StatusCode);
  20:                 context.HttpContext.Response.Redirect(location);
return Task.CompletedTask;
  22:             });
  23:         }
  24:     }
  25: }

我们通过一个简单的应用来演示针对客户端重定向的错误页面呈现方式。我们在如下这个应用中注册了一个路由模板为“error/{statuscode}”的路由，路由参数“statuscode”自然代表响应的状态码。在作为路由处理器的HandleError方法中，我们会直接响应一个包含响应状态码的字符串。我们调用UseStatusCodePagesWithRedirects方法注册StatusCodePagesMiddleware中间件的时候将重定义路径设置为“error/{0}”。 

class Program
   2: {
new Random();
void Main()
   5:     {
new WebHostBuilder()
   7:             .UseKestrel()
   8:             .ConfigureServices(svcs => svcs.AddRouting())
   9:             .Configure(app => app
)
, HandleError))
  12:                 .Run(context=>Task.Run(()=>context.Response.StatusCode = _random.Next(400,599))))


鲜花
握手
雷人
路过
鸡蛋
该文章已有0人参与评论

请发表评论

全部评论

专题导读
More+
上一篇：
ASP.NET 2.0 绑定高级技巧发布时间：2022-07-10
下一篇：
ASP.NET单点登录可能遇到的问题发布时间：2022-07-10
热门推荐
More+
热门话题
More+
阅读排行榜

扫描微信二维码

查看手机版网站

随时了解更新最新资讯

139-2527-9053

在线客服（服务时间 9:00～18:00）

在线QQ客服
地址：深圳市南山区西丽大学城创智工业园
电邮：jeky_zhao#qq.com
移动电话：139-2527-9053

Powered by 互联科技 X3.4© 2001-2213 极客世界.|Sitemap