设置响应时，IIS7重写 customError？

By default IIS 7 uses detailed custom error messages so I would assume that Response.StatusCode will equal 404.XX rather than just 404.

You can configure IIS7 to use the simpler error message codes or modify your code handling the more detailed error messages that IIS7 offers.

More info available here: http://blogs.iis.net/rakkimk/archive/2008/10/03/iis7-enabling-custom-error-pages.aspx

Further investigation revealed I had it the wrong way around - detailed messages aren't by default but perhaps they've been turned on, on your box if you're seeing the different error messages that you've mentioned.

Solved: It turns out that "Detailed Errors" needs to be on in order for IIS7 to "passthrough" any error page you might have. See http://forums.iis.net/t/1146653.aspx

Set existingResponse to PassThrough in system.webServer/httpErrors section:

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

Default value of existingResponse property is Auto:

Auto tells custom error module to do the right thing. Actual error text seen by clients will be affected depending on value of fTrySkipCustomErrors returned in IHttpResponse::GetStatus call. When fTrySkipCustomErrors is set to true, custom error module will let the response pass through but if it is set to false, custom errors module replaces text with its own text.

More information: What to expect from IIS7 custom error module

The easiest way to make the behavior consistent is to clear the error and use Response.TrySkipIisCustomErrors and set it to true. This will override the IIS global error page handling from within your page or the global error handler in Application_Error.

Server.ClearError();
Response.TrySkipIisCustomErrors = true;

Typically you should do this in your Application_Error handler that handles all errors that your application error handlers are not catching.

More detailed info can be found in this blog post: http://www.west-wind.com/weblog/posts/745738.aspx

I'm not sure if this is similar in nature or not, but I solved an issue that sounds similar on the surface and here's how I handled it.

First of all, the default value for existingResponse (Auto) was the correct answer in my case, since I have a custom 404, 400 and 500 (I could create others, but these three will suffice for what I'm doing). Here are the relevant sections that helped me.

From web.config:

<customErrors mode="Off" />

And

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL">
<clear />
<error statusCode="404" path="/errors/404.aspx" responseMode="ExecuteURL" />
<error statusCode="500" path="/errors/500.aspx" responseMode="ExecuteURL" />
<error statusCode="400" path="/errors/400.aspx" responseMode="ExecuteURL" />
</httpErrors>

From there, I added this into Application_Error on global.asax:

    Response.TrySkipIisCustomErrors = True

On each of my custom error pages I had to include the correct response status code. In my case, I'm using a custom 404 to send users to different sections of my site, so I don't want a 404 status code returned unless it actually is a dead page.

Anyway, that's how I did it. Hope that helps someone.

This issue has been a major headache. None of the suggestions previously mentioned alone solved it for me, so I'm including my solution. For the record, our environment/platform uses:

• .NET Framework 4
• MVC 3
• IIS8 (workstation) and IIS7 (web server)

Specifically, I was trying to get an HTTP 404 response that would redirect the user to our custom 404 page (via the Web.config settings).

First, my code had to throw an HttpException. Returning a NotFoundResult from the controller did not achieve the results I was after.

throw new HttpException(404, "There is no class with that subject");

Then I had to configure both the customErrors and httpError nodes in the Web.config.

<customErrors mode="On" defaultRedirect="/classes/Error.aspx">
<error statusCode="404" redirect="/classes/404.html" />
</customErrors>

...

<httpErrors errorMode="Custom" existingResponse="Auto" defaultResponseMode="ExecuteURL">
<clear />
<error statusCode="404" path="/classes/404.aspx" responseMode="ExecuteURL" />
</httpErrors>

Note that I left the existingResponse as Auto, which is different than the solution @sefl provided.

The customErrors settings appeared to be necessary for handling my explicitly thrown HttpException, while the httpErrors node handled URLs that fell outside of the route patterns specified in Globals.asax.cs.

P.S. With these settings I did not need to set Response.TrySkipIisCustomErrors

TrySkipIisCustomErrors is only a part of a puzzle. If you use Custom Error Pages but you also want to deliver some RESTful content based on 4xx statuses then you have a problem. Setting web.config's httpErrors.existingResponse to "Auto" does not work, because .net seems to always deliver some page content to IIS, therefore using "Auto" causes all (or at least some) Custom Error Pages to be not used. Using "Replace" won't work too, because response will contain your http status code, but its content will be empty or filled with Custom Error Page. And the "PassThrough" in fact turns the CEP off, so it can't be used.

So if you want to bypass CEP for some cases (by bypassing I mean returning status 4xx with some content) you will need additional step: clean the error:

void Application_Error(object sender, EventArgs e)
{
var httpException = Context.Server.GetLastError() as HttpException;
var statusCode = httpException != null ? httpException.GetHttpCode() : (int)HttpStatusCode.InternalServerError;


Context.Server.ClearError();
Context.Response.StatusCode = statusCode;
}

So if you want to use REST response (i.e. 400 - Bad Request) and send some content with it, you will just need to set TrySkipIisCustomErrors somewhere in action and set existingResponse to "Auto" in httpErrors section in web.config. Now:

• when there's no error (action returns 4xx or 5xx) and some content is returned the CEP is not used and the content is passed to client;
• when there's an error (an exception is thrown) the content returned by error handlers is removed, so the CEP is used.

If you want to return status with empty content from you action it will be treated as an empty response and CEP will be shown, so there's some room to improve this code.