正确使用 Asp.Net Response.TransmitFile 和 Response.End()答案

【问题标题】：Correct usage of Asp.Net Response.TransmitFile and Response.End()正确使用 Asp.Net Response.TransmitFile 和 Response.End()
【发布时间】：2013-01-28 16:41:37
【问题描述】：

这段代码的正确用法是什么？

httpContext.Response.AddHeader("Content-Disposition", "inline; filename=" + HttpUtility.UrlPathEncode(fileName));
httpContext.Response.ContentType = "image/png";
httpContext.Response.AddHeader("Content-Length", new FileInfo(physicalFileName).Length.ToString());
httpContext.Response.TransmitFile(physicalFileName);
httpContext.Response.Flush();
httpContext.Response.End();  //Use it or not?

.Flush()和.End()真的很好用吗？

根据this，您永远不应该使用Response.End()（仅在错误或黑客攻击的情况下）

但在某些答案中，建议使用 .End()...？

喜欢this文章。

那么使用Response.End是否合适？

【问题讨论】：

标签： c# asp.net

【解决方案1】：

根据Thomas Marquardt，你不应该使用Response.End()。相反，您应该使用Context.ApplicationInstance.CompleteRequest()。也检查一下这个article，它来自Microsoft KB，建议使用Application.CompleteRequest() 而不是Response.End()。

【讨论】：

我认为@DanielCuadra 提出了一个有效的观点，即如果您不使用 Response.End，人们仍然可以编辑响应。但是我相信 Response.SuppressContent 会阻止这种情况。
我的回答是试图准确警告 Thomas Marquardt 的文章并未涵盖所有场景，也没有列出假设/先决条件/警告以防止出现极端情况下的问题；世界上没有人能写出没有错误的文章。流文件（而不是简单地呈现 aspx 页面）是一种在输出流上写入意外的额外字节可能会极大地影响您的网站的操作，并且您需要数天或数周的时间来调试并找出问题所在。

【解决方案2】：

我添加这个是为了让人们不会陷入错误接受的响应：在传输文件后大多数情况下可能需要Response.End()。

无论您是使用 TransmitFile，还是决定直接写入输出流，都没有关系，只是大多数时候您希望确保在发送文件后没有人可以写入单个字节。

这一点特别重要，因为在某些时候会在 IIS 上安装过滤器，在全局 asax EndRequest 上安装代码，或者调用您的代码然后做更多事情的开发人员，其中任何一个最终都会将更多内容附加到输出流而您没有注意到它，它会破坏您传输的文件内容。 - CompleteRequest 不会让您摆脱这种情况，因为它允许在您调用它后在响应中添加更多内容。

Response.End() 是保证未来没有其他代码更改或 IIS 过滤器将按预期操纵您的响应的唯一方法。

【讨论】：

根据我的经验 Response.End() 会导致非常烦人的 ThreadAbort 异常。它不会破坏任何东西，但会在我们的日志中填充虚假的错误消息。
完全正确，而且效率也很低，但是我还没有找到任何其他方法来强制没有其他代码段会改变响应输出流。举个例子，你的 IT 安全部门可能会在不询问您的情况下在一年中的任何一天安装 IIS 上的 http 模块，该模块将过滤请求并可能在输出流上附加“版权”消息（或注入一些企业 cookie 用于跟踪目的等），就在响应通过电线。想象一下，您的下载遇到了各种各样的问题，却不知道发生了什么。
msdn.microsoft.com/en-us/library/… "CompleteRequest 方法不会引发异常，调用 CompleteRequest 方法之后的代码可能会被执行。如果您的意图是避免执行后续代码，并且如果性能损失End 是可以接受的，你可以调用 End 而不是 CompleteRequest。” - 谢谢你提出来。我完全错过了这部分。
也许你没有错过：在多人抱怨各种奇怪的问题避免调用 Response.End() 之后，MS 添加了文档中的这一部分。 MS 最终承认确实存在合法案例并修复了他们的文档。
难道 Response.SuppressContent 不会阻止写入响应吗？