New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 46 users

Issue metadata

Status: WontFix
Owner:
OOO, sick family
Closed: Mar 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Strict MIME type checking prevents JavaScript served as 'text/plain' from executing.

Reported by l...@lxe.co, Mar 4 2013 Back to list

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.32 (KHTML, like Gecko) Chrome/27.0.1425.0 Safari/537.32

Steps to reproduce the problem:
1. Navigate to http://akdubya.github.com/dustjs/benchmark/index.html
2. Open console
3. Examine errors

What is the expected behavior?
Scripts should load and execute.

What went wrong?
JavaScript files are blocked from executing with the following error messages:

Refused to execute script from 'http://github.com/wycats/handlebars.js/raw/766497bb553a926c046c5e5b50ee35529d168ba5/lib/handlebars.js' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled. index.html:1
Refused to execute script from 'http://github.com/janl/mustache.js/raw/master/mustache.js' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled. index.html:1
Refused to execute script from 'http://github.com/jquery/jquery-tmpl/raw/master/jquery.tmpl.js' because its MIME type ('text/plain') is not executable, and strict MIME type checking is enabled. 

Did this work before? Yes Possibly before 2013-02-11

Chrome version: 27.0.1425.0  Channel: dev
OS Version: OS X 10.8.2

I agree that content owners should provide proper content-type headers, but preventing scripts served with an erroneous header from executing is unnecessary.
 

Comment 1 Deleted

Comment 2 by l...@lxe.co, Mar 4 2013

I've made a simple test file. I hope this helps:

http://lxe.co/strict-mime.html
Cc: nyerramilli@chromium.org
Labels: -Pri-2 -Type-Bug Pri-1 Type-Regression Mstone-27 Area-WebKit
Status: Untriaged
Tested with URL 'http://lxe.co/strict-mime.html' - Able to repro this issue on Macbook pro 10.8.2 with canary 27.0.1429.0,Dev 27.0.1425.0

Bisect info :

You are probably looking for a change made after 182110 (known good), but no later than 182122 (first known bad).
WEBKIT CHANGELOG URL:
  http://trac.webkit.org/log/trunk/?rev=142684&stop_rev=142637&verbose=on&limit=10000
CHANGELOG URL:
  http://build.chromium.org/f/chromium/perf/dashboard/ui/changelog.html?url=/trunk/src&range=182110%3A182122

ubuntu 12.10 with Chrome Dev 27.0.1425.0 also has this bug

need fix asap!

Comment 6 Deleted

Comment 7 by l...@lxe.co, Mar 5 2013

I think the strict type checking should only be enabled if 'X-Content-Type-Options: nosniff' is set, and not by default.
Labels: ReleaseBlock-Beta

Comment 9 by sas...@tape.io, Mar 5 2013

Can confirm for Mac OSX 10.8.2 / Chrome Version 27.0.1425.0 dev ...

This breaks a lot of pages, for example those which load js files from github.

Comment 10 by kareng@google.com, Mar 6 2013

Cc: abarth@chromium.org
Owner: mkwst@chromium.org
Status: Assigned
i am guessing http://trac.webkit.org/changeset/142683 mike?
Cc: tsepez@chromium.org scarybea...@gmail.com
GitHub does in fact serve assets from `raw.github.org` with a `X-Content-Type-Options: nosniff` header. Chrome matches the behavior of IE8, 9, and 10 on this page, and Gecko will match if/when they fix https://bugzilla.mozilla.org/show_bug.cgi?id=471020.

I've had conversations with GitHub folks about this issue in particular; they don't actually want folks serving files from raw.github.org, which is why they serve resources with the 'nosniff' header. They'd prefer that you set up something on GitHub Pages.

If we want this security feature, and I believe we do, this is an expected consequence.

Comment 12 Deleted

Comment 13 by l...@lxe.co, Mar 6 2013

Sorry guys, looks as though I didn't examine the headers completely. I used the Chrome development console, which possibly omits some of the headers.

< HTTP/1.1 200 OK
< Date: Wed, 06 Mar 2013 16:32:12 GMT
< Server: GitHub.com
< Content-Type: text/plain; charset=utf-8
< Status: 200 OK
< X-RateLimit-Limit: 100
< X-RateLimit-Remaining: 100
< X-Frame-Options: deny
< X-Content-Type-Options: nosniff
< Content-Disposition: inline
< Content-Transfer-Encoding: binary
< X-Runtime: 15
< ETag: "b58e92aa7a78de6439385c19e58a95a0"
< Via: 1.1 varnish
< Content-Length: 69641
< Accept-Ranges: bytes
< Via: 1.1 varnish
< Age: 0
< X-Served-By: cache-v25-ASH
< X-Cache: MISS
< X-Cache-Hits: 0
< Vary: Accept-Encoding
< Cache-Control: private

There is indeed a 'X-Content-Type-Options: nosniff' header. In that case, this issue is invalid.
Status: WontFix
Thanks for taking another look!

I'm closing this out as WontFix, but I do think we need to fairly closely monitor whether or not this change breaks more of the web than we expect it to. If you see related errors, please do let us know.
It seems to break gchat inside google plus as https://talkgadget.google.com/talkgadget/js?name=lite&am=!fBmxK3Da63kJhSKU-I8&ver=RrS9crbocm0.lo.en..&jsmode=lo.en..&zd=qc has a content-type of text/plain

Comment 16 by Deleted ...@, Mar 8 2013

Is there a way to temporarily disable strict type checking? I get why github wants to discourage this practice but it's really useful when you're trying to reference a specific commit in a jsfiddle...
> Is there a way to temporarily disable strict type checking?

Nope.  It's up to GitHub to define how it wants its content to be used.  In this case, it's telling the browser that it doesn't want its content used in this way.
Project Member

Comment 18 by bugdroid1@chromium.org, Mar 9 2013

Labels: -Webkit-JavaScript -Type-Regression -Mstone-27 -Area-WebKit Cr-Content Type-Bug-Regression Cr-Content-JavaScript M-27

For those wanting GitHub raws to just work, check out http://rawgithub.com/ /ht @yaypie @kangax
Project Member

Comment 20 by bugdroid1@chromium.org, Apr 5 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 21 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content-JavaScript Cr-Blink-JavaScript
This bug has a release block of beta but this bug is currently present in Chrome OS beta.

Comment 23 by mkwst@chromium.org, Apr 18 2013

Labels: -ReleaseBlock-Beta
This behavior is working as intended, as discussed above. Dropping the release blocking flag for clarity, thanks for the heads up.

Comment 24 by mkwst@chromium.org, Apr 19 2013

 Issue 232327  has been merged into this issue.

Comment 25 by Deleted ...@, Jun 16 2013

If you really want to get files from github, or any other page that gives X-Content-Type-Options: nosniff. You can use this peace of code: 
'''
<?php

$lessjs = file_get_contents("https://raw.github.com/cloudhead/less.js/master/dist/less-1.3.3.min.js");

header("Content-Type: text/javascript");
print($lessjs);
'''

Comment 26 by math...@qiwi.be, Aug 23 2013

An online service that does what comment #25 suggests is <http://rawgithub.com/>.

Comment 27 by Deleted ...@, Aug 28 2013

Refused to execute script from 'https://code.google.com/apis/youtube/dashboard/gwt/com.google.youtube.frontend.partner.ui.client.DeveloperApp.nocache.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled. index.html:1

Whitch is from link https://code.google.com/apis/youtube/dashboard/gwt/index.html
Strange, it's google's site)

Comment 28 by Deleted ...@, Oct 7 2013

I have the issue with local resources using as:
<script type="text/javascript" src="/res/js/util.js"></script>
I got message:
Refused to execute script from 'http://localserver/res/js/util.js' because its MIME type ('application/octet-stream') is not executable, and strict MIME type checking is enabled.
IE 8 & 9 working good.
If I were king of the Chrominauts, I would have:

*  Made this optional - strict MIME type enforcement or not, at the user's discretion.
*  If not strict, show a warning message
I guess I can't edit my past comment... Just wanted to add that this broke our site.  Don't get me wrong, I'm glad to set the correct MIME type from our server for JavaScript files (and everything else too).  It was just inconvenient that we were suddenly forced to do this.

Comment 31 by vmakh...@gmail.com, Nov 27 2013

I think this should be optional
But on by default I think
Make it optional as my wish, for dev use.
> Make it optional as my wish, for dev use.

It is optional.  The way you opt-in is by sending this header:

X-Content-Type-Options: nosniff
The rule also applies to local (file://) content without any HTTP header.
... and that behavior is apparently not affected by --allow-file-access-from-files.
> The rule also applies to local (file://) content without any HTTP header.

Would you be willing to file a separate bug about that?  That sounds like something we want to fix.
Thanks, I mean will this be an option which I can toggle in
Chrome/Chromium settings.
> Thanks, I mean will this be an option which I can toggle in
> Chrome/Chromium settings.

It's very unlikely we would add such an option.
Would a command line flag be better?
> Would a command line flag be better?

No.
I request this to be open again, users should have control over their browser and should be free to execute the scripts if explicitly asked.
@heavy.l..... I agree - I would like to use a browser that I have full
control over.

Comment 44 by d.cor...@webu.fr, May 7 2014

For dev, it's usefull to have a script hosted in local, (file://) or on a gitlab / github. +1
I'd like something to disable this as well. I don't use github scripts on my website, but I use it for something entirely different: bookmarklets for use on IRCCloud (https://www.irccloud.com). Specifically, I used a script hosted on github's gist service to grab my "now playing" song from Last.fm, and then look up the song information on Spotify, and then post the song info along with a spotify URI in the channel.

It's a bummer that github wants to act that way, but I think that users should have the right to override something their own browser is doing. A setting like this doesn't even have to be in chrome://settings. It could be in a much lower end area. I personally don't mind having a command line flag, but I think this is too extreme.

For the past 3 weeks I've been trying to figure out what happened to my song scripts, and I finally found this issue report that describes exactly what I see. Amazing to see that most, if not all, of this is connected to github.

For my use case, it makes no sense for me to make a github pages website, just to host a script that I use as a bookmarklet.

Chrome devs, please take this feedback and consider it. It's very sad that I have to now figure out something else for my bookmarklet scripts. Having a client side way to enable this feature would be very (and I mean very) much appreciated.
Absolutely agree, users should have ultimate control of how their browser reacts. Plus this helps with web dev.
Perhaps it could be a command line flag, or a setting on "chrome:flags"?

This would help prevent the purpose of the strict MIME type checking from
being defeated.
Cc: -abarth@chromium.org

Comment 49 by Deleted ...@, Jul 24 2014

This is really strange setting..This is happening with cross-domain Ajax calls as well when the response type is not a JSON. The same code is working fine in FireFox and breaking in Chrome. Unfortunately We don't find any work around (except building a proxy).
I'm also looking for something in chrome:flags to change settings for this and allow me to load scripts from Gihub for dev purposes. I vote for this.
@#50: rawgit.com? Or Github Pages?

Sign in to add a comment