7

我们应用程序的用户在一天中至少每两秒钟下载一次附件。

以前的场景：

在用户下载附件后，我们使用 Response.End() 中止与客户端的连接。当我们遇到性能问题时，我们开始记录异常，其中最重复的一个是线程中止异常。由于我们从 Web 服务获取附件，因此我们必须进行一些清理，并且我们在 try-catch-finally 块中进行了清理。经过一番研究，我了解到 Response.End() 之后的任何代码即使在 finally 块中也不会被执行。是对的吗？

当前场景：

我已经阅读了堆栈溢出中有关 Response.End() 有害的线程，并且仅在真正需要时才需要使用它，因此我决定改用 HttpContext....CompleteRequest() 。使用此代码，完成了所需的清理工作，但呈现的 html 被附加到下载的附件中。我尝试覆盖同一篇文章中建议的 Render 和 RaisePostBackEvent，但问题仍然存在。有关如何解决此问题的任何想法都会有所帮助。

代码：

HttpContext.Current.Response.Clear();

Response.ClearContent();

Response.ClearHeaders();

Response.AddHeader("Content-Disposition", "attachment; filename=" +   
filename);
Response.AddHeader("Content-Length", fileContent.Length.ToString());
Response.ContentType = "application/octet-stream";
Response.BinaryWrite(fileContent);
Response.Flush();
4

2 回答 2

7

Response.End内部抛出ThreadAbortException杀死请求 - 如果您需要进行某种清理，这需要在调用之前Response.End完成。

Response.Redirect并且Response.End不要与 try / catch 块很好地交互。因此，在您的情况下，您应该在 try / catch 中将所有逻辑写入响应流，然后Response.End在 finally 块之后简单地调用。

于 2012-05-15T15:35:14.437 回答
1

老 Q，不确定它是否有帮助，但在创建 PDF 文件以交付给浏览器时，我的做法与您的示例基本相同。但是，在处理结束时，我有以下内容：

    Response.OutputStream.Flush()
    Response.OutputStream.Close()
    Response.End()

添加 .Close() 基本上。似乎在生产中工作正常。

Ed：我也发现了这个，提到 Close(): Is Response.End() 被认为是有害的？

解决问题的另一种方法是简单地覆盖 Page_PreRender() 并将内容交付代码放在那里（这在功能上是有意义的）。那么你肯定不会得到任何不需要的 HTML，而且根本不需要 Response.End()。

于 2013-01-07T09:58:30.347 回答