Refused to apply style because its MIME type "text/html" is not supported stylesheet MIME type, and strict MIME checking is enabled

Question

We have a site deployed in production with xyz webmasters. Below are two screenshots of the web console when the error occurs in two different instances.

We are facing this issue intermittently and not consistently. Moreover, this is occurring with few users and not all the users (i don't know if this is related to region or not). When this issue occurs, the page does not load properly. After few refresh attempts, the page loads properly and everything else works as expected.

It is known fact that webmasters enabled strict MIME type checking.

The URL paths of all the resources (.js & .css files) are accurate. The MIME type set at origin for these files is correct. Below is the code snippet of the .jsp page where these files are referred.

        <link rel="stylesheet" href="${pageContext.request.contextPath}/static/css/bootstrap/bootstrap.min.css" type="text/css" />
    <link rel="stylesheet" type="text/css" href="${pageContext.request.contextPath}/static/css/jquery/jquery-ui.css" type="text/css" />

    <script src="${pageContext.request.contextPath}/static/js/jquery/jquery.min.js" type="text/javascript" ></script>
    <script src="${pageContext.request.contextPath}/static/js/bootstrap/bootstrap.min.js" type="text/javascript"></script>   
    <script src="${pageContext.request.contextPath}/static/js/jquery/jquery.slimscroll.min.js" type="text/javascript"></script>
    <script src="${pageContext.request.contextPath}/static/js/jquery/jquery.dataTables.min.js" type="text/javascript"> </script>

As per my understanding, the request flow works like in this small diagram.

I suspect that the issue is caused by webmasters servers when they are sending response back to client browser (step 4). After they read response from App server, I suspect their server is failing to maintain the same Content-Type of the file (.css/.js). Before I claim this, I want to confirm my understanding but I am falling short of tools to prove this as it is happening only in production. We don't see this issue in our development environment to debug!!!

As per webmasters, the issue is in application's code. What I can see in our code is the type for each .js / .css files in .jsp file. What I see is that the browser is NOT accepting the response from webmasters. As we are maintaining rel="stylesheet" type="text/css" for CSS files and type="text/javascript" for all javascript files, I don't see the issue in application server!!

Thanks in advance for your advises.

Edit 1: Added mimetypes in web.xml, as below:

<mime-mapping>    
    <extension>js</extension>        
    <mime-type>application/javascript</mime-type>        
</mime-mapping>
<mime-mapping>    
    <extension>css</extension>        
    <mime-type>text/css</mime-type>        
</mime-mapping>

Added mimetypes to server.xml in liberty server, as below for reference.

<mimeTypes>
    <type>js=application/javascript</type>
    <type>css=text/css</type>
</mimeTypes>

Inspite of this the we often get mime type mismatch in the browser. The webmasters team claims that application server must be sending wrong content, without any reasonable information.

Edit 2: Then I tested what are the headers the resources (js/css files) are sending with below command.

curl -I https://myapplication/static/js/angular/angular.min.js Below is the response I get. It is consistently returned the same response when I run the loop 100 times.

HTTP/1.1 200 OK 
X-Backside-Transport: OK OK  
Content-Language: en-US
Content-Length: 168517
**Content-Type: application/javascript**  
Date: Tue, 19 Jun 2018 10:38:25 GMT 
Last-Modified: Tue, 29 May 2018 17:04:10 GMT 
X-Powered-By: Servlet/3.1 
X-Global-Transaction-ID: 1178221711
Connection: close

So, I don't see any issue on application server side.

- Edit 3: When webmasters suggested that a stale cache may create this kind of issues, the cache is disabled from their side. I additionally written server side code to ensure that cache is disabled. Below is the code snippet for reference:

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setHeader("Expires", "0"); // Proxies.

To make sure that the resource is loaded from server and not from cache, look at the network tab in developer tools. If the resource indicates 200 status code, it is loaded from server successfully. If the status code is 304, it is loaded from cache.

- Edit 4: I have no knowledge how the webmasters establish ssl connection. When a SSL connection is not established properly, it gives the content as text/html. At this stage, I don't know if that is the case. I am looking for all possible areas to solve the issue!!!

“As we are maintaining rel="stylesheet" type="text/css" for CSS files and type="text/javascript" for all javascript files, I don't see the issue in application server” - and Akamai is supposed to care about those HTML attributes somehow? I very much doubt that. The error messages you see in the browser console refer to the Content-Type response header these resources were delivered with - and most likely Akamai is simply passing on what your server gives it in that regard. — CBroe
These javascript/css files are just referred in our .jsp page. We "don't add any response header" for these files. When I load the URL of the file in browser directly, it loads properly. What is the other way to check if that is the issue? I am fine if the issue is in our code, I will be happy to fix it. But we need to be sure of it. One question: If the issue is with the application code, then all the users should experience that issue, but that is not the case. Apart from "type", where to look for in our application on this? — Gana
Adding the appropriate response headers is usually done by the web server, automatically. Can you directly check how your server responds, without Akamai interfering? — CBroe
Without Akamai, it works perfectly fine. We don't see any issues!! We have one instance without Akamai for initial roll-off and that does not have this issue. — Gana
The down voters, can you please specify the reason so that it is possible for me to correct it!! — Gana

John John · Accepted Answer · 2018-06-20T10:32:34

What the client requests (HTML/XML) that initiates the request is almost pointless in general and hopeless for setting the mime of another file request. The server's response is what ultimately determines what the mime type response will be. There are generally two ways to do this.

In most cases with Apache HTTP servers all the files with the same extensions have the same mime types so all *.js files would have the application/javascript mime type in example.

Setting the mime type via Apache .htaccess file:

AddType text/css .css
AddType application/javascript .js

Sometimes people use Apache rewrites or other advanced methods and occasionally there aren't any file extensions. The mime types can be added to files individually.

Setting the mime type via PHP:

header('Content-Type: text/css; charset=UTF-8');//Use only in .css files.
header('Content-Type: application/javascript; charset=UTF-8');//Use only in .js files.

If for some reason you need to run PHP inside of a .css file you'd use this in the .htaccess file and then use the above code to ensure the file's header tells the browser what the correct mime type is.

AddType application/x-httpd-php5 .css .html

As for what is causing the intermittent issues I'm not sure as I write all of my own code for the explicit purpose of avoiding this and other issues that you're encountering. Of course most people don't have that option. So the best case scenario I can recommend in hunting down what is causing the issue is to determine what is setting the header for the files (such as a CSS file being served as HTML). If you already have server code such as PHP running in those files then you'll need to override it (e.g. with the PHP above). It is critical to understand that headers must be sent first before any content is sent otherwise at best the headers will go unseen and at worse corrupt the file request. I suspect the file you're having trouble with likely have server side code in them; if that is not by design I recommend downloading them via FTP and having a direct look to ensure what is on your live server matches what is on your development machine (e.g. did those files get hacked).

Additionally the XML you posted will have no effect on anything requested from the server (unless this is somewhere stated as being something officially supported by Amazon's servers).

Refused to apply style because its MIME type "text/html" is not supported stylesheet MIME type, and strict MIME checking is enabled

2 Answers