IE 声称无法识别 text/javascript MIME 类型
我们一直在开发 Ruby on Rails 应用程序。我们最近在使用 HTTPS 的 Apache 代理后面重新部署了该应用程序。
完成此操作后，我们的一位用户在尝试使用该应用程序时会被发送到以下页面： http://shell.windows.com/fileassoc/mimeassoc.asp?mime=text/javascript，其中写着：
MIME Type: text/javascript
Description: UnKnown
Windows does not recognize this MIME type.
有谁知道在什么情况下 IE 会声称不知道要做什么与一个text/javascript 文件？到目前为止只有这一位用户。
Windows 7 / IE 8 和 XPsp2 / IE8
编辑 添加 IE barfs 上的完整 HTTP 响应
HTTP/1.1 200 OK
Date: Mon, 24 Oct 2011 00:31:27 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.9
ETag: "a6d7d64e3ca943eabc73db920baa7d76"
Cache-Control: max-age=0, private, must-revalidate
X-UA-Compatible: IE=Edge,chrome=1
X-Runtime: 0.003257
Status: 200
Content-Type: text/javascript; charset=utf-8
Connection: close
window.location.href='https://xx.xx.org.au/AED/sessions/new'
We have been developing a Ruby on Rails application. We have recently re-deployed this application behind an Apache proxy which uses HTTPS.
Since we've done this one of our users gets sent to the following page when trying to use the app: http://shell.windows.com/fileassoc/mimeassoc.asp?mime=text/javascript, which says:
MIME Type: text/javascript
Description: UnKnown
Windows does not recognize this MIME type.
Does anyone know under what circumstances IE would claim not to know what to do with a text/javascript file? It's just this one user so far.
Windows 7 / IE 8 and XPsp2 / IE8
EDIT Adding the full HTTP response that IE barfs on
HTTP/1.1 200 OK
Date: Mon, 24 Oct 2011 00:31:27 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: Phusion Passenger (mod_rails/mod_rack) 3.0.9
ETag: "a6d7d64e3ca943eabc73db920baa7d76"
Cache-Control: max-age=0, private, must-revalidate
X-UA-Compatible: IE=Edge,chrome=1
X-Runtime: 0.003257
Status: 200
Content-Type: text/javascript; charset=utf-8
Connection: close
window.location.href='https://xx.xx.org.au/AED/sessions/new'
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
您应该尝试
application/javascript。You should try
application/javascript.好的。看来我们已经弄清楚了。我们的应用程序中存在一个错误，导致它向浏览器发送一些无效的 JavaScript。 Rails 似乎通过发送一个如下所示的小 JS 片段来处理未经身份验证的会话到登录页面的重定向：
我们在这个文件的 ERB 中有一个拼写错误，导致它发送这个：
有趣的是，只有某些版本的 IE 才能获得对此感到困惑。
Ok. Looks like we've figured it out. It was an error in our application that caused it to send some invalid JavaScript to the browser. It seems Rails handles redirects of unauthenticated sessions to the login page by sending a little JS fragment that looks like this:
We had a typo in the ERB for this file that made it send this instead:
What's interesting is that only some versions of IE get confused by this.
IE 应该识别 text/javascript (参见 例如，其中提到了“text/javascript”）。一定有其他因素在起作用。您可以尝试：
（1）您可以直接在脚本标签中指定类型
（2）JavaScript是否来自具有相同协议的同一站点？用户可能会阻止来自不安全地址的不安全内容，并且 IE 可能只会向您提供误导性的错误消息。
(3) 因为你现在支持 apache，所以还有其他可能让 IE 感到困惑的标头吗？
(4) 我打赌您检查过 Rails 是否设置了正确的资源位置（即它使用代理主机、apache，而不是 Rails）。
IE should recognise text/javascript (see for example, 'text/javascript' is mentioned there). Other factors must be at play. You may try:
(1) you can specify the type directly in the script tag
(2) Is the javascript coming from the same site with same protocol? The user may block content that is not secured when coming from a unsecured address and IE may be just given you a misleading error message.
(3) Because you are now behind apache, are any other headers there that may be confusing IE?
(4) I bet you checked that Rails sets the right location for resources (i.e. it uses the proxy host, apache, not rails).
http 响应标头是否指定 X-Content-Type-Options: nosniff？
如果是这样，ie9 将不会执行任何脚本，直到您这样做
do the http response headers specify X-Content-Type-Options: nosniff?
if so, ie9 will not execute any script until you do so
我怀疑你的 javascript 内容要么不正确，要么只是“IE”不正确。 :-)
首先，如果您说它是 UTF-8，您确定这就是您所提供的服务吗？根据 Brad 的建议，删除字符集定义并查看行为是否发生变化。
还要获取正在返回的 javascript 的副本，并尝试在某处验证它。我看到其他人报告了 JavaScript 以某些特定方式损坏的问题，导致仅某些版本的 IE 崩溃。您是否连接多个js文件或类似的文件？另一个例子是意外的 %> javascript 文件中的标签会使某些浏览器感到困惑。
通过使用 firebug 或 chrome 开发人员工具获取客户端返回的值，您可以确保代理不会搞乱标头或编码（包括 gzip）。
我还听说某些旧版本的 IE 无法在 iframe 中正确处理 mimetypes。您使用 iframe 吗？
最后但并非最不重要的一点是，某些防病毒/安全软件会修改传出请求的 Accept 标头（不是很好吗？），欺骗服务器认为浏览器不支持 gzip 或其他内容。您能获取 javascript 的传出请求的副本吗？您想要检查修改的请求标头。
My suspicion is that your javascript content is either not correct, or just not "IE" correct. :-)
First of all, if you are saying its UTF-8 are you certain this is what you are serving? In line with Brad's advice, drop the charset definition and see if the behavior changes.
Also grab a copy of the javascript being returned and try to validate it somewhere. I've seen others report issues where the javascript was corrupted in certain specific ways that caused only certain versions of IE to break. Are you concatenating multiple js file or anything like that? Another example is an accidental %> tag in your javascript file will confuse some browsers.
By grabbing the returned value client side using firebug or chrome developer tools you can be sure the proxy isn't screwing up the headers or the encoding (including gzip).
I've also heard that certain older versions of IE don't handle mimetypes properly in iframes. Are you using an iframe at all?
Last but not least, some antivirus/security software will modify the outgoing request Accept headers (not very nice is it?) tricking the server into thinking the browser doesn't support gzip or something. Can you grab a copy of the outgoing request for the javascript? You want to check for modified request headers.
您可以删除
script标记的type属性。 HTML5 不需要它，所有浏览器都将其理解为“它们本地风格的 JavaScript”，这正是您想要的。您的页面不会根据 HTML4 文档类型进行验证，但只要您知道它不验证的原因，我认为就可以了。工作比验证更重要。You can drop the
typeattribute of thescripttag. HTML5 does not require it, and all browsers understand it to be "their local flavour of JavaScript", which is what you want. Your page won't validate against the HTML4 doctype, but as long as you know why it isn't validating, I think that's okay. More important to work than to validate.http://shell.windows.com/fileassoc/mimeassoc.asp?mime =笑话/诡计问题
http://shell.windows.com/fileassoc/mimeassoc.asp?mime=joke/trickquestion