如何发送状态代码“500”对于IIS中的通用错误页面？ [英] How to send status code "500" for generic error page in IIS?
问题描述
我使用ASP.NET的< customErrors> 指令使用通用错误页面。
I am using a generic error page using ASP.NET's <customErrors> directive.
<customErrors mode="On" defaultRedirect="500.html" redirectMode="ResponseRewrite">
</customErrors>
问题 - 发生错误时，此页面不会返回HTTP状态500。它来自200.所以链接检查器和蜘蛛没有看到任何问题。
Problem - when an error occurs, this page does not return HTTP status "500". It comes as 200. So link checkers and spiders do not see that there is any problem.
如何发送500 HTTP状态以及静态500.html页面？
How can I send the 500 HTTP status along with the static 500.html page?
要求：
- 我必须使用redirectMode =ResponseRewrite
- 我不能使用动态页面，只能使用静态.html。
推荐答案
customErrors元素的MSDN文档声明它是由System.Web.Configuration.CustomErrorsSection实现的。如果我们使用Red Gate的.NET Reflector来分析该类，我们可以看到框架中使用该设置的位置。
The MSDN documentation for the customErrors element states that it is implemented by System.Web.Configuration.CustomErrorsSection. If we use Red Gate's .NET Reflector to analyze that class, we can see where that setting is used in the Framework.
它由System.Web.UI使用。 Page.HandleError和System.Web.HttpResponse.ReportRuntimeError。
It is used by System.Web.UI.Page.HandleError and System.Web.HttpResponse.ReportRuntimeError.
这两个最终都调用了System.Web.HttpResponse.RedirectToErrorPage。 （此方法的名称令人困惑：请务必注意RedirectToErrorPage将redirectMode设置作为参数，因此即使您正在使用ResponseRewrite并且实际上没有重定向也会调用它。）
Both of these end up calling System.Web.HttpResponse.RedirectToErrorPage. (The name of this method is confusing: it is important to note that RedirectToErrorPage takes the redirectMode setting as a parameter, so it is called even if you are using ResponseRewrite and no redirection actually happens.)
RedirectToErrorPage方法的相关部分是：
The relevant part of the RedirectToErrorPage method is:
if (redirectMode == CustomErrorsRedirectMode.ResponseRewrite)
{
this.Context.Server.Execute(url);
}
似乎没有任何方法可以设置响应代码错误处理：在一天结束时，它只是一个普通的Server.Execute。因此，您似乎不可避免地需要编写代码来实现所需的HTTP响应。
There doesn't appear to be any way to set the response code in the error handling: at the end of the day it's just a plain Server.Execute. It therefore seems unavoidable that you would need to write code to achieve the HTTP response you want.
您能否重新检查为什么要使用普通的.html文件？这似乎是错误处理的明智选择，因为您不希望在可能导致发生其他错误的情况下经历.aspx页面的所有开销。
Can you re-examine why you want to use a plain .html file? This seems a sensible choice for error handling, because you don't want to go through all the overhead of a .aspx page when that might cause another error to occur.
但也许有一些中间立场与.html文件一样健壮？
But perhaps there is some middle ground which will be just as robust as a .html file?
例如，您可以制作预编译的HttpHandler，将其注册到URL / 500.error，然后将500.error设为defaultRedirect页面。 （这与ScriptResource.axd的工作原理类似。）如果您将模块预编译为DLL（而不是从普通的.axd文件中进行动态编译），您可能会发现它在面对错误的条件。如果你遇到一个错误甚至不会起作用，那么一个静态的.html文件可能也不会工作 - 请记住，customErrors指令仍然依赖于在底层运行的.NET，并且仍然使用StaticFileHandler来提供服务您的.html文件。
For example, you could make a precompiled HttpHandler, register it to the URL /500.error, and then make 500.error your defaultRedirect page. (This would be similar to how ScriptResource.axd works.) If you precompile your module into a DLL (as opposed to on-the-fly compilation from a plain old .axd file), you may find it is just as robust in the face of error conditions. If you encounter an error where not even this will work, then a static .html file probably won't work either -- keep in mind that the customErrors directive still relies on .NET running under the hood, and still uses the StaticFileHandler to serve your .html file.
或者您可以考虑在IIS应用程序前面使用反向代理，即使面对应用程序的灾难性故障，也可以提供友好的500页池。这将是更多的设置工作，但将比customErrors更强大，例如如果你的web.config被破坏，即使是customErrors也行不通。
Alternatively you could consider a reverse proxy in front of your IIS application which would serve a friendly 500 page even in the face of catastrophic failure of the application pool. This would be more work to set up, but would be even more robust than customErrors, e.g. if your web.config becomes corrupted, even customErrors won't work.
这篇关于如何发送状态代码“500”对于IIS中的通用错误页面？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
