Hello everybody,

first thing, this is a crossposting from the following thread: http://www.dotnetnuke.com/Community/Forums/tabid/795/forumid/108/threadid/240373/scope/posts/Default.aspx

I posted it in the "Configure It" forum, but seeing the lack of answers, i realized i had made a mistake. So here it is

---

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

---

ps: i bumped up the original thread with more informations and things i had tried, hoping to ignite the discussion. If you're wondering about it, don't hesitate to go and see the original post :)

Hello nitin, and thank you for your reply.

However, i don't see how it relates to the problem; the custom error page is displaying all right, it's just that the Server.Transfer command in the custom error module fails when the compression module tries to do its work.

However, for anyone interested, i corrected the problem by taking the source code for the compression module and modding it so that it would skip compressing in certain cases, cases which i manually set in the custom error page.

The problem of this custom page comes from the fact that the application.Request.Url.LocalPath property is not changed when i do a Server.Transfer and that the compression module still sees the page as default.aspx

It's not a beautiful hack, i would rather have preferred something a bit cleaner, but is does the job :)

samy