Nous utilisons Tomcat (v7) sous OS X depuis assez longtemps et n’avons jamais rencontré de problèmes. Cependant, après la mise à jour du système d'exploitation vers High Sierra, les applications Web ne fonctionnent plus lorsque la compression est activée dans le fichier server.xml.
Chrome affiche en permanence un ERR_CONTENT_DECODING_FAILED (évidemment sans affichage de contenu). Lorsque la compression est désactivée, tout fonctionne bien. Je suppose que la racine du problème est la mise à niveau de zlib par Apple dans High Sierra. Tout fonctionnait bien sur Sierra. Les fichiers journaux de Tomcat semblent parfaits - aucune erreur ne s'y produit.
Quelqu'un at-il rencontré le même problème et a-t-il réussi à le résoudre ou connaît-il une solution de contournement viable sans désactiver la compression ?
En outre, il serait également utile que quelqu'un puisse confirmer que les versions plus récentes de Tomcat ne rencontrent pas ce problème sur High Sierra.
Merci de votre aide.
Il s'agit d'un bogue dans la façon dont la méthode setLevel()
du SDK Java est implémentée. Il est signalé que les données compressées résultant de la définition du niveau sont ignorées par le SDK. Cela entraînerait des données compressées corrompues. Le correctif pour le bogue peut être trouvé ici , écrit par xuemingshen.
Solution de contournement jusqu'à ce qu'un correctif soit détecté: désactivez la compression dans la configuration server.xml
de votre projet Tomcat.
Workarround/Hack pour Windows: Malheureusement, je ne suis pas familier avec OS X, mais je suis confronté au même problème sous Windows et j'ai pu trouver une solution un peu sale pour cela. L'erreur deflate.c a été corrigée dans 8u162-ea
, voir https://bugs.openjdk.Java.net/browse/JDK-8189789
Malheureusement, 8u162-ea
peut ne pas contenir tous les correctifs ou n'est probablement pas suffisant pour un environnement de production.
Pour résoudre ce problème sous 8u152
, téléchargez et installez la dernière mise à jour à partir de http://jdk.Java.net/8/
Accédez au dossier d'installation (par exemple C:\Java\jdk8-162-ea\jre\bin\
) et copiez le Zip.dll
qui contient le correctif (voir JDK 9 deflate.c fix ) et collez-le au même endroit, sous le jdk 8u152
.
J'espère que vous pourrez trouver quelque chose de similaire sous OS X.
Fyi, utilisateurs d’OS X, j’ai essayé d’installer JDK 8u162-ea à partir de http://jdk.Java.net/8/ , et le problème n’a pas été résolu. Je pense que la raison en est que, contrairement au JDK Windows, le JDK OS X ne contient pas zlib, mais utilise plutôt la zlib fournie avec OS X (/usr/lib/libz.1.dylib). Cela se voit en consultant les bibliothèques partagées dont dépend l'exécutable Java:
$ otool -L /Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/bin/Java
/Library/Java/JavaVirtualMachines/jdk1.8.0_162.jdk/Contents/Home/bin/Java:
/System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 19.0.0)
/System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 55179.0.2)
/System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 45.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.5)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 169.3.0)
/usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0)
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 744.1.0)
/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 945.11.0)
Je pense donc que nous avons besoin d’un correctif pour ce problème d’Apple sous la forme d’un mise à jour pour High Sierra.
Notre solution de contournement pour les développeurs locaux: nous utilisons Spring Boot et avons un EmbeddedServletContainerCustomizer. Après mise à jour sur High Sierra, même problème. Le problème n'existe que pour le développement local, donc pas quelque chose à pousser à la production. Comme mentionné ci-dessus, nous avons désactivé la compression dans notre configuration principale comme suit:
@Bean
public EmbeddedServletContainerCustomizer servletContainerCustomizer() {
return new EmbeddedServletContainerCustomizer() {
@Override
public void customize(ConfigurableEmbeddedServletContainerFactory servletContainer) {
((TomcatEmbeddedServletContainerFactory) servletContainer).addConnectorCustomizers(
new TomcatConnectorCustomizer() {
@Override
public void customize(Connector connector) {
AbstractHttp11Protocol httpProtocol = (AbstractHttp11Protocol) connector.getProtocolHandler();
httpProtocol.setCompression("off");
httpProtocol.setCompressionMinSize(256);
String mimeTypes = httpProtocol.getCompressableMimeTypes();
mimeTypes += "," + MediaType.APPLICATION_JSON_VALUE;
mimeTypes += "," + "text/css";
mimeTypes += "," + "application/javascript";
httpProtocol.setCompressableMimeTypes(mimeTypes);
}
});
};
};
}