如何避开“Content-encoding gzip deflate” Chrome发送的标头？ [英] how to get around "Content-encoding gzip deflate" header sent by Chrome?
问题描述
我们在嵌入式设备的网络服务器上有一个简单的HTML登录表单。 Web服务器由于严重的内存限制而被自定义编码。不管这些限制，我们都喜欢Chrome并希望支持它。所有浏览器都会在我们的登录表单中发布HTTP请求，其中包含预期的username = myname& password = mypass字符串，但不是Chrome。相反，我们从Chrome收到Content-encoding gzip deflate请求。顺便说一句，所有浏览器，我的意思是这个测试可以在Internet Explorer 9 beta，8,7,6; Firefox版本4测试版，3，2;歌剧10，9; Safari 5,4,3;和SeaMonkey 2.
请参阅w3.org的 http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html 我们尝试发回一个HTTP 406代码来表明这台服务器确实不支持该编码，希望Chrome能够再次尝试并以标准方式发布预期的字符串。由网络服务器返回的406代码清楚地显示在Chrome的检查元素窗口中，但它似乎被Chrome视为错误代码，并且不会向Web服务器发送进一步的请求。 登录失败。我们也尝试了HTTP返回代码405和200，结果相同。
有没有办法绕过这种行为，或者使用客户端JavaScript来阻止Chrome发送内容编码gzip deflate请求，或者与服务器端响应，这将很好地解释为Chrome我们不做gzip，只是发送给我们的常规方式？
任何帮助将不胜感激！
此致，
Bert
您正在错误代码部分寻找：Section RFC 2616的14.11规定，如果您无法处理Content-Encoding，则发送415（不支持的媒体类型）。
We have a simple HTML login form on our embedded device's web server. The web server is custom coded because of severe memory limitations. Regardless of these limitations, we like Chrome and would like to support it.
All browsers post an HTTP Request to our login form containing the expected "username=myname&password=mypass" string, but not Chrome. Instead we receive from Chrome a "Content-encoding gzip deflate" request. BTW, by "all browsers", I mean this was tested to work fine on Internet Explorer versions 9 beta, 8, 7, 6 ; Firefox versions 4 beta, 3, 2 ; Opera 10, 9 ; Safari 5, 4, 3 ; and SeaMonkey 2.
Referring to section "14.2 Accept Charset" of the w3.org's http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html we tried sending back a HTTP 406 code to indicate that this server does not support that encoding in the hope that Chrome would try again and post the expected strings the standard way. The 406 code returned by the web server is clearly displayed in Chrome's "Inspect Element" window, but it seems to be treated by Chrome as an error code, and no further requests are sent to the web server. "Login failed." We also tried HTTP return codes 405 and 200, same result.
Is there a way to get around this behavior either with client-side JavaScript that will prevent Chrome from sending the "Content-encoding gzip deflate" request, or with a server-side response that will explain nicely to Chrome we don't do gzip, just send it to us the regular way?
We tried posting to the Google Chrome Troubleshooting forum with no response.
Any help would be greatly appreciated!
Best regards, Bert
You're looking in the wrong section for the error code: Section 14.11 of RFC 2616 specifies that you send a 415 (Unsupported Media Type) if you can't deal with the Content-Encoding.
这篇关于如何避开“Content-encoding gzip deflate” Chrome发送的标头？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
