最近an IE update似乎打破了我们的一些嵌入式设备配置软件。
嵌入式设备的空间受限，因此我们预先gzip所有大型资源，并使用Content-Encoding通知浏览器需要对资源进行gunzip。这在IE之前一直运行良好，今天在Firefox和Chrome中运行良好。显然，不支持gzip的浏览器不起作用，但它们很少见，我们不用担心它们。
似乎发生的事情是IE发出javascript请求并试图评估实际的gzip字节而不是gunzipping并评估javascript代码的字符。
我已经看过wireshark和mitmproxy中的请求，似乎没有什么不寻常的。以下是IE发送的请求和标题（使用mitmproxy记录）：
GET /extall.js.gz HTTP/1.1
Accept: application/javascript, */*;q=0.8
Referer: http://10.242.2.10:3001/index.htm
Accept-Language: en-US
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; rv:11.0) like Gecko
Accept-Encoding: gzip, deflate
Host: 10.242.2.10:3001
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache
然后这是响应数据，身体被删除（它是gzip压缩数据。）
HTTP/1.0 200 OK
Date: Wed, 27 Aug 2014 19:12:54 GMT
Server: Foo
Content-type: text/javascript; charset=utf-8
Content-Encoding: gzip
Content-Length: 203228
...
为了它的价值我用一些Perl代码掀起了一个基本的测试用例，用上面的标题说明，因为摆弄硬件很麻烦。据我所知，触发IE问题的最简单方法是将Content-Encoding标头设置为gzip，并事先gzip正文，而不是使用常规的mod_deflate或其他。
注意：IE要求申请/ javascript。我已经将我们的内容类型更改为投降，但它对此没有任何帮助。