[Reprint] Summary of custom error pages and exception logs for ASP. IIS7 above

Summary of custom error pages and exception logs for ASP. IIS7 above Wang Yujie 2014-1-11 Saturday 02:31455 Reads 1 Comments

Custom error pages and exception records is a very old topic, but it can still make people explode. After I have done countless experiments and experience and principles, write this article, has been the police later generations.

Scope and limitations of this article

1. This article applies only to ASP. NET 4 Integrated mode applications that are deployed in IIS7 or later versions. IIS7 above means that Windows Server 2008 and above servers are applicable. I've already measured it on the ws2012r2,iis8.
2. The methods in this article apply to both ASP. NET WebForm and MVC applications.

The issues addressed in this article

1. is the static error page good or the dynamic error page good? How do I design error handling for ASP?
2. I don't want the error page to follow the aspxerrorpath= ... This little tail.
3. My custom error page debugging in VS is good, why not deploy to the server will not come out?
4. My custom error page can be displayed correctly, but why is the HTTP status code returned incorrectly?
5. How to record the Exception log, there is no better practice?

One, the choice of error page

Choose a static HTML page as the error page, or use an. aspx or MVC view to display the error page? The problem is that many people have different preferences. I strongly recommend that you use HTML static pages as error pages. Please look at the analysis:

First, with the dynamic page of the person, nothing but to solve three problems: Display error summary, log, return the correct status code. However, the biggest problem with dynamic pages is that they are handled by ASP. NET and background code, in case your background code is exploded, or if ASP. NET itself explodes, then your error page will itself cause another error if it is requested. Static HTML does not have this problem. The practice of building a errorcontroller in MVC is even more unacceptable. MVC is based on ASP. MVC's controller can only catch MVC's own errors, not catch the error of the ASP, meaning that when your error is not at the MVC level, Errorcontroller does not have any useful. For example, when you deploy an MVC application that lacks MVC DLLs, the MVC framework itself can't get out of the way, how does this bug get caught?

In addition, I don't think you should ever display any error summaries to visitors on an internet site. This is very insecure. So there is absolutely no need to use dynamic pages.

The question of returning the correct status code is this: many small partners found their error page can be displayed, but the return status code is 200OK, so helpless under the dynamic page, write on response.statuscode = 500 such code to strong. This is a solution in a later article, so don't risk using dynamic pages for status code. Some small partners will ask, I only write a response.statuscode=500 what is the risk? Oh, think of this situation: 404.cshtml,razor engine DLL is missing ...

In addition, one principle is that the error page should be independent. If your static page to use external resources such as pictures and CSS, it is recommended to embed in the page, make a single file, so as not to display the wrong page when the request related resources to throw an exception again. The small partner asks again, asks a CSS and the picture what, the swelling will cause the abnormality? Then you look at this: resources.axd?image= ..., hehe.

So what happens when I use a static page to log logs? The correct method should be given to the "Application_Error" event in Global.asax. There will be a Xiang solution later.

Second, configuration error page: CustomErrors VS httperrors

First, there are two ways to display the error page. If you open IIS, you will see two places with Error pages:. NET error pages and error pages.

From the developer's point of view, the ". NET Error Pages" under the ASP. is the Web.confg/system.web/customerrors node. The "Error Pages" Under IIS section is the Web.config/system.webserver/httperrors node, which is unique to IIS7.

Any change to these two places on IIS is actually a modification to the Web. config file.

So which one should we use to configure the custom error page? One of my principles is to have IIS present the error page to the user, not to be dependent on ASP. The apes are as follows:

Customerror's question:

A) By default, Customerror will display the error page in 302 redirects, if the client requests a 404 page, then it will be a 302 followed by a 200OK, for humans This is OK, after all, the user saw a friendly error page, But search engines will think that this nonexistent address is the normal page and put your 404 page revenue search results. And each time an error is thrown, the URL will follow Aspxerrorpath's small tail, such as:

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

b) After configuring the Redirectmode= "Responserewrite", it will cause a problem, in 09 when a bug was submitted to Ms Connect, but Microsoft is not going to fix this bug. That is, the mode is valid on the VS-brought ASP. NET development Server, the browser displays the parsed HTML page, and after deployment to IIS, the browser displays the raw HTML, which is the HTML code of your error page. And the behavior is not deterministic, and God knows how your site will explode in a different environment.

c) IIS7 the specificity of the above version: in Integrated mode, the IIS error page takes precedence over the ASP. NET error page, that is, the default error page of IIS overrides the customerrors page you configured, which is why your debug at Vs is good, and the deployment to the server explodes.

After IIS7, depending on your configuration, the user's request is not necessarily processed on the ASP. If the exception is thrown in a location other than ASP. NET, the customerrors error page is not displayed.

Therefore, I strongly recommend that you use the HttpErrors node instead of customerrors to configure the error page.

Third, file or the correct matching method of Executeurl:httperrors

Put a proper configuration example: It is used with file.

Note two places:

1. Slash is the backslash "\" of the Windows file path instead of the slash "/" of URL URL
2. Path does not start with "~" or "\"

Don't ask me why, I do not know, anyway this is good.

If you unfortunately use Executeurl, you will find that the URL path can only start with "/":

And your error page will return 200OK instead of the correct 404, 500, and other error codes. This has been written in my previous article:

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

Using file means that when the error is burst, IIS will plug the target file, such as 404.html content, into the current response stream, keeping the HTTP status code still 404. That's what we want.

Iv. Abnormal log records

In the beginning of the article raised a question, wood has a dynamic page, how to log error logs? My practice is to deal with it in the Global.asax.

The sample code for the Application_Error event is as follows:

Varexception= HttpContext.Current.Server.GetLastError();If (Null !=exception){ By default 500 VarStatusCode= (Int)HttpStatusCode.Internalservererror; If (exceptionIs HttpException) {StatusCode= New HttpException(Null,exception).Gethttpcode(); } Else If (exceptionIs UnauthorizedAccessException) { To prevent login prompt in IIS Which would appear when returning 401.StatusCode= (Int)HttpStatusCode.Forbidden; } If ((Loghttpnotfound &&StatusCode== 404) ||StatusCode!= 404) { If (Null !=_loggerfunc) { Loggerfunc(String.format (, httpcontext. Current. Request. Url Exception} } exceptioninfo = Exception. Message; _statuscode = Statuscode}             /span>                

A small suggestion is not to record 404 errors, because your website on the Internet will be a variety of search engines, scanning tools and hackers to explode, there is an attack by the dictionary to guess the directory, return 404 is not exist, return 403 is the existence. So, when you encounter this boring hacker, if you record 404 requests, then your log will be very large ...

I remember that the components used in the log are Nlog, simple to use and easy to work with. Log4net the goods have not been updated for a long time.

If you decide to design a log module yourself, remember the two principles:

The log module itself does not affect the entire system as it explodes, meaning that any exception in the log module should not bubble out.

Considering concurrent write logs, the log operation should be fire and forget, and the application cannot wait for the log to be written.

V. Summary

1. Use static HTML pages as error pages.
2. Using HttpErrors Configuration error page, the purpose is to be compatible with IIS7 above environment, return correct error code, remove Aspxerrorpath small tail.
3. Log records are written in Global.asax and recorded in the Application_Error event.

[Reprint] Summary of custom error pages and exception logs for ASP. IIS7 above