Can't display PDF from HTTPS in IE 8 (on 64-bit Vista)

Question

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?

Solution 1

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 :)

Solution 2

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.

Solution 3

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

did the trick for us in IE8 and IE9.

That did not require changing settings in the browser.

Solution 4

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.

Solution 5

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).

View more solutions

Comments

[x0n]

Might be this IE bug (5,5.5,6,7 and 8) is described here: support.microsoft.com/kb/323308

[DougN]

Good call Jeff. It's actually the 32-bit IE on 64-bit Vista (some of the pages contain flash, and there isn't a 64-bit flash player yet). Will edit the question...

[Jeff Moser]

There could be a potential issue with saving the file. I updated my answer.

[DougN]

Hmmm. In IE I unchecked "Do not save encrypted pages to disk". It looks like .jpg, .gif, .js and .css files are getting saved, but no .PDF or .html. Very odd... (although it's right in THIS case, it seems hard to believe IE could guess an image wouldn't contain private info)

[Jeff Moser]

What MIME type / "Content-type" are you sending for the PDF?

[Eamon Nerbonne]

I've run into this problem before; it's definitely caching related; IE won't "cache" the download into the system temp file and thus adobe can't open it from there.

[wweicker]

Thanks Eamon, I kept trying and ended up finding a programmatic solution!

[Tomasz]

Don't know if this has been solved yet or not, but given the information here, I had the PDF loading directly into the MSIE window. Afterwards, got it loading properly by changing MSIE Internet Options/Security Settings, Internet Zone - Custom Level options, "Automatic Prompting for file downloads" to Enable.

[CodeClimber]

Just to say I had this same issue after introducing SSL on applications running on a Tomcat (J2EE) server i.e. pdf docs not being displayed in IE7. None of the cache-control solutions worked but this did i.e. "httpResponse.addHeader("Accept-Ranges", "none");". +1 from me.

[Alexander Reifinger]

Header set Pragma "no-cache" was the culprit here - removing this made IE8 display the PDF again. Thank you, Internet Explorer team for another 2 wasted hours.

[Jon Gretar]

With me, it only works when adding Response.ClearHeaders(); first (Windows 2003/IIS 6.0).

[Ben]

This worked great for me.... Thank you so much, I've been trying loads of different ways people have suggested online and none worked until now, so thank you :)