I have a application (folder with an app pool) running on iis 6 where im trying to setup a custom error page. I in the web config I have a element for the custom error but it never shows up. If I go into IIS and look at the properties of the app I can set a custom error to point to oops.html. It seems that IIS is not using the setting in my web.config for handling the errors.
Here is what I have
in web.config
<system.web>
...
<customErrors mode="On" defaultRedirect="/oops.html" redirectMode="ResponseRewrite" />
...
</system.web>
<system.webServer>
...
<httpErrors existingResponse="PassThrough" />
...
<system.webServer>
Address to the app is like this:
http://www.mysite.com/myappfolder/
the web config is in:
http://www.mysite.com/myappfolder/
and oops.html is in:
http://www.mysite.com/myappfolder/oops.html
if it try to go to:
http://www.mysite.com/myappfolder/NothingReal
a 404 will be thrown and only when I have configured IIS to redirect to oops.html will I see the page.
What are the rules for specifying the target of customerrors? Should I remove the “/” what about using ~/myappfolder/oops.html? How do I bypass IIS 6 error handling and have all the errors redirect to my page?
So this was a combination of issues. First was that there are two levels of error handling going on on the server.
The first level sits in IIS. When IIS comes across an error it will use its error pages to relay or obscure the issue.
The second level is in the ASP runtime. With there is an error in the page the script can then delegate to the “oops” page given the web config is configured to do that.
If asp dose not redirect to an “oops” page or the location of that page in incorrect then IIS handles the error. In the case of not redirecting the 500 level error would be thrown. In the case of a wrong location of the “oops” page then it would throw a 404.
My issue was in the way this was being handled and that IIS and my web config were pointing to the same page, making debugging slightly more challenging.
in the end I worked out my issues the first of which being that the path is relative to the webconfig that is handling the redirect and that ~/ was being used incorrectly.