Non-compliant Content-Type header for multipart media types

[rcgardne]

Affects: 5.x

The org.springframework.http.codec.multipart package contains various methods for building a Content-Type header for multipart media types. The default method produces a header with the following format:

"multipart/{sub-type};boundary={boundary};charset={charset|UTF-8}"

However, RFC7578 specifies only a required parameter of boundary and optional parameters as none. Hence, the addition of a charset parameter is not strictly in accordance with RCF7578. Robust server implementations should ignore this parameter, but some do not (in my case, civetweb), causing request failures. Here are the relevant framework versions and code locations causing the problems:

• master:

  spring-framework/spring-web/src/main/java/org/springframework/http/codec/multipart/MultipartWriterSupport.java

  Line 105 in 24bd014

  params.put("charset", getCharset().name());

• 5.x.x:

  spring-framework/spring-web/src/main/java/org/springframework/http/codec/multipart/MultipartHttpMessageWriter.java

  Line 234 in ec9de94

  params.put("charset", getCharset().name());

• < 5.x implementations work differently, I haven't taken time to verify.

I'd like to hear concerns - is removing charset for multipart requests appropriate?

[rstoyanchev]

From previous investigations on charsets and multipart requests, there is a lot of history, multiple specs and and behaviors.

In that context one possible concern is whether existing applications rely on this behavior (right or wrong). For example whether a request prepared with the MultipartHttpMessageWriter that customizes the charset to use, say for multipart headers, would be successfully interpreted by a server side app using Standard Servlet multiple parsing (e.g. Tomcat and Jetty) or Apache Commons FileUpload.

[poutsma]

Solved by only adding the charset parameter if it is non-standard (i.e. not UTF-8 or ASCII).