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?

Christianna

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

Acrobat/Reader is only available as a 32-bit app. I believe Adobe only makes 32-bit plugins for browsers as well, so there's no way to view a PDF in a 64-bit browser... at least not with Acrobat/Reader. – Oscar

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

Christianna

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. – Pulpwood

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

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

Fluecure

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. – Lushy

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

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. – Statolith

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

Answer 3

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

did the trick for us in IE8 and IE9.

That did not require changing settings in the browser.

Spear

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

Chabot

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. – Peter

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

Gasholder

Answer 6

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

Rhiana

Answer 7

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.

Gaudy

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... – Christianna

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

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) – Christianna

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

What cache-control headers are you sending? Try sending Cache-Control: private rather than any directive that forbids caching. – Coachandfour

Answer 8

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.

Adaptable