Jetty服务器处理HTTP/1.1分块请求时的连接关闭问题分析

在Jetty 12服务器升级过程中，开发人员发现了一个与HTTP/1.1分块传输编码请求处理相关的重要行为变化。当服务器在未完全接收客户端分块请求体的情况下提前发送响应时，会导致连接被异常关闭，影响后续请求的正常处理。

问题现象

在Jetty 12环境中，当服务器处理HTTP/1.1分块传输编码的POST请求时，如果应用程序在未完全读取请求体内容的情况下就发送响应，Jetty服务器会在响应后立即关闭连接。这种行为会导致客户端后续复用该连接的请求失败，出现"NoHttpResponseException"等异常。

通过抓包分析可以观察到，服务器在收到部分分块数据后就发送了响应，而没有等待完整的请求体传输完成。这与Jetty 10的行为有所不同——在旧版本中，服务器会通过发送"Connection: Close"头显式通知客户端关闭连接，而新版本则直接关闭连接。

技术背景

HTTP/1.1协议规范要求持久连接必须完整处理每个请求和响应。对于分块传输编码的请求，服务器必须读取到表示结束的"0\r\n\r\n"标记才能认为请求处理完成。如果服务器在未读取完请求体的情况下就发送响应，实际上违反了协议规范。

Jetty 12相比早期版本的一个重要变化是移除了Servlet规范相关的特殊处理逻辑。在旧版本中，Jetty会尝试自动"消费"未读取的请求内容（在一定限制内），以符合Servlet规范的要求。但这种行为存在安全风险——恶意客户端可能发送超大请求体来消耗服务器资源。

解决方案

对于开发者而言，正确处理这种情况有以下几种方式：

1. 完整读取请求体：在处理程序中有意识地读取并消费整个请求体内容，这是最规范的解决方案。可以使用IOUtils.consume()等方法确保请求体被完整读取。

2. 使用HTTP/2协议：HTTP/2协议设计上支持请求和响应的多路复用，不会因为单个请求体未完全读取而影响其他请求。

3. 调整客户端行为：客户端可以检测连接异常并重建连接，但这属于被动解决方案。

需要特别注意的是，开发者不应简单地通过添加"Connection: close"头来解决问题，这会显著影响性能，违背HTTP/1.1持久连接的设计初衷。

实现细节

Jetty 12内部实现了称为"consumeAvailable"的机制，会尝试异步读取网络缓冲区中可用的请求内容。如果终止块(terminal chunk)已经在网络缓冲区中，Jetty会读取它并保持连接开放。然而，如果终止块尚未到达，Jetty不会无限期等待，而是会关闭连接。

这种设计权衡了协议规范遵守和资源保护的需求。开发者应当理解，从协议角度来看，当请求内容未完成时，服务器除了关闭连接外别无选择。

最佳实践

对于高性能HTTP服务开发，建议：

1. 明确处理请求体：无论是否需要请求体内容，都应确保其被完整读取
2. 考虑升级到HTTP/2：特别是对于需要高性能和连接复用的场景
3. 合理设置超时：配置适当的读取超时，平衡资源保护和用户体验
4. 错误处理：客户端应妥善处理连接异常，具备重试机制

通过理解这些底层机制，开发者可以构建更健壮的网络应用，充分利用现代Web服务器的能力。