生成 PDF，IE 和 HTTPS 出错 [英] Generating PDF, error with IE and HTTPS
问题描述
我正在将 PDF 流式传输到 ASP.NET 2.0 中的浏览器.这适用于通过 HTTP 的所有浏览器和通过 HTTPS 的所有浏览器除外 IE.据我所知，这曾经(在过去 5 年左右)在所有版本的 IE 中都有效，但我们的客户最近才开始报告问题.我怀疑 不要将加密的页面保存到磁盘 安全选项过去是默认禁用的，并且在某些时候默认启用(Internet 选项 -> 高级 -> 安全).关闭此选项作为一种变通方法有帮助，但作为长期解决方案并不可行.
我收到的错误信息是:
<块引用>Internet Explorer 无法从 www.sitename.com 下载 OutputReport.aspx.
Internet Explorer 无法打开此 Internet 站点.请求的站点不可用或找不到.请稍后再试.
用于创建 PDF 的工具是来自 DataDynamics 的 ActiveReports.创建 PDF 后，以下是发送它的代码:
Response.ClearContent()Response.ClearHeaders()Response.AddHeader("cache-control", "max-age=1")Response.ContentType = "应用程序/pdf"Response.AddHeader("content-disposition", "attachment; filename=statement.pdf")Response.AddHeader("content-length", mem_stream.Length.ToString)Response.BinaryWrite(mem_stream.ToArray())Response.Flush()Response.End()注意:如果我没有明确指定缓存控制，那么 .NET 代表我发送 no-cache，所以我尝试将缓存控制设置为:private 或 public 或 maxage=#，但这些似乎都没有工作.
这是一个转折点:当我运行 Fiddler 来检查响应头时，一切正常.我收到的标题是:
<块引用>HTTP/1.1 200 正常
缓存控制:max-age=1
日期:2009 年 7 月 29 日星期三 17:57:58 GMT
内容类型:应用程序/pdf
服务器:Microsoft-IIS/6.0
MicrosoftOfficeWebServer:5.0_Pub
X-Powered-By:ASP.NET
X-AspNet-版本:2.0.50727
内容处置:附件；文件名=statement.pdf
内容编码:gzip
变化:接受编码
传输编码:分块
一旦我关闭 Fiddler 并再次尝试，它就会再次失败.我注意到的另一件事是，当 Fiddler 运行时，我收到一条此网站的安全证书有问题 警告消息，我必须单击 继续访问此网站(不推荐) 打通.当 Fiddler 关闭时，我不会遇到此安全警告，它会立即失败.
我很好奇 Fiddler 和浏览器之间发生了什么，以便它在 Fiddler 运行时工作，但在它不运行时中断，但更重要的是，有没有人知道如何更改我的代码以便将 PDF 流式传输到 IE 将工作不更改客户端机器?
更新: Fiddler 的问题已经解决，非常感谢 EricLaw，所以现在它的行为始终如一(无论 Fiddler 是否运行都已损坏).
基于 Google 搜索，网络上似乎有很多关于同一问题的报告，每个报告都有自己特定的响应标头组合，似乎可以针对各自的情况解决问题.我已经尝试了许多这些建议，包括添加 ETag、LastModified 日期、删除 Vary 标头(使用 Fiddler)以及 Cache-Control 和/或 Pragma 标头的数十种组合.我为 ContentType 尝试了内容传输编码:二进制"以及应用程序/强制下载".到目前为止没有任何帮助.有一个 少数 微软 KB 文章，所有这些都表明 Cache-Control: no-cache 是罪魁祸首.还有其他想法吗?
更新:顺便说一下，为了完整起见，Excel 和 Word 输出也会出现同样的问题.
更新: 没有取得任何进展.我将 Fiddler 的 .SAZ 文件通过电子邮件发送给 EricLaw，他在调试 IE 时能够重现该问题，但目前还没有解决方案.赏金即将到期...
经过两周的疯狂追逐，我一直无法找到任何代码更改组合来允许这种流式传输 PDF、Excel 或 Word 的方法'不要将加密的页面保存到磁盘'选项打开时的文档.
Microsoft 在许多知识库文章和私人电子邮件中表示这种行为是有意为之.看来，当不要将加密的页面保存到磁盘"选项打开时，IE 的行为是正确的，并且按照要求执行.这篇文章是迄今为止我发现的最好的资源解释了为什么要启用此设置以及启用它的优点和缺点:
<块引用><块引用><块引用>'不要将加密的页面保存到磁盘'在处理 SSL (HTTPS) 连接时发挥作用.就像网络服务器可以发送有关如何缓存文件的完成信息一样基本上将 Internet Explorer 设置为在 SSL (HTTPS) 连接期间不将文件保存到缓存中，无论网络服务器是否建议您这样做.
开启此功能有什么好处，安全性是开启此功能的首要原因.页面不会存储在 Internet 临时文件缓存中.
缺点是什么?性能缓慢，因为即使每次必须从网络服务器获取页面上使用了十几次的 1 字节 gif 图像，也不会将任何内容保存到缓存中.更糟糕的是，某些用户操作可能会失败，例如下载的文件将被删除、出现错误或无法打开 PDF 文档等."
此时我们能找到的最佳解决方案是向我们的客户和用户传达使用此设置的替代方案:
<块引用><块引用><块引用>使用'关闭浏览器时清空 Internet 临时文件文件夹'.每次浏览器关闭时，所有文件都将从缓存中清除，假设没有锁定来自浏览器的另一个实例或某些外部应用程序的文件.
在使用不要将加密的页面保存到磁盘"之前需要考虑很多因素.听起来像是一个很棒的安全功能，但使用此功能的结果可能会导致您的帮助台呼叫因下载失败或性能下降而增加."
I am streaming a PDF to the browser in ASP.NET 2.0. This works in all browsers over HTTP and all browsers except IE over HTTPS. As far as I know, this used to work (over the past 5 years or so) in all versions of IE, but our clients have only recently started to report issues. I suspect the Do not save encrypted pages to disk security option used to be disabled by default and at some point became enabled by default (Internet Options -> Advanced -> Security). Turning this option off helps, as a work-around, but is not viable as a long term solution.
The error message I am receiving is:
Internet Explorer cannot download OutputReport.aspx from www.sitename.com.
Internet Explorer was not able to open this Internet site. The requested site is either unavailable or cannot be found. Please try again later.
The tool used to create the PDF is ActiveReports from DataDynamics. Once the PDF is created, here is the code to send it down:
Response.ClearContent()
Response.ClearHeaders()
Response.AddHeader("cache-control", "max-age=1")
Response.ContentType = "application/pdf"
Response.AddHeader("content-disposition", "attachment; filename=statement.pdf")
Response.AddHeader("content-length", mem_stream.Length.ToString)
Response.BinaryWrite(mem_stream.ToArray())
Response.Flush()
Response.End()
Note: If I don't explicitly specify cache-control then .NET sends no-cache on my behalf, so I have tried setting cache-control to: private or public or maxage=#, but none of those seem to work.
Here is the twist: when I run Fiddler to inspect the response headers, everything works fine. The headers that I receive are:
HTTP/1.1 200 OK
Cache-Control: max-age=1
Date: Wed, 29 Jul 2009 17:57:58 GMT
Content-Type: application/pdf
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
content-disposition: attachment; filename=statement.pdf
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
As soon as I turn Fiddler off and try again, it fails again. One other thing that I noticed is that when Fiddler is running I get a There is a problem with this website's security certificate warning message, and I have to click Continue to this website (not recommended) to get through. When Fiddler is off, I do not encounter this security warning and it fails right away.
I am curious what is happening between Fiddler and the browser so that it works when Fiddler is running but breaks when it's not, but more importantly, does anyone have any ideas how I could change my code so streaming PDFs to IE will work without making changes to the client machine?
Update: The Fiddler issues are resolved, thank you very much EricLaw, so now it behaves consistently (broken, with or without Fiddler running).
Based on Google searching, there seem to be plenty of reports of this same issue all over the web, each with it's own specific combination of response headers that seem to fix the problem for their individual cases. I've tried many of these suggestions, including adding an ETag, LastModified date, removing the Vary header (using Fiddler) and dozens of combinations of the Cache-Control and/or Pragma headers. I tried "Content-Transfer-Encoding: binary" as well as "application/force-download" for the ContentType. Nothing has helped so far. There are a few Microsoft KB articles, all of which indicate that Cache-Control: no-cache is the culprit. Any other ideas?
Update: By the way, for completeness, this same issue occurs with Excel and Word outputs as well.
Update: No progress has been made. I emailed the .SAZ file from Fiddler to EricLaw and he was able to reproduce the problem when debugging IE, but there are no solutions yet. Bounty is going to expire...
After two weeks on a wild goose chase, I have not been able to find any combination of code changes that will allow this method of streaming PDF, Excel or Word documents when the 'Do not save encrypted pages to disk' option is turned on.
Microsoft has said this behavior is by design in a number of KB articles and private emails. It appears that when the 'Do not save encrypted pages to disk' option is turned on that IE is behaving correctly and doing what it is told to do. This post is the best resource I have found so far that explains why this setting would be enabled and the Pros and Cons of enabling it:
"The 'Do not save encrypted pages to disk' comes into play when dealing with SSL (HTTPS) connections. Just like a web server can send done information about how to cache a file one can basically set Internet Explorer up to not save files to the cache during an SSL (HTTPS) connection regardless if the web server advises you can.
What is the upside for turning this feature on, security is the number one reason why the feature is turned on. Pages are not stored in the Temporary Internet Files cache.
What is the downside? Slow performance, since nothing is saved to the cache even that 1 byte gif image used a dozen times on the page must be fetched from the webserver each time. To make matters worse some user actions may fail such as downloaded files will be deleted and an error presented or opening PDF documents will fail to name a few scenarios."
The best solution we can find at this point is to communicate to our clients and users that alternatives exist to using this setting:
"Use 'Empty Temporary Internet Files folder when browser is closed'. Each time the browser closes all files will be purged from the cache assuming there is not a lock on a file from another instance of the browser or some external application.
A lot of consideration needs to be given before utilizing 'Do not save encrypted pages to disk'. Sounds like a great security feature and it is but the results of using this feature may cause your help desk calls to go up for download failures or slow performance."
这篇关于生成 PDF，IE 和 HTTPS 出错的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
