Code

My focus as a developer is to give the end user the best application I can. With the focus being on feature development and quick turn around, sometimes bugs get through, even with an extensive suite of unit tests. I also have to be mindful that my set of users includes bots: Google, Bing, and yes Yahoo.

Bots are important in helping your site thrive in the ever growing market of the internet. It is important to communicate correctly to them. Think of them as your official ambassadors to your community of users. If the bots are confused, then they will not portray the correct information to the real live people you want using your site.

Error pages are important in communicating what is a page I want indexed, or what is a page that can be disregarded. Bots normally only show pages that return a 200 (OK) status in results pages. Other statuses do not show up regularly at the top of a search results page.

Question: How do I ensure that my ASP.Net MVC pages are returning the correct status code?

Answer: Setup, Setup, Setup.

There is nothing glamorous about this post, but it is fundamental to security and the overall health of my site’s public image.

Step 1: Web.Config

Config is tricky for several reasons, you want to cover the major errors, and you want the status code to be correct when the page displays your nice error page.

<customErrors mode="RemoteOnly" redirectMode="ResponseRewrite" defaultRedirect="~/Error/500">

<error statusCode="403" redirect="~/Error/403" />

<error statusCode="404" redirect="~/Error/404" />

</customErrors>

Note: For IIS7 users (which should be everyone now), remember to put this in the system.webServer section. This forces IIS7 to let your application handle errors. Without this you’ll get the ugly gray error screens that are par for IIS7.

<httpErrors existingResponse="PassThrough" />

The thing to take away from the configuration above is that the redirectMode is set to ResponseRewrite. This insures that when a page errors on /hello/kitty, it stays on /hello/kitty. This tells the user that this page is borked, and also any bot that might have traveled their. The redirects are pointing to an error controller, but before we get to the controller let’s look at how the routes are set up.

Step 2: Route Setup

Routes are very important, I cannot stress this enough. If you are using the default route setup that comes with Asp.Net MVC then DON’T!!! The default catch all is terrible for many reasons, but the biggest reason is that it will catch urls that have no relevance in the application itself. This will confuse search engines, and ultimately users who see those crazy results in the search engine results.

After meticulously crafting your routes, you will need these two additional routes.

routes.MapRoute(

"Error",

"Error/{status}",

new { controller = "Error", action = "Index", status = UrlParameter.Optional }

);

routes.MapRoute(

"404",

"{*url}",

new { controller = "Error", action = "Index", status = 404 }  // 404s

);

The first route should be familiar looking. It is what will catch the redirects from the configuration. The second route is a catch all. Yes I just admonished you for having a catch all route, but this one is different. We have a catch all for mistakes. Think of it as a safety net for a trapeze artist. It is important to have specifically defined you routes for this to work. The next step is create the controller.

Step 3: The Error Controller

public class ErrorController : Controller

{

public ActionResult Index(int? status)

{

var codes = Enum.GetValues(typeof (HttpStatusCode)).Cast<int>();

var httpCode = status.HasValue

? (int?)codes.FirstOrDefault(c => c == status.Value) ?? 500

: 500;

// insure response is the right code

Response.StatusCode = httpCode;

switch (httpCode) {

case 404:

ViewBag.Message = "The page you were looking for could not be found.";

break;

default:

ViewBag.Message = "An error occurred while processing your request.";

break;

}

return View("Error");

}

}

The thing to note here is the Response.StatusCode being set. It will ensure when you page is rendered that the resulting response is correctly tagged. Now you can craft a beautiful Error view and drop it in Shared or in the Error views folder. I usually drop mine in Shared.

Conclusion

Error pages are very important to get right, they communicate to your users and search engines that what they are currently looking at is a mistake and to ignore it. Hopefully they never see those pages, but when they do, they know that you are hard at work fixing the issue that caused them to see it in the first place.

Stay Code Thirsty My Friends.