You can download the HttpModule here.
Defining custom error pages is a convenient way to show users a friendly page when they encounter an HTTP error such as a 404 Not Found, or a 500 Server Error. Unfortunately ASP.NET handles custom error pages by responding with a 302 Temporary redirect to the error page that was defined. For example, consider an example application that has IIS configured to map all requests to it, and has the following customErrors element defined in its web.config:
<customErrors mode="RemoteOnly" defaultRedirect="~/error.aspx">
<error statusCode="404" redirect="~/404.aspx" />
</customError>
If a user requested a page that didn't exist, then the HTTP response would look something like:
http://www.domain.com/non-existant-page.aspx --> 302 Found
http://www.domain.com/404.aspx --> 404 Not Found
Date: Sat, 26 Jan 2008 03:08:21 GMT
Server: Microsoft-IIS/6.0
Content-Length: 24753
Content-Type: text/html; charset=utf-8
X-Powered-By: ASP.NET
As you can see, there is a 302 redirect that occurs to send the user to the custom error page. This is not ideal for two reasons:
1) It's bad for SEO
When a search engine spiders crawls your site and comes across a page that doesn't exist, you want to make sure you respond with an HTTP status of 404 and send it on its way. Otherwise you may end up with duplicate content issues or indexing problems, depending on the spider and search engine.
2) It can lead to more incorrect HTTP status responses
This ties in with the first point, but can be significantly more serious. If the custom error page is not configured to response with the correct status code then the HTTP response could end up looking like:
http://www.domain.com/non-existant-page.aspx --> 302 Found
http://www.domain.com/404.aspx --> 200 OK
Date: Sat, 26 Jan 2008 03:08:21 GMT
Server: Microsoft-IIS/6.0
Content-Length: 24753
Content-Type: text/html; charset=utf-8
X-Powered-By: ASP.NET
Which would almost guarantee that there would be duplicate content issues for the site with the search engines, as the search spiders are simply going to assume that the error page is a normal page, like any other.Furthermore it will probably cause some website and server administration headaches, as HTTP errors won't be accurately logged, making them harder to track and identify.
I tried to find a solution to this problem, but I didn't have any luck finding anything, other than people who were also looking for a way to get around it. So I did what I usually do, and created my own solution.
The solution comes in the form of a small HTTP module that hooks onto the HttpContext.Error event. When an error occurs, the module checks if the error's type is an HttpException. If the error is an HttpException, then the following process takes place:
- The response headers are cleared (context.Response.ClearHeaders() )
- The response status code is set to match the actual HttpException.GetHttpCode() value (context.Response.StatusCode = HttpException.GetHttpCode())
- The customErrorsSection from the web.config is checked to see if the HTTP status code (HttpException.GetHttpCode() ) is defined.
- If the statusCode is defined in the customErrorsSection then the request is transferred, server-side, to the custom error page. (context.Server.Transfer(customErrorsCollection.Get(statusCode.ToString).Redirect) )
- If the statusCode is not defined in the customErrorsSection, then the response is flushed, immediately sending the response to the client.(context.Response.Flush() )
Here is the source code for the module.
1: Imports System.Web
2: Imports System.Web.Configuration
3:
4: Public Class HttpErrorModule
5: Implements IHttpModule
6:
7: Public Sub Dispose() Implements System.Web.IHttpModule.Dispose
8: 'Nothing to dispose.
9: End Sub
10:
11: Public Sub Init(ByVal context As System.Web.HttpApplication) Implements System.Web.IHttpModule.Init
12: AddHandler context.Error, New EventHandler(AddressOf Context_Error)
13: End Sub
14:
15: Private Sub Context_Error(ByVal sender As Object, ByVal e As EventArgs)
16: Dim context As HttpContext = CType(sender, HttpApplication).Context
17: If (context.Error.GetType Is GetType(HttpException)) Then
18: ' Get the Web application configuration.
19: Dim configuration As System.Configuration.Configuration = WebConfigurationManager.OpenWebConfiguration("~/web.config") 20:
21: ' Get the section.
22: Dim customErrorsSection As CustomErrorsSection = CType(configuration.GetSection("system.web/customErrors"), CustomErrorsSection) 23:
24: ' Get the collection
25: Dim customErrorsCollection As CustomErrorCollection = customErrorsSection.Errors
26:
27: Dim statusCode As Integer = CType(context.Error, HttpException).GetHttpCode
28:
29: 'Clears existing response headers and sets the desired ones.
30: context.Response.ClearHeaders()
31: context.Response.StatusCode = statusCode
32: If (customErrorsCollection.Item(statusCode.ToString) IsNot Nothing) Then
33: context.Server.Transfer(customErrorsCollection.Get(statusCode.ToString).Redirect)
34: Else
35: context.Response.Flush()
36: End If
37:
38: End If
39:
40: End Sub
41:
42: End Class
The following element also needs to be added to the httpModules element in your web.config (replace the attribute values if you aren't using the downloaded binary):
<httpModules>
<add name="HttpErrorModule" type="ColinCochrane.HttpErrorModule, ColinCochrane" />
</httpModules>
And there you go! No more 302 redirects to your custom error pages.
Subscribe
Email Subscription