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打开DotNetReferenceSource\Source\ndp.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）。
