遭遇ASP.NET的Request is not available in&nb
前一篇文章抱怨了一下 ASP.NET FormsAuthentication 的设计,这篇文章要抱怨一下HttpContext的设计。
如果ASP.NET程序以IIS集成模式运行,在Global.asax的Application_Start()中,只要访问Context.Request,比如下面的代码
var request = Context.Request;
Request is not available in this context
不信你可以试试。
这个问题只会出现在IIS集成模式(Integrated),如果改为传统模式(Classic),问题就不会出现。
今天就被这个问题小小折腾了一下。我们在错误日志模块中增加了记录当前访问网址的操作,这样,发生错误时,我们可以准确地知道引发错误的访问网址。我们添加了下面这样的
代码:
HttpContext context = HttpContext.Current;
if (context != null && context.Request != null && context.Request.Url != null)
{
return context.Request.Url.AbsoluteUri;
}
然后将更新的日志模块部署到服务器上,在一个应用中却出现“Request is not available in this context”异常,如下图:
从上面的异常信息可以看出,异常发生于在Application_Start中访问HttpContext的Request属性时(该应用在Application_Start进行了日志记录操作,所以访问了HttpContext.Request)。
用ILSpy查看HttpContext的
代码:
internal bool HideRequestResponse;
public HttpRequest Request
{
get
{
if (this.HideRequestResponse)
{
throw new HttpException(SR.GetString("Request_not_available"));
}
return this._request;
}
}
可以看出,这个异常是在HideRequestResponse == true时扔出的,也就是说在Application_Start阶段,HideRequestResponse的值是true。
让人困惑的地方是既然在HideRequestResponse == true时不允许访问Request属性,那HttpContext为什么不提供一种方式让调用者知道——“此时严禁调用Request”。如果调用者调用前可以检查一下相关规定,就不用这么既浪费感情,又要付出代价(捕获这个HttpException)。
另外,我们的需求只是想得到当前请求的URL,不能访问Request,我们就不能得到这个URL。难道在Application_Start时就不能得到当前请求的URL,这个URL是从外部(IIS)传递给ASP.NET Runtime的,与ASP.NET Runtime的状态根本无关,有点想不通。。。
无奈,只能将就着先把问题解决,通过捕获异常进行判断,
代码如下:
HttpContext context = HttpContext.Current;
if (context != null && context.Request != null && context.Request.Url != null)
{
try
{
return context.Request.Url.AbsoluteUri;
}
catch (Exception ex)
{
if (ex is HttpException)
{
return string.Empty;
}
}
}
作者:dudu
相关新闻>>
- 发表评论
-
- 最新评论 更多>>