I'm having a hardcore head-ache from trying to get complete programmatic control over rendering of an error in IIS7 (integrated mode). What I want to do is given an error (page not found, internal server error, not authenticated, etc), transfer the whole request to a custom ASPX or HTML (I prefer the latter) with the correct HTTP status code.
What I want is IIS7 to don't give a crap about what I set the HTTP status code to. I don't want its error handling. When I set Response.StatusCode = (int)HttpStatusCode.NotFound
, what I want is not IIS to render its own error page, but perhaps transfer the request to another file.
I've gotten this static configuration stuff to work:
<configuration>
<system.webServer>
<httpErrors>
<clear />
<error statusCode="404" path="/errors/404.html" responseMode="ExecuteURL" />
</httpErrors>
</system.webServer>
</configuration>
While this works, it doesn't give me programmatic control over what to do with the response, given an error scenario. Configuration is a good fallback, but I'd really like to be able to set Response.StatusCode
and render something completely different from the configured 404.html
in certain circumstances (like a JSON response if we receive Accept: application/json
), but IIS7 won't let me. Not a chance.
So what the heck am I supposed to do? I've tried to set HttpResponse.TrySkipIisCustomErrors Property
, but that looks like a huge hack and doesn't seem to work consistently. Is setting this property to true really the recommended best practice to get the behavior I want?
At the moment, the feeling I'm left with is nothing but intense hate towards IIS7. Can anyone please help me remedy this by proving that I'm just being stupid and that I can indeed have full control over the HTTP stack?
Have a look at the following: IIS7 Overrides customErrors when setting Response.StatusCode?.
You need to set