Internet Explorer（具有默认设置，我通常认为它会在 Great Unwashed 的桌面上生效）似乎不喜欢在 HTTP 响应中接受附件内容的想法，如果相应的请求不是直接从用户操作发出的（如“点击”处理程序，或本机表单提交）。可能还有更多细节和细微差别，但这是令我沮丧的基本行为。
在我看来，这种情况很常见：一些可下载内容（例如，准备好的 PDF 报告）前面的用户界面允许在创建内容时使用一些选项和输入。现在，与所有允许用户规定应用程序如何做某事的表单一样，输入可能是错误的。不总是，但有时。
因此有一个两难选择。如果客户端试图做一些花哨的事情，比如运行一个 AJAX 事务让服务器审查表单内容，然后重新提交以获取下载，IE 不会喜欢那样的。它不会喜欢它，因为携带附件的实际 HTTP 事务不会发生在原始用户操作事件处理程序中，而是发生在 AJAX 完成回调中。更糟糕的是，由于 IE 安全栏似乎认为解决所有问题的方法是简单地从其原始 URL 重新加载外部页面，因此它对用户继续下载可疑内容的邀请甚至不起作用。
另一种选择是让表格开火。服务器检查参数，如果有任何错误，它会响应表单容器页面，并适当地添加错误消息。如果表单内容正常，它会生成内容并将其作为附加文件在 HTTP 响应中发回。在这种情况下（我认为），IE 很高兴，因为内容显然是由用户直接请求的（顺便说一下，这是一种区分好内容和坏内容的可笑的站不住脚的方式）。这很好，但现在的问题是客户端环境（即我页面上的代码）无法判断下载是否有效，因此表单仍然只是坐在那里。如果我的表单在某种对话框中，那么我真的需要在操作完成时关闭它——真的，那个'
在我看来，唯一要做的就是为表单对话框配备消息，例如“下载开始时关闭它”。这对我来说似乎很蹩脚，因为它是“请为我按下这个按钮”界面的一个例子：理想情况下，我自己的代码应该能够在适当的时候按下按钮。我不知道的一个关键问题是客户端代码是否有任何方法可以检测到表单提交导致附件下载。我从来没有听说过检测这种情况的方法，但这对我来说会打破僵局。