disable chrome strict MIME type checking on local dev

Question

I have a CSS file that my local dev server (webpack) is serving up with apparently the wrong mime type.

Refused to apply style from 'http://localhost:10001/font-awesome/css/font-awesome.min.css' 
because its MIME type ('text/html') is not a supported stylesheet MIME type, 
and strict MIME checking is enabled.

Is there anyway to disable this? I assume it's a chrome setting. At least for a specific host.

Digging into the webpack config, if it doesn't do something basic like this is usually an exercise in frustrating yak shaving.

Most other answers refer to ways of fixing the server. I just want to hack this client side since the server is being stubborn.

related:

• Disable Chrome strict MIME type checking
• Link and execute external JavaScript file hosted on GitHub

Answer 1

Your question is from a while ago, but ranks well on Google for this problem so I wanted to chip in with a couple pointers.

It might be an HTTP/404 in disguise

The error message is probably just misleading you. It's unfortunate that Google Chrome removes the response entirely, even the preview of the "Network" dev panel.

The MIME type might be incorrect because the server is answering with an HTTP 404 message.
To test: Open the URL to the CSS file in the browser directly, or fetch it with a tool like wget.

Have you checked if the path is correct? Depending on your configuration the css file might not be where it was before (Assuming it's not a problem with webpack or its configuration).

I can just guess blindly here what the correct URL might be...
http://localhost:10001/node_modules/font-awesome/css/font-awesome.min.css
http://localhost:10001/css/font-awesome/font-awesome.min.css
http://localhost:10001/css/font-awesome.min.css
http://localhost:10001/font-awesome.min.css

Checking the request header

In general, not just in case of CSS responses:
The request headers can be prepared to gracefully fallback, should a text/html response come through (the default Apache 404 page, for example).
Accept: text/css, text/plain, */*

But you should not configure */* as acceptable for every request. It's not always useful, even on a local development environment - responses of the wrong type should be fixed early.

Why frameworks want to handle this gracefully

The server may deliver the correct answer, but with an incorrect Content-Type header. The framework assumes the server "must have meant application/json" and lets the JSON parser to its thing anways.

If this works, the framework can just ignore the incorrect Content-Type and still function.
The goal of this is mainly to run on shared hosting environments where editing .htaccess settings may be impossible.
It's ok if your application handles content types more strict, with the drawback of debugging errors like this from time to time.

Related answers
If this doesn't help, answers from here were helpful for me:
Stylesheet not loaded because of MIME-type