The title says it all. Actually a ton of information on how to do this, and I'm very close. I read a few things on Google, as well as the following stackoverflow posts:
How to handle 404 in ASP.NET MVC?
How can I handle 404 correctly in ASP.NET MVC?
Custom error pages on asp.net MVC3
http://blog.davebouwman.com/2011/04/21/custom-404-pages-for-asp-net-mvc-3/
I have 404 working at the action level. And I use the suffix * .aspx on my controllers. If you have a url like
"http://blahblah/AppName/idontexist.aspx"
User error controller loaded. My problem boils down to a controller that doesn't have .aspx, nor does it exist. This gives a typical IIS Server 404 html page that I don't want. Another bend in the job is that I cannot change the configuration of IIS. I have to handle this through the code / web.config / global.asax (or some other part of the project that I did not think about).
Here are my entries in web.config (this is the root web.config, not one):
<httpErrors defaultPath="/Error.aspx/HttpError" errorMode="Custom" existingResponse="Replace" defaultResponseMode="ExecuteURL"> <remove statusCode="500" subStatusCode="-1" /> <remove statusCode="404" subStatusCode="-1" /> <error statusCode="500" path="/Error.aspx/HttpError" responseMode="ExecuteURL" /> <error statusCode="404" path="/Error.aspx/NotFound" responseMode="ExecuteURL" /> </httpErrors> <customErrors mode="On" defaultRedirect="~/Error.aspx/HttpError"> <error redirect="~/Error.aspx/NotFound" statusCode="404" /> </customErrors>
And here are my routes in global.asax:
routes.MapRoute( "Default", // Route name "{controller}.aspx/{action}/{id}", // URL with parameters new { controller = "StartController", action = "StartAction", id = UrlParameter.Optional } // Parameter defaults ); routes.MapRoute( "NotFoundController", // Route name "{controller}.aspx", // URL with parameters new { controller = "Error", action = "NotFound" } // Parameter defaults ); routes.MapRoute( "NotFoundController2", // Route name "{controller}", // URL with parameters new { controller = "Error", action = "NotFound" } // Parameter defaults ); routes.MapRoute( "Root", // Route name "", // URL with parameters new { controller = "StartController", action = "StartAction", id = UrlParameter.Optional } // Parameter defaults );
I also think that one catch with using routes to locate them is that I am losing the 404 status code; however, since the route indicates an action specifically designed for this purpose, I believe that this point is controversial.
In any case, any thoughts, suggestions or criticisms will be welcome. I am very close here. Thanks!
EDIT 1
I was still studying this. Is there a way to define a custom route restriction that will be redirected to the Error Controller if the text “.aspx” is not found in the URL?
EDIT 2
It doesn't seem like the restrictions have been used. I also tried to implement
protected void Application_Error() { }
for implementation on http://blog.davebouwman.com/2011/04/21/custom-404-pages-for-asp-net-mvc-3/ , but when I do not specify .aspx for the controller, it looks like an application never gets a chance to throw a mistake. It seems that IIS is being processed before the application can respond to it.
If I could make IIS changes, preferably only for this application virtual directory entry, would this allow a more viable solution for this?
If I could capture the URL somewhere, look for .aspx, and if it was not found, output 404 not found, and redirect to the 404 application level page instead of the standard IIS, which will be pretty close to perfect.
Thoughts?
EDIT 3
I believe that processing this script is simply not possible if your application is not the root site for the IIS server, and not a virtual directory. I noticed that in IIS 6.0 you can configure the default IIS error pages. In addition, you can replace specific cases with a URL. I tried to do this with a virtual directory site, but the IIS 404 Not found page is displayed.
So this means: you can handle this on IIS 6 if you have a dumb amount of control over your installation, and the site you are doing this for is the root site.
Not entirely applicable in the real scenarios that I imagine.