PDF wrong error in IE6 and IE7 with https

Response.Write("<script language=\"javascript\">window.open( with https and pdf

What we do in a Asp.Net 1.1.4332 application is the following:

a button triggers a server event that does some processing and puts the data in a session object after that the following code is executed :

string page = Request.ApplicationPath + "/ApkRapportPage.aspx";    
Response.Write("<script language=\"javascript\">window.open('" + page + "','_new');</script>");

this opens a page that streams a pdf to the new browser window

basically with the following code ( I know stuff is missing here, but that doesn't really mater for the question)

byte[] pdfbytes = Convert.FromBase64String(rapportB64);

Response.ClearContent();
Response.ClearHeaders();
Response.Buffer = true;
Response.ContentType = GetContentType(format);
string header = GetContentDispostionHeader(fileName, format, type);
Response.AddHeader("Content-Disposition", header);
Response.BinaryWrite(pdfbytes);   
Response.End();

Okay this code works !

Just not in IE6 and IE7 when using HTTPS

When using IE6 with HTTPS it results in a save-as dialog (not a pdf that opens in a browser) When using IE7 with HTTPS it results in a blank screen When using Firefox it works just fine

If I simulate the extra server side processing in the page_load to put the required data in the session and replace the button with a link that opens the same pdf generating page in a new window, the code works.

For the actual application it is not an option to get the required data before the button is clicked.

So I would really like to get the following code to work

string page = Request.ApplicationPath + "/ApkRapportPage.aspx";    
Response.Write("<script language=\"javascript\">window.open('" + page + "','_new');</script>");

Questions: Does anybody know why this code doesn't work in IE6 and IE7 when using HTTPS ? What is needed to get the code to work ?

Extra info:

• I tried not using response.write but just a javascript window.open behind the button, this has the same effect
• when googling for pdf streaming, you can find a lot of people having trouble with this, mostly they set header lengths or other properties or static file compression flags in IIS. I am pretty confident I tried them all.
• Adobe acrobat reader settings, browser settings or any other client side settings don't seem to be the problem. Tested on different machines, with http works, with https it doesn't.
• Switching between https and http might have something to do with this, but when I set IE to tell me when I am switching, no switching seems to occur during testing.
• When replacing the window.open part with a response.redirect then the code also works, just not in a new window

Any help would be greatly appreciated !

---

As requested the headers, as shown by Fiddler:

   HTTP/1.1 200 OK
   Server: Microsoft-IIS/5.1
   Date: Thu, 05 Mar 2009 14:18:36 GMT
   X-Powered-By: ASP.NET
   X-AspNet-Version: 1.1.4322
   Content-Disposition: Inline;filename=APKrapport.pdf
   Cache-Control: private
   Content-Type: application/pdf; charset=utf-8
   Content-Length: 28307

From stackoverflow

• Getting attachments to open the way you want has everything to do with the headers you send. If you locate to an .aspx page that you want to act as a dynamic PDF resource these HTTP headers become increasingly important.

  This website states a number of reasons why it might not work in IE.

  1. Set the content-type of the response to "application/pdf", ex. response.setContentType("application/pdf");
  2. Add a dummy parameter on the end of the url, like: http://x.y.z/DoGenCompStmt?filename=dummy.pdf because IE ignores content-types, so you need to give it a hint, and the ".pdf" extension is an easy way.
  3. Set the "content-length" on the response, otherwise the Acrobat Reader plugin may not work properly, ex. response.setContentLength(bos.size());
  4. An additional thing that seems to help some IE browsers is to also have : response.setHeader("Content-Disposition", "inline;filename=somepdf.pdf");

  EDIT: since you already tried all of the above i can only point you to the rfc for content disposition which to my knowledge is the only way to tell a browser how to deal with binary content.

  EDIT: what would really help is to see the HTTP Headers it currently returns when you try to open the pdf in the browser. Fiddler does a great job at catching traffic

  KeesDijk : Yep, thanks for the effort. But I tried all that.

• You'd be better off using a generic handler (.ASHX) to serve this sort of content, rather than trying to force a web-page to serve content other than HTML.

  KeesDijk : Thanks for the suggestion. I just tried this and it looks like a cleaner solution. It doesn't solve my problem though. The result is the same.

• After a lot of trial and error I found a working solution, still not sure why the other code doesn't work.

  This code works:

  StringBuilder js = new StringBuilder("<script language=\"javascript\">");
  js.Append("_window = window.open(\"\",'_new');");
  js.Append("_window.document.open(\"application/pdf\");");
  js.Append("_window.location.href = \"ApkRapportPage.aspx\";");  
  js.Append("_window.document.close();");
  js.Append("</script>");
  
  Response.Write(js.ToString());
  

  Must have something to do with the mime type.

  It has a problem though. When IE is set to show when you switch between HTTP and HTTPS this code will give that message twice. The following code doesn't switch but causes the page load of ApkRapportPage to be fired twice.

  StringBuilder js = new StringBuilder("<script language=\"javascript\">");
  js.Append("_window = window.open(\"ApkRapportPage.aspx\",'_new');");
  js.Append("_window.document.open(\"application/pdf\");");
  js.Append("_window.location.href = \"ApkRapportPage.aspx\";");  
  js.Append("_window.document.close();");
  js.Append("</script>");
  
  Response.Write(js.ToString());
  

• If you are getting a blank page when trying to view a PDF inline in the IE7 browser and you are using Acrobat version 6. Update your Acrobat version to resolve problem.

• Note that this problem is unrelated to HTTPS, the same problem (and the same fix) applies for HTTP.

  The fix works because the problem with IE is that it doesn't display PDF in a script-opened window if the PDF is loaded at once. (Unknown why, but this is the core of the problem, and the fix.)

  KeesDijk : No it is not. The specific sample in the question worked in HTTP and not in HTTPS. Maybe in some cases that with http you have a different problem that can be solved in the same way, but the original problem only occured with HTTPS.