3
最近an IE update似乎已經打破了我們的一些嵌入式設備配置軟件。爲什麼Internet Explorer 11不能解碼這個javascript？
嵌入式設備空間非常有限，所以我們預先壓縮了我們所有的大型資源，並使用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
然後這裏的響應數據，與主體消隱
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
...
對於（它是gzip壓縮數據）。值得一提的是，我用一些Perl代碼掀起了一個基本的測試用例，用上面的頭文件說明，因爲擺弄硬件是一件麻煩事。據我所知，觸發IE問題的最簡單方法是將Content-Encoding標頭設置爲gzip，並且只是預先gzip body，而不是使用常規的mod_deflate或其他。
注意：IE要求申請/ javascript。我已經將我們的內容類型改爲投降，並且對此沒有幫助。