FiddlerCore 解码 sdch 响应答案

【问题标题】：FiddlerCore decoding an sdch responseFiddlerCore 解码 sdch 响应
【发布时间】：2016-10-28 10:40:56
【问题描述】：

我从一个希望用 FiddlerCore 解析的网站收到一个奇怪的响应。在 chrome 开发人员工具中，如果我检查响应，它看起来完全正常，而在 fiddler 中则不然。代码 sn-p 如下（以前可以正常工作）

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);


  }

最初我认为它是分块/压缩的，所以我添加了 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 是否存在然后将其删除，出于我的目的，这工作正常，但用于使用一般代理功能提琴手，你会想要更多的逻辑在这里。

【问题讨论】：

内容编码显示为sdch。这有帮助吗？ blog.endpoint.com/2009/07/…
哦，这是一个有趣的文档，我可以让 fiddler 拒绝/更改接受的编码标头
让我测试一下然后回来，这是有道理的问题，发布和回答，我会弹回来一点！
在检查从 Chrome 发送的来自 LinkedIn 的答案时，我在 Fiddler 应用程序本身中看到了相同的行为。内容编码是“sdch，gzip”。选择在 Fiddler 中解码后，Content-Encoding 只是“sdch”，我看到的内容与您的问题相同。通过 Firefox 执行请求时不会发生这种情况。然后答案只编码为“gzip”。更改从 Accept-Encoding 标头中删除“sdch”的请求应该可以工作。
谢谢大家现在把它剥离出来测试

标签： c# fiddlercore

【解决方案1】：

内容编码显示为 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 页面中使用公共页眉/页脚。如果客户端将这些公共数据本地存储在“字典”中，服务器只需要指示客户端如何使用该字典重建页面。

【讨论】：