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

时间:2022-07-23 17:01:44

博客后台切换至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("/") + )); //后续也有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("/") + ));
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 ? : ; //进行重定向操作
//...
_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) == ); }
}

根据上面的代码,触发这个问题的条件是_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) == -) {
SetStartTime();
} Volatile.Write(ref _timeoutState, );
}

然后再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)。