我从一个我想用FiddlerCore解析的网站得到一个奇怪的回应.在chrome开发人员工具中,如果我检查响应,它看起来完全正常,在fiddler中则不然.代码片段如下(以前工作正常)
String html = oSession.GetResponseBodyAsString();
返回以下内容,这不是html,请注意这是一个示例而不是完整的大字符串.
JRHwJNeR\0???\0\0\u0001??D\0?2?\b\0?\u0016?7]<!DOCTYPE html>\n win\">
它也充满了"\n"和这样的html
\n\n\n\n\n \n <meta name=\"treeID\" content=\"dwedxE+pgRQAWIHiFSsAAA==\">\n
响应标头如下:
Cache-Control:no-cache, no-store
Connection:keep-alive
Content-Encoding:sdch, gzip
Content-Language:en-US
Content-Type:text/html;charset=UTF-8
Date:Fri, 28 Oct 2016 10:17:02 GMT
Expires:Thu, 01 Jan 1970 00:00:00 GMT
Pragma:no-cache
Server:Apache-Coyote/1.1
Set-Cookie:lidc="b=VB87:g=518:u=60:i=1477649823:t=1477731496:s=AQG-LTdly5mcIjAtiRHIOrKE1TiRWW-l"; Expires=Sat, 29 Oct 2016 08:58:16 GMT; domain=.thedomain.com; Path=/
Set-Cookie:_lipt=deleteMe; Expires=Thu, 01-Jan-1970 00:00:10 GMT; Path=/
Strict-Transport-Security:max-age=0
Transfer-Encoding:chunked
Vary:Accept-Encoding, Avail-Dictionary
X-Content-Type-Options:nosniff
X-Frame-Options:sameorigin
X-FS-UUID:882b3366afaa811400a04937a92b0000
X-Li-Fabric:prod-lva1
X-Li-Pop:prod-tln1-scalable
X-LI-UUID:iCszZq+qgRQAoEk3qSsAAA==
X-XSS-Protection:1; mode=block
Fiddler启动代码:
Fiddler.FiddlerApplication.AfterSessionComplete += FiddlerApplication_OnAfterSessionComplete;
Fiddler.FiddlerApplication.BeforeResponse += delegate(Fiddler.Session oS) {
oS.utilDecodeResponse();
};
Fiddler.FiddlerApplication.Startup(0, FiddlerCoreStartupFlags.Default);
}
最初我假设它是chunked/gzipped所以我添加了utilDecodeResponse(); 对onBeforeResponse没有任何影响!
只是为了覆盖所有的基础,我也尝试手动解码UTF-8,Unicode,Bigendian等的responseBodyBytes,只是因为关闭机会类型不正确并禁用了javascript并加载了页面以证明它不是一些时髦的模板事情,这也没有任何区别.
有任何想法吗？
更新:
根据Developer&NineBerry提供的信息,解决方案如下:
为了防止响应被SDCH编码,你可以像这样添加一个处理程序:
Fiddler.FiddlerApplication.BeforeRequest += delegate (Fiddler.Session oS)
{
oS.oRequest["Accept-Encoding"] = "gzip, deflate, br";
};
应该注意的是,这不适用于所有内容,因为您手动设置标头而不是检查SDCH是否存在然后将其删除,为了我的目的,这可以正常工作,但是对于使用fiddler的一般代理功能你我想在这里有更多的逻辑.
内容编码显示为 SDCH - Shared Dictionary Compression；所以在这种情况下手动解码 UTF-8、Unicode、Bigendian 等格式的 responseBodyBytes 将不起作用。
您可以在此处找到有关 SDCH 的更多详细信息 - SDCH Ref 1和SDCH Ref 2
摘自上述网站：
共享字典压缩是一种内容编码方法，早在 2008 年就由 Google 提出，并在 Chrome 中实现，并得到了许多 Google 服务器的支持。完整的提案可以在这里获得 - https://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/att-0441/Shared_Dictionary_Compression_over_HTTP.pdf。我不会在这篇博文中复制文档的内容，而是尝试尽可能简洁地总结：
该协议的整体思想是减少跨 HTTP 连接的冗余。HTTP 响应中的“公共数据”数量显然很重要——例如，您经常会看到一个网站在多个 HTML 页面中使用公共页眉/页脚。如果客户端将这些公共数据本地存储在“字典”中，则服务器只需要指示客户端如何使用该字典重建页面。