In our asp.net web page (.net 4.7.2) we use custom exception rendering logic which creates specific error pages for the user in global.asax.cs via:
Application_Error(object sender, EventArgs e)
This works fine. However there are some asp.net errors which never hit the Application_Error
-event.
For those errors, we set explicitly an error page in the web.config via the customErrors
-element. This looks like this:
<customErrors mode="On" defaultRedirect="~/CustomErrors/FatalError.aspx" redirectMode="ResponseRewrite" />
The Problem
The above works fine in most of the cases. However, there are some few asp.net errors, which are not handled by the Application_Error
event and also bring the FatalError.aspx to throw an exception, even if there is no asp-code within. A good example of such an error is, when you type the following reserved address into your browser:
https://[yourWebsite]/com1
This blows the .aspx- based default error page with the following error message (Http-Status-Code 500):
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.
Even setting an aspx-file which has absolutely no asp-code within, leads to this error. The same happens also, if the defaultRedirect
-attribute is configured to a resource which not exists! It also doesn't make any difference, if there are explict error
-elements defined under the customErrors
-element, which define the redirect-resource based on an explicit http statusCode.
When setting the redirectMode
of the customErrors
-element to ResponseRedirect
, the aspx-based default error handler works fine.
However, this is not option, since our client don’t want to see the redirect.
As a workaround, we can try to use a static html file. However, in this case, asp.net sends the response without the correct content-type back to the browser and the HTML-page is rendered as text.
There are lot of posts throughout the internet which state this an error. However, the proposed solution is always either, to use an .aspx-file, or to use the Application_Error
event in global.asax.cs to set the content-type manually in code. However, both variants are not possible in this very situation as described above (every aspx-file blows and Application_Error
is never called).
Question
How can we configure a reliable error handling, which never shows any asp.net specific error-information but an application specific one, even with such edge cases as described in this post.
Please note, the question is not about how to circumvent the error with the reserved resource names. This is only an example and there are probably many more other circumstances, where asp.net errors occur, which never reach the Application_Error
event and bring aspx-based error files down. The goal is really to have a mechanism for rendering application branded error message instead of asp.net error messages, which works fully reliable.
Also as a side node, we use also the httpErrors-element in the webServer-section to change errors which stem not from asp.net but from IIS itself. However, we have not observed any dependency to the problem described above, hence, I have not mentioned that in the main text.