Improve filename handling in p:fileDownload and p:dataExporter

[cagataycivici]

p:fileDownload and p:dataExporter set the Content-Disposition header and include the filename option, but filename only works for ASCII text. If you specify a filename that has non-ASCII text (suppose you want the filename to be in Chinese), most browsers will not show the correct filename.

A partial workaround for this issue exists by URL-encoding the filename. In my tests, IE, Chrome, and Opera will decode a URL-encoded filename and offer the expected filename. Firefox, however, will not decode filename.

RFC6266 resolves this issue by introducing the filename* option, which can be used to send a filename with UTF-8 encoding. All the major browsers now support this option, and the original filename option can be sent at the same time for browsers that lack support. See http://greenbytes.de/tech/tc2231/, in particular attfnboth and attfnboth2.

So, for p:fileDownload, the Content-Disposition header should be set like this:

externalContext.setResponseHeader("Content-Disposition", contentDispositionValue + ";filename="" + content.getName() + "";filename*=UTF8''" + URLEncoder.encode(content.getName(), "UTF-8"));

p:dataExporter is similarly affected.

[VsevolodGolovanov]

IE8 would still fail (won't download, shows error dialog) if the fallback filename (without asterisk) contains non-ASCII characters. So it should be ASCIIfied somehow.
Update: actually it works in IE8, if you URLEncoder.encode the fallback filename too!

[hans-adler]

Related problem: p:dataExporter should probably add " left and right of the file name if not present. It appears that otherwise the server creates an HTTP header for the file name that does not conform to the standard if the file name contains a comma. Most browser accept this, but Chrome panics with ERR_RESPONSE_HEADERS_MULTIPLE_CONTENT_DISPOSITION.

A workaround is to write fileName="&#{myView.filename}"" rather than just fileName="#{myView.filename}" or to add the quotes in the view.

It appears that DefaultStreamedContent already does the same operation, so that p:fileDownload does not have this problem.

[tandraschko]

Duplicate of #1312