CustomErrors does not work when setting redirectMode="ResponseRewrite"

Question

In a old site, I was changing the way that CustomErrors works by adding redirectMode="ResponseRewrite" (new in 3.5 SP1)

The thing is that it shows me the generic error page (the one that you get when you don't set customErrors

<customErrors mode="RemoteOnly" defaultRedirect="Error.aspx" redirectMode="ResponseRewrite">
    <error statusCode="404" redirect="404.aspx" />
</customErrors>

If I remove then redirectMode="ResponseRewrite" part, it works fine.

I'm sure 3.5 SP1 is installed in the server, because I use the setting in other sites hosted in the same server.

Any idea?

Answer 1

I found that the problem was in Error.aspx. Still can't find what was the actual error in error.aspx that causes the problem.

Changing the page to a static html file solved the problem.

Answer 2

I know this question is a bit old, but I thought I should point out that it doesn't need to be a static file to get this working.

I ran into a similar thing, and it's just a matter of finding that error in your Error.aspx, in our case it was because the masterpage in use relied on a piece of session data and when ResponseRewrite was set the session is not available to our Error.aspx page.

I haven't worked out yet whether this unavailability of session is due to our specific app config or a "by design" part of ASP.net.

Answer 3

I have the same problem here: if I set redirectMode="ResponseRewrite" the custom error page is not displayed, unless it is a static html.

But I need to handle the error (send an e-mail, save a record in the log), so I must use an aspx error page.

Additionaly, if I use redirectMode="ResponseRedirect", the custom error aspx is displayed, but in this case I loose access to the error/exception details (Server.GetLastError is null), so it is not what I need either.

Any thought on this? Thanks,

Ricardo.

Answer 4

What's happening is IIS is seing the error status code and presenting it's own error page instead of yours. To solve you need to set this in the code behind page of your error page to prevent IIS from doing this:

Response.TrySkipIisCustomErrors = true;

This will only work in IIS7 or above, for earlier versions of IIS you'll need to play with the error page settings.

Answer 5

In my particular case, my error page had a master page that had a user control that tried to use Session. If Session isn't available, you get an HttpException: "Session state can only be used when enableSessionState is set to true, either in a configuration file or in the Page directive." Easiest fix is to switch to static html, second easiest fix is to use a simpler error page, hardest fix is to make incredibly sure that your error page makes no assumptions anywhere (like that Session won't throw an exception, for example) and can't possibly error out.

Answer 6

It is important to note for anyone trying to do this in an MVC application that ResponseRewrite uses Server.Transfer behind the scenes. Therefore, the defaultRedirect must correspond to a legitimate file on the file system. Apparently, Server.Transfer is not compatible with MVC routes, therefore, if your error page is served by a controller action, Server.Transfer is going to look for /Error/Whatever, not find it on the file system, and return a generic 404 error page!