Chrome DevTools 协议 - 在 Golang 中使用 gzip 主体的

Question

我一直在研究一个 golang 脚本，它使用chrome devtools 协议来：1）拦截一个请求2）抓取拦截请求的响应体3）对html文档进行一些修改4）继续拦截的请求该脚本适用于 HTML 文档，除非Content-Encoding设置为gzip. 分步过程如下所示”1）拦截请求 s.Debugger.CallbackEvent("Network.requestIntercepted", func(params godet.Params) {    iid := params.String("interceptionId")    rtype := params.String("resourceType")    reason := responses[rtype]    headers := getHeadersString(params["responseHeaders"])    log.Println("[+] Request intercepted for", iid, rtype, params.Map("request")["url"])    if reason != "" {        log.Println("  abort with reason", reason)    }    // Alter HTML in request response    if s.Options.AlterDocument && rtype == "Document" && iid != "" {        res, err := s.Debugger.GetResponseBodyForInterception(iid)        if err != nil {            log.Println("[-] Unable to get intercepted response body!")        }        rawAlteredResponse, err := AlterDocument(res, headers)        if err != nil{            log.Println("[-] Unable to alter HTML")        }        if rawAlteredResponse != "" {            log.Println("[+] Sending modified body")            err := s.Debugger.ContinueInterceptedRequest(iid, godet.ErrorReason(reason), rawAlteredResponse, "", "", "", nil)            if err != nil {                fmt.Println("OH NOES AN ERROR!")                log.Println(err)            }        }    } else {        s.Debugger.ContinueInterceptedRequest(iid, godet.ErrorReason(reason), "", "", "", "", nil)    }})2）改变响应体在这里，我对 HTML 标记做了一些小改动procesHtml()（但该功能的代码与此问题无关，因此不会在此处发布）。我还从请求中获取标头，并在必要时更新content-length和date继续响应。然后，我在调用时对主体进行 gzip 压缩r := gZipCompress([]byte(alteredBody)，它返回一个字符串。然后将该字符串连接到标头，这样我就可以制作rawResponse.func AlterDocument(debuggerResponse []byte, headers map[string]string) (string, error) {    alteredBody, err := processHtml(debuggerResponse)    if err != nil {        return "", err    }

Answer 1

我最终使用了一个不同的库来更好、更有效地处理更大的响应。

现在，DevTools 协议似乎在解压之后返回响应主体，但在调用Network.GetResponseBodyForInterception. 这当然只是一个假设，该假设基于这样一个事实，即调用时Network.GetResponseBodyForInterception获得的响应主体未压缩（尽管它可能是 base64 编码的）。此外，该方法被标记为实验性的，文档中没有提及任何关于压缩响应的内容。基于该假设，我将进一步假设，当我们从Network.GetResponseBodyForInterception自己压缩身体已经来不及了。我确认我正在使用的库不会压缩或解压缩 gzipped 响应。

我可以继续使用我的代码，而无需担心 gzip 压缩响应，因为我可以毫无问题地更改正文。