views:

323

answers:

3

I'm developing a front-end to a Rails application. In cross-browser testing, I immediately discovered that Internet Explorer (apparently all modern versions, but at least IE 7 and IE 8) is not correctly interpreting a file I'm trying to load via AJAX (with jQuery) as JavaScript. A file download warning appears and the user needs to confirm that the file should be downloaded. Unfortunately, this is not acceptable for the purposes of the application.

I created a couple of test files; one is just a JavaScript file served from Amazon S3; the other is actually a resource URL served by Varnish/Rails. The latter is the one that triggers the warning. So:


LINK: URL that gives a warning in IE

REQUEST HEADERS:

Accept:     application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10

RESPONSE HEADERS:

Age:              1952
Cache-Control:    public, max-age=3598
Connection:       keep-alive
Content-Encoding: gzip
Content-Length:   2060
Content-Type:     text/javascript; charset=utf-8
Date:             Fri, 13 Nov 2009 22:54:18 GMT
Etag:             "272d9ec2e59aa92da18758cf42a4d729"
Server:           nginx/0.7.61 + Phusion Passenger 2.2.5 (mod_rails/mod_rack)
Status:           200 OK
Via:              1.1 varnish
X-Powered-By:     Phusion Passenger (mod_rails/mod_rack) 2.2.5
X-Runtime:        0.11573
X-Varnish:        176673116 176651738


LINK: URL that does not give a warning in IE

REQUEST HEADERS:

Accept:     application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_2; en-us) AppleWebKit/531.21.8 (KHTML, like Gecko) Version/4.0.4 Safari/531.21.10

RESPONSE HEADERS:

Age:              14
Connection:       keep-alive
Content-Encoding: gzip
Content-Length:   52
Content-Type:     text/javascript
Date:             Fri, 13 Nov 2009 22:55:03 GMT
Etag:             "7b7ded6696ee52551289c856d3173db4"
Last-Modified:    Fri, 13 Nov 2009 22:30:45 GMT
Server:           AmazonS3
Via:              1.1 varnish
X-Amz-Id-2:       CR79uoLC67sr0e0uj4CUOCoBQgcIW/jaJc/FNSA3zsK3Lns/gAqx98/T9h/UeJGm
X-Amz-Request-Id: BCF2F2D69F5126DD
X-Varnish:        1566212056 1566211955


What immediately sticks out to me is the Content-Type of "text/javascript; charset=utf-8" for the URL that gives a warning - is that valid? I had always assumed that only "text/javascript" would be valid.

Also, the URL that gives a warning returns content of Content-Type "text/javascript," but it is a Rails URL that does not have an extension of .js - could that make a difference?

Is there anything else that sticks out, or does anyone have any other ideas of what could be causing this problem? Thanks very much for any help.

A: 

First thing, I would try changing an extension to .js as you suggested. Internet Explorer has some nasty extension (among other things) based heuristics for determining document type.

It also sniffs the content in some cases, so the beginning should be typical for this type of a file (no weird characters, e.t.c.)

EFraim
Thanks EFraim. One of our Rails programmers changed the URL construction to include "index.js," and IE now recognized the document type as "JScript" - a step forward. However, that didn't fix the problem; using AJAX to load the file still brings up a file prompt to confirm the download, rather than it loading in the background. What else might be causing this?
Bungle
A: 

Make sure your JQuery statment looks something like this:

$.ajax({
  type: "GET",
  url: "test.js",
  dataType: "script"  // Defaults to HTML
});
reach4thelasers
A: 

It's been some time and I've since forgotten the details of this problem, but I do know that the ultimate cause was due to a POST request that returned a Content-Type of "text/javascript."

Apparently, IE interprets POSTs that return "text/javascript" in the response headers as a security threat, which causes it to display the dreadful, and terribly uninformative, error message bar.

We changed the Content-Type of the response to "text/html" and that solved it!

Bungle