The subject of serving PDF documents comes up rather frequently on the Struts mailing lists. This seems like an obvious candidate for a Wiki entry!
It should be noted right up front that serving PDFs, and the issues that frequently come up, are in no way specific to Struts (although there may indeed be some Struts-specific issues). This is a general requirement which can be troublesome whether using Struts or not, so feel free to reference this entry outside the Struts world as well.
First up, let's see an example of serving a PDF from a Struts Action:
public ActionForward execute(ActionMapping mapping, ActionForm inForm, HttpServletRequest request, HttpServletResponse response) throws Exception { // somePDFGenerator is some class that returns a ByteArrayOutputStream // representation of a PDF. Could be iText, could be DataVision, could be your own // custom class, whatever. ByteArrayOutputStream pdfStream = somePDFGenerator.generatePDF(); response.setContentType("application/pdf"); response.setHeader("Content-Disposition", "inline; filename=myPDF.pdf"); response.setContentLength(pdfStream.size()); ServletOutputStream sos = response.getOutputStream(); pdfStream.writeTo(sos); sos.flush(); sos.close(); pdfStream.close(); pdfStream = null; return null; }
This is clearly not meant to be robust, production-quality code, but it should get the basic point across. It should be noted that the StrutsFileDownload Wiki entry shows how to do this using the DownloadAction introduced with Struts 1.2.6. In general, I suggest using the DownloadAction whenever you need to serve content like this if you want to do it directly from with a Struts apps.
So, what issues can arise? Here are just a few (all of which seem to be bug{{^H^H^H}} features of various versions of InternetExplorer), and please do feel free to add from your own experience:
- IE will not react well if you do not specify the contentLength properly, so always be sure to do so.
- If you use the nocache setting on the Struts request processor, you may get an error saying the file could not be retrieved, or text to that effect. This may only happen in IE and may only happen under SSL. Removing this setting fixes the problem. If you want to control caching without experiencing this problem, a filter like the Cache Control Filter in Java Web Parts (http://javawebparts.sourceforge.net) will allow you to do so.
- In some cases, the contentType "
application/pdf
" will not work properly. Try using "application/x-octet-stream
" instead. - If you want the client to save the file rather than try and open it, change the Content-Disposition header to "
attachment;filename=myPDF.pdf
". In this case especially you may have to use the alternate contentType mentioned above for IE clients. - In some cases, despite the content-type header, IE will refuse to believe that a file is actually a PDF, and will not call AcroRead, but display the raw content in the browser. The only workarounds I know for this are
- to create the PDF with a different generator and hope for the best, or
- to save the file to disk and then open it outside of the browser.
- to create the PDF with a different generator and hope for the best, or