遭遇ASP.NET的Request is not available in this context

前一篇文章抱怨了一下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;
        }
    }
}

后续文章：关于在Application_Start中访问Context.Request