ASP.NET Core 6错误页面，N种展示方法，你试过吗？

由于ASP.NET是一个同时处理多个请求的Web应用框架，所以在处理某个请求过程中出现异常并不会导致整个应用的中止。出于安全方面的考量，为了避免敏感信息外泄，客户端在默认情况下并不会得到详细的出错信息，这无疑会在开发过程中增加查错和纠错的难度。对于生产环境来说，我们也希望最终用户能够根据具体的错误类型得到具有针对性并且友好的错误消息。ASP.NET提供的相应的中间件可以帮助我们将定制化的错误信息呈现出来。本文提供的示例演示已经同步到《ASP.NET Core 6框架揭秘-实例演示版》） 目录 [2101]开发者异常页面的呈现（源代码） [2102]定制异常页面的呈现（源代码） [2103]利用注册的中间件处理异常（源代码） [2104]针对异常页面的重定向（源代码） [2105]基于响应状态码错误页面的呈现（设置响应内容模板）（源代码） [2106]基于响应状态码错误页面的呈现（提供异常处理器）（源代码） [2107]基于响应状态码错误页面的呈现（利用中间件创建异常处理器）（源代码） [2101]开发者异常页面的呈现如果ASP.NET应用在处理某个请求时出现异常，它一般会返回一个状态码为“500 Internal Server Error”的响应。为了避免一些敏感信息的外泄，客户端只会得到一个很泛化的错误消息。以如下所示的程序为例，处理根路径的请求时都会抛出一个InvalidOperationException类型的异常。 var app = WebApplication.Create(); app.MapGet("/", void () => throw new InvalidOperationException("Manually thrown exception")); app.Run(); 利用浏览器访问这个应用总是会得到图1所示的错误页面。可以看出这个页面仅仅告诉我们目标应用当前无法正常处理本次请求，除了提供的响应状态码（“HTTP ERROR 500”），它并没有提供任何有益于纠错的辅助信息。 图1　默认的错误页面 有人认为浏览器上虽然没有显示任何详细的错误信息，但这并不意味着HTTP响应报文中也没有携带任何详细的出错信息。如下所示的服务端会返回的HTTP响应报文，该响应没有主体内容，有限的几个报头也并没有承载任何与错误有关的信息。 HTTP/1.1 500 Internal Server Error Content-Length: 0 Date: Sun, 07 Nov 2021 08:34:18 GMT Server: Kestrel 由于应用并没有中断，浏览器上也并没有显示任何具有针对性的错误信息，我们无法知道背后究竟出现了什么错误。这个问题有两种解决方案：一种是利用日志，ASP.NET在处理请求过程中出现异常时，会发出相应的日志事件，我们可以注册相应的ILoggerProvider对象将日志输出到指定的渠道。另一种解决方案就是利用注册的DeveloperExceptionPageMiddleware中间件显示一个“开发者异常页面（Developer Exception Page）”。 如下的演示程序调用IApplicationBuilder接口的UseDeveloperExceptionPage扩展方法来注册了这个中间件。该程序注册了一个路由模板为“{foo}/{bar}”的终结点，后者在处理请求时直接抛出异常。 var app = WebApplication.Create(); app.UseDeveloperExceptionPage(); app.MapGet("{foo}/{bar}", void () => throw new InvalidOperationException("Manually thrown exception")); app.Run(); 一旦注册了DeveloperExceptionPageMiddleware中间件，ASP.NET应用在处理请求过程中出现的异常信息就会以图2所示的形式直接出现在浏览器上，我们可以在这个页面中看到几乎所有的错误信息，包括异常的类型、消息和堆栈信息等。 图2　开发者异常页面（基本信息） 开发者异常页面除了显示与抛出的异常相关的信息，还会以图3所示的形式显示与当前请求上下文相关的信息，包括当前请求URL携带的所有查询字符串、所有请求报头、Cookie的内容和路由信息（终结点和路由参数）。如此详尽的信息无疑会极大地帮助开发人员尽快找出错误的根源。由于此页面上往往会携带一些敏感的信息，所以只有在开发环境才能注册这个中间件。实际上Minimal API在开发环境会默认注册这个中间件。