无法在 IE 8 中显示来自 HTTPS 的 PDF(在 64 位 Vista 上)

发布于 2024-07-25 04:13:24 字数 560 浏览 10 评论 0原文

我有一个自制的 HTTPS 服务器,可以提供简单的文件(它嵌入在我的应用程序中)。 它效果很好——一直使用它。

最近添加了 SSL 支持——Chrome、FireFox 和 IE 都喜欢它并且加载页面效果很好。

我发现的问题是当我尝试通过 HTTPS 连接加载 PDF 文件时。 由于某种原因,PDF 永远不会在 IE 8(64 位 Vista 上的 64 位)中显示。 它在 Chrome 中运行良好。 当使用普通 HTTP 时,它在 IE 8 中工作正常——仅在使用 HTTPS 时失败。

注意:当提到 IE 8 时,它是 64 位 Vista 上的 32 位 IE 8,尽管 64 位 IE 8 具有相同的行为。

这让我认为这是某种 IE 8/HTTPS/PDF/64 位操作系统问题,但我不确定。

IE 8 的 DebugBar 显示请求和响应完全按照预期进行——没有任何错误。 IE 8 不显示任何错误或任何东西——纯白屏幕(或在我尝试加载 PDF 之前显示的页面)。 清除缓存/cookies/等。

IE/PDF/HTTPS 是否存在任何已知问题?

I have a home-grown HTTPS server that serves up simple files (it's embedded within my app). It works great -- been using it forever.

Recently added SSL support -- Chrome, FireFox and IE all like it and load pages just fine.

The problem I find is when I try to load a PDF file over the HTTPS connection. For some reason, the PDF never displays in IE 8 (64-bit on 64-bit Vista). It works fine in Chrome.
And it works fine in IE 8 when using plain HTTP -- only fails when using HTTPS.

NOTE: When IE 8 is mentioned, it's 32-bit IE 8 on 64-bit Vista, although the 64-bit IE 8 has the same behavior.

That makes me think it's some sort of IE 8/HTTPS/PDF/64-bit OS issue, but I'm not sure.

DebugBar for IE 8 shows the request and response went exactly as expected -- no errors at all. IE 8 doesn't show any errors or anything -- pure white screen (or the page that was displayed before I tried to load the PDF). Cleared cache/cookies/etc.

Are there any known issues with IE/PDF/HTTPS?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(8

倒数 2024-08-01 04:13:24

我想我会回来给出最终答案。

感谢所有建议“不要将加密页面保存到磁盘”的人。

我听从了 EricLaw 的建议并设置:

Cache-Control: private 

我还发现我有 Pragma: no-cache,我将其删除。

现在就像一个魅力:)

Thought I'd come back and give the final answer.

Thank you to everyone that suggested "Do not save encrypted pages to disk".

I followed EricLaw's advice and set:

Cache-Control: private 

I also found that I had Pragma: no-cache, which I removed.

Works like a charm now :)

み零 2024-08-01 04:13:24

我遇到了同样的问题,只能通过要求用户修改其安全设置以关闭“Internet 选项”对话框的“高级”选项卡中的“不将加密的页面保存到磁盘”来使其正常工作:
http://support.microsoft.com/kb/812935

...然后 随着恐慌立即结束,我开始查看代码(使用 VB 的 ASP.NET)。 我使用了 fiddler,发现即使我没有指定缓存控制标头,框架似乎也会自动为我指定 no-store。 解决问题的关键实际上是这个PHP问题。 通过将缓存控制标头设置为 max-age=1,文件将被缓存 1 秒,刚好足够 Adob​​e Reader 从磁盘中获取文件并将其加载到内存中。 我更新了代码以生成 PDF,如下所示:

Response.ClearContent()
Response.ClearHeaders()
Response.AddHeader("cache-control", "max-age=1")
Response.ContentType = "application/pdf"
Response.AddHeader("content-disposition", "attachment; filename=whatever.pdf")
Response.AddHeader("content-length", mem_stream.Length.ToString)
Response.BinaryWrite(mem_stream.ToArray())
Response.Flush()
Response.End()                                

更新: 我认为它可以正常工作,但我想我说得太早了。 我创建了一个新问题来解决此问题。

I ran into this same problem, and could only get it to work by asking the user to modify their security settings to turn off Do not save encrypted pages to disk in the Advanced tab of the Internet Options dialog:
http://support.microsoft.com/kb/812935

...then with the immediate panic over, I started looking at the code (ASP.NET using VB). I used fiddler and found that even when I wasn't specifying the cache-control header it seemed that the Framework was automatically specifying no-store for me. The key to solving the issue was actually in this PHP question. By setting the cache-control header to max-age=1 the file would be cached for 1 second, just long enough for Adobe Reader to pick it up from the disk and load it into memory. I updated our code to generate the PDF as follows:

Response.ClearContent()
Response.ClearHeaders()
Response.AddHeader("cache-control", "max-age=1")
Response.ContentType = "application/pdf"
Response.AddHeader("content-disposition", "attachment; filename=whatever.pdf")
Response.AddHeader("content-length", mem_stream.Length.ToString)
Response.BinaryWrite(mem_stream.ToArray())
Response.Flush()
Response.End()                                

Update: I thought it was working, but I guess I spoke too soon. I created a new question to follow through with this issue.

是你 2024-08-01 04:13:24
response.setHeader("Cache-Control","private");

在 IE8 和 IE9 中为我们做到了这一点。

这不需要更改浏览器中的设置。

response.setHeader("Cache-Control","private");

did the trick for us in IE8 and IE9.

That did not require changing settings in the browser.

峩卟喜欢 2024-08-01 04:13:24

我在 IE8 和 https 上也遇到了类似的问题。 当我尝试将 pdf 流式传输到新窗口时,我得到了一个空白的 html 页面(它在 FireFox 中工作,如果不是通过 https)。 经过大量搜索并尝试响应标头的不同变体后,我的解决方案是设置:

Response.AppendHeader("Accept-Ranges", "none");

这会在之前下载整个 pdf如果它是一个非常大的pdf文件,它打开起来不太方便用户。 但就我而言,大多数 pdf 文件只有几页。 希望这可以帮助别人。

I had a similar problem with IE8 and https. When I tried to stream a pdf to a new window, I got a blank html page instead (it worked in FireFox and if it wasn't via https). After a lot of searching and trying different variations of the response headers, the solution for me was to set:

Response.AppendHeader("Accept-Ranges", "none");

This downloads the whole pdf before it opens which is less user-friendly if it is a very large pdf. But in my case most pdfs were only a few pages. Hope this helps someone out.

回忆凄美了谁 2024-08-01 04:13:24

我在您的问题中没有看到任何对 .NET 的引用,但我将提供相关的解决方案。 希望您能从中获得所需的信息,并且假设您的问题与 .NET 有关的开发人员也可能会发现其中的价值。

这是我之前使用过的一种通过 HTTPS 渲染浏览器内 PDF 的方法,无需**缓存。

    private void RenderPdfToResponse(byte[] documentBytes) {
        Response.BufferOutput = true;
        Response.ClearContent();
        Response.ClearHeaders();
        Response.AddHeader("Cache-control", "no-store");
        Response.ContentType = "application/pdf";
        Response.AddHeader("Content-Length", documentBytes.Length.ToString());
        Response.BinaryWrite(documentBytes);
        Response.Flush();
        HttpContext.Current.ApplicationInstance.CompleteRequest();
    }

** 会出现一个伪缓存,其长度足以让 Adob​​e Reader 加载 PDF 文件。 我查找了描述我正在谈论的内容的参考资料,以及随机论坛主题 是我能做的最好的事情:

IE 将 PDF 存储在
分配的“易失性”内存和位置
%system% Temp 中的指针。 这是
文件存储的唯一位置。 这
指针被删除并分配
Adobe 一旦释放内存
阅读器已关闭。

我不能保证其技术准确性,但它确实反映了我使用上述方法观察到的情况。 事实上,我认为该文件在 Adob​​e Reader(在浏览器中)中加载完成后就会消失。

I don't see any reference to .NET in your question, but I'm going to provide a related solution. Hopefully you can take from it what you need, and developers assuming your question pertains to .NET might find value in it, too.

Here's a method I've used before to render in-browser PDFs, via HTTPS, without** caching.

    private void RenderPdfToResponse(byte[] documentBytes) {
        Response.BufferOutput = true;
        Response.ClearContent();
        Response.ClearHeaders();
        Response.AddHeader("Cache-control", "no-store");
        Response.ContentType = "application/pdf";
        Response.AddHeader("Content-Length", documentBytes.Length.ToString());
        Response.BinaryWrite(documentBytes);
        Response.Flush();
        HttpContext.Current.ApplicationInstance.CompleteRequest();
    }

** There is a pseudo-cache that occurs, just long enough for Adobe Reader to load the PDF file. I looked for a reference describing what I'm talking about, and a random forum thread is the best I could do:

IE stores the PDF in
allocated 'volatile' memory and places
a pointer in %system% Temp. This is
the only place the file is stored. The
pointer is deleted and allocated
memory is freed as soon as Adobe
Reader is closed.

I can't vouch for the technical accuracy of that, but it does reflect what I've observed using the method above. In fact, I think that file disappears the moment it's finished loading in Adobe Reader (in the browser).

书信已泛黄 2024-08-01 04:13:24

我的解决方案(我们花了几天时间研究标题才使其发挥作用):

            if (System.Web.HttpContext.Current.Request.Browser.Browser == "InternetExplorer"
                && System.Web.HttpContext.Current.Request.Browser.Version == "8.0")
            {
                System.Web.HttpContext.Current.Response.Clear();
                System.Web.HttpContext.Current.Response.ClearContent();
                System.Web.HttpContext.Current.Response.ClearHeaders();
                System.Web.HttpContext.Current.Response.ContentType = "application/octet-stream";

                System.Web.HttpContext.Current.Response.AppendHeader("Pragma", "public");
                System.Web.HttpContext.Current.Response.AppendHeader("Cache-Control", "private, max-age=60");
                System.Web.HttpContext.Current.Response.AppendHeader("Content-Transfer-Encoding", "binary");

                System.Web.HttpContext.Current.Response.AddHeader("content-disposition", "attachment; filename=" + document.Filename);
                System.Web.HttpContext.Current.Response.AddHeader("content-length", document.Data.LongLength.ToString());

                System.Web.HttpContext.Current.Response.BinaryWrite(document.Data);
            }

希望对某人有帮助

My solution (it took us days of playing around with headers to get this to work):

            if (System.Web.HttpContext.Current.Request.Browser.Browser == "InternetExplorer"
                && System.Web.HttpContext.Current.Request.Browser.Version == "8.0")
            {
                System.Web.HttpContext.Current.Response.Clear();
                System.Web.HttpContext.Current.Response.ClearContent();
                System.Web.HttpContext.Current.Response.ClearHeaders();
                System.Web.HttpContext.Current.Response.ContentType = "application/octet-stream";

                System.Web.HttpContext.Current.Response.AppendHeader("Pragma", "public");
                System.Web.HttpContext.Current.Response.AppendHeader("Cache-Control", "private, max-age=60");
                System.Web.HttpContext.Current.Response.AppendHeader("Content-Transfer-Encoding", "binary");

                System.Web.HttpContext.Current.Response.AddHeader("content-disposition", "attachment; filename=" + document.Filename);
                System.Web.HttpContext.Current.Response.AddHeader("content-length", document.Data.LongLength.ToString());

                System.Web.HttpContext.Current.Response.BinaryWrite(document.Data);
            }

Hope that helps someone

一抹苦笑 2024-08-01 04:13:24

您在 Vista 64 上运行 32 位还是 64 位版本的 IE? 两者都有。 大多数时候使用 32 位版本,因为还没有多少插件支持 64 位。

我会检查一下两者之间是否有区别。 如果它在 Vista 64 上的 IE 8 32 位中工作,则可能是 64 位版本的浏览器帮助程序对象 (BHO) 的问题。

另外,检查(通过任务管理器在进程名称后是否存在“*32”)其他浏览器是否在 32 位模式下运行。

我要检查的另一件事是 HTTPS 是否导致 IE8 由于某种原因不缓存 PDF 文件(HTTPS 流量通常不缓存)。 我会运行 procmon 来查看您是否注意到 PDF 文件被写入文件系统。 您可能需要更改某些策略设置。 我不确定是否有其他方法可以表示您有一个不应写入磁盘但仍可以显示的 PDF。

Are you running the 32 bit or 64 bit version of IE on Vista 64? It comes with both. Most times the 32 bit version is used since not many plugins support 64 bit yet.

I'd check to see if there is a difference between the two. If it works in IE 8 32 bit on Vista 64 then it could be an issue with the 64 bit version of the Browser Helper Object (BHO).

Also, check to see (via Task Manager's presence of a '*32' after a process name) if the other browsers are running in 32 bit mode.

Another thing I'd check to see if is HTTPS is causing IE8 to not cache the PDF file for some reason (HTTPS traffic is typically not cached). I'd run procmon to see if you notice a PDF file being written to the file system. There could be policy setting that you might need to change. I'm not sure if there is an alternative way of saying you have a PDF that shouldn't be written to disk but still could be displayed.

熟人话多 2024-08-01 04:13:24

作为用户,我在从 Schwab.com 加载 pdf 文件时遇到了同样的问题。 建议“在“Internet 选项”对话框的“高级”选项卡中关闭“不将加密页面保存到磁盘”:http ://support.microsoft.com/kb/812935”为我工作。

As a user, I was having the same problem loading pdf files from Schwab.com. The advice to " turn off Do not save encrypted pages to disk in the Advanced tab of the Internet Options dialog: http://support.microsoft.com/kb/812935" worked for me.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文