最近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以顺从它,但这并没有解决问题。