JasperReports failure to download PDF in Internet Explorer

What is supposed to happen: We have a PDF document being generated using JasperReports in a struts-based Java application. The PDF writes to the screen, where the user is prompted to open or save this generated PDF file. Usually, the user clicks "open" and views the file.

What is happening: When Internet Explorer goes to display the Open/Save/Cancel dialogue box, it instead displays a warning message: "Internet Explorer cannot download document.pdf from server"

Notes:

• This is not the only place in the application where a PDF is generated in Jasper and written to an output stream. The other PDFs are working, although each has subtle differences here and there as to how they are generated. Nothing that is different is causing the problem.
• This application was recently converted to SSL, and the issue appears the be happening only on the SSL version for MOST but not ALL affected users.
• Not all users are affected, some can access without problems. In addition, some users (including myself) get the error in one environment and not another, with the same codebase.

Investigation:

I read up on a few sites:

1. Microsoft lists this as a bug in IE and offers several suggestions. My Do not save encrypted pages to disk check box is not checked.
2. This big thread offers more suggestions about response headers. I have tried each of these.
3. Another thread. More of the same.
   

I've tried changing the headers. Original code:


response.setHeader("Content-Disposition", "attachment; filename=Preview.pdf");
response.addHeader("Content-Description", "Download");
response.setContentType("application/pdf");


New code:


response.setHeader("Content-Length", String.valueOf(file.length));
response.setHeader("Content-Disposition", "attachment; filename=Preview.pdf");
response.addHeader("Content-Description", "Download");
response.setContentType("application/pdf");
response.setHeader("Pragma", "public");
response.setHeader("Cache-control", "must-revalidate");


No luck. I've tried loading the headers in various orders, and I've tried various header values, including blank for pragma and cache-control, and other values. No luck.

So, I'm still working.

Resolution, May 22, 2008:
The problem is fixed and has nothing to do with anything mentioned here. There was a silly block of formerly unreachable code that was now reachable, either due to a novice programmer making changes or the Websphere upgrade from 6.0 to 6.1. This code, I kid you not, removed the attachment and reset the HTTP status to 404. I never saw this code yesterday when I was working on this, but I do feel kind of stupid now.