A refusé d'appliquer le style car son type MIME "text/html" n'est pas pris en charge, mais la vérification MIME stricte est activée
Nous avons un site déployé en production avec les webmasters xyz. Vous trouverez ci-dessous deux captures d'écran de la console Web lorsque l'erreur se produit dans deux instances différentes.
Nous sommes confrontés à ce problème de manière intermittente et non uniforme. De plus, cela se produit avec peu d'utilisateurs et pas tous les utilisateurs (je ne sais pas si cela est lié à la région ou non). Lorsque ce problème se produit, la page ne se charge pas correctement. Après quelques tentatives d'actualisation, la page se charge correctement et tout le reste fonctionne comme prévu.
Il est de notoriété publique que les webmasters activaient la vérification de type MIME stricte.
Les chemins d’URL de toutes les ressources (fichiers .js et .css) sont exacts . Le type MIME défini sur Origine pour ces fichiers est correct. Voici l'extrait de code de la page .jsp où ces fichiers sont référés.
<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>
Selon ma compréhension, le flux de demandes fonctionne comme dans ce petit diagramme.
Je soupçonne que le problème est causé par les serveurs de webmasters lorsqu'ils envoient une réponse au navigateur client (étape 4). Après avoir lu la réponse du serveur d'applications, je soupçonne que leur serveur ne parvient pas à conserver le même type de contenu du fichier (.css/.js). Avant de prétendre cela, je veux confirmer ma compréhension, mais je manque d’outils pour le prouver, car cela n’arrive que dans la production. Nous ne voyons pas ce problème dans notre environnement de développement à déboguer !!!
Selon les webmasters, le problème est dans le code de l'application. Ce que je peux voir dans notre code est le type de chaque fichier .js/.css dans le fichier .jsp. Ce que je vois, c'est que le navigateur n'accepte pas la réponse des webmasters. Comme nous maintenons rel = "stylesheet" type = "text/css" pour les fichiers CSS et type = "text/javascript" pour tous les fichiers javascript}, Je ne vois pas le problème dans le serveur d'applications !!
Merci d'avance pour vos conseils.
Edit 1: Ajout de types MIME dans web.xml, comme ci-dessous:
<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>
Ajout de types MIME au fichier server.xml dans Liberty Server, comme indiqué ci-dessous à titre de référence.
<mimeTypes>
<type>js=application/javascript</type>
<type>css=text/css</type>
</mimeTypes>
Malgré cela, il arrive souvent que le navigateur ne corresponde pas avec le type mime. L'équipe des webmasters affirme que le serveur d'applications doit envoyer un contenu erroné, sans aucune information raisonnable.
Edit 2: Ensuite, j'ai testé les en-têtes que les ressources (fichiers js/css) envoient avec la commande ci-dessous.
curl -I https: //myapplication/static/js/angular/angular.min.js Ci-dessous, la réponse que je reçois. La même réponse est systématiquement renvoyée lorsque je lance la boucle 100 fois.
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
Donc, je ne vois pas de problème du côté du serveur d'applications.
- Éditer 3: Lorsque les webmasters ont suggéré qu'un cache obsolète puisse créer ce type de problème, le cache est désactivé de leur côté. J'ai également écrit le code côté serveur pour m'assurer que le cache est désactivé. Ci-dessous l'extrait de code pour référence:
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.
Pour vous assurer que la ressource est chargée à partir du serveur et non du cache, consultez l'onglet Réseau des outils de développement. Si la ressource indique un code de statut 200, elle est chargée à partir du serveur. Si le code d'état est 304, il est chargé à partir du cache.
- Edit 4: Je ne sais pas comment les webmasters établissent une connexion ssl. Lorsqu'une connexion SSL n'est pas établie correctement, le contenu est transmis sous forme de texte/html. A ce stade, je ne sais pas si c'est le cas. Je cherche tous les domaines possibles pour résoudre le problème !!!
Le seul moyen que j’ai trouvé pour résoudre ce problème est de rendre les styles et les fichiers de script en ligne dans le fichier jsp.
J'ai minifié chaque fichier css et .js et les ai ajoutés en ligne dans le fichier jsp.
Cela a résolu le problème !!
Ce que le client demande (HTML/XML) pour lancer la demande est presque inutile en général et sans espoir pour définir le mime d'une autre demande de fichier. La réponse du serveur est ce qui détermine finalement la réponse de type mime. Il y a généralement deux façons de le faire.
Dans la plupart des cas, avec les serveurs HTTP Apache, tous les fichiers portant les mêmes extensions ont les mêmes types mime. Par conséquent, tous les fichiers * .js ont le type application/javascript mime.
Définition du type mime via le fichier Apache .htaccess:
AddType text/css .css
AddType application/javascript .js
Parfois, les gens utilisent les méthodes de réécriture Apache ou d’autres méthodes avancées et parfois il n’ya pas d’extension de fichier. Les types MIME peuvent être ajoutés aux fichiers individuellement.
Définir le type mime 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.
Si, pour une raison quelconque, vous devez exécuter PHP dans un fichier .css, vous l'utiliserez dans le fichier .htaccess, puis le code ci-dessus pour garantir que l'en-tête du fichier indique au navigateur le type de mime correct.
AddType application/x-httpd-php5 .css .html
En ce qui concerne la cause des problèmes intermittents, je ne suis pas sûr d'écrire all de mon propre code dans le but explicite d'éviter ce problème et d'autres que vous rencontrez. Bien sûr, la plupart des gens n'ont pas cette option. Par conséquent, le meilleur scénario que je puisse recommander pour trouver la cause du problème consiste à déterminer le paramètre définissant l'en-tête des fichiers (par exemple, un fichier CSS transmis au format HTML). Si vous avez déjà du code serveur tel que PHP exécuté dans ces fichiers, vous devez le remplacer (par exemple, avec le PHP ci-dessus). Il est critique de comprendre que les en-têtes doivent être envoyés en premier avant tout contenu. Dans le meilleur des cas, les en-têtes resteront invisibles et, au pire, corrompront la demande de fichier. Je soupçonne que le fichier avec lequel vous rencontrez des problèmes a probablement un code côté serveur; Si tel est le cas not de par ma conception, je vous recommande de les télécharger via FTP et de vérifier directement ce qui se trouve sur votre serveur actif correspond à ce qui se trouve sur votre ordinateur de développement (ces fichiers ont-ils par exemple été piratés).
De plus, le XML que vous avez publié n'aura aucun effet sur les demandes du serveur (à moins que cela soit indiqué comme étant officiellement supporté par les serveurs d'Amazon).