JDK11 的 HttpClient 在处理分块传输（chunked）或 Content-Length 不匹配的响应时会提前截断响应体；根本原因是服务端 Netty 编码器重写响应内容后未同步更新 Content-Length 头，导致客户端按错误长度解析。
jdk11 httpclient 无法读取完整响应体的根源在于服务端 netty 编码器重写响应内容后未同步更新 content-length 头，导致客户端按错误长度解析，从而截断长 hex 字符串响应。
在使用 JDK11 新增的 java.net.http.HttpClient 时，其 BodyHandlers.ofString() 默认依赖 HTTP 响应头中的 Content-Length 或 Transfer-Encoding: chunked 协议语义来确定响应体边界。当服务端（如基于 Netty 实现）对原始响应体加密并转换为 hex 字符串后，若未正确更新 Content-Length 头，而仅修改了响应体字节内容，就会引发严重不一致：
- 加密后 hex 字符串长度 ≈ 原始字节数 × 2（十六进制编码膨胀）；
- 若服务端仍保留原始 Content-Length（例如 1024），但实际发送了 2048 字节，HttpClient 将只读取前 1024 字节并静默截断；
- 而 OkHttp 等成熟客户端具备更强的容错能力（如自动缓冲、忽略错误 Content-Length、兼容分块流式读取），因此表现正常。
问题代码中 HttpResponseEncipher.encode() 方法调用了 msg.replace(encryptContent(buf)) 替换响应体，但遗漏了关键步骤：重设 Content-Length 和 Content-Type。修复方式非常明确——在替换响应体后，必须显式更新头部：
protected void encode(ChannelHandlerContext ctx, Netty4HttpResponse msg, List<Object> out) {
ByteBuf buf = msg.content();
ByteBuf encryptBuf = encryptContent(buf); // 返回 UTF-8 编码的 hex 字符串 ByteBuf
FullHttpResponse rep = msg.replace(encryptBuf);
// ✅ 关键修复：同步更新 Content-Length（单位：字节）
rep.headers().setInt("content-length", encryptBuf.readableBytes());
// ✅ 推荐：显式声明 content-type，避免 charset 推断歧义
rep.headers().set("Content-Type", "text/plain; charset=utf-8");
if (isSpiltResponse || encryptBuf.readableBytes() <= splitThreshold) {
out.add(rep);
} else {
// 分块逻辑需确保每块 Header 正确，且 LastHttpContent 终止流
out.add(createPart(rep));
while (encryptBuf.readableBytes() > splitThreshold) {
out.add(new DefaultHttpContent(encryptBuf.readRetainedSlice(splitThreshold)));
}
out.add(new DefaultLastHttpContent(encryptBuf.readRetainedSlice(encryptBuf.readableBytes())));
}
}⚠️ 注意事项：
- setInt("content-length", ...) 比 set("content-length", String.valueOf(...)) 更安全，避免空格/格式错误；
- 若启用 Transfer-Encoding: chunked，则不应设置 Content-Length，此时需确保 DefaultHttpContent / DefaultLastHttpContent 流式结构完整且无 header 冲突；
- JDK11 HttpClient 对非标准响应（如缺失/错误 Content-Length + 非 chunked）行为严格，不建议依赖“侥幸解析”，务必保证服务端协议合规；
- 可通过 Wireshark 或 curl -v 验证响应头是否准确，例如检查 Content-Length: 3276 是否与 hex 字符串实际字节数一致。
总结：这不是 JDK HttpClient 的缺陷，而是服务端 HTTP 协议实现不严谨所致。遵循 RFC 7230，任何修改响应体的操作都必须同步修正 Content-Length 或切换至 chunked 编码。修复后，HttpClient 将完整接收整个加密 hex 字符串，与 OkHttp 表现完全一致。
