Go httputil.DumpResponse 怎样裁剪敏感响应头

如果你用 httputil.DumpResponse 记录 HTTP 调试信息，最稳妥的做法不是先改原响应，而是先复制一份 http.Response，再复制它的 Header，删除敏感字段，最后用 body=false 生成只含状态行和响应头的摘要。这样业务代码继续使用原响应，日志只接触经过裁剪的副本。

先确认 DumpResponse 的职责边界

Go 官方文档把 DumpResponse(resp, body) 定义为“像 DumpRequest 一样转储响应”。它解决的是把 http.Response 写成便于调试的 HTTP/1.x 文本表示，不负责判断哪些头可以进入日志，也没有参数让调用者传入敏感头名单。

body 只决定是否把响应正文也纳入转储。标准库实现会在需要正文时读取并恢复 resp.Body；这对一般调试很方便，但不能替代脱敏策略。尤其是响应头里的 Set-Cookie、临时令牌或内部路由信息，即使不记录正文，也可能单独造成泄露。

复制响应并裁剪敏感头

第一步是做一个浅复制，再把 Header map 单独克隆。Go 的 Header 是 map，只写 safe := *resp 而不复制 safe.Header，后面的 delete 或 Del 仍会影响原对象。为了应对手工构造的非规范大小写键，下面的辅助函数用 strings.EqualFold 比较键名。

package main

import (
    "net/http"
    "net/http/httputil"
    "strings"
)

// cloneResponseForDump 只准备调试副本，不改变业务代码持有的原响应。
func cloneResponseForDump(resp *http.Response, blocked []string) *http.Response {
    // 结构体复制保留状态码、URL 和其他元数据，但 Header map 还需要独立克隆。
    safe := new(http.Response)
    *safe = *resp
    safe.Header = resp.Header.Clone()

    // 用大小写不敏感比较处理手工构造的 Header 键，避免漏删同名字段。
    for key := range safe.Header {
        for _, name := range blocked {
            if strings.EqualFold(key, name) {
                delete(safe.Header, key)
                break
            }
        }
    }
    return safe
}

// dumpResponseHeaders 只转储状态行和响应头，默认不读取响应正文。
func dumpResponseHeaders(resp *http.Response) ([]byte, error) {
    blocked := []string{
        "Set-Cookie", "Authorization", "Proxy-Authenticate",
        "X-API-Key", "X-Auth-Token",
    }
    safe := cloneResponseForDump(resp, blocked)

    // body=false 让日志边界停在响应头；正文仍由业务流程自己处理。
    return httputil.DumpResponse(safe, false)
}

这里删除的是日志副本里的字段，原始 resp.Header 不会跟着变化。名单应按业务实际扩展，例如内部追踪头、用户标识头或网关注入的临时凭据；不要只因为字段名里出现“Token”就机械删除所有业务数据，最好把允许写入日志的字段和明确禁止字段分别记录在配置中。

只输出响应头摘要

对大多数 HTTP 调试场景，响应状态、Content-Type、Content-Length、缓存信息和少量追踪字段已经足够定位问题。调用 DumpResponse(safe, false) 后，日志不会主动把正文复制进摘要，既降低敏感数据暴露面，也避免把大 JSON、文件或流式响应全部读进内存。

func logResponseSummary(resp *http.Response) error {
    dump, err := dumpResponseHeaders(resp)
    if err != nil {
        // 转储失败时只记录错误类型，不把原始响应内容作为兜底日志。
        return err
    }

    // 生产日志应使用结构化 logger，并按环境控制是否输出完整响应头。
    logger.Printf("http response summary:\n%s", dump)
    return nil
}

如果日志系统还会自动采集完整的 http.Response、请求上下文或错误对象，单独裁剪 DumpResponse 并不能覆盖那条旁路。要把“日志输入”统一收口：调试摘要走安全副本，原响应只流向业务处理，异常日志只保留状态码、请求标识和经过筛选的头。

确实需要正文时显式复制

有些问题需要查看错误响应正文，例如接口返回的字段路径或上游错误码。这时不要直接把共享的 resp.Body 交给多个读取者。先限制最大读取量，再一次性得到字节切片，用两个独立的 io.ReadCloser 分别给业务响应和调试副本。

package main

import (
    "bytes"
    "fmt"
    "io"
    "net/http"
    "net/http/httputil"
)

// dumpResponseWithBoundedBody 在需要正文时同时保留业务读取副本和日志读取副本。
func dumpResponseWithBoundedBody(resp *http.Response, maxBody int64) ([]byte, error) {
    // 限制读取量，避免错误接口返回超大正文导致调试路径占满内存。
    limited := io.LimitReader(resp.Body, maxBody+1)
    body, err := io.ReadAll(limited)
    if err != nil {
        return nil, fmt.Errorf("read response body: %w", err)
    }
    if int64(len(body)) > maxBody {
        return nil, fmt.Errorf("response body exceeds %d bytes", maxBody)
    }

    // 读取后关闭原流，再为业务和调试副本各放入一个独立 Reader。
    if err := resp.Body.Close(); err != nil {
        return nil, fmt.Errorf("close response body: %w", err)
    }
    resp.Body = io.NopCloser(bytes.NewReader(body))

    safe := cloneResponseForDump(resp, []string{"Set-Cookie", "Authorization", "X-API-Key"})
    safe.Body = io.NopCloser(bytes.NewReader(body))

    // body=true 现在只读取 safe.Body，不会再次消费业务响应的 Body。
    return httputil.DumpResponse(safe, true)
}

这个示例选择了“正文超过上限就报错”的策略；也可以改为截断并明确写入 body_truncated=true。关键是先确定上限、关闭原流并分别创建 Reader，不能依赖一个已读到 EOF 的 Body 让后续日志再次读取。

把敏感头名单变成日志边界

不要把删除名单当成永久完整的安全证明：上游可能新增自定义头，网关也可能把秘密放在非标准字段里。生产环境更适合设置“允许记录的头”白名单，开发环境再按需临时放宽；无论哪种方式，都要让日志采集链路继承同一套规则。

常见问题

DumpResponse 能直接传入要忽略的响应头吗？

不能。它只接受响应和是否包含正文两个参数，需要调用方先准备安全副本。

为什么不能直接对 resp.Header 调用 Del？

因为这会修改业务流程后续仍要使用的原响应。应先复制 Response，再用 Header.Clone 复制 map。

body=false 会不会关闭响应正文？

标准库会用占位 Body 生成不含正文的转储并恢复原字段；但日志路径仍建议把 body=false 作为明确默认值，不要依赖隐含行为。

响应头里没有 Authorization，还需要裁剪吗？

需要。Set-Cookie、API Key、自定义认证头和内部路由头同样可能包含不应进入日志的信息，名单要结合实际网关和上游约定维护。