HttpContext.Current.Items cleared via responseMode=“ExecuteURL”?

匆匆过客 提交于 2019-12-05 08:36:56

As explained here, the ExecuteURL generates two requests: the first one throws the exception and the second one generates the error response.

Since Context.Items is cleared between requests, your code always see the 2nd request generated hence the diff between the Items.

Try the sugestion in the post: use system.web > customErrors with redirectMode="ResponseRewrite" instead.

I've followed a trace and determined the following. Some is loosely inferred.

The CustomErrorModule (in the IIS module stack) receives the SEND_RESPONSE notification.

The HttpStatus is 500, so it clones the context, sets a new URL (according the the matching custom error rule), and executes the request on this context (see ExecuteRequest).

The purpose of HttpContext.Items per documentation is:

Gets a key/value collection that can be used to organize and share data between an IHttpModule interface and an IHttpHandler interface during an HTTP request.

Viewing this function definition critically, of course, there is only "HTTP request". However, it seems likely that the Items dictionary is itself an item in a dictionary keyed on the HttpContext, which is a unique (cloned) reference in this executing child request. The trace shows the full pipeline (all modules, e.g. duplicate authentication) being run for this ExecuteURL, so this isolated context is of course required.

From unmanaged code, it is trivial to GetParentContext. However, from managed code this hierarchy is not available. So, I'm left without a way to retrieve the original Items.

As an alternate solution, it might be functional to leverage a Global.asax variable, since my tests showed the child request sharing an ApplicationInstance, but I'm not certain client access to this is necessarily sequential.

Another, possibly better approach, would be to avoid re-running the entire pipeline; to never exit the MVC handler (e.g. Controller.OnException and TransferToAction). However, this prevents implementing a Single-Point-of-Truth for error page configuration, since errors can also be raised outside of MVC's awareness.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!