FiddlerCore解码一个sdch响应

本文关键字：一个 sdch 响应 解码 FiddlerCore | 更新日期: 2023-09-27 18:15:27

我从一个网站得到了一个奇怪的回应，我正在寻找与FiddlerCore解析。在chrome开发工具，如果我检查响应看起来完全正常，在小提琴手它没有。代码片段如下(过去可以正常工作)

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

  }

最初我认为它是块/压缩，所以我添加了utildecoderresponse ();到onBeforeResponse，但没有效果!

只是为了涵盖所有的基础，我也尝试手动解码responseBodyBytes在UTF-8, Unicode, Bigendian等只是在off chance的响应内容类型是不正确的，禁用javascript和加载页面，以证明它不是一些怪异的模板的东西，这也没有区别。

任何想法?

更新:

与开发商提供的信息一致;NineBerry下面的解决方案如下:

为了防止响应被SDCH编码，您可以添加一个处理程序，如下所示:

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

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

FiddlerCore解码一个sdch响应

内容编码显示为SDCH -共享字典压缩;所以手动解码responseBodyBytes在UTF-8, Unicode, Bigendian等将无法在这种情况下工作。

你可以在这里找到更多关于SDCH的细节-SDCH Ref 1 &SDCH Ref 2

以上网站节选:

共享字典压缩是一种内容编码方法，早在2008年就由谷歌提出，并在Chrome中实现，并得到许多谷歌服务器的支持。完整的提案可以在这里获得-https://lists.w3.org/Archives/Public/ietf-http-wg/2008JulSep/att-0441/Shared_Dictionary_Compression_over_HTTP.pdf。与其在这篇博文中复制文档的内容，我将尽可能简洁地总结:
该协议的整体思想是减少跨HTTP连接的冗余。HTTP响应中"通用数据"的数量显然是重要的——例如，你经常会看到一个网站在多个HTML页面中使用通用的页眉/页脚。如果客户端要将这些公共数据存储在本地的"字典"中，服务器只需要指示客户端如何使用该字典重建页面。

相关文章：