Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HttpHeaders.setContentDispositionFormData() doesn't encode non-acsii characters correctly [SPR-14547] #19115

Closed
spring-projects-issues opened this issue Jul 30, 2016 · 2 comments
Assignees
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Jul 30, 2016

Wenhao Ji opened SPR-14547 and commented

When passing name or filename containing non-ascii characters to the setContentDispositionFormData method, a browser like Chrome and IE may behave strangely, opening a download dialog where those characters are replaced by hyphens.

The parameters in http headers should be encoded according to [RFC5987] https://tools.ietf.org/html/rfc5987, so that we can get the correct string no matter what kind of characters are passed into.

For example,

@RequestMapping("downloadForm")
public HttpEntity<String> downloadFormData() throws UnsupportedEncodingException {
    HttpHeaders headers = new HttpHeaders();
    headers.setContentDispositionFormData("form", "中文.txt");
    return new HttpEntity<String>("a=b", headers);
}

The Content-Disposition header values that returns from the controller method above should be like filename=UTF-8'zh-Hant-CN'%E4%B8%AD%E6%96%87.txt.


Affects: 4.3.2

Issue Links:

  • #16193 Switch source encoding to UTF-8 and enforce it in the build
  • #20610 FormHttpMessageConverter doesn't support utf-8 filename
  • #19072 Allow configuring the message converter in HttpPutFormContentFilter
  • #19769 StandardMultipartHttpServletRequest cannot decode multipart Content-Disposition header encoded by FormHttpMessageConverter
@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 25, 2016

Brian Clozel commented

This is now fixed and backported.
This will be shortly available in the 5.0 and 4.3 SNAPSHOTS if you'd like to try it.

Note that I didn't change the default implementation of setContentDispositionFormData(String name, String filename), as the latest RFC7230 states that:

In practice, most HTTP header
field values use only a subset of the US-ASCII charset US-ASCII.
Newly defined header fields SHOULD limit their field values to
US-ASCII octets. A recipient SHOULD treat other octets in field
content (obs-text) as opaque data.

You can now use the dedicated method setContentDispositionFormData(String name, String filename, Charset charset), which requires the charset for the given field header.

Let me know if you have any feedback about this.

Thanks for the report!

@spring-projects-issues
Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Aug 26, 2016

Juergen Hoeller commented

The tests for this require consistent UTF-8 encoding in the test sources as well, following up on #16193 which switched enforced UTF-8 for the main sources.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants