Accept-Encoding 标头由浏览器发送但未被服务器接收

发布于 2024-08-28 15:12:38 字数 399 浏览 7 评论 0原文

几周来我一直在尝试调试这个。我的家庭网络上所有客户端上的所有浏览器都发送“接受编码:gzip,deflate”。然而,在请求到达 Web 服务器之前,该标头不知何故被丢弃在某个地方。例如,http://www.whatsmyip.org/http_compression/ 表示“不,您的浏览器是不请求压缩内容”。

我使用 Fiddler 来确保我的所有浏览器确实都在发送标头。我已经换掉路由器了我已经关闭了所有防病毒软件。

Brighthouse/Roadrunner(本地有线电视 ISP)表示他们没有进行任何过滤(我不明白为什么他们在这种情况下会这样做)。

任何建议将非常受欢迎!

I have been trying to debug this for weeks. All of the browsers on all of the clients on my home network are sending 'Accept-Encoding: gzip,deflate'. However, that header is somehow, somewhere being dropped before the request makes it to a web server. For example, http://www.whatsmyip.org/http_compression/ says 'No, your browser is not requesting compressed content'.

I've used Fiddler to make sure that all of my browsers are indeed sending the header. I've swapped out my router. I've turned off all anti-virus software.

Brighthouse/Roadrunner (the local cable ISP) says they are not doing any filtering (and I can't see why they would in this case).

Any suggestions would be most welcome!

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

林空鹿饮溪 2024-09-04 15:12:38

尝试使用 HTTPS。

如果您通过 HTTPS 浏览网站,则您的浏览器和 Web 服务器之间的任何内容都无法更改请求或响应的任何 HTTP 级别方面,包括是否启用压缩,除非您立即清楚地了解这一事实(检查在浏览器地址栏中查看网站的证书,看看它是否合法)。

Try it with HTTPS.

If you are browsing a site via HTTPS, nothing between your browser and the web server can alter any HTTP-level aspect of the the request or response, including whether compression is enabled, without you having immediate and clear knowledge of that fact (check the site's certificate in your browser address bar and see if it's legit).

森末i 2024-09-04 15:12:38

我遇到了 Accept-Xncoding 问题,并确定是 CA Internet Security Suite 导致了该问题。禁用还不够,您必须卸载然后清除 IE 缓存。

I had the Accept-Xncoding issue and determined it was CA Internet Security Suite causing the issue. Disabling wan't enought, you had to uninstall and then clear IE Cache.

苍暮颜 2024-09-04 15:12:38

检查您的防病毒软件。它可能会拦截您的出站流量并动态修改标头以获得未压缩的内容。懒惰的程序员不喜欢包含解压缩方法本身,或处理分块编码。

Norton Internet Security 将使用以下行覆盖接受编码:

---------------: ----- -------

McAfee 将使用以下行覆盖:

X-McProxyFilter: ** **********

我尚未识别的东西会用以下内容覆盖:

Accept-Xncoding: gzip, deflate

您可能也有同样的情况。我读到区域警报完全清除了编码标头(这意味着重新计算数据包的大小,但他们为什么要关心他们在系统上引入了多少负载?)。如果您正在运行区域警报,请关闭“互联网隐私选项”或其他任何选项,然后重试。

每次我看到这个问题时,都是由糟糕的防病毒软件造成的。完全禁止某人接收压缩内容而不让他们知道是肮脏的。

Check your antivirus software. It's probably intercepting your outbound traffic and modifying headers on the fly in order to get uncompressed content. Lazy programmers don't like to include decompression methods themselves, or deal with chunked encoding.

Norton Internet Security will overwrite accept encoding with this line:

---------------: ----- -------

McAfee overwrites with this:

X-McProxyFilter: *************

something I haven't identified yet overwrites with this:

Accept-Xncoding: gzip, deflate

You are probably in the same boat. I read Zone Alarm wipes out the encoding header entirely (which means recalculating the size of the packet, but why should they care how much load they introduce on your system?). If you're running Zone Alarm, turn off the 'internet privacy option' or whatever it is, and try again.

Everytime I've seen this problem, it has been the result of shitty antivirus. Completely disabling someone's ability to receive compressed content without letting them know is dirty.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文