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?

Answer 1

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.

Answer 2

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

Answer 3

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.

Answer 4

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.

Answer 5

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

Answer 6

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.