我们在嵌入式设备的Web服务器上有一个简单的HTML登录表单。由于严重的内存限制，Web服务器是自定义编码的。无论这些限制如何，我们都喜欢Chrome，并且愿意支持它。
所有浏览器都会将HTTP请求发布到我们的登录表单，其中包含预期的“username = myname＆amp; password = mypass”字符串，但不包含Chrome。相反，我们从Chrome收到“内容编码gzip deflate”请求。顺便说一句，“所有浏览器”，我的意思是这个测试在Internet Explorer版本9 beta，8,7,6; Firefox版本4 beta，3,2;歌剧10,9; Safari 5,4,3;和SeaMonkey 2.
参考w3.org的http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html部分“14.2 Accept Charset”，我们尝试发回一个HTTP 406代码，表明此服务器不支持该编码，希望Chrome再试一次并发布预期字符串是标准方式。 Web服务器返回的406代码清楚地显示在Chrome的“Inspect Element”窗口中，但Chrome似乎将其视为错误代码，并且不再向Web服务器发送请求。 “登录失败。”我们还尝试了HTTP返回码405和200，结果相同。
有没有办法绕过这种行为，使用客户端JavaScript阻止Chrome发送“内容编码gzip deflate”请求，或使用服务器端响应，这将很好地解释Chrome我们不能做gzip，只是按常规方式发送给我们？
我们尝试过发布到Google Chrome故障排除论坛，但没有回复。
非常感谢任何帮助！
祝你好运， 伯特
答案 0 :(得分：2)
您正在查找错误代码的错误代码：RFC 2616的第14.11节规定，如果您无法处理内容编码，则会发送415（不支持的媒体类型）。
答案 1 :(得分：0)
听起来好像第一次使用chrome在服务器上发帖子时，chrome默认使用gzip编码。很奇怪。
简单的方法就是将您的用户名/密码作为GET参数放置，并且在发送响应时，只要您不发送gzip内容编码，chrome就应该从该点开始使用非gzipped帖子。希望有用吗？
答案 2 :(得分：0)
我用一个打印到stdout的简单Python脚本测试了一下。我以为我遇到了同样的问题，但后来我意识到我只是忘了冲洗stdout。在发送请求内容之前，Chrome似乎始终将请求发送到标题的末尾，您必须使用第二次recv调用来获取POST数据。相反，整个Firefox请求都在一次recv调用中返回。