Hello everybody,
we have a dotnetnuke site where we set up a custom ExceptionHandler module. What the module does is redirect the user to a specific CustomError.aspx page where, depending on the value of the debug parameter in web.config, we either display the source of the error (complete with filename and line number, and as much info as possible/reasonable) or a generic message telling the user that we're aware of the problem and that we've logged it. We do log it, through internal mailing and bugtracking system...
Everything went fine until recently. We decided to upgrade from DNN 4.3 to DNN 4.8. In the process, i discovered some new options i was interested in, such as the Compression Module. However, when we activate the compression module, redirecting to the CustomError.aspx doesn't work anymore and we get the standard yellow asp.net error page saying that custom errors aren't set up.
There is also an exception coming from the compression module saying that it cannot append headers to the message: apparently this happens when the compression module tries to add the compression header to the Response object.
So basically, here is a step-by-step of what happens (you can also look there to have an idea of the rough working of the handler: http://www.dotnetjohn.com/articles.aspx?articleid=42 or http://www.codeproject.com/KB/aspnet/ASPNETExceptionHandling.aspx):
- unhandled exception fires up
- Custom Exception Module catches it -> Server.Transfer("CustomError.aspx")
- CustomError page gets latest error, pretties it up and either shows the debugging data or logs it and redirects the user to another page where we tell him we're on the case.
I tried to bypass the problem in a lot of ways, but i'm at my wits' end, especially regarding my unsifficient knowledge of DNN. So, am i doing something very wrong here and should i change our custom error handler to benefit more from DNN's architecture, or is there a configuration thingie that i've overlooked?
Thank you for reading and for any input!
samy