Spring Boot 3.2.0升级后PUT请求Gzip压缩Payload被截断求助

• 检查版本配置变更

  • 对比Spring Boot 3.1.9与3.2.0的server.compression系列配置，确认enabled、mime-types、min-response-size等参数的默认值是否变更，是否遗漏PUT请求对应的媒体类型配置。
  • 查阅Spring Boot 3.2.0官方发行日志，聚焦HTTP压缩、Web服务器集成相关的更新，排查是否有Gzip处理逻辑的改动。

• 追踪请求数据流转

  • 在代码中添加日志，打印PUT请求的Content-Length、Content-Encoding头信息，以及解压前后的字节数，验证请求头声明与实际数据是否匹配。
  • 通过自定义Filter或Interceptor拦截请求，将原始输入流完整写入临时文件，对比压缩文件实际大小与Content-Length，排查传输过程中是否存在数据丢失。

• 验证Tomcat压缩配置

  • 即便换回Tomcat 10.1.19，仍需检查Spring Boot 3.2.0的自动配置是否覆盖了Tomcat原生设置。可通过自定义TomcatServletWebServerFactory显式配置压缩参数：

    @Bean
    public TomcatServletWebServerFactory tomcatServletWebServerFactory() {
        TomcatServletWebServerFactory factory = new TomcatServletWebServerFactory();
        factory.addConnectorCustomizers(connector -> {
            Http11NioProtocol protocol = (Http11NioProtocol) connector.getProtocolHandler();
            protocol.setCompression("on");
            protocol.setCompressibleMimeTypes("application/json,application/xml");
            protocol.setCompressionMinSize(2048);
        });
        return factory;
    }
    

  • 检查Tomcat的server.xml是否存在手动压缩配置，确认与Spring Boot自动配置无冲突。

• 排查消息转换器变动

  • Spring Boot 3.2.0升级了Jackson版本，检查MappingJackson2HttpMessageConverter等消息转换器在处理解压后数据时是否存在截断。可自定义转换器并添加日志，打印读取的字节数验证转换完整性。
  • 临时禁用默认消息转换器，改用简单自定义转换器处理请求体，排查是否为转换器逻辑导致问题。

• 多场景测试验证

  • 使用不同大小的Gzip压缩数据发起PUT请求，确认问题是否仅出现在特定数据规模下，缩小排查范围。
  • 切换至Jetty或Undertow等其他Web服务器，测试是否仍存在相同问题，判断问题是Spring Boot通用问题还是Tomcat特有问题。

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