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

后续文章：