[转载]针对IIS7以上的ASP.NET网站自定义错误页面与异常日志总结

news/2024/5/10 9:04:29/文章来源:https://blog.csdn.net/weixin_30415801/article/details/95373035

针对IIS7以上的ASP.NET网站自定义错误页面与异常日志总结

汪宇杰

2014-1-11 星期六 02:31

455 Reads 1 Comments

自定义错误页面和异常记录是个很古老的话题了，但依旧可以让人爆到现在。在我做了无数次试验并总结经验和原则后，写下本文，已警后人。

本文的范围和限制

本文仅仅适用于部署在IIS7或以上版本中的ASP.NET 4.0集成模式应用程序。IIS7以上的意思是Windows Server 2008以上服务器适用。我已在WS2012R2，IIS8上测过。
本文的方法均适用于ASP.NET WebForm和MVC应用程序。

本文针对的问题

静态错误页面好还是动态错误页面好？我该如何设计ASP.NET网站错误处理？
我不希望错误页面后面跟上aspxerrorpath=…这个小尾巴。
我的自定义错误页面在VS里调试是好的，为什么部署到服务器上就出不来了？
我的自定义错误页面可以正常显示，但为什么返回的Http状态码不正确？
异常日志该怎样记录，有没有比较好的实践？

一、错误页面的选择

选择静态html页面作为错误页，还是使用.aspx或是MVC View来显示错误页面好？这个问题许多人的偏好都不一样。我强烈建议大家用html静态页面作为错误页。请看分析：

首先，用动态页面的人，无非是为了解决三个问题：显示错误摘要、记录日志、返回正确的状态码。但是，动态页面最大的问题在于，它们本身是要经过ASP.NET和后台代码处理的，万一你的后台代码是爆的，或者ASP.NET自己爆了，那你的错误页面一旦被请求，本身就会引发另一个错误。而静态html是不会有这个问题的。至于在MVC里专门建一个ErrorController的做法就更不可取了。MVC是基于ASP.NET之上的，MVC的Controller只能抓MVC自己的错误，抓不到ASP.NET的错误，意思就是说，当你的错误并不在MVC层面上的时候，ErrorController没有任何用武之地。例如，当你部署的MVC应用程序缺少MVC的dll时候，MVC框架本身都跑不起来，这个错误如何去抓？

另外，我认为在一个Internet站点上，绝不应该向访客显示任何的错误摘要。这是非常不安全的。所以完全没有必要用动态页面。

至于返回正确状态码的问题是这样的：不少小伙伴发现自己的错误页面能够显示，但返回的状态码是200OK，所以无奈之下用动态页面，写上Response.StatusCode = 500这样的代码来强撸。这个在稍后的文章里有解决方案，所以不要为了状态码而冒险用动态页面。有的小伙伴会问，我只写一笔Response.StatusCode=500能有什么风险？呵呵，想想这种情况：404.cshtml，razor引擎的dll不见了……

另外，一个原则是：错误页面应当是独立的。如果你的静态页面要用到图片和CSS等外部资源，建议嵌入在页面里边，做成单文件的，以免显示错误页面时请求相关资源再次引发异常。小伙伴又要问了，请求个CSS和图片什么的，肿么会引发异常呢？那你看看这个：resources.axd?image=…，呵呵。

那么用了静态页面以后，记录日志怎么办呢？正确的方法应该是交给Global.asax中的“Application_Error”事件处理。稍后会有翔解。

二、配置错误页面：customErrors VS httpErrors

首先，错误页面的显示方式有两种。如果你打开IIS，会看到两个配错误页的地方：.NET Error Pages和Error Pages。

站在开发者的角度来说，ASP.NET Section下的“.NET Error Pages”就是web.confg/system.web/customErrors节点。而IIS Section下的”Error Pages”是web.config/system.webServer/httpErrors节点，这个是IIS7以上特有的。

任何在IIS上对这两处的更改其实都是在修改web.config文件。

那么我们该用哪一个来配置自定义错误页呢？我的一个原则是：让IIS向用户展示错误页面，而不要依赖于ASP.NET。猿因如下：

CustomError的问题：

a) 在默认情况下，CustomError会采用302重定向的方式来展示错误页面，如果客户端请求了一个404的页面，那它得到的将会是一个302紧接着一个200OK，对于人类来说这是OK的，毕竟用户看到了友好的错误页面，但搜索引擎会认为这个不存在的地址是正常的页面，并把你的404页面收入搜索结果。并且每次引发错误，URL后边都会跟上aspxerrorpath这个小尾巴，比如：

http://yoursite.com/404.html?aspxerrorpath=/somethingnotexsit

b) 在配置了redirectMode=“ResponseRewrite”后，会引发一个问题，09年就有人当bug提交到MS Connect上了，但目前微软不打算fix这个bug。即该模式在VS自带的ASP.NET Development Server上是有效的，浏览器显示的是解析后的HTML页面，而部署到IIS上之后，浏览器显示是raw html，即你的错误页面的HTML代码。并且该行为不具有确定性，天晓得你的网站换个环境部署又会爆成什么样。

c) IIS7以上版本的特殊性：在集成模式下，IIS的错误页面会优先于ASP.NET错误页面，即IIS的默认错误页会覆盖你配置的CustomErrors页面，这就是为什么你在VS下调试是好的，部署到服务器上就爆了。

在IIS7之后，取决于你的配置，用户的请求并不都一定在ASP.NET管线上处理。如果引发异常的地方不在ASP.NET，那就不会显示CustomErrors的错误页面。

所以，我强烈建议大家用httpErrors节点替代CustomErrors来配置错误页面。

三、File还是ExecuteURL：httpErrors的正确配法

先贴一个正确的配置样例：是用File配的。

注意两处地方：

斜杠是Windows文件路径的反斜杠“\”而不是网址URL的斜杠“/”
Path不要以“~”或“\”开头

不要问我为什么，我也不知道，反正这么弄就是好的。

如果你不幸用了ExecuteURL，你会发现URL路径只能以“/”开头：

并且你的错误页会返回200OK而不是正确的404、500等错误码。这在我以前的文章里写过：

http://diaosbook.com/Post/2012/6/24/correct-way-to-implement-custom-error-page-return-statecode-instead-of-http-200

而用File的意思是，当错误被爆出来之后，IIS会把目标File，比如404.html的内容，塞到当前的Response流里面，保持Http状态码依旧是404。这就是我们想要的。

四、异常日志记录

文章在一开始就提了个问题，木有了动态页面，怎么记录错误日志？我的做法是在Global.asax里处理。

Application_Error事件样例代码如下：

var exception = HttpContext.Current.Server.GetLastError(); if (null != exception) { // by default 500 var statusCode = (int)HttpStatusCode.InternalServerError; if (exception is HttpException) { statusCode = new HttpException(null, exception).GetHttpCode(); } else if (exception is UnauthorizedAccessException) { // to prevent login prompt in IIS // which will appear when returning 401. statusCode = (int)HttpStatusCode.Forbidden; } if ((LogHttpNotFound && statusCode == 404) || statusCode != 404) { if (null != _loggerFunc) { LoggerFunc(string.Format("ASP.NET Error Captured, Request URL: {0}, Exception:", HttpContext.Current.Request.Url), exception); } } ExceptionInfo = exception.Message; _statusCode = statusCode; }