http 代理通常不应修改或直接透传上游响应中的 content-encoding 头；若代理对响应体执行了自动解压缩（如通过 io.copy 读取 resp.body），则必须移除该头，否则会导致客户端误判编码状态，破坏协议一致性与缓存语义。
http 代理通常不应修改或直接透传上游响应中的 content-encoding 头；若代理对响应体执行了自动解压缩（如通过 io.copy 读取 resp.body），则必须移除该头，否则会导致客户端误判编码状态，破坏协议一致性与缓存语义。
在 HTTP 协议中，Content-Encoding 是一个端到端（end-to-end） 头字段，而非逐跳（hop-by-hop）头（如 Connection 或 Proxy-Authenticate）。这意味着它描述的是消息体最终的编码方式，应由原始服务器设定，并被最终客户端正确解析和处理。
然而，Go 标准库的 http.Transport 在默认配置下会对 Content-Encoding: gzip、deflate 等进行自动解压缩——当调用 resp.Body.Read()（包括 io.Copy(dst, resp.Body)）时，底层已透明解压，返回的是明文内容。此时若代理不加处理地将上游响应的 Content-Encoding: gzip 原样写入下游响应头，而实际传输的却是已解压的字节流，就会造成头体不一致：
// ❌ 错误示例：透传 Content-Encoding 但 body 已被自动解压
proxyResp.Header.Set("Content-Encoding", upstreamResp.Header.Get("Content-Encoding"))
io.Copy(proxyWriter, upstreamResp.Body) // ← 此处 Transport 已解压
// → 客户端收到 "Content-Encoding: gzip" 但得到的是纯文本，解析失败
✅ 正确做法是：代理在解压响应体后，必须删除 Content-Encoding 头（并可选地调整 Content-Length，若已知解压后长度）：
// ✅ 正确示例：解压后清理编码头
upstreamResp, err := http.DefaultClient.Do(req)
if err != nil { /* handle */ }
defer upstreamResp.Body.Close()
// 清理 hop-by-hop 头（RFC 7230 §6.1）及 Content-Encoding（因已解压）
for _, h := range []string{"Content-Encoding", "Content-Length", "Transfer-Encoding"} {
proxyResp.Header.Del(h)
}
// 注意：若需保留 Content-Length，应计算解压后长度（通常需缓冲或流式估算）
io.Copy(proxyWriter, upstreamResp.Body) // 自动解压后的明文
⚠️ 特别注意：
- 缓存兼容性：Content-Encoding 影响资源的 ETag 和 Vary 语义。不同编码被视为同一 URI 的不同表示（representations），因此篡改或错误透传该头将导致 CDN 或中间缓存命中/失效逻辑紊乱。
- 例外场景：仅在完全可控的私有生态中（如内部网关 + 定制客户端），且明确约定代理统一解压、客户端忽略 Content-Encoding 时，才可考虑强制移除并保持协议“契约”一致——但这本质是自定义协议，不再严格遵循 HTTP 语义。
- 透明代理 vs 转码代理：标准透明代理必须保持端到端语义不变；若需转码（如 gzip → br），则属于主动内容转换代理，须重签 Content-Encoding、更新 ETag、设置 Vary: Accept-Encoding，并承担相应责任。
总结：代理不是简单搬运工，而是协议守门人。当 Transport 自动解压时，Content-Encoding 必须被移除；透传该头而不透传对应编码体，是违反 HTTP 核心契约的行为，将引发兼容性、安全性和缓存问题。
