Go Transport MaxResponseHeaderBytes 怎样限制响应头大小

如果 Go HTTP 客户端遇到异常膨胀的响应头，应该在复用的 http.Transport 上设置 MaxResponseHeaderBytes。它限制的是服务端响应头允许占用的总字节数，不是响应体大小，也不是服务端接收请求头的上限。设置为正数时使用这个上限；设置为零时交给 Transport 使用默认限制。

官方文档：https://pkg.go.dev/net/http#Transport

最稳妥的做法是把它当成客户端的响应头边界：先按业务协议估算 Cookie、追踪字段和协商字段的总量，再用一个正数阈值保护 RoundTrip。超限会在拿到可用响应之前失败，不能等到读取 Response.Body 时才处理。

它限制的是哪一段数据

MaxResponseHeaderBytes 位于客户端 Transport，针对的是上游返回的响应头。状态行和头部字段都属于建立响应时需要读取的元数据；响应体则在响应成功返回后由 Response.Body 继续读取，两者不能用同一个阈值理解。

因此，下面三件事要分开判断：

把阈值放在 Transport 层

配置位置应是实际负责发请求的 Transport。正数表示允许读取的响应头总字节数，例如 64 KiB。Transport 应该复用，而不是每次请求临时创建，否则连接池和统一边界都会被拆散。

package main

import (
    "context"
    "fmt"
    "net/http"
    "time"
)

func requestWithHeaderLimit(ctx context.Context, url string) error {
    transport := &http.Transport{
        // 用正数限制响应头总量；64 KiB 只是示例值，应按协议估算。
        MaxResponseHeaderBytes: 64 

示例里的阈值不是通用答案：如果上游会返回多组 Cookie、签名或分页元数据，应该把这些字段的峰值相加，再留出协议和代理链路的余量。Transport 是并发安全且适合复用的低层组件，边界应随它一起复用。

超限时为什么得到 RoundTrip 错误

Transport 读取响应头时会先使用限制值建立读取边界。如果头部没有在阈值内完成解析，调用 client.Do 或底层 RoundTrip 会返回错误，调用方不会得到一个可以安全使用的 *http.Response。这也是为什么错误处理应紧跟在发请求之后，而不是只围绕 resp.Body.Read 编写。

当前 Go 源码中的错误文本包含 server response headers exceeded ...; aborted。正文可以记录这个信息用于日志聚合，但不要把错误字符串当成稳定的机器协议；业务判断应以请求返回了错误为主，必要时再用 errors.Is 检查底层错误类别。

零值、负值与服务端限制别混淆

官方字段文档明确写的是：零值使用默认限制。当前 Go 源码的内部判断是“只有大于零才使用显式值”，否则回退到 10 MiB 的保守默认值。因此工程配置最好直接写一个有单位含义的正数，不要用负数表达“无限大”，也不要把默认值当成永远不变的协议承诺。

它也不是服务端的 MaxHeaderBytes：后者约束服务端读取客户端请求头，配置在 http.Server 一侧。两者都叫 header，但方向相反。若问题是下载内容超大，应在读取响应体时单独使用业务层的字节限制；把响应体问题转成 MaxResponseHeaderBytes 并不能达到目标。

上线前的判断清单

1. 先盘点上游可能返回的 Cookie、认证、追踪和协商头字段，确认峰值而不是只看平均值。
2. 在真正复用的 Transport 上设置正数阈值，并用请求错误路径记录 URL、上游标识和阈值，不把敏感头内容直接写日志。
3. 把“未拿到 Response”和“拿到 Response 但 Body 过大”分开监控，避免把两类容量问题归为同一个错误。
4. 如果通过代理或多级网关，分别确认它们是否还有更早的响应头限制。

相关问题

MaxResponseHeaderBytes 能限制响应体吗？

不能。它只约束响应头；响应体要在拿到响应后由读取逻辑或业务策略单独限制。

把值设成零是不是完全不限制？

不是。零值表示使用 Transport 的默认限制，不能理解为无限大。