I think I have found a bug regarding in the IIS Error Pages system.
Note: - I am not using .NET Error Pages - this is set to Off
The problem:
When a custom error page is setup for the 500.100 (Classic ASP) response code, IIS always sends a custom error page even when errorMode is set to Detailed. The only way to get IIS to send the error is to explicitely remove the entry in the web.config.
EG:
<remove statusCode="500" subStatusCode="100"/>
or
<clear/>
Note - the following does not work (which works for all other codes):
<remove statusCode="500" subStatusCode="-1"/>
My scenario:
- IIS 8 (I am unaware if the issue exists in older versions of IIS)
- Website running .NET 2.0 - Classic pipeline
- Feature Delegation on Error Pages set to read only
- Error page setup in IIS as follows (due to the feature delegation above, these entries are not in the web.config):
- 404 - /path/to/404.htm - ExecuteURL
- 500 - /path/to/500.htm - ExecuteURL
- 500.100 - /path/to/500.htm - ExecuteUrl
Turning off Custom Errors:
In order to turn off the custom errors, all I need to do is:
- Load IIS
- Load
Error Pages
- Click
Edit Feature Settings
- Select
Detailed Errors
This works successfully for all codes except Classic ASP 500 errors (status code 500.100).
The only way I can get the proper Classic ASP error is to setup the following (which requires me to change the feature delegation to Read/Write):
<system.webServer>
<httpErrors errorMode="Detailed">
<clear/>
OR
<remove statusCode="500" subStatusCode="100"/>
</httpErrors>
</system.webServer>
Summary
It seems that if a 500.100 custom error page is setup, then setting Detailed Errors to true does not work for Classic ASP 500 errors.
Is this a bug or am I missing something?