HttpResponse.End vs HttpResponse.Close vs HttpResponse.SuppressContent

Question

在ASPX页面中,我希望在特定点(不是由于错误条件)结束响应,具体取决于代码路径,以便在流中不发送任何其他内容.所以自然使用:

Response.End();

这会导致ThreadAbortException,这是设计使然.

以下似乎有效,但看起来不像这个问题的正确方法:

Response.Flush();
Response.Close();

那么,这个怎么样？

Response.Flush();
Response.SuppressContent = true

然后让页面正常完成.

我可以处理并吞下ThreadAbortException,但我只是想知道SuppressContent方法是否有任何错误/陷阱？

编辑: 举几个例子.假设我有一个ASPX页面,我可以将内容类型更改为多种可能性之一.根据内容类型和方案,在代码中的给定点我想阻止将更多内容发送到客户端.假设在SuppressContent设置为true后,运行任何进一步的服务器端代码都没有问题.我只是不想将任何其他内容发送给客户端.

编辑2: MyPage.aspx - 有一个母版页,可能包括标准内容,页眉,页脚等.此页面可以呈现为普通页面.它还可以写出要下载的(例如)XML文档.如果写出一个XML文档(在页面加载时确定),它将清除输出,将内容类型设置为XML,将所有XML写出,然后如果正常,最终将使用其余的ASPX页面呈现为坚持到底 - 这显然不是必需的/打破XML.

编辑3: 现在我正在使用SuppressContent方法.为了尝试结束这个问题,我提出了一个赏金,并且会以另一种方式提出问题:你什么时候应该使用SuppressContent？为什么要使用它而不是Response.End？

---

请参阅我在下面提供的答案,我实际上最终得到了解决方案,因为我最终找到了一种方法来避免使用Response.End时出现ThreadAbortException.到目前为止,我已经排除了答案.

---

Answer 1

我知道这是一个老问题,但我将这包括在内,以免任何可能偶然发现这篇文章的人受益.我一直在追查一个错误,这个错误让我回顾了我对Response.End的使用,并在这个问题后的一年内发现了MSDN帖子,可以概括为" 从不使用Response.End ".以下是设计IIS7集成管道的Thomas Marquardt所说的:

End方法也在我的"从不使用"列表中.停止请求的最佳方法是调用HttpApplication.CompleteRequest.End方法只是因为我们试图在发布1.0时与经典ASP兼容.Classic ASP有一个Response.End方法,用于终止ASP脚本的处理.为了模仿这种行为,ASP.NET的End方法尝试引发ThreadAbortException.如果成功,调用线程将被中止(非常昂贵,不利于性能),管道将跳转到EndRequest事件.ThreadAbortException,如果成功,当然意味着线程在它可以调用更多代码之前展开,所以调用End意味着你之后不会调用任何代码.如果End方法无法引发ThreadAbortException,它会将响应字节刷新到客户端,但它会同步执行此操作,这对性能非常不利,并且当End完成执行后的用户代码时,管道会提前跳转到EndRequest通知.将字节写入客户端是一项非常昂贵的操作,特别是如果客户端位于世界的中途并使用56k调制解调器,因此最好异步发送字节,这是我们在请求以正常方式结束时所执行的操作.同步刷新真的很糟糕.总而言之,你不应该使用End,但使用CompleteRequest是完全没问题的.End的文档应声明CompleteRequest是跳过EndRequest通知并完成请求的更好方法.

来自http://blogs.msdn.com/b/aspnetue/archive/2010/05/25/response-end-response-close-and-how-customer-feedback-helps-us-improve-msdn-documentation.aspx

Answer 2

我最终找到了一个简单的解决方案,使用Response.End()而不会得到ThreadAbortException.

Response.Flush();
Response.End();

从我原来的问题来看,在将一些内容发送到响应流之后,我一直在尝试一个Response.End().

似乎如果在执行Response.End()时存在未刷新的内容,则会得到ThreadAbortException.通过在结束之前立即执行Flush,实际上不会抛出ThreadAbortException.

似乎工作得很好 - 当我使用Response.End时,现在没有抛出ThreadAbortException

Answer 3

更新 - 警告：有一个更好的方法，不要使用这个，请参阅 Ethan 的答案！

我不会说有充分的理由避免 Response.End。希望通过让页面请求循环继续并让它执行不必要的额外工作来避免 ThreadAbortException 的成本似乎并不正确。

ThreadAbortException 是一种特殊类型的异常，旨在停止线程执行（即使捕获也会自动重新抛出）。也就是说，在某些情况下它可能会造成损害（请参阅ThreadAbortException末尾添加的社区内容）。

除非您处于其中一种情况，否则您应该坚持使用 Response.End。请注意，周围的一些用法，请执行 SuppressContent & Response.End，我想在您想要避免来自内部 Response.Flush 的某些内容的情况下。