http 代理不应直接透传上游响应中的 content-encoding 头，尤其当代理自身对响应体执行了自动解压（如通过 resp.body 读取）时；否则会导致响应头与实际响应体编码状态不一致，破坏缓存语义与客户端解析逻辑。
http 代理不应直接透传上游响应中的 content-encoding 头，尤其当代理自身对响应体执行了自动解压（如通过 resp.body 读取）时；否则会导致响应头与实际响应体编码状态不一致，破坏缓存语义与客户端解析逻辑。
在 Go 的标准库中，http.Transport 默认启用自动解压缩：当客户端发起请求且未显式设置 Accept-Encoding: identity 时，Transport 会在收到 Content-Encoding: gzip（或 br、deflate）响应后，透明解压响应体，并将解压后的原始字节暴露给 resp.Body。此时，resp.Header 中仍保留原始 Content-Encoding 字段——但该字段已不再反映 resp.Body 的真实编码状态。
若代理直接使用 io.Copy(w, resp.Body) 转发响应体，同时又原样复制 resp.Header.Get("Content-Encoding") 到下游响应头，则会产生严重不一致：
// ❌ 危险示例：透传 Content-Encoding 但转发已解压的 Body
w.Header().Set("Content-Encoding", resp.Header.Get("Content-Encoding")) // 如 "gzip"
io.Copy(w, resp.Body) // 实际写入的是明文，非 gzip 流！客户端收到 Content-Encoding: gzip 头，却接收到未压缩字节，将导致解析失败（如浏览器报错“invalid compressed data”）。
正确做法是：代理必须保持头与体的一致性。若代理解压了响应体（常见于正向代理或中间件式反向代理），则必须移除 Content-Encoding 头，并可选地重置 Content-Length（若已知解压后长度）：
// ✅ 正确示例：解压后清理编码头
resp.Body.Close() // 确保 Transport 已完成解压
defer resp.Body.Close()
// 移除 end-to-end 编码头（因其语义已失效）
resp.Header.Del("Content-Encoding")
resp.Header.Del("Content-Range") // 若存在，也需清理（因长度变化）
// 可选：清除 Transfer-Encoding（若上游用 chunked，此处已转为 content-length 或流式）
resp.Header.Del("Transfer-Encoding")
// 设置新 Content-Length（若能获取解压后长度，否则留空由 net/http 自动处理）
if cl := resp.ContentLength; cl >= 0 {
w.Header().Set("Content-Length", strconv.FormatInt(cl, 10))
}
io.Copy(w, resp.Body)值得注意的是：Content-Encoding 是端到端（end-to-end）头，而非逐跳（hop-by-hop）头，这意味着它描述的是消息体最终呈现给终端用户的编码方式，而非某次传输的临时压缩。因此，任何修改该头的行为（如代理添加、删除或变更值）都必须同步保证响应体的真实编码状态与之严格匹配，否则将违反 HTTP/1.1 规范（RFC 7230 § 5.7, RFC 7231 § 3.1.2.2），并破坏 ETag 验证、条件请求及缓存一致性——因为不同 Content-Encoding 值对应不同的资源变体（vary on encoding），缓存系统会将其视为独立实体。
总结：
- ✅ 代理若不做解压，可透传 Content-Encoding（但需确保 Body 未被 Transport 解压）；
- ✅ 代理若主动解压（如统一提供明文响应），必须删除 Content-Encoding 头；
- ⚠️ 绝不可“半途而废”：既解压 Body，又保留原始编码头；
- ? 在私有生态中若强制约定客户端接受代理层解压，则需全局统一策略，并显式禁用客户端自动解压（如设置 Request.Header.Set("Accept-Encoding", "identity")）。
