启用Gzip压缩与分块传输的HttpClient断连时返回不完整响应

核心原因 #

启用AutomaticDecompression后，HttpClient的处理逻辑发生了变化：

• 未启用自动解压时，客户端直接遵循分块传输规则读取数据，连接中断时底层网络层会立刻检测到异常，抛出HttpRequestException。
• 启用自动解压后，Gzip解压流会先缓存接收到的压缩数据，尝试执行解压操作。此时连接中断的话，解压流只会认为数据尚未接收完成，不会立刻触发异常——直到你尝试读取完整的解压内容（比如反序列化JSON），才会发现数据不完整。

这是因为Gzip格式依赖自身的结束标记（CRC校验和、长度标识），而HTTP分块的零长度块是HTTP层面的结束信号，解压处理器不会主动关联这两个层面的标记，它只关注Gzip流自身的完整性。当连接中断时，客户端已经收到HTTP 200响应头，HttpClient会判定请求“成功”，但实际压缩数据不完整，解压后的内容自然也不完整。

解决办法 #

1. 主动读取完整响应内容 #

获取响应后，不要直接返回，先强制读取完整内容，此时数据不完整会立刻抛出异常：

var response = await httpClient.GetAsync(url, cancellationToken);
if (response.IsSuccessStatusCode)
{
    // 强制读取完整内容，连接中断时会在此抛出异常
    var content = await response.Content.ReadAsStringAsync(cancellationToken);
    // 也可在此提前验证JSON格式（比如尝试反序列化）
    return response;
}

2. 调整API返回Content-Length（可选） #

如果场景允许，可以在API端禁用分块传输，返回Content-Length头，让客户端校验数据长度：

// 全局配置Kestrel禁用分块传输
services.Configure<KestrelServerOptions>(options =>
{
    options.Limits.MaxResponseBufferSize = int.MaxValue;
});

// 或者在接口中手动生成带Content-Length的响应
public async Task<ActionResult> Get(int category)
{
    var entries = await _service.getEntries(category);
    var jsonBytes = Encoding.UTF8.GetBytes(JsonSerializer.Serialize(entries));
    return File(jsonBytes, MediaTypeNames.Application.Json);
}

这种情况下，客户端会根据Content-Length校验接收的数据，长度不匹配时立刻抛出异常。

3. 自定义解压处理器（进阶） #

如果需要更精细的控制，可以自定义HttpContent来处理解压，同时校验HTTP分块的完整性。不过这种方式复杂度较高，适合对性能和异常处理有严格要求的场景。

补充说明 #

未启用自动解压时，HttpClient直接处理HTTP分块，连接中断时无法接收到分块的结束标记（零长度块），底层网络层会立刻检测到连接断开并抛出异常。而启用自动解压后，解压流的缓冲机制掩盖了底层的连接异常，直到读取完整解压内容时才暴露问题。

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