This question is posted on Stack Overflow, and I'm cross-posting here because I think this might be a more correct forum for it.
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?