如何绕过Chrome发送的"Content-encoding gzip deflate“头？

Question

我们在嵌入式设备的web服务器上有一个简单的HTML登录表单。由于严重的内存限制，web服务器是自定义编码的。不管这些限制，我们喜欢Chrome并希望支持它。

所有浏览器都会向我们的登录表单发送一个HTTP请求，其中包含预期的"username=myname&password=mypass“字符串，但不包含Chrome。取而代之的是，我们从Chrome收到了一个“内容编码gzip压缩”请求。顺便说一句，我所说的“所有浏览器”，我的意思是，这在Internet Explorer版本9 beta，8，7，6；Firefox版本4 beta，3，2；Opera10，9；Safari5，4，3；和SeaMonkey 2上运行良好。

参考w3.org的http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html的"14.2 Accept Charset“一节，我们尝试发回一个HTTP406代码，以表明该服务器不支持该编码，希望Chrome会再试一次，并以标准方式发布预期的字符串。web服务器返回的406代码清楚地显示在Chrome的"Inspect Element“窗口中，但Chrome似乎将其视为错误代码，并且不会向web服务器发送进一步的请求。“登录失败。”我们还尝试了HTTP返回代码405和200，结果相同。

有没有办法绕过这种行为，既可以通过客户端JavaScript来阻止Chrome发送“内容编码gzip压缩”请求，也可以通过服务器端响应来很好地向Chrome解释我们不做gzip，只需以常规的方式发送给我们？

我们尝试在Google Chrome故障排除论坛上发帖，但没有响应。

任何帮助都将不胜感激！

致以最好的问候，伯特

Answer 1

您在错误的部分中查找错误代码:RFC2616的第14.11节指定，如果您不能处理Content-Encoding，则发送415 (不支持的媒体类型)。

Answer 2

听起来就像第一次使用chrome向服务器发送邮件时，chrome默认使用gzip编码。很奇怪。

简单的解决方法就是将你的用户名/传递作为GET参数，在发送响应时，只要你不发送gzip内容编码，chrome就应该从那时开始使用非gzip压缩的帖子。希望这能行得通？

Answer 3

我用一个输出到stdout的简单Python脚本对此进行了一些测试。我以为我也遇到了同样的问题，但后来我意识到我只是忘记了刷新stdout。似乎Chrome总是在发送请求内容之前将请求发送到头部的末尾，并且您必须使用第二个recv调用来获取POST数据。相反，整个Firefox请求在单个recv调用中返回。