.Net HttpWebResponse 通过 HTTPS 响应流 - 可与 Fiddler 配合使用 - 无垃圾
我对此很陌生，但到目前为止，我已经找到了除此之外所有问题的答案！在这里拉我的头发。
情况是这样的：
A) 从 HTTPS 站点获取 httpWebRequest.GetResponse().GetResponseStream()（无需登录，仅加密流量）有效Fiddler 正在运行 并解密 HTTPS 流量。
B) 从 HTTPS 站点获取 httpWebRequest.GetResponse().GetResponseStream()（无需登录，仅加密流量）给我带来胡言乱语（垃圾）没有 Fiddler 运行就像流被加密或编码一样。
在这两种情况下，服务器都会返回 200 OK；这种情况发生在 POST 某些数据之后的响应上（HTTPS 站点的初始 webRequest - 起始页面 - 在运行和不运行 Fiddler 的情况下都会返回一个可读流）。
我不知道从这里该做什么。我知道该流应该自动解密和解码，但我想事实并非如此。非常感谢任何帮助。非常感谢。
I am new to this but so far have been able to find the answers to all of my questions except this one! Pulling my hair out here.
The situation is this:
A) Getting an httpWebRequest.GetResponse().GetResponseStream() from an HTTPS site (no login, just encrypted traffic) works with Fiddler running and decrypting HTTPS traffic.
B) Getting an httpWebRequest.GetResponse().GetResponseStream() from an HTTPS site (no login, just encrypted traffic) gives me jibberish (garbage) without Fiddler running as if the stream is either encrypted or encoded.
Server returns 200 OK in both cases; this happens on the response after the POST of some data (the initial webRequest - starting page - to the HTTPS site returns a readable stream both with and without Fiddler running).
I have no idea what to do from here. I know that the stream should be automatically decrypted and decoded but I guess it is not. Any help is greatly appreciated. Much thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
好吧，不确定这里发生了什么（我缺乏细节/缺乏社区兴趣/等等），但在安装 Wireshark 并查看不同的场景后，我终于自己找到了答案。
对于那些感兴趣的人来说，事实证明，Fiddler 在传递到最终客户端之前会自动解压缩服务器返回的“页面”。我没有在我的代码中解压缩（不知道我应该解压缩），因此出现了问题。至于初始 Web 请求没问题，我没有为其指定编码，因此服务器以未压缩的“页面”响应（我为所有后续请求指定了编码）。
就是这样。
Well, not sure what happened here (lack of detail on my part / lack of community interest / etc.), but I finally found the answer myself after installing Wireshark and looking at different scenarios.
For those interested, it turned out that Fiddler automatically decompressed the "page" returned by the server before passing to the end client. I was not decompressing in my code (didn't know I should) and thus the problem. As for the initial webrequest being fine, I did not specify an encoding for it and thus the server responded with an uncompressed "page" (I specified an encoding on all subsequent requests).
And there it is.