Chrome DevTools 协议 - Golang 中带有 gzip 正文的ContinueInterceptedRequest
哈喽！大家好，很高兴又见面了，我是编程网的一名作者，今天由我给大家带来一篇《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 将其放入 <body></body> 标记内
����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的技术知识我们会一点点深入介绍，欢迎大家关注编程网公众号，一起学习编程~
免责声明：
① 本站未注明“稿件来源”的信息均来自网络整理。其文字、图片和音视频稿件的所属权归原作者所有。本站收集整理出于非商业性的教育和科研之目的，并不意味着本站赞同其观点或证实其内容的真实性。仅作为临时的测试数据，供内部测试之用。本站并未授权任何人以任何方式主动获取本站任何信息。
② 本站未注明“稿件来源”的临时测试数据将在测试完成后最终做删除处理。有问题或投稿请发送至: 邮箱/279061341@qq.com QQ/279061341
