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: https://github.com/spring-projects/spring-framework/blob/24bd0148d5e569d8f995c422496ef325e6aa8379/spring-web/src/main/java/org/springframework/http/codec/multipart/MultipartWriterSupport.java#L105
- 5.x.x: https://github.com/spring-projects/spring-framework/blob/ec9de943eef738caf9d2a7a8a591aed170b5899d/spring-web/src/main/java/org/springframework/http/codec/multipart/MultipartHttpMessageWriter.java#L234
- < 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?
Comment From: 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.
Comment From: poutsma
Solved by only adding the charset parameter if it is non-standard (i.e. not UTF-8 or ASCII).