C# Response.End() 与 HttpContext.Current.ApplicationInstance.CompleteRequest()
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/10603553/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Response.End() vs HttpContext.Current.ApplicationInstance.CompleteRequest()
提问by user1396468
The users of our application download an attachment at least once in two seconds during the day.
我们应用程序的用户在白天至少每两秒下载一次附件。
Previous Scenario:
上一个场景：
We were using Response.End() to abort the connection to the client after the user downloads an attachment. As we were having performance issues, we started logging exceptions and one of the most repeated one was the thread abort exception. Since we are getting the attachment from a web service, We have to do some clean up and we had the clean up in try-catch-finally block. After some research, I have understood that any code after Response.End() will not be executed even if it is in finally block. Is that right?
在用户下载附件后，我们使用 Response.End() 中止与客户端的连接。当我们遇到性能问题时，我们开始记录异常，其中最重复的异常之一是线程中止异常。由于我们从 Web 服务获取附件，因此我们必须进行一些清理，并且在 try-catch-finally 块中进行了清理。经过一番研究，我了解到 Response.End() 之后的任何代码即使在 finally 块中也不会被执行。那正确吗？
Current Scenario:
当前场景：
I've read the thread in stack overflow about Response.End() being harmful and it needs to be used only when it is really needed, so I decided to use HttpContext....CompleteRequest() instead. With this code, the clean up needed is done, but the html that is rendered is being appended to the attachment downloaded. I tried overriding the Render and RaisePostBackEvent suggested in the same article but the problem still persists. Any idea on how to resolve this issue would be helpful.
我已经阅读了堆栈溢出中关于 Response.End() 有害的线程，并且只有在真正需要时才需要使用它，所以我决定使用 HttpContext....CompleteRequest() 代替。使用此代码，所需的清理工作已完成，但呈现的 html 将附加到下载的附件中。我尝试覆盖同一篇文章中建议的 Render 和 RaisePostBackEvent，但问题仍然存在。有关如何解决此问题的任何想法都会有所帮助。
Code:
代码：
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();
采纳答案by Tejs
Response.Endinternally throws the ThreadAbortExceptionto kill the request - if you need to do some kind of cleanup, this needs to be done beforethe call to Response.Endis made.
Response.End内部抛出终止ThreadAbortException请求 - 如果您需要进行某种清理，则需要在调用之前Response.End完成。
Response.Redirectand Response.Enddo not interact well with try / catch blocks. So in your situation, you should do all your logic writing to the response stream in your try / catch, then simply call Response.Endafter your finally block.
Response.Redirect并且Response.End不能与 try / catch 块很好地交互。因此，在您的情况下，您应该在 try / catch 中将所有逻辑写入响应流，然后Response.End在 finally 块之后调用。
回答by ingredient_15939
Old Q, and not sure if it helps, but I do essentially the same as your example when creating PDF files to deliver to the browser. However, at the end of processing, I have the following:
老 Q，不确定它是否有帮助，但在创建 PDF 文件以交付给浏览器时，我的做法与您的示例基本相同。但是，在处理结束时，我有以下内容：
Response.OutputStream.Flush()
Response.OutputStream.Close()
Response.End()
The addition of .Close() basically. Seems to work fine in production.
添加 .Close() 基本上。似乎在生产中工作正常。
Ed: Just found this too, mentioning Close(): Is Response.End() considered harmful?
Ed：刚刚也发现了这个，提到 Close()：Response.End() 被认为是有害的吗？
Another approach to your problem is simply overriding Page_PreRender() and putting the content delivery code in there (which kind of makes functional sense). Then you definitely won't get any unwanted HTML, and there should be no need for Response.End() at all.
解决您的问题的另一种方法是简单地覆盖 Page_PreRender() 并将内容交付代码放在那里（这在功能上有意义）。那么你绝对不会得到任何不需要的 HTML，而且根本不需要 Response.End()。
