I use an Application_Error handler to log all unhandled exceptions; generally it works well, but 404 errors always are skipped. Any ideas what might be the reason?
Actually, that is because that's an http protocol error returned by your web server. It's not a .net framework exception and thus it can't be handled by asp.net. However, you can configure IIS to serve a custom page when it returns a 404 error and this can be done through your web.config file. Needless to say that this custom page could be an aspx page where you can add some custom processing such as logging the error ;)
404's are not always caused by exceptions. You can just set the Response.Status* fields to generate a 404 response.
Use Application_EndRequest to examine the response and act on it.
Related
I would like the following behavior in regards to error statuscode responses:
In JsonResult Actions (for AJAX postbacks), return custom body along with some error statuscode
For errors in other action methods, show IIS (custom) error page
For 404 errors, show IIS (custom) error page
In local environment: For errors in non-json action methods, and 404, show ASP.NET error page with stacktrace
If I set existingResponse=Replace in the httpErrors element in web.config, the IIS error pages override any response with an error-statuscode. That is I cannot return a custom json response.
If I set existingResponse=Auto I can return a custom json response by setting Response.TrySkipIisCustomErrors=true, but then the ASP.NET (custom) error pages are shown for any other error statuscode. That is, it never falls back to the IIS error pages. It seems that ASP.NET automatically sets the TrySkipIisCustomErrors on server errors, which I do not want.
Is there any way to achieve what I describe? I could possibly use the ASP.NET customErrors section instead, but I realize it also has disadvantages, as described here:
https://dusted.codes/demystifying-aspnet-mvc-5-error-pages-and-error-logging
One could use a combination of httpErrorsand customErrors, but the latter does no support ExecuteURL - only static error pages. That is unfortunate since I would like to make use of the master Layout.cshtml.
Any suggestions?
I am trying to handle all HTTP errors to my custom error pages, but I find that when there is a % at the end of url, i cannot use config setting or code to handle it,
for example: http://localhost/abc%
the response is:
Bad Request - Invalid URL
HTTP Error 400. The request URL is invalid.
So, can we use config setting or c# code to handle this error request?
Who said not possible?
Response.TrySkipIisCustomErrors = true;
OR
<configuration>
<system.webServer>
<httpErrors existingResponse="PassThrough" />
</system.webServer>
</configuration>
original post
See this 4 part series for configuring custom error pages within IIS: http://www.dotnetscraps.com/dotnetscraps/post/Did-you-know-Enable-Custom-Error-in-IIS-7-75.aspx.
I personally prefer to use Application_Error event to log the errors and redirect user to custom error pages. Note that you need to use integrated pipe-line in IIS to catch all errors otherwise IIS will show its own error page for resources that are not served by ASP.NET.
EDIT:
Sorry for the wrong answer. I have XP machine currently that shows 404 for % sign so couldn't verify above. Searching over internet, I found that it's simply not possible to display custom error page for 400 status code. See this question from server fault for more information.
I have a rather complex legacy ASP.Net application that is under continuous development, and for one client it has started erroring recently.
The application uses ASP.Net 3.5 and C# on the server side, backed by SQL Server 2005 and IIS6.
The application also utilises the Microsoft ASP.net AJAX libraries and DevExpress components.
We have a fairly comprehensive logging platform in place, via a Page_Error handler in a custom page base, which logs all unhandled exceptions and displays a nice error page.
The problem is, one client has recently started getting errors which we cannot trace - nothing is logged, despite the nice error page being displayed. No exceptions are caught and handled by the Page_Error handler, which is the method which redirects users to the error page - and no redirection happens without the error being handled.
I have added some client side Javascript to the ASP.Net Ajax PageScriptManager EndRequestHandler Javascript handler which logs clientside errors to a wide open ashx logging script.
The only errors the client side catches are as follows:
Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 0
Sys.WebForms.PageRequestManagerParserErrorException: The message received from the server could not be parsed. Common causes for this error are when the response is modified by calls to Response.Write(), response filters, HttpModules, or server trace is enabled.
Details: Error parsing near '
<!DOCTYPE html P'.
These errors have no corresponding server side error.
Unfortunately, there is no scope to set up unit tests for this project, its too large and I wouldn't know where to begin for the client-server interaction part.
My question is, can anyone recommend a method of seeing what is erroring, why it is erroring and why this isn't being caught by the Page_Error handler?
You could try using ELMAH to catch exceptions that aren't handled inside your application.
As it turned out, there isnt a way to track these down - the issue was wider in scope and involved a clients firewall preventing AJAX communications randomly, or modifying the resulting pass back.
When setting up asp.net error handlers for things like 404 errors, it is more 'efficient' to do this in IIS, or handle it in the Global.asax Application_Error event? I know the latter will be called, and I want to log this information in a database, but should I then just return without any redirect and let IIS do the redirect, or would it be better to do a response.redirect inside application_error once we've logged it?
Handing in IIS is more efficient but in glabal.asax allows you to log it or react to it.
Remember the decision is not commonly yours but based on the mime setup. So if a resource has been set to be hanled as a static content, you will not receive it in the ASP.NET.
Here's an interesting one for you.
I've got my custom 500.aspx setup which is called when a 500 error occurs in my application. The 500.aspx also sends me an email with the error details.
I've noticed one small problem.
If you attempt an xss attack on the 500.aspx itself, the 500 page is not called.
This is obviously some sort of logic issue.
In fact, microsoft themselves suffer from the same issue.
See it in action here
http://www.microsoft.com/500.aspx?aspxerrorpath=%3Cscript%3Ealert(%22XSS%22)%3C/script%3E
How can I prevent this?
Ed
If you attempt an xss attack on any page, the custom error page will not be called (here's another random page on Microsoft.com with xss in the querystring).
The behavior appears to be intentional to stop the attack dead in its tracks. Even the error message indicates this behavior:
Request Validation has detected a
potentially dangerous client input
value, and processing of the request
has been aborted.
The only workaround appears to be to disable validation or to capture and handle the error in your global on Application_Error.
It appears that once you define a page to handle specific(or non specific?) errors, it is no longer available directly via its url, sorta like the Web.Config cant be called via the browser.
I would set up a 500Test.aspx which throws an exception causing a 500 error (and thus fires the 500.aspx)
That might work.
You might want to think about handling your errors in the Application_Error event in Global.asax.cs instead of the 500.aspx page. You could put the email code there, then redirect the user to an error page after you've done your error handling (this is how we do it where I work).