Title: Refused to apply style because its MIME type "text/html" is not supported stylesheet MIME type, and strict MIME checking is enabled
Tags: html;apache;http;web;mime-types
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 &amp; .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" /&gt;
<link rel="stylesheet" type="text/css" href="${pageContext.request.contextPath}/static/css/jquery/jquery-ui.css" type="text/css" /&gt;
<script src="${pageContext.request.contextPath}/static/js/jquery/jquery.min.js" type="text/javascript" &gt;</script&gt;
<script src="${pageContext.request.contextPath}/static/js/bootstrap/bootstrap.min.js" type="text/javascript"&gt;</script&gt;
<script src="${pageContext.request.contextPath}/static/js/jquery/jquery.slimscroll.min.js" type="text/javascript"&gt;</script&gt;
<script src="${pageContext.request.contextPath}/static/js/jquery/jquery.dataTables.min.js" type="text/javascript"&gt; </script&gt;
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&gt;
<extension&gt;js</extension&gt;
<mime-type&gt;application/javascript</mime-type&gt;
</mime-mapping&gt;
<mime-mapping&gt;
<extension&gt;css</extension&gt;
<mime-type&gt;text/css</mime-type&gt;
</mime-mapping&gt;
Added mimetypes to server.xml in liberty server, as below for reference.
<mimeTypes&gt;
<type&gt;js=application/javascript</type&gt;
<type&gt;css=text/css</type&gt;
</mimeTypes&gt;
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!!!
Comment: _“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.

Comment: Adding the appropriate response headers is usually done by the web server, automatically. Can you directly check how your server responds, without Akamai interfering?

Comment: 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?

Comment: 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.

Comment: The down voters, can you please specify the reason so that it is possible for me to correct it!!

Comment: @CBroe: I added mime-types for the files so that the response headers are correctly passed (if they were not). However, I still see the issue. Any other thoughts from your side? Edited my question with additional information. Thanks

Here is the accepted answer: The only way i found to get rid of this issue is to make the styles and script files in-line in the jsp file.
I have minified each css and .js file and added them in-line in the jsp file.
This solved the issue!!

Here is another answer: 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).
Comment for this answer: @Gana What about, if any type of requests, is consistent when the mime type is incorrect? Certain types of browsers, older versions, weird URL requests, referrers, etc? To fix the inconsistency caused by the error you need to find what consistency creates the error. Additionally I am not familiar with IBM's Liberty server however ensure that the `server.xml` does *not* have a BOM (Byte Order Mark). I recommend editing the file with Notepad++ and ensuring the encoding is UTF-8 *without* BOM. Check that! The presence of a BOM can seriously screw with files.
Comment for this answer: @Gana Okay, please let me know if the issue persists and / or you find something else causing any problems. I consider final tests to *always* be done with witnesses such as friends because for some reason things break in front of them that won't break for me *thus* if you're dealing with a "shy" bug try getting friends to witness a page request or ask to see a page loaded on one of their computers.
Comment for this answer: @Gana It is *not* standard for same URL requests to yield different results unless you explicitly programmed it so; in this scenario obviously not. So the big question is: **are you able to produce the error yourself?** If so debugging should be much easier than miscellaneous scenarios. If you *think* cache is disabled verify that it is. E.g. the developer tools in your browser? You need to analyze what you have done to verify high level of confidence. You have either not considered what is causing the problem or you have though missed something. Try Winmerge to compare header requests.
Comment for this answer: @Gana Please go to the site in my profile and on the contact page send me a URL and I'll have a look directly, if you don't mind. I'm fairly deep in to stuff right now though maybe I can catch something.
Comment for this answer: @Gana Yeah I see the errors in my logs. I'm working on cleaning it up and will attempt to reconstruct the private message. I'll reply there and here when I get it done. I'm *very* good at finding errors. :-)
Comment for this answer: I am setting mime types just the way you suggested. You referred apache's .htaccess file, in my case it is server.xml file in Liberty server. Yes, it is officially supported in IBM Liberty server. When I tested if the files return the correct content-type, I get it correct always (Command used to test the headers: curl -I https://myapplication/static/js/angular/angular.min.js). They don't have any server side code. They are plain css/js files.
Comment for this answer: Thanks John, I did take care of that!
Comment for this answer: Yes the issue persists. I have scanned through each possible area. Server side code, html code, angular code and added code to remove cache, mime-type config in server.xml (server level), web.xml(application level). Tested if the files return correct content-type, yes it is correct but browser get a different response. Webmasters say that it is standard configuration and they don't have anything to change!!
Comment for this answer: That is the biggest challenge!! :( Yes, I am able to experience the error myself! I have verified that the cache is disabled. Http status codes reveal whether the resource is loaded from cache or loaded from server. 304 indicates loaded from cache and 200 is successful load from server. Whenever the page is loaded successfully, I could find these details from dev tools network tab. What else to look for John? You are pointing to all possible areas, thanks for your effort.
Comment for this answer: I could not do so due to an error on the page. System Error: a system error has occurred and a report has been sent to the administrator (Incorrect integer value: '' for column 'id_authentication' at row 1). Let me know your email id

{'source': 'StackExchangeDataset', 'subset': 'stackoverflow.com', 'metadata': {'AnswerCount': 2, 'CommentCount': 6, 'ContentLicense': 'CC BY-SA 4.0', 'CreationDate': '2018:00:06/12/18', 'FavoriteCount': 2.0, 'PostTypeId': 1, 'Tags': '<html><apache><http><web><mime-types>', 'Title': 'Refused to apply style because its MIME type "text/html" is not supported stylesheet MIME type, and strict MIME checking is enabled', 'ViewCount': 24115, 'id': 50813133, 'user_AboutMe': '', 'user_AccountId': 2922140.0, 'user_DisplayName': 'Gana', 'user_Reputation': 462.0, 'user_Views': 178.0, 'user_id': 2504156.0}}