最近IE更新似乎破坏了我们的一些嵌入式设备配置软件。
由于嵌入式设备空间非常有限，因此我们对所有大型资源进行预压缩，并使用Content-Encoding来通知浏览器需要解压缩该资源。在IE之前，这总是很好地工作，并且今天在Firefox和Chrome中也能正常工作。显然，不支持gzip的浏览器将无法工作，但它们很少，我们不必担心。
似乎发生的情况是IE请求javascript并尝试评估实际的gzip字节，而不是解压缩并评估作为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要求application/javascript。 我已更改我们的content-type以顺从它，但这并没有解决问题。