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

[spring-projects-issues]

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:

• Switch source encoding to UTF-8 and enforce it in the build [SPR-11569] #16193 Switch source encoding to UTF-8 and enforce it in the build
• FormHttpMessageConverter doesn't support utf-8 filename [SPR-16061] #20610 FormHttpMessageConverter doesn't support utf-8 filename
• Allow configuring the message converter in HttpPutFormContentFilter [SPR-14503] #19072 Allow configuring the message converter in HttpPutFormContentFilter
• StandardMultipartHttpServletRequest cannot decode multipart Content-Disposition header encoded by FormHttpMessageConverter [SPR-15205] #19769 StandardMultipartHttpServletRequest cannot decode multipart Content-Disposition header encoded by FormHttpMessageConverter

[spring-projects-issues]

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]

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.