We Keep Coding

Custom Error Page handled by Application when file not found

In asp.net mvc is it possible to redirect to a custom error page when a static file is is not found rather than have IIS serve an error page?
The example below, adding this to System.Web in the web.config file will redirect the user to an Error controller and return an Error page view.
<customErrors mode="RemoteOnly" defaultRedirect="~/Error" redirectMode="ResponseRedirect">
<error statusCode="404" redirect="~/Error" />
</customErrors>
That is fine if the url resembels a controller and action but if a static file was typed into the url such as mysite.com/myFile.html, the custom error page isn't returned and IIS serves an Error page. Is it possible to have this handled within the mvc application, perhaps by redirecting the user to the same Error controller that the above custom error handler redirects to?

Is there a simple way to replace the ASP.NET Web API HTML error page with a simple Error.json file?

I feel like I may be over complicating things with a guide like this one:
How to override all standard error pages in WebAPI
I couldn't get it to work because I think the version of ASP.NET Web API that I'm using has deprecated the context.Request.CreateErrorInfoResponse()
All I want to do is display an HTTP 403 Forbidden as a single static file located in ~/Error.json
I've tried doing this to my Web.config file:
<system.web>
<customErrors mode="RemoteOnly">
<error statusCode="403" redirect="~/Error.json" />
</customErrors>
</system.web>
And I've tried this too:
<system.web>
<customErrors mode="On">
<error statusCode="403" redirect="~/Error.json" />
</customErrors>
</system.web>
It doesn't seem to have any effect at all when this exception is thrown:
throw new APIException(HttpStatusCode.Forbidden, new MessageError("foobar"));
In my application, there will be only one situation where a Forbidden response is received, and I don't want my RESTful API to be returning an HTML response in this event.
What can I do to fix this?
The reason why I need to do this is to render the Web Application useless if a customer tries to crack or pirate this web application. I would like to do all of this within Startup.cs if it's possible to crash the app and to return a json response of the error rather than an HTML response that the throw new Exception method does by default.

ASP.NET MVC customError page doesn't get displayed for some of the 400 errors

I'm having quite an interesting issue with the custom error pages management for a new ASP.NET MVC application.
This issue is like this:
- if I'm calling an URL (doesn't matter which) with a "bad" argument at the end of URL, like ..../c<, the application is displaying the correct server error page as instructed in the web.config;
- if I'm changing the URL to a more nasty one, like .../<c (to look more like an HTML tag, there is no more server error page displayed in the browser and instead of that, I'm getting a plain YSOD with a message like An exception occurred while processing your request. Additionally, another exception occurred while executing the custom error page for the first exception. The request has been terminated.
According to ELMAH, both requests ended with a 400 status code and the message being:
- for the first one: System.Web.HttpException (0x80004005): A potentially dangerous Request.Path value was detected from the client (<).
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
- for the second one: System.Web.HttpException (0x80004005): A potentially dangerous Request.Path value was detected from the client (<).
at System.Web.HttpRequest.ValidateInputIfRequiredByConfig()
at System.Web.HttpApplication.PipelineStepManager.ValidateHelper(HttpContext context)
So, both errors are the same, the status code is the same, but for one of the errors, the custom error page is not getting displayed. I've also went to global.asax in debug mode and checked the Server.GetLastError() in protected void Application_Error(object sender, EventArgs e) and again, both errors were the same, nothing is different.
In web.config, this is how my <customErrors> tag looks like:
<customErrors mode="On" defaultRedirect="/ServerError.aspx" redirectMode="ResponseRewrite">
<error statusCode="500" redirect="/ServerError.aspx" />
<error statusCode="404" redirect="/PageNotFound.aspx" />
</customErrors>
Can please someone tell me why the behavior is different in these two cases?
Thank you very much for your time.

There's a lot of misinformation and/or out-of-date solutions regarding error handling in IIS 7+. The main things to understand are:-
.NET 4.0 made breaking changes to ASP.NET's request validation.
IIS 7+ introduced a new way of handling custom error pages.
Most people are using hodge-podge solutions involving all of customErrors, httpErrors the Application_Error handler, and often setting requestValidationMode="2.0" on the httpRuntime property and/or disabling request validation entirely! This makes it really difficult to use other people's solutions because any and all of these can affect the behaviour. I had a quick search around and I found several semi-duplicates without accepted answers, probably for this reason.
The reason that these two errors give you different behaviour is that they occur at different stages in the request pipeline. The customErrors node in your web.config interacts with errors "inside" your application, while request validation takes place "outside" your application. IIS rejects the dangerous request before it gets to your application code, and so your customErrors replacement doesn't happen.
So how do we fix that?
Ideally you want a solution with as few moving parts as possible. IIS7 gives us a new way to specify error page replacement at the IIS level instead of at the application level - the httpErrors node. This lets us catch all our errors in one place:-
<configuration>
...
<system.webServer>
...
<httpErrors errorMode="Custom" existingResponse="Replace">
<clear />
<error statusCode="400" responseMode="ExecuteURL" path="/ServerError.aspx"/>
<error statusCode="403" responseMode="ExecuteURL" path="/ServerError.aspx" />
<error statusCode="404" responseMode="ExecuteURL" path="/PageNotFound.aspx" />
<error statusCode="500" responseMode="ExecuteURL" path="/ServerError.aspx" />
</httpErrors>
...
</system.webServer>
...
</configuration>
If you care about SEO (and you should!), you still have to make sure that your controller/page sets an appropriate status code:-
this.Response.StatusCode = 500; // etc.
You should remove your customErrors node entirely. It is normally used for backwards-compatibility. You should also ensure that requestValidationMode is not set on the httpRuntime node.
This should catch most errors (excluding, obviously, errors in parsing your web.config!)
Related:- ASP.NET MVC Custom Errors
MSDN Documentation:- http://www.iis.net/configreference/system.webserver/httperrors
Note: in your case, if you want to set defaultPath on the httpErrors node, you'll get a lock violation because of ApplicationHost.config settings. You can either do as I did and just set path individually for the error codes you care about, or you can have a look at unlocking the node:-
http://www.iis.net/learn/get-started/planning-your-iis-architecture/introduction-to-applicationhostconfig
http://forums.iis.net/t/1159721.aspx
My intuition is that it's more trouble than it's worth in low-control environments like Azure App Service / Azure Web Sites. You might as well set the paths for individual status codes.
I've put a full working example of using httpErrors for custom error pages up on github. You can also see it live on azure web sites.

Is it possible to handle 404 errors only in ASP.Net?

What web.config settings should I enter so that I can handle 404 errors but not other errors. The reason I want to handle 404 errors is that sometimes I purposely enter urls for inexisting pages but which I can handle and internally redirect to the real pages. That works fine, however, I do not want to handle other pages. On the contrary, I want to load the standard "non-custom" errors so that I can identify what is wrong with the page and see the line number causing the error. But when I enable custom errors for 404, I start getting redirected to the default error page (for 500 errors) and not have a clue of what caused the error.
Alternately I would consider having a custom error page that properly displays which page and which line is causing the error. I could do that for classic ASP but I could not find how to do that for ASP.Net.
Any help or pointers would be greatly appreciated.
Thanks!
P.S. not sure if it makes a difference, but my test server is IIS7.5 while the one for the live website is IIS6.

Try this:
<httpErrors errorMode="Custom" existingResponse="Replace">
<remove statusCode="404" subStatusCode="-1" />
<error statusCode="404" path="/Errors/404.aspx" responseMode="ExecuteURL"/>
</httpErrors>
Please refer to the following post:
http://tedgustaf.com/en/blog/2011/5/custom-404-and-error-pages-for-asp-net-and-static-files/

Display custom error page when file upload exceeds allowed size in ASP.NET MVC

My main issue is that I want to display an custom error page when an uploaded file exceeds allowed size (maxRequestLength in web.config).
When the big file is uploaded an HttpException is thrown before my upload action method in the controller is invoked. This is expected.
I have tried to catch the exception in a custom attribute and also to override OnException in the controller. Why isnt it possible to catch the exception in either the attribute or the OnException method?
Its possible though to catch the exception in Application_Error in global.asax but neither Response.Redirect nor Server.Transfer works for redirecting to the custom error page.
Server.Transfer gives the "failed to process child request" error and response.redirect gives the "Http headers already sent" error.
Any ideas?
Thanks in advance!
Marcus

When running under IIS7 and upwards there is another parameter:
<system.webServer>
<security>
<requestFiltering>
<requestLimits maxAllowedContentLength="10485760" />
</requestFiltering>
</security>
</system.webServer>
The default setting is slightly less than 30 MB.
For uploaded files with size between maxRequestLength and maxAllowedContentLength IIS7 will throw an HttpException with HTTP code 500 and message text Maximum request length exceeded. When this exception is thrown, IIS7 kills the connection immediately. So an HttpModule that redirects on this error will only work if the HttpException is handled and cleared (using Server.ClearError()) in Application_Error() in global.asax.cs.
For uploaded files with size bigger than maxAllowedContentLength IIS7 will display a detailed error page with error code 404 and subStatusCode 13. The error page can be found in C:\inetpub\custerr\en-US\404-13.htm
For redirects on this error on IIS7 I recommend redirecting on httpErrors instead.
To redirect to a different action set a smaller value for maxAllowedContentLength than maxRequestLength in web.config and also add the following to web.config:
<system.webServer>
<httpErrors errorMode="Custom" existingResponse="Replace">
<remove statusCode="404" subStatusCode="13" />
<error statusCode="404" subStatusCode="13" prefixLanguageFilePath=""
path="http://yoursite.com/Error/UploadTooLarge" responseMode="Redirect" />
</httpErrors>
</system.webServer>

When running on IIS6, I solved it with a HttpModule by handling the BeginRequest and check if httpApplication.Context.Request.Length is larger than maxRequestLength.
To be able to redirect the entire request has to be read before redirecting.
See code example at this link:
http://www.velocityreviews.com/forums/t97027-how-to-handle-maximum-request-length-exceeded-exception.html

The velocity eviews link was really helpful in solving the issue. As stated, the only drawback was the entire request (and file) needs to be read before the redirection can be done.
But it can be limited to run only when the page where the file upload control is present by being loaded like this
if (HttpContext.Current.Request.Url.ToString().Contains("UploadedPage.aspx")
{
//read and process page request
}

You need to make a custom HttpHandler that will do this for you. ASP.NET will automatically kill the connection if the upload size is too large (as you found out).