Geek Answers Handbook

How to get around the "Content-encoding gzip deflate" header sent by Chrome?

We have a simple login form on our embedded web server. The web server is customizable due to severe memory limitations. Regardless of these restrictions, we like Chrome and would like to support it.

All browsers send an HTTP request to our login form containing the expected line "username = myname & password = mypass", but not Chrome. Instead, we receive from Chrome a request for a Content-encoding gzip deflate request. BTW, "all browsers", I mean that it has been tested to work perfectly in Internet Explorer version 9 beta, 8, 7, 6; Firefox version 4 beta, 3, 2; Opera 10, 9; Safari 5, 4, 3; and SeaMonkey 2.

Referring to the “14.2 Accept Charset” section of w3.org http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html , we tried to send HTTP 406 code to indicate that this server does not support this encoding in hoping Chrome will try again and publish the expected lines in a standard way. The 406 code returned by the web server is clearly displayed in the Chrome Inspect Element window, but it appears to be handled 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, the same result.

Is there a way around this behavior, either with client-side JavaScript, which will prevent Chrome from sending a request to “Skip gzip encoding”, or a server-side response that would perfectly explain Chrome, t do gzip, just send it to us in the usual way?

We sent a message to the Google Chrome troubleshooting forum with no response.

Any help would be greatly appreciated!

Regards, Bert

+5
source share
3 answers

You are looking for the wrong section for the error code: Section 14.11 of RFC 2616 indicates that you are sending 415 (Unsupported Media Type) if you cannot handle Content-Encoding.

+2
source

, chrome , chrome gzip. .

- / GET, , gzip, gzip . , ?

0

I tested this a bit with a simple Python script that was printed on stdout. I thought I had the same problem, but then I realized that I just forgot to reset stdout. It seems that Chrome always sends the request to the end of the headers before sending the contents of the request, and you need to use the second recv call to get the POST data. In contrast, an entire Firefox request is returned in a single recv call.

0
source

More articles:


All Articles