什么时候需要将HttpMultipartMode设置为STRICT模式？

两种模式的核心行为差异 #

HttpMultipartMode是Apache HttpComponents定义的multipart请求格式实现规范，两种常用模式的核心行为区别如下：

• BROWSER_COMPATIBLE模式（默认值）
  该模式为兼容早期老旧浏览器的非标准multipart实现设计，核心特征：
  • 每个part的Content-Disposition请求头中name属性值会自动补充双引号包裹
  • 二进制类型part会默认添加非标准的Content-Transfer-Encoding: binary头
  • 不会为纯文本类型part自动添加Content-Type头
  • 行分隔符固定使用CR+LF，完全对齐老版本浏览器的实现逻辑
• STRICT模式
  严格遵循RFC 6532、RFC 2045等multipart相关国际标准实现，核心特征：
  • 所有请求头的格式、编码完全符合标准规范，不会添加任何非标准属性
  • 会根据part的内容类型自动补充符合规范的Content-Type头
  • 不会额外添加Content-Transfer-Encoding这类非标准头
  • 属性值的引号、转义处理完全对齐标准要求

模式切换解决415 Unsupported Media Type的原因 #

415错误的核心触发逻辑是服务端无法识别请求携带的媒体类型，两种模式的差异刚好匹配了服务端的校验规则：

目前绝大多数现代服务端框架（比如Spring Web、Go net/http、Node.js multer最新版等）的multipart解析器默认遵循RFC标准实现，对非标准格式的multipart请求会直接判定为非法，返回415错误。
你遇到的场景大概率是BROWSER_COMPATIBLE模式添加的非标准Content-Transfer-Encoding头，或者文本part缺失Content-Type头，导致服务端解析失败。切换到STRICT模式后请求格式完全符合标准，服务端就可以正常解析处理。

选型建议 #

• 对接遵循标准实现的服务端时，优先使用STRICT模式，避免非标准属性导致的兼容性问题
• 只有对接老旧的、基于早期浏览器逻辑开发的服务端时，才需要使用BROWSER_COMPATIBLE模式
• 如果有传输中文/特殊字符文件名的需求，可以使用RFC6532模式，该模式对国际化字符的支持更完善

内容的提问来源于stack exchange，提问作者prachi