[1.7.x] Galaxy + CloudFront CDN = Refused to execute Meteor bundled code because its MIME type ('text/html') is not executable

deployment
1

Hi,

We updated yesterday our code to the last version of Meteor 1.7 and when we deploy to Galaxy an error appears in the browser (Chrome and Firefox tested).

Refused to execute script from "https://xxxx.cloudfront.net/371890059e93ce15eb387a53a7f0bf59486de356.js?meteor_js_resource=true&_g_app_v_=434" because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.

Maybe we need to change MIME Type but it’s the js code bundled by Meteor and with the version 1.6.1 it is working correctly. If we stop Cloudfront the web runs normally.

Any idea? How can we change MIME Type for Meteor js bundle, to sometihing like:

header('Content-type: application/javascript; charset=utf-8');

Thanks

2

I got the same, but with CSS just now

Resource interpreted as Stylesheet but transferred with MIME type text/html: “https://xxxxxx.cloudfront.net/xxxxx?meteor_css_resource=true&g_app_v=5”.

And I am still running 1.6.1. Could be a cloudfront issue?

3

That means Cloudfront has cached the file on the edge before it has returned its real content. Either run an invalidation on the file or enable query string forwarding + caching.

4

We have invalidated all files and nothing changed.

5

Did you invalidate just the file or the whole URL including query string?

6

Just the files.

It is strange. When we deploy the Meteor 1.6.1 version to the same Galaxy domain with the same CloudFront distribution the platform works normally…

The version that do not work is the same code updated to Meteor 1.7.

7

Try invalidating the entire URL, that might help.

8

We have invalidated the URL but so far nothing has changed.

Thank you for your answer

9

Hi @jorgeer, have you fixed the error?

11

Unfortunately not, I disabled cloudflare on that app, so that “fixed it”, but it is a bad temporary workaround.

12

@jorgeer Sorry, are you using Galaxy?

You are using Cloudflare, don’t you? We are using Cloudfront. Maybe it’s an error with Meteor or Galaxy MIME type.

Thanks

13

D’oh, no, I’m also using Cloudfront, I’m just mixing them up. And I’m using galaxy, yes.

14

I was seeing a similar error with Galaxy + CloudFlare (w/o CloudFront). It stemmed from us invalidating the CF cache, thus removing JS & CSS assets with long URLs with query strings unique to the particular build; meanwhile if the HTML is cached anywhere else in the chain, including in a browser somewhere, it would refer to the old, invalidated asset that would then return 'text/html' via Meteor returning a 404 page.

If you’ve verified that the URL in question is in fact returning valid JS or CSS with the wrong MIME type, it’s probably a CF configuration issue. Otherwise, you might need to change your invalidation settings to have longer TTLs for JS & CSS than for HTML.

15

Hi,

We don’t know why but last update to 1.7.0.3 solved the problem.

Anyway, thanks!

2 Likes