MIME type ('text/html') not a supported stylesheet MIME type

alwaysblank · February 20, 2018, 9:16pm

Do you see your stylesheet when you go to http://localhost:3000/app/themes/twinllamas/dist/styles/main.css? Google search suggests that many people with this error are seeing it because that URL is actually returning an error page, not a stylesheet.

builtbyvern · February 20, 2018, 9:28pm

I get a 404 when I try to view it because the server refuses to send it. I have confirmed that my stylesheet does exist in my dist folder though.

alwaysblank · February 20, 2018, 11:27pm

The browser will always return a 404 for style.css when you run yarn start because it uses webpack to inject styles directly into the page. The file in your dist folder is probably one left over from running yarn build. The specific error you’re seeing seems new. This workaround may work for you: Enable CSS build when watching · Issue #1826 · roots/sage · GitHub

Some other discussions:
https://discourse.roots.io/t/sage-9-main-css-404-on-devurl/9799/33
https://discourse.roots.io/t/consequences-of-absent-main-css-with-yarn-start-sage-9/10755/3

mikesource · February 22, 2018, 12:51pm

Just got the same error but with Sage 8…

builtbyvern · February 22, 2018, 5:46pm

It’s honestly really frustrating. I wanted to get into Trellis, but as a solo developer I don’t have days on end to wait for a solution.

I ran yarn build before yarn start. Maybe I’m crazy but it’s not that the file doesn’t exist. It’s that the server is serving the stylesheet as wrong MIME type. If I was using a different theme or product, I’d understand, but I expect Trellis, Bedrock and Roots to play nicely together out of the box.

MWDelaney · February 22, 2018, 7:39pm

Hi,
We all do our best to respond to support threads as our time and expertise allows. As I’m sure you understand, we all have day-jobs as well which can sometimes keep us away from the forum for longer than we’d wish.

To your problem, reviewing this thread…

I see that the problem appears in Chrome --does it appear in other browsers as well?
Have you tried destroying and re-creating your Trellis VM?
Another user mentions the problem on a Mac, but I don’t see where you’ve indicated a platform. Are you also on a Mac?
Have you tried another theme? If Trellis has a MIME type problem with Sage’s .css files, then other themes should show the same problem.

We hope we can help you nail down this issue. Thanks for working with us.

davidohlin · March 6, 2018, 7:30am

We’re experiencing the same issue, so I’ll try to answer these questions.

I see that the problem appears in Chrome --does it appear in other browsers as well?
Having the same issues in Chrome (version 64.0.3282.186) and Safari (version 11.0.3). Safari gives a different error message, saying that the file doesnt exist:
Failed to load resource: the server responded with a status of 404 (Not Found)

Have you tried destroying and re-creating your Trellis VM?
Yes, It didn’t help.

Are you also on a Mac?
Yes, macOS High Sierra 10.13.3.

Have you tried another theme?
I threw in Html5blank and I do not get the same error.

MWDelaney · March 6, 2018, 3:44pm

Okay, first and most importantly:

Error messages about `main.css` while running `yarn start` (or `yarn run start`) are normal, expected, and by design.

This happens because main.css actually doesn’t exist while running yarn start. Instead, styles are built in memory and injected into the page by Webpack. Errors related to main.css in the browser console can and should be safely ignored while running yarn start.

If you are running `yarn start` and your page/site looks unstyled in the browser

This can happen sometimes. It’s inconsistent and seems to have something to do with the imperfect software that “shares” your local theme development directory with the Vagrant box. You can fix it either by making a change to, and saving, any .scss file, or hard-refreshing the page (with SHIFT+Refresh), or sometimes both.

If the missing `main.css` file message persists after running `yarn build` or `yarn build:production`

Make sure you’re not refreshing your page WHILE the yarn task is running. Sage versions its assets and browsers are really reluctant to give up on caches of stylesheets. Let yarn finish its task, wait a beat, and then refresh your browser.

Let us know if any of that helps.

craigpearson · March 26, 2018, 7:28pm

Woops, it would seem that my previous post isn’t valid. I’m now getting this error consistently. I’ve tracked this down to yarn dependancies as existing projects which have cached dependancies on a different machine work fine. This is a Sage / WebPack issue specifically. Unfortunately I don’t have time to investigate this deeper today, but crudely copying node_modules from another project pre February works for me.

I’ll try to find some time later in the week to provide anymore information

krishaamer · March 29, 2018, 12:45pm

+1

Also seeing this in Chrome 65 using Trellis + Bedrock + Sage 9.

craigpearson · March 30, 2018, 2:12am

Hey,

So after a lot of trial and error and comparing some projects with the very useful Mac app Kaleidoscope I’ve managed to track this down to a Trellis issue as first assumed. Or at least the HBP5 dependancy paired with a Chrome update

Issue

The issue lies in the extra security directives applied by the HBP5 nginx configuration. This is included in Trellis here:

github.com

roots/trellis/blob/e43b15def1c1a2d404362d360d200dd5ca3b6023/roles/wordpress-setup/templates/wordpress-site.conf.j2#L135


  try_files $uri $uri/ /index.php?$args;
}
{% endblock %}


{% block h5bp -%}
{% if h5bp_cache_file_descriptors_enabled -%}
include h5bp/directive-only/cache-file-descriptors.conf;
{% endif -%}


{% if h5bp_extra_security_enabled -%}
include h5bp/directive-only/extra-security.conf;
{% endif -%}


{% if h5bp_no_transform_enabled -%}
include h5bp/directive-only/no-transform.conf;
{% endif -%}


{% if h5bp_x_ua_compatible_enabled -%}
include h5bp/directive-only/x-ua-compatible.conf;
{% endif -%}

Looking at the HBP5 config file you can see that only CSS from the same source is trusted by a Content-Security-Policy directive here:

github.com

h5bp/server-configs-nginx/blob/c5c6602232e0976d9e69d69874aa84d2a2698265/h5bp/directive-only/extra-security.conf#L17


add_header X-Content-Type-Options nosniff always;


# The X-XSS-Protection header is used by Internet Explorer version 8+
# The header instructs IE to enable its inbuilt anti-cross-site scripting filter.
add_header X-XSS-Protection "1; mode=block" always;


# with Content Security Policy (CSP) enabled (and a browser that supports it (http://caniuse.com/#feat=contentsecuritypolicy),
# you can tell the browser that it can only download content from the domains you explicitly allow
# CSP can be quite difficult to configure, and cause real issues if you get it wrong
# There is website that helps you generate a policy here http://cspisawesome.com/
# add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' https://www.google-analytics.com;" always;

Recent security updates to webkit browsers (Safari / Chrome) mean that although these settings have been lying dormant for a while in the HBP5 directives they’ve only just started being applied with the recent releases of browsers. Combined with updates of Trellis.

How to reproduce

Latest version of the roots stack
Latest version of Chrome / Chrome Beta
Run yarn run start - issue will occur as localhost:3000 is not seen as the same domain as your site URL

Fix

As we don’t need this in our development environment I’d suggest that we disable the HBP5 extra security directives on development.

Change highlighted line from

github.com

roots/trellis/blob/e43b15def1c1a2d404362d360d200dd5ca3b6023/roles/wordpress-setup/templates/wordpress-site.conf.j2#L134


location / {
  try_files $uri $uri/ /index.php?$args;
}
{% endblock %}


{% block h5bp -%}
{% if h5bp_cache_file_descriptors_enabled -%}
include h5bp/directive-only/cache-file-descriptors.conf;
{% endif -%}


{% if h5bp_extra_security_enabled -%}
include h5bp/directive-only/extra-security.conf;
{% endif -%}


{% if h5bp_no_transform_enabled -%}
include h5bp/directive-only/no-transform.conf;
{% endif -%}


{% if h5bp_x_ua_compatible_enabled -%}
include h5bp/directive-only/x-ua-compatible.conf;
{% endif -%}

To

# Only apply extra security outside dev to avoid proxy CSP issues
{% if h5bp_extra_security_enabled and not_dev -%}
include h5bp/directive-only/extra-security.conf;
{% endif -%}

The not_dev helper is already configured here:

github.com

roots/trellis/blob/e43b15def1c1a2d404362d360d200dd5ca3b6023/roles/wordpress-setup/defaults/main.yml#L41


nginx_skip_cache_uri: /wp-admin/|/wp-json/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap(_index)?.xml
nginx_skip_cache_cookie: comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in


# Nginx includes
nginx_includes_templates_path: nginx-includes
nginx_includes_deprecated: roles/wordpress-setup/templates/includes.d
nginx_includes_pattern: "^({{ nginx_includes_templates_path | regex_escape }}|{{ nginx_includes_deprecated | regex_escape }})/(.*)\\.j2$"
nginx_includes_d_cleanup: true


# h5bp helpers
not_dev: "{{ env != 'development' }}"
h5bp: "{{ item.value.h5bp | default({}) }}"
h5bp_cache_file_descriptors_enabled: "{{ h5bp.cache_file_descriptors | default(not_dev) }}"
h5bp_extra_security_enabled: "{{ h5bp.extra_security | default(true) }}"
h5bp_no_transform_enabled: "{{ h5bp.no_transform | default(false) }}"
h5bp_x_ua_compatible_enabled: "{{ h5bp.x_ua_compatible | default(true) }}"
h5bp_cache_busting_enabled: "{{ h5bp.cache_busting | default(false) }}"
h5bp_cross_domain_fonts_enabled: "{{ h5bp.cross_domain_fonts | default(true) }}"
h5bp_expires_enabled: "{{ h5bp.expires | default(false) }}"
h5bp_protect_system_files_enabled: "{{ h5bp.protect_system_files | default(true) }}"

Although @swalkinshaw may have some better solutions? My concern about this condition is that it will undo environment parity and may cause more issues in the support forum. If you’d like a hand with this Scott I’d love to raise my first PR if you can offer your thoughts on this proposed fix?

Important After applying the above fix you should run a vagrant provision in your affected projects. Also be mindful that this would mean you won’t be aware of similar CSP issues in your development environment yet they may appear on staging / production

EDIT As per comments below the root of this issue doesn’t appear to be CSP related, however the fix provided does still work

cc @krishaamer, @davidohlin, @builtbyvern, @mikesource, @asuh, @rmendoza

swalkinshaw · March 30, 2018, 3:07am

At this first this appeared promising, but the line in the extra-security config you linked is commented out.

I just checked on a brand new Vagrant/Trellis provision and that line is commented out too:

# The X-Frame-Options header indicates whether a browser should be allowed
# to render a page within a frame or iframe.
add_header X-Frame-Options SAMEORIGIN always;

# MIME type sniffing security protection
#       There are very few edge cases where you wouldn't want this enabled.
add_header X-Content-Type-Options nosniff always;

# The X-XSS-Protection header is used by Internet Explorer version 8+
# The header instructs IE to enable its inbuilt anti-cross-site scripting filter.
add_header X-XSS-Protection "1; mode=block" always;

# with Content Security Policy (CSP) enabled (and a browser that supports it (http://caniuse.com/#feat=contentsecuritypolicy),
# you can tell the browser that it can only download content from the domains you explicitly allow
# CSP can be quite difficult to configure, and cause real issues if you get it wrong
# There is website that helps you generate a policy here http://cspisawesome.com/
# add_header Content-Security-Policy "default-src 'self'; style-src 'self' 'unsafe-inline'; script-src 'self' https://www.google-analytics.com;" always;

Note the last line starts with #.

swalkinshaw · March 30, 2018, 3:12am

CSP also has very specific and explicit errors. It would say it’s denied due to CSP, not a Mime type error.

craigpearson · March 30, 2018, 3:13am

This could potentially be this line:

add_header X-Content-Type-Options nosniff always;

Apologies it’s late here in the UK (4am)

If you run a test locally you’ll see the errors stop in Chrome / Safari. I’ve tried this on existing projects and new. Admittedly my reference to CSP is sleep deprived me getting all excited about fixing something

Twansparant · March 30, 2018, 8:22am

Thanks for your deep research! I was also running into this error (mainly in Chrome, but later also in Safari) and couldn’t figure out what was going on.

I ssh’d into my Vagrant box and commented out the line:

add_header X-Content-Type-Options nosniff always;

in: /etc/nginx/h5bp/directive-only/extra-security.conf

And I can confirm the error disappears in Chrome & Safari!
Nice work

swalkinshaw · March 30, 2018, 4:47pm

Okay now that makes sense

Blocks a request if the requested type is “style” and the MIME type is not “text/css”

Disabling this in Trellis would certainly fix it, but I’d hope that it can be fixed in Sage itself. If a CSS file is being served, it should have the text/css MIME type.

evance · April 9, 2018, 2:48pm

Same issue experienced here…

I opened an issue over at the sage repo.

Muhaki · September 13, 2018, 12:26pm

I’ve noticed that when you run Yarn build the dist folder will create styles folder and css files. But when you run Yarn start it will delete styles folder (but still keep scripts folder) inside dist. Can this be something? I’ve got the same issue right now, and not really aware of how to fix it. Tried the solution above, and it removed the Error with MIME bla bla. But got a new error that says mine .css files could not be found.

MWDelaney · September 13, 2018, 1:51pm

Are you experiencing a problem, or just the error message while running start?

start runs Browsersync which compiles styles and javascript in memory and injects them into the page while you work, so you can see your changes automatically. This can sometimes freak out your browser and throw some error messages, but as long as nothing is visually or functionally broken you should be fine ignoring those messages during development.

Muhaki · September 13, 2018, 2:18pm

Its just an error, i am still seing styles and etc

MIME type ('text/html') not a supported stylesheet MIME type

Error messages about main.css while running yarn start (or yarn run start) are normal, expected, and by design.

If you are running yarn start and your page/site looks unstyled in the browser

If the missing main.css file message persists after running yarn build or yarn build:production

Issue

How to reproduce

Fix

Error messages about `main.css` while running `yarn start` (or `yarn run start`) are normal, expected, and by design.

If you are running `yarn start` and your page/site looks unstyled in the browser

If the missing `main.css` file message persists after running `yarn build` or `yarn build:production`