Why won't Internet Explorer 11 decode this javascript?

Question

Recently an IE update seems to have broken some of our embedded device configuration software.

The embedded device is very space constrained so we pre-gzip all of our large resources and use Content-Encoding to inform the browser that it needs to gunzip the resource. This has always worked fine in IE before and works fine in Firefox and Chrome today. Obviously browsers that do not support gzip will not work, but they are rare enough that we don't worry about them.

What seems to happen is that IE makes the request for the javascript and the tries to evaluate the actual gzip bytes instead of gunzipping and evaluating the characters that are javascript code.

I've looked at the requests in wireshark and mitmproxy and nothing seems too out of the ordinary. Here are the request and headers that IE is sending (recorded with 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

And then here is the response data, with the body elided (it is gzipped data.)

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

...

For what it's worth I whipped up a basic test case, illustrated with the headers above, with just some Perl code, because fiddling with the hardware is a hassle. As far as I can tell, the easiest way to trigger the issue with IE is to set the Content-Encoding header to gzip and just gzip the body beforehand instead of using regular mod_deflate or whatever.

NOTE: IE asks for application/javascript. I've changed our content-type to capitulate and it doesn't help with this.

Answer 1

So it turns out that this is a bug in IE. The workaround is to remove the .gz from the path. WAH WAH.