博客后台切换至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）。
转发：https://www.cnblogs.com/dudu/p/cannot-redirect-after-http-headers-have-been-sent.html