Application_Error异常处理,重定向无限循环和CSS加载问题

问题描述:

我在globals.asax文件的Application_Error事件中有错误处理。在此事件中,我使用的是 Response.Redirect(〜errorview.aspx)方法,用于重定向到能够以用户友好的方式处理错误的网站。

I have error handling in Application_Error event of globals.asax file. Inside this event, I'm using Response.Redirect(~errorview.aspx) method, for redirection to site which is able to handle errors in user friendly way.

一切正常,除非Application_Start事件中出现异常。当在那里发生错误时,我的应用程序陷入无限循环,并反复命中Application_Error方法。而且,我重定向到的页面永远不会被点击。将 Response.Redirect(〜errorview.aspx)方法更改为 Response.Redirect(〜errorview.aspx,false)更改没有。

Everything works fine, unless exception is rising in Application_Start event. When error occurs there, my application gets trapped in infinite loop with the Application_Error method hit repeatedly. What is more, the page I'm redirecting to never gets hit. Changing Response.Redirect(~errorview.aspx) method to Response.Redirect(~errorview.aspx, false) changes nothing.

好消息是,当 Response.Redirect(〜errorview.aspx)被替换为 Server.Transfer(〜errorview.aspx),errorview.aspx页成功被命中。

The good news is, when Response.Redirect(~errorview.aspx) has been replaced with Server.Transfer(~errorview.aspx), errorview.aspx page succesfully gets hit.

现在的副作用是没有加载CSS,而且errorview.aspx页面看起来很丑。而且,当 Application_Start 事件发生异常时,CSS不会仅仅加载。从其他任何地方抛出的异常都不会使CSS混乱。

The side effect now is not loading CSS, and errorview.aspx page looks ugly. What is more, the CSS is not loaded only when exception occurs in Application_Start event. Exceptions thrown from any other place don't make the CSS mess.

我如何以正确的方式处理此问题,以及为什么在一种特殊情况下CSS会丢失?在我的情况下,处理错误的适当方法是什么?

How I can handle this problem in correct way, and why the CSS is missing in the one particular situation ? What is the appropriate way of handling errors in my case ?

更新

对于CSS加载,我使用的是:

For CSS loading, I'm using this:

<link href="~/Css/Layout/style.css" type="text/css" rel="stylesheet" 
      runat="server" ID="_uid" />

错误页面我正在从以下位置传输: http:// localhost / APP / Pages / Module / Pages / ErrorView.aspx

error page I'm transfering from: http://localhost/APP/Pages/Module/Pages/ErrorView.aspx

css文件夹路径: http:// localhost / APP / Pages / Module / CSS / Layout / style .css

css folder path: http://localhost/APP/Pages/Module/CSS/Layout/style.css

感谢您提供任何线索。问候。

Thanks for any clues in advance. Regards.

如果在Application_Start期间遇到异常,则比尝试使CSS加载错误要麻烦得多。页。 Application_Start旨在作为网站初始化所有内容的引导程序。如果无法成功初始化应用程序,则可能无法处理任何请求。 (当已知应用程序在Application_Start中仍然存在异常时,您不应该将其发布到生产环境中。)

If you're getting exceptions during Application_Start, you have bigger problems than trying to get CSS to load in the error page. Application_Start is intended as a bootstrapper for the Web site to initialize everything. If you can't successfully initialize the application, you probably won't be able to service any requests. (You shouldn't be publishing an application to a production environment when it is known to have exceptions in the Application_Start anyway.)

最终,Server.Transfer在做什么只需从处理当前路径切换到处理新路径即可。请求上下文未修改,因此新路径中的任何相对引用都是相对于原始请求的。如果Application_Start中发生异常,则没有原始请求。 (请求不是由Application_Start处理的。请求可能导致Application_Start被调用,但对请求一无所知。)这可能就是为什么Application.Start异常的Server.Transfer无法加载CSS的原因-没有原始的请求上下文。

Ultimately, what Server.Transfer is doing is simply switching from processing the current path to processing the new path. The request context is not modified, so any relative references in the new path are relative to the original request. If an exception happens in Application_Start, there is no original request. (Requests aren't handled by Application_Start. A request can cause Application_Start to be invoked, but it won't know anything about the request.) That's probably why Server.Transfer from an Application_Start exception doesn't load the CSS - there's no original request context.

此外,最好是有一个静态的仅html错误页面。如果由于IIS中的某些ASP.NET处理导致错误,则同样由ASP.NET处理的错误页面也可能会遭受相同的错误,从而可能导致无限循环(错误页面重定向到错误页面因为有错误-泡沫,冲洗,重复)。 (这是您遇到的无限循环情况。)最终,好的浏览器会注意到这一点并停止循环,但是您仍然有失控的请求周期。如果使用仅静态的html页面,则可以防止ASP.NET尝试处理请求。 (它通常也更干净,因为您应该有一个非常简单明了的错误页面,向访问者显示该页面,并在后台处理所有错误陷阱和通知。)

Also, it's generally a better idea to have a static html-only error page. If there's an error caused by some ASP.NET processing in IIS, then it's likely that an error page that is also processed by the ASP.NET will suffer the same error, possibly causing an infinite loop (the error page redirects to the error page because there was an error - lather, rinse, repeat). (This is the infinite loop situation that you experienced.) Eventually, good browsers will notice this and stop the loop, but you still have the runaway request cycle. If you use a static html-only page, then you prevent ASP.NET from ever attempting to process the request. (It's usually cleaner, too, as you should have a very simple, straightforward error page that displays to the visitor and have all the error trapping and notifications handled behind the scenes.)