One of the developers ran into a problem with a servlet he was working on recently. In his app, he was displaying a link that would cause the app to deliver a text file that the user would be prompted to save.
All was well and good with Firefox with the following code:
private final static String MIME_TYPE = "text/plain"; ByteArrayOutputStream myDataOutputStream = (ByteArrayOutputStream)writeResultsToStream(myData); response.setContentType(MIME_TYPE); String filename = "downloadfile.txt"; response.addHeader("Content-disposition","attachment; filename=" + filename); response.setContentLength(myDataOutputStream.size()); response.getOutputStream().write(myDataOutputStream.toByteArray()); response.getOutputStream().flush();
Because the data may contain confidential information, options like saving it out as a flat file were precluded. All well and good except that our in-house users who would be accessing the servlet primarily use Internet Explorer 6.
One of the other developers suggested the following change that fixed the issue when the servlet was running on Tomcat (which we use for our desktop development):
response.addHeader("Content-disposition","attachment; filename=" + filename); to
response.addHeader("Content-disposition","attachment;filename=" + filename);
Unfortunately, the problem reoccurred when the application was deployed on our Dev server running ATG Dynamo.
We determined that part of the problem also lay in some of the headers likely being passed from ATG, where this note was helpful:
“The MIME types “text/plain” and “application/octet-stream” are termed ambiguous because they generally do not provide clear indications of which application or CLSID should be associated as the content handler.”
http://msdn.microsoft.com/en-us/library/ms775147.aspx
Which I read to mean that it attempts to derive the file name from the URL, even though we’ve passed a name in the header.
Also, ‘The main problem is that Internet Explorer strictly interprets a combination of SSL (https) and “cache-control: no-cache” as “do not save encrypted pages to disk.”’
http://www.alagad.com/go/blog-entry/error-internet-explorer-cannot-download-filename-from-webserver
My suggestion (per my research) was to make the following additional changes to the header:
response.addHeader("Pragma", "public"); response.addHeader("Cache-Control", "max-age=0");
I haven’t dug into the respective application server headers and settings, but I’m definitely hoping to get the chance to compare the server configurations and the headers the browser receives.
