customErrors 元素的 MSDN 文档声明它由 System.Web.Configuration.CustomErrorsSection 实现。如果我们使用 Red Gate 的 .NET Reflector 来分析该类,我们可以看到该设置在框架中的使用位置。
它由 System.Web.UI.Page.HandleError 和 System.Web.HttpResponse.ReportRuntimeError 使用。
这两个最终都调用 System.Web.HttpResponse.RedirectToErrorPage。(此方法的名称令人困惑:重要的是要注意 RedirectToErrorPage 将 redirectMode 设置作为参数,因此即使您使用的是 ResponseRewrite 并且实际上没有发生重定向,它也会被调用。)
RedirectToErrorPage 方法的相关部分是:
if (redirectMode == CustomErrorsRedirectMode.ResponseRewrite)
{
this.Context.Server.Execute(url);
}
似乎没有任何方法可以在错误处理中设置响应代码:归根结底,它只是一个普通的 Server.Execute。因此,您似乎不可避免地需要编写代码来实现所需的 HTTP 响应。
你能重新检查一下为什么要使用普通的 .html 文件吗?这似乎是错误处理的明智选择,因为您不希望在可能导致发生另一个错误时经历 .aspx 页面的所有开销。
但也许有一些中间立场会像 .html 文件一样健壮?
例如,您可以制作一个预编译的 HttpHandler,将其注册到 URL /500.error,然后将 500.error 设为您的默认重定向页面。(这类似于 ScriptResource.axd 的工作方式。)如果您将模块预编译为 DLL(而不是从普通的旧 .axd 文件进行动态编译),您可能会发现它在面对错误情况。如果您遇到一个错误,即使这也不起作用,那么静态 .html 文件可能也不起作用 - 请记住,customErrors 指令仍然依赖于在后台运行的 .NET,并且仍然使用 StaticFileHandler 来提供服务你的 .html 文件。
或者,您可以考虑在 IIS 应用程序前面使用反向代理,即使面对应用程序池的灾难性故障,它也可以提供友好的 500 页。这将需要更多的工作来设置,但会比 customErrors 更健壮,例如,如果您的 web.config 损坏,即使 customErrors 也不起作用。