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.

Windows Environment Variables: Solved

Some of you may recall this issue that I was having with Windows Environment Variables not resolving properly on my servers. Today, on the verge of launching a shiny new production server (supposed to happen this weekend, more likely next weekend), I have resolved the issue.

The solution comes from here, but requires more explanation.

If you are experiencing this problem, you are apparently setting your environment variables by right clicking on My Computer, selecting Properties & going to the advanced tab. Not correct. You need to right click on my computer and select MANAGE, go to advanced, and set the environment variables there. I tried this months ago, but apparently if you're already experiencing the issue, just resetting the environment variables there won't work. You need to delete them and recreate them in the Manage screen, including your Path variable.

Thank goodness, that one was a real bother.