Google chrome “如何走动”；内容编码gzip deflate“；由Chrome发送的标题？

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

所有浏览器都会向我们的登录表单发送HTTP请求，其中包含预期的“username=myname&password=mypass”字符串，但不包括Chrome。相反，我们从Chrome收到一个“Content encoding gzip deflate”请求。顺便说一句，所谓“所有浏览器”，我的意思是这在InternetExplorer版本9测试版、8测试版、7测试版、6测试版上运行良好；Firefox版本4测试版、3测试版、2测试版；歌剧10、9；狩猎5、4、3；和西蒙基2号

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

有没有一种方法可以绕过这种行为，或者使用客户端JavaScript阻止Chrome发送“Content encoding gzip deflate”请求，或者使用服务器端响应向Chrome很好地解释我们不做gzip，只是以常规方式发送给我们

我们试着在谷歌Chrome故障排除论坛上发帖，但没有回应

任何帮助都将不胜感激

致以最良好的祝愿，

---

Bert

第一次使用chrome向服务器发送帖子时，chrome默认使用gzip编码。很奇怪

---

简单的解决方法是将username/pass作为GET参数，在发送响应时，只要不发送gzip内容编码，chrome应该从那时起开始使用none-gzip帖子。希望能奏效？

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

您在错误的部分中查找错误代码：RFC 2616的第14.11节规定，如果无法处理内容编码，则发送415（不支持的媒体类型）