生成PDF，错误与IE和HTTPS [英] Generating PDF, error with IE and HTTPS

问题描述

我流PDF格式在ASP.NET 2.0的浏览器。这在HTTP上的所有浏览器和所有的浏览器除了的IE浏览器通过HTTPS。据我所知，这用来工作（在过去的5年左右），在IE浏览器的所有版本，但我们的客户最近才开始报告问题。我怀疑不要将加密的页面到磁盘用于在默认情况下，在某些时候被禁用安全选项成为默认情况下启用（Internet选项 - >高级 - >安全）。关闭此选项会有所帮助，作为一个变通办法，而不是作为一个可行的长期解决方案。

我收到错误消息是：

  

Internet Explorer无法从www.sitename.com下载OutputReport.aspx。

  
  

的Internet Explorer无法打开此Internet站点。请求的站点不可用或无法找到。请稍后再试。

用于创建PDF的工具是从 DataDynamics 的ActiveReports。一旦PDF创建，这里是code派下来：

  Response.ClearContent（）
Response.ClearHeaders（）
Response.AddHeader（缓存控制，最大年龄= 1）
Response.ContentType =应用程序/ PDF
Response.AddHeader（内容处置，附件;文件名= statement.pdf）
Response.AddHeader（内容长度，mem_stream.Length.ToString）
Response.BinaryWrite（mem_stream.ToArray（））
Response.Flush（）
到Response.End（）
 

请注意：如果我没有明确指定缓存控制那么.NET发送无缓存代表我的，所以我曾尝试缓存控制设置为：私人或公共或超过maxage =＃，但没有这些似乎的工作。

下面是扭曲：当我运行Fiddler检查响应报头，一切工作正常。我收到的标题是：

  

的HTTP / 1.1 200 OK

  缓存控制：最大年龄= 1

  日期：星期三，2009年17点57分58秒GMT

  内容类型：应用程序/ PDF

  服务器：Microsoft-IIS / 6.0

  MicrosoftOfficeWebServer：5.0_Pub

  的X已启动方式：ASP.NET

  的X ASPNET-版本：2.0.50727

  内容处置：附件;文件名= statement.pdf

  内容编码：gzip

  有所不同：接受编码

  传输编码：分块

当我打开提琴手，然后再尝试，再次失败。我注意到的另一件事是，当小提琴手正在运行，我得到一个没有此网站的安全证书的警告消息的问题，我必须单击继续浏览此网站（不推荐） 打通。当小提琴手是关闭的，我不遇到这个安全警告和失败的时候了。

我很好奇是什么提琴手和浏览器之间发生的事情，这样它的时候提琴手运行工作，但是当它不会打破，但更重要的是，没有任何人有任何想法如何，我可以改变我的code使流的PDF文件，以IE浏览器将不会更改到客户机工作的？

更新：的提琴手问题都解决了，非常感谢你EricLaw，所以现在一致（破碎，有或无小提琴手运行）的行为

根据谷歌搜索，似乎有很多同样的问题的报告，所有网站上，每个响应头的它自己的特定组合，似乎解决该问题的个别情况。我尝试过很多这样的建议，包括增加了ETag，上次更改日期，消除Vary标头（使用招）等几十种的Cache-Control和/或杂注头的组合。我尝试内容传输编码：二进制，以及应用程序/强制下载，为的Con​​tentType。到目前为止，没有任何帮助。有一个几个 微软 KB 文章，所有这一切都表明，的Cache-Control：no-cache的的是罪魁祸首。任何其他的想法？

更新：顺便说一句，完整性，与Excel发生同样的问题和Word输出以及

更新：没有已经取得了进展。我从提琴手通过电子邮件发送的.SAZ文件EricLaw，他能够在调试IE时重现该问题，但没有解决办法呢。赏金即将过期...

解决方案

在白费力气

两周后，我一直没能找到code的变化，使流PDF这种方法的任意组合， Excel或Word文档时，不要将加密的页面到磁盘选项是打开的。

微软曾表示，这种行为是通过设计一些KB文章和私人电子邮件。看来，当不要将加密的页面到磁盘选项打开时，IE浏览器的正常运作和做什么它被告知的事情。 这个帖子是迄今为止，说明我已经找到了最好的资源为什么这个设置​​将被启用和优点，并启用它的缺点：

  

    

      

的不将加密的页面到磁盘使用SSL打交道时进场（HTTPS）连接。就像一个Web服务器可以发送有关如何缓存文件包含一个可以操作的信息基本上Internet Explorer设置了如果Web服务器建议你可以到不是一个SSL（HTTPS）连接时将文件保存到缓存中，无论

      
      

什么是对，安全是头号原因开启此功能开启此功能的​​上涨空间。页面没有存放在Temporary Internet Files文件缓存。

      
      

什么缺点？性能缓慢，因为没有保存到缓存中使用即使是1个字节的GIF图像在页面上了十几次，必须从网络服务器每次取出。更糟糕的是，例如下载的文件将被删除并且错误presented或打开PDF文档将无法仅举几例情况下某些用户操作可能会失败。

    
  

我们可以发现在这一点最好的解决办法是向我们的客户和用户的替代品存在的通信使用此设置：

  

    

      

使用'关闭浏览器时清空Temporary Internet Files文件夹。每次在浏览器关闭所有文件将从缓存假设没有从浏览器或一些外部应用程序的另一个实例文件的锁被清除。

      
      

很多的考虑需要利用之前给予不要将加密的页面到磁盘。听起来像一个伟大的安全功能，它是，但使用此功能的结果可能会导致您的帮助台呼叫上去下载故障或性能降低。

    
  

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屋！