Question

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?

Answer 1

Have a look at the following: IIS7 Overrides customErrors when setting Response.StatusCode?.

You need to set

  <system.webServer>
    <httpErrors existingResponse="PassThrough" />
  </system.webServer>