【发布时间】:2021-02-13 00:34:03
【问题描述】:
我正在编写一些中间件,即使目标使用 TLS 加密,我也需要能够记录响应正文内容。
我有一个处理程序链,在其中我将响应主体存储在中间缓冲区中,以便我可以多次读取它。这是基于 icza (Golang read request body) 提供的优秀示例。
在我的处理函数中,我正在这样做....
body, err := ioutil.ReadAll(resp.Body)
if err != nil {
log.Fatal(err)
}
// Print the response body to stdout
fmt.Printf("Dest HTTP response body: %s\n", body)
bRdr := bytes.NewReader(body)
n, err := io.Copy(w, bRdr) // Copy the entire response body into our outgoing response
我发现,当连接到不使用 TLS 的目的地时,我得到可读的输出,但是当使用 TLS 连接到目的地时,似乎响应正文仍然是加密的,尽管复制到最终响应originator 导致 originator 接收到有效的响应正文内容。
这是使用加密路径读取响应正文的预期行为吗? 我可以解密这些数据以使其可读吗?我已经阅读了http、tls和crypto包的文档,但没有找到任何线索。
【问题讨论】:
-
TLS 在完全不同的层上运行。当您阅读正文时,您不是在查看 TLS 流。
-
TLS 加密/解密在这一层是透明的。你确定你正在查看加密的正文,还是一些垃圾数据?
-
您看到的是压缩体吗?
-
感谢大家的cmets。 Travis 似乎已经确定了我遇到的问题。我正在阅读的响应正文似乎是 gzip 编码的(响应包含“Content-Encoding:gzip”)。为了验证情况是否如此,我必须在转发之前明确删除原始请求中的“Accept-Encoding: gzip”标头,并将传输配置为设置“DisableCompression:true”。完成这两项更改后,我会看到没有“Content-Encoding”标头的响应,并且我阅读的正文是人类可读的。
-
现在我需要做的就是重新打开 gzip 编码并弄清楚如何解压缩 gzip 压缩的响应正文。我看到关于该主题的其他各种帖子,所以我会研究这些。
标签: go middleware