Spring框架中HTTP头处理不当导致的请求阻塞问题分析

问题背景

在Spring框架应用中，开发人员经常会遇到需要在一个HTTP请求处理中发起另一个HTTP请求的场景。最近在Spring Boot 3.2.x版本中，一些开发者报告了一个奇怪的现象：当使用WebTestClient进行测试时，如果控制器内部使用RestTemplate发起请求，并且复用了传入的HTTP头信息，会导致请求阻塞或超时。

问题现象

具体表现为：

1. 控制器接收请求后，使用RestTemplate向另一个服务发起请求
2. 如果复用了传入请求的HTTP头信息，请求会阻塞并最终超时
3. 同样的代码在Spring Boot 3.1.x版本中工作正常
4. 问题在使用WebTestClient时出现，而使用TestRestTemplate时则正常

根本原因分析

经过深入排查，发现问题根源在于HTTP头信息的处理不当，特别是Content-Length头的处理：

1. HTTP头污染：控制器错误地复用了传入请求的所有HTTP头信息，包括Content-Length
2. 内容长度不匹配：复用的Content-Length值对应的是原始请求体的长度，而RestTemplate发送的是不同的请求体
3. 框架行为变化：Spring Framework 6.1+为了减少内存使用，默认不再缓冲请求体，导致Content-Length处理方式变化

技术细节

在Spring Framework 6.1版本中，为了提高性能，ClientHttpRequestFactory的实现不再缓冲请求体。这带来了两个重要影响：

1. 对于JSON等内容类型，框架无法预先知道内容大小，因此不再自动设置Content-Length头
2. 如果手动设置了错误的Content-Length值，会导致服务器等待更多数据，最终超时

解决方案

正确的做法是：

1. 不要盲目复用HTTP头：特别是安全相关头和内容相关头（Content-Length, Transfer-Encoding等）
2. 显式创建需要的头：只传递必要的头信息
3. 必要时使用缓冲：如果需要旧版行为，可以包装ClientHttpRequestFactory

修正后的控制器代码示例：

@PostMapping
public ResponseEntity<?> handleRequest(@RequestBody RequestDemo request, 
                                      @RequestHeader HttpHeaders headers) {
    RequestDemo newRequest = new RequestDemo();
    HttpHeaders newHeaders = new HttpHeaders();
    newHeaders.setContentType(MediaType.APPLICATION_JSON);
    // 只复制需要的头
    if (headers.containsKey("X-Custom-Header")) {
        newHeaders.add("X-Custom-Header", headers.getFirst("X-Custom-Header"));
    }
    
    HttpEntity<RequestDemo> entity = new HttpEntity<>(newRequest, newHeaders);
    restTemplate.postForObject("http://service", entity, ResponseDemo.class);
    return ResponseEntity.ok().build();
}

最佳实践建议

1. HTTP头处理原则：

   • 永远不要盲目复制所有传入头
   • 明确知道每个头的用途后再决定是否传递
   • 特别注意内容相关头和安全相关头

2. 测试策略：

   • 同时使用WebTestClient和TestRestTemplate进行测试
   • 对头信息处理进行专门测试
   • 考虑升级到RestClient（Spring 6.1+推荐）

3. 版本升级注意事项：

   • 注意框架行为变化，特别是性能优化带来的副作用
   • 完整阅读版本升级指南
   • 对HTTP客户端相关代码进行重点测试

总结

这个问题很好地展示了HTTP协议细节的重要性以及框架行为变化可能带来的影响。作为开发者，我们需要：

1. 深入理解HTTP协议，特别是头信息的语义
2. 谨慎处理头信息的传递和复用
3. 关注框架升级带来的行为变化
4. 建立完善的测试策略，覆盖不同客户端场景

通过遵循这些原则，可以避免类似的隐蔽问题，构建更加健壮的应用程序。