Question

我从一个我想要用FiddlerCore解析的网站得到一个奇怪的回应。在Chrome开发人员工具中，如果我检查响应，它看起来完全正常，在小提琴手中它没有。代码片段如下（过去工作正常）

String html = oSession.GetResponseBodyAsString();

返回以下内容，其中不是html，请注意这是一个示例而不是完整的大字符串。

JRHwJNeR\0���\0\0\u0001��D\0�2�\b\0�\u0016�7]<!DOCTYPE html>\n win\">

它也充斥着＆＃34; \ n＆＃34;和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);


  }

最初我假设它被分块/ gzip所以我添加了utilDecodeResponse（）;对onBeforeResponse没有任何影响！

为了覆盖所有基础，我还尝试手动解码UTF-8，Unicode，Bigendian等中的responseBodyBytes，只是因为响应内容类型不正确并禁用了javascript并加载了页面以证明它不是＆n ＃39; t一些时髦的模板东西，也没什么区别。

有什么想法吗？

更新：

符合Developer＆amp; Sons提供的信息。 NineBerry解决方案如下：

为了防止响应被SDCH编码，您可以添加如下处理程序：

    Fiddler.FiddlerApplication.BeforeRequest += delegate (Fiddler.Session oS)
    {
        oS.oRequest["Accept-Encoding"] = "gzip, deflate, br";
    };

应该注意的是，这并不适合所有事情，因为你手动设置标题而不是检查SDCH是否存在然后删除它，为了我的目的，这工作正常，但是使用一般fiddler的代理功能你需要更多的逻辑。

Answer 1

内容编码显示为SDCH - 共享字典压缩;所以手动解码UTF-8，Unicode，Bigendian等中的responseBodyBytes在这种情况下不起作用。

您可以在此处找到有关SDCH的更多详细信息 - SDCH Ref 1＆amp; SDCH Ref 2

以上网站摘录：

共享字典压缩是一种内容编码方法，由Google于2008年提出，并在Chrome中实施，并由许多Google服务器支持。完整的提案可以在此处获得 - https://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/att-0441/Shared_Dictionary_Compression_over_HTTP.pdf。我不会在这篇博文中复制文档的内容，而是尽量简明扼要地总结：
协议的整个想法是减少跨HTTP连接的冗余。 HTTP响应中的“常见数据”量显然很大 - 例如，您经常会看到网站在多个HTML页面中使用通用页眉/页脚。如果客户端将此公共数据本地存储在“字典”中，则服务器只需要指示客户端如何使用该字典重建页面。

FiddlerCore解码sdch响应

1 个答案: