This is likely old news for many people, but I hadn't come across the HTTP
Content-Disposition response header until recently, so here's my notes about it. The idea is to get the browser to ask the user to save a dynamically generated document they've downloaded, with a useful default filename for the downloaded file.
For anythat generates a response document you want the user to be asked to save, near the top, stick something like the following line:
<% response.setHeader("Content-Disposition", "attachment; filename=\"my useful filename.csv\""); %>
The vital part is the "attachment" bit - this tells the browser that it should ask the user what to do with the response, rather than taking a guess. The "filename" bit gives the browser a default filename it should suggest to the user.
This HTTP response header is honoured by "recent versions of all the major browsers" - i.e. older IE browser probably get confused by it.
This approach can be used to give sensible filenames to any dynamically generated content we want the user to save. Including PDFs, XLS, CSV, and anything else we don't want the browser to try to display.
The situation to think about is that you've got a web service/app that generates something other than a web page for the user. Maybe it's a PDF, Excel spreadsheet, CSV file, custom zip package, etc.
You want that dynamically generated HTTP response to include some hints for the browser telling it what type of content it's getting and a suggested sensible filename for the returned document.
The mimetype response header is well known, it tells the browser what the response looks like and if the browser is well behaved it'll look up what to do for each mimetype it knows about. Here I'm interested in the cases where we need the browser to decide the response needs saving as a file.
The problem I was having was that when setting the mimetype to something like "text/csv", some browsers would see that as a text document and automatically display it. I want the browser to instead offer to save the CSV document.
This led me to which describes the Content-Disposition HTTP response header. The main aim of the header is to tell the browser (and mail agents) whether the following chunk should be displayed or should trigger asking the user what to do with it.
If the header is set to "attachment" there is an option second parameter "filename" which gives the browser/mail agent a default name for the attached content. This filename should be just the last part of the name, with no path provided (and the browser/agent must ignore any path elements).
This lets us not only persuade the browser that it should ask the user whether they want to open or save the file, but also provide a sensible default name for the file if they do save it. Hence getting round the annoying issue of downloads getting the default name set to whatever the last part of the URL is.
In general, the format of the header should be something like:
Content-Disposition: attachment; filename="sensible-filename"
This isn't a replacement for the mimetype - you should set that header as well.
If you're generating the response from a JSP then this needs to be provided via a
response.setHeader() fragment at the top of your JSP (before any content has been generated). Note that the filename is in double quotes, so you'll need to escape them when creating this header via JSP.