Serving PDF using IE

Question

NOTE: This is not a question but rather a thread for solutions to this problem. I hope that someone who is having this same problem in the future can find this information useful. If you have a solution you would like to share then post it here.
I have been having the same problem that many have been having with generating PDF files and returning to IE client. I have read through the many suggestions on how to do this using Java here in these forums and on the web and never really found a direct solution to my problem.
The basic advice that I have seen pretty much everywhere holds true. You must set the content type and the content length without exception. Some say you need to set the content disposition but I have not seen the need for this--it may only apply in special situations I have not yet encountered.
The problem I had was trying to serve PDFs using a struts based framework. This required my URL to look something like (http://localhost/app/report/view.do?jobId=1234567890), where /report/view mapped to an action and jobId was the report job identifier. Using the classic code below in a Struts Action fails miserably to view or save the generated PDF with an error indicating IE failed to communicate with the server.
// load pdfbytes here
response.setContentType("application/pdf");
response.setContentLength(pdfbytes.length);
ServletOutputStream ouputStream = response.getOutputStream();
ouputStream.write(pdfbytes, 0, pdfbytes.length);
ouputStream.flush();
ouputStream.close();I tried many variations with the response such as changing the buffer size, setting content disposition, changing Acrobat preferences among others and nothing worked.
During my search on the web I found an article that indicated IE violates HTTP in that it defines it's own way for determining the content of a URL rather than using the response header. I believe Microsoft's web site says this is by design and not a flaw. The article also indicated that the workaround was to use Microsoft extensions. (I cannot find the article again, if I could I would post a link to it).
With this new information in hand I decided to create a test servlet that would serve an existing PDF from the local file system. The following are snippets from web.xml and the PdfReportViewServlet:
<servlet>
   <servlet-name>pdf</servlet-name>
   <display-name>PDF Report View Servlet</display-name>
   <description>Used to serve PDF reports to client once they are completed running.</description>
   <servlet-class>report.PdfReportViewServlet</servlet-class>
</servlet>
<servlet-mapping>
   <servlet-name>pdf</servlet-name>
   <url-pattern>*.pdf</url-pattern>
</servlet-mapping>     
public class PdfReportViewServlet extends HttpServlet {
   public void service(HttpServletRequest request, HttpServletResponse response)
   throws IOException, ServletException {
      // Read in PDF test file
      File l_file = new File("c:/temp/test.pdf");
      FileInputStream in = new FileInputStream(l_file);
      int length = in.available();
      byte[] pdfbytes = new byte[length];
      in.read(pdfbytes);
      in.close();
      // Send response
      response.setContentType("application/pdf");
      response.setContentLength(pdfbytes.length);
      ServletOutputStream ouputStream = response.getOutputStream();
      ouputStream.write(pdfbytes, 0, pdfbytes.length);
      ouputStream.flush();
      ouputStream.close();
}Basically anything ending in "pdf" will be handled by the servlet. After deploying this code to Tomcat and typing in a test URL like (http://localhost/APP/test.pdf) it works!
I then decided to see what would happen if I changed the PDF extension from "pdf" to something else to determine if IE was using the "pdf" extension in the URI or using the content type to determine the true content (At least to prove it in my mind). I changed the following in web.xml:
<servlet-mapping>
   <servlet-name>pdf</servlet-name>
   <url-pattern>*.rpt</url-pattern>
</servlet-mapping>     Now the servlet will handle anything ending in "rpt" but will still return PDF content. The result was a bunch of gibberish that was the PDF file converted into text and displayed in IE. IE must be using the file extension in the URI to identify the content type.
Just for fun I decided to try not setting the content length to see what would happen. I reverted the web.xml file back to map to "*.pdf" and commented out the line to set content length:
      // Send response
      response.setContentType("application/pdf");
      // response.setContentLength(pdfbytes.length);
      ServletOutputStream ouputStream = response.getOutputStream();
      ouputStream.write(pdfbytes, 0, pdfbytes.length);
      ouputStream.flush();
      ouputStream.close();The darn thing worked! So I guess IE doesn't care about content length.
Hmmmm, do I even need to set the content type? I commented out the line to set content type and.....
it worked!
So my new servlet code looks like this and works fine:
      // Send response
      ServletOutputStream ouputStream = response.getOutputStream();
      ouputStream.write(pdfbytes, 0, pdfbytes.length);
      ouputStream.flush();
      ouputStream.close();Of course in my production code I will be setting content type and length because other browsers that correctly implement HTTP will require it unlike IE, at least I think they require it until future testing proves otherwise.
In conclusion, it seems that IE uses the URI to determine the content type rather than using the response header. So if you want IE to correctly recognize the content type of any target you better use the approriate extension in the URI rather than depend on the response header content type.
BTW: I was using Tomcat 5.0.14, IE 6 SP1, Win2k Pro SP4, and Acrobat 6. I have not tested this using different configurations. When I have the time I will try and perform more extensive testing.

Answer 1

That's great. Now try doing a POST to your URL and see if IE still likes it. Or use HTTPS. Or both POST and HTTPS. Or use GET with a really long URL and watch IE crash (This one is probably a buffer overrun). Then try those various combinations on different versions of IE with all the various patches, etc. I've given up and I just tell people to download Firefox.