[
https://issues.apache.org/jira/browse/WICKET-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13538327#comment-13538327
]
Sven Meier commented on WICKET-4934:
------------------------------------
I've tried out our current solution on different browsers.
The filename >Downlöad"here now.tmp< gives the following:
IE Downlöad_here+now.tmp
FF Downl%C3%B6ad%22here+now.tmp
Chrome Downlöad"here+now.tmp
Opera Downlöad%22here+now.tmp
Safari Downl%C3%B6ad%22here+now.tmp
I'd suggest we move the encoding logic to WebResponse in Wicket 7, writing the
UTF-8 encoded file name once with >filename=< and once with >filename*=UTF-8''<
(see attached patch). This gives:
IE Downlöad"here now.tmp
FF Downlöad"here now.tmp
Chrome Downlöad"here now.tmp
Opera Downlöad"here now.tmp
Safari Downl%C3%B6ad%22here%20now.tmp
Yes, Safari would still be broken, but I don't think Wicket should do browser
sniffing for a broken Safari.
> DownloadLink uses wrong encoding for spaces/non-ASCII characters
> ----------------------------------------------------------------
>
> Key: WICKET-4934
> URL: https://issues.apache.org/jira/browse/WICKET-4934
> Project: Wicket
> Issue Type: Bug
> Components: wicket
> Affects Versions: 6.4.0
> Environment: IE7/8, FF 17.0.1, Chrome 23
> Reporter: Matthias Piepkorn
> Priority: Minor
> Labels: download
> Attachments: DownloadLink.patch
>
>
> When downloading a file with spaces and non-ASCII characters in the filename
> using DownloadLink, all browsers I tested show a wrong filename in the file
> download dialog.
> For a file named Test 'ä'.txt, I got the following output from different
> browsers:
> IE: Test+'ä'.txt
> FF: Test+%27%C3%A4%27.txt
> Chrome: Test+%27ä%27.txt
> I have attached a patch that fixes the issue for me. The problem is that
> a) the used URL encoding is wrong. PATH encoding, not QUERY encoding is
> required
> b) only IE needs the filename to be encoded, other browsers seem to work with
> the original name
> See e.g.
> http://stackoverflow.com/questions/93551/how-to-encode-the-filename-parameter-of-content-disposition-header-in-http
> for a discussion of the underlying issue.
> Note: I do not believe the attached patch is the optimal fix for this issue.
> I would prefer removing the encoding handling from DownloadLink and putting
> it into AbstractResource.setResponseHeaders(), so other components using
> attachments benefit, too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
