title: Refused to apply style because its MIME type "text/html" is not supported stylesheet MIME type, and strict MIME checking is enabled
body: <p>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.</p>
  
  <p><a href="https://i.stack.imgur.com/BkbRg.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/BkbRg.png" alt="enter image description here"></a>
  <a href="https://i.stack.imgur.com/3l6GT.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/3l6GT.png" alt="enter image description here"></a></p>
  
  <p>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.</p>
  
  <p>It is known fact that webmasters enabled strict MIME type checking.</p>
  
  <p>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.</p>
  
  <pre><code>        &lt;link rel="stylesheet" href="${pageContext.request.contextPath}/static/css/bootstrap/bootstrap.min.css" type="text/css" /&gt;
      &lt;link rel="stylesheet" type="text/css" href="${pageContext.request.contextPath}/static/css/jquery/jquery-ui.css" type="text/css" /&gt;
  
      &lt;script src="${pageContext.request.contextPath}/static/js/jquery/jquery.min.js" type="text/javascript" &gt;&lt;/script&gt;
      &lt;script src="${pageContext.request.contextPath}/static/js/bootstrap/bootstrap.min.js" type="text/javascript"&gt;&lt;/script&gt;   
      &lt;script src="${pageContext.request.contextPath}/static/js/jquery/jquery.slimscroll.min.js" type="text/javascript"&gt;&lt;/script&gt;
      &lt;script src="${pageContext.request.contextPath}/static/js/jquery/jquery.dataTables.min.js" type="text/javascript"&gt; &lt;/script&gt;
  </code></pre>
  
  <p>As per my understanding, the request flow works like in this small diagram.</p>
  
  <p><a href="https://i.stack.imgur.com/tk3cR.png" rel="nofollow noreferrer"><img src="https://i.stack.imgur.com/tk3cR.png" alt="enter image description here"></a></p>
  
  <p>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!!!</p>
  
  <p>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 <strong><em>rel="stylesheet" type="text/css" for CSS files</em></strong> and <strong><em>type="text/javascript" for all javascript files</em></strong>, I don't see the issue in application server!!</p>
  
  <p>Thanks in advance for your advises.</p>
  
  <ul>
  <li><p><strong>Edit 1:</strong>
  Added mimetypes in web.xml, as below:</p>
  
  <pre><code>&lt;mime-mapping&gt;    
      &lt;extension&gt;js&lt;/extension&gt;        
      &lt;mime-type&gt;application/javascript&lt;/mime-type&gt;        
  &lt;/mime-mapping&gt;
  &lt;mime-mapping&gt;    
      &lt;extension&gt;css&lt;/extension&gt;        
      &lt;mime-type&gt;text/css&lt;/mime-type&gt;        
  &lt;/mime-mapping&gt;
  </code></pre></li>
  </ul>
  
  <p>Added mimetypes to server.xml in liberty server, as below for reference.</p>
  
  <pre><code>&lt;mimeTypes&gt;
      &lt;type&gt;js=application/javascript&lt;/type&gt;
      &lt;type&gt;css=text/css&lt;/type&gt;
  &lt;/mimeTypes&gt;
  </code></pre>
  
  <p>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.</p>
  
  <ul>
  <li><p><strong>Edit 2:</strong>
  Then I tested what are the headers the resources (js/css files) are sending with below command.</p>
  
  <p>curl -I <a href="https://myapplication/static/js/angular/angular.min.js" rel="nofollow noreferrer">https://myapplication/static/js/angular/angular.min.js</a>
  Below is the response I get. It is consistently returned the same response when I run the loop 100 times.</p></li>
  </ul>
  
  <blockquote>
  <pre><code>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
  </code></pre>
  </blockquote>
  
  <p>So, I don't see any issue on application server side.</p>
  
  <p><strong>- Edit 3:</strong>
  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:</p>
  
  <pre><code>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.
  </code></pre>
  
  <p>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.</p>
  
  <p><strong>- Edit 4:</strong>
  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!!!</p>