Response.Redirect引起的“无法在发送HTTP标头之后进行重定向”

博客后台切换至i.cnblogs.com之后，在日志中发现大量的“无法在发送HTTP标头之后进行重定向”（Cannot redirect after HTTP headers have been sent）的错误信息。

检查代码发现问题是由下面的代码触发的：

IHttpHandler IHttpHandlerFactory.GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
{
    context.Response.Redirect("http://i.cnblogs.com/" + 
        context.Request.RawUrl.Substring(context.Request.RawUrl.LastIndexOf("/") + 1));

    //后续也有context.Response.Redirect代码
    //...
    return PageParser.GetCompiledPageInstance(newurl, path, context);
}

“无法在发送HTTP标头之后进行重定向”问题来源于Response.Redirect之后，又进行了Response.Redirect。

解决方法很简单：在Response.Redirect之后立即返回。

IHttpHandler IHttpHandlerFactory.GetHandler(HttpContext context, string requestType, string url, string pathTranslated)
{
    context.Response.Redirect("http://i.cnblogs.com/" + 
        context.Request.RawUrl.Substring(context.Request.RawUrl.LastIndexOf("/") + 1));
    return null;
    //...    
}

为什么之前没有加return null呢？因为以前一直以为Response.Redirect会结束当前请求，不会执行Response.Redirect之后的代码。

现在残酷的现实说明了不完全是这样的，那问题背后的真相是什么？让我们来一探究竟。

由于微软公开了.NET Framework的源代码，现在无需再看Reflactor出来的代码，可以直接下载源代码用Visual Studio进行查看。

.NET Framework源代码下载链接：http://referencesource.microsoft.com/download.html （相关新闻：微软开放了.NET 4.5.1的源代码）

用Visual Studio打开DotNetReferenceSourceSource dp.sln，搜索HttpResponse.cs，找到Response.Redirect的实现代码：

public void Redirect(String url)
{
    Redirect(url, true, false);
}

实际调用的是internal void Redirect(String url, bool endResponse, bool permanent) ，传给endResponse的值的确是true啊，为什么后面的代码还会执行？

进一步查看internal void Redirect()的实现代码（省略了无关代码）：

internal void Redirect(String url, bool endResponse, bool permanent) 
{
    //...

    Page page = _context.Handler as Page;
    if ((page != null) && page.IsCallback) {
        //抛异常
    }

    // ... url处理

    Clear(); //Clears all headers and content output from the buffer stream.

    //...
    this.StatusCode = permanent ? 301 : 302; //进行重定向操作
    //...
    _isRequestBeingRedirected = true; 

    var redirectingHandler = Redirecting;
    if (redirectingHandler != null) {
        redirectingHandler(this, EventArgs.Empty);
    }

    if (endResponse)
        End(); //结束当前请求
}

从上面的代码可以看出，我们要找的真相在End()方法中，继续看HttpResponse.End()的实现代码：

public void End() {
    if (_context.IsInCancellablePeriod) {
        AbortCurrentThread();
    }
    else {
        // when cannot abort execution, flush and supress further output
        _endRequiresObservation = true;

        if (!_flushing) { // ignore Reponse.End while flushing (in OnPreSendHeaders)
            Flush();
            _ended = true;

            if (_context.ApplicationInstance != null) {
                _context.ApplicationInstance.CompleteRequest();
            }
        }
    }
}

注意啦！真相浮现了！

以前一直以为的Response.Redirect会结束当前请求，就是上面的AbortCurrentThread()情况，如果将Response.Redirect放在try...catch中就会捕捉到ThreadAbortException异常。

通常情况下，我们在WebForms的Page或MVC的Controller中进行Redirect，_context.IsInCancellablePeriod的值为true，执行的是AbortCurrentThread()，所以不会遇到这个问题。

而我们现在的场景恰恰是因为_context.IsInCancellablePeriod的值为false，为什么会是false呢？

进一步看一下_context.IsInCancellablePeriod的实现：

private int _timeoutState; // 0=non-cancelable, 1=cancelable, -1=canceled

internal bool IsInCancellablePeriod {
    get { return (Volatile.Read(ref _timeoutState) == 1); }
}

根据上面的代码，触发这个问题的条件是_timeoutState的值要么是0，要么是-1，根据我们的实际情况，应该是0=non-cancelable。

再来看看我们的实际应用场景，我们是在实现IHttpHandlerFactory接口的GetHandler方法中进行Response.Redirect操作的，也就是说在这个阶段_timeoutState的值还没被设置（默认值就是0）。为了验证这个想法，继续看一下_timeoutState在哪个阶段设值的。

Shift+F12找到所有引用_timeoutState的地方，在HttpConext中发现了设置_timeoutState的方法BeginCancellablePeriod，实现代码如下：

internal void BeginCancellablePeriod() {
    // It could be caused by an exception in OnThreadStart
    if (Volatile.Read(ref _timeoutStartTimeUtcTicks) == -1) {
        SetStartTime();
    }

    Volatile.Write(ref _timeoutState, 1);
}

然后再Shift+F12找到了在HttpApplication.ExecuteStep()中调用了BeginCancellablePeriod()：

internal Exception ExecuteStep(IExecutionStep step, ref bool completedSynchronously) 
{
    //..
    if (step.IsCancellable) {
        _context.BeginCancellablePeriod(); // request can be cancelled from this point
    }
    //..
}

从上面的代码可以看出，当step.IsCancellable为true时，会调用BeginCancellablePeriod()，就不会出现这个问题。

而我们用到的IHttpHandlerFactory.GetHandler()所在的IExecutionStep的实现可能将IsCancellable设置为了false。

那IHttpHandlerFactory.GetHandler()是在哪个IExecutionStep的实现中调用的呢？

在园子里木宛城主的一篇写得非常棒的博文（ASP.NET那点不为人知的事）中找到了答案——MapHandlerExecutionStep：

当执行到MapHandlerExecutionStep时会执行如下代码获取最终执行请求：context.Handler = this._application.MapHttpHandler()。HttpApplication对象的MapHttpHandler方法将根据配置文件结合请求类型和URL以调用相应的IHttpHandlerFactory来获取HttpHandler对象。

我们再回到.NET Framework的源代码中看一看MapHandlerExecutionStep的实现：

// execution step -- map HTTP handler (used to be a separate module)
internal class MapHandlerExecutionStep : IExecutionStep {
    private HttpApplication _application;

    internal MapHandlerExecutionStep(HttpApplication app) {
        _application = app;
    }

    void IExecutionStep.Execute() {
        //...
    }

    bool IExecutionStep.CompletedSynchronously {
        get { return true;}
    }

    bool IExecutionStep.IsCancellable {
        get { return false; }
    }
}

看到有没有？IExecutionStep.IsCancellable返回的值是false。

到此，水落石出，真相大白！

请看大屏幕——

由于MapHandlerExecutionStep（调用IHttpHandlerFactory.GetHandler()的地方）返回的IsCancellable的值是false，于是在HttpApplication.ExecuteStep()执行时没有调用_context.BeginCancellablePeriod()——也就是没有把_timeoutState设置为1，_context.IsInCancellablePeriod的值就是false。从而造成在Response.Redirect中进行Response.End()时没有执行AbortCurrentThread()（通常情况下都会执行这个）。于是代码继续执行，后面又来一次Response.Redirect，最终引发了——“无法在发送HTTP标头之后进行重定向”（Cannot redirect after HTTP headers have been sent）。