Chrome DevTools 协议 - Golang 中带有 gzip 正文的ContinueInterceptedRequest

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《Chrome DevTools 协议 - Golang 中带有 gzip 正文的ContinueInterceptedRequest》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

我一直在开发一个 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) 更改响应正文

在这里，我对 proceshtml() 中的 html 标记进行了一些小更改（但该函数的代码与此问题无关，因此不会在此处发布）。我还从请求中获取标头，并在必要时更新 content-length 和 date，然后再继续响应。然后，我在调用 r := gzipcompress([]byte(alteredbody) 时对正文进行 gzip 压缩，这会返回一个字符串。然后将该字符串连接到标头，以便我可以制作 rawresponse。

func alterdocument(debuggerresponse []byte, headers map[string]string) (string, error) {
    alteredbody, err := processhtml(debuggerresponse)
    if err != nil {
        return "", err
    }


    alteredheader := ""
    for k, v := range headers{
        switch strings.tolower(k) {
            case "content-length":
                v = strconv.itoa(len(alteredbody))
                fmt.println("updating content-length to: " + strconv.itoa(len(alteredbody)))
                break
            case "date":
                v = fmt.sprintf("%s", time.now().format(time.rfc3339))
                break
        }
        alteredheader += k + ": " + v + "\r\n"
    }

    r := gzipcompress([]byte(alteredbody))

    rawalteredresponse := 
    base64.stdencoding.encodetostring([]byte("http/1.1 200 ok" + "\r\n" + alteredheader + "\r\n\r\n\r\n" + r))

    return rawalteredresponse, nil
}

注意：我现在使用 gzip 压缩所有响应的正文。以上是暂时的，我正在研究如何解决这个问题。

gzip 压缩函数如下所示：

func gzipcompress(datatoworkwith []byte) string{
    var b bytes.buffer

    gz, err := gzip.newwriterlevel(&b, 5)
    if err != nil{
        panic(err)
    }
    if _, err := gz.write(datatoworkwith); err != nil {
        panic(err)
    }
    if err := gz.flush(); err != nil {
        panic(err)
    }
    if err := gz.close(); err != nil {
        panic(err)
    }
    return b.string()
}

如第一个代码片段所示，响应正文和标头在此处设置：

err := s.Debugger.ContinueInterceptedRequest(iid, godet.ErrorReason(reason), rawAlteredResponse, "", "", "", nil)

结果是浏览器中出现一堆乱码。对于非 gzip 压缩的请求，这无需 gzip 函数即可工作。我也改变了压缩级别（没有成功）。我是否以错误的顺序处理正文（字符串 > []byte > gzip > 字符串 > base64）？这应该以不同的顺序完成吗？任何帮助将不胜感激。

响应看起来像这样，chrome 将其放入 标记内

����r∸� ��_a��q%gh��kʔ��vu�˷c�v�}

或在响应中：

我还可以看出它正在正确压缩，因为当我删除标头时，请求会导致 .gz 文件下载，并且未压缩时包含所有正确的 .html。此外，gzipcompress 中返回的对象中的前几个字节告诉我它已正确压缩：

31 139 8

或

0x1f 0x8b 0x08

解决方案

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

现在，DevTools 协议似乎在调用 Network.GetResponseBodyForInterception 时在解压缩后但在浏览器中渲染之前返回响应正文。当然，这只是一个假设，因为我在 https://github.com/ChromeDevTools/devtools-protocol 中没有看到该方法的代码。该假设基于以下事实：当调用 Network.GetResponseBodyForInterception 时，获得的响应正文未压缩（尽管它可能是 base64 编码的）。此外，该方法被标记为实验性的，并且文档没有提及任何有关压缩响应的内容。基于这个假设，我将进一步假设，当我们从 Network.GetResponseBodyForInterception 获得响应时，我们自己压缩主体就为时已晚了。我确认我正在使用的库不会压缩或解压缩 gzip 响应。

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

作为参考，我现在使用 https://github.com/wirepair/gcd，因为它在拦截较大响应时更加健壮和稳定。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~