Tomcat 7 la compression GZIP ne fonctionne pas

sur Windows, j'ai rencontré ce comportement en essayant d'activer temporairement la compression de contenu dans mon environnement de développement pour acquérir une compréhension approximative de la charge utile totale d'une page dans mon application.

je peux confirmer que L'Antivirus ESET NOD32 se comporte de la manière que @bugs_ décrit dans sa réponse à cette question et je peux également confirmer que l'exécution de Fiddler4 a le même effet. Cependant, la fermeture de Fiddler et la désactivation du balayage HTTP de NOD32 n'ont pas résolu le problème. problème, pour ce faire, j'ai dû désactiver l'utilisation de "sendfile" dans mon connecteur comme suit:

<Connector port="8080" protocol="HTTP/1.1"
           connectionTimeout="20000"
           compression="on" compressionMinSize="8192" useSendfile="false"
           compressableMimeType="text/html,text/xml,text/plain,text/css,text/javascript,application/javascript"
           redirectPort="8443" />

L'attribut important, ici, est useSendfile="false"

J'utilise Apache Tomcat 8, sous Windows. La documentation Tomcat (http://tomcat.apache.org/tomcat-8.0-doc/config/http.html) dit ce qui suit à propos de useSendfile:

Utilisez cet attribut pour activer ou désactiver la capacité sendfile. La valeur par défaut est true. Notez que l'utilisation de sendfile désactivera toute compression que Tomcat aurait pu effectuer sur la réponse.

ce sujet compression:

il y a un compromis entre l'utilisation de la compression (enregistrer votre bande passante) et l'utilisation de la fonctionnalité sendfile (enregistrer vos cycles CPU). Si le connecteur supporte la fonctionnalité sendfile, par exemple le connecteur NIO, l'utilisation de sendfile aura priorité sur la compression. Les symptômes seront que les fichiers statiques plus grand que 48 Kb sera envoyé non compressé. Vous pouvez désactiver sendfile en paramétrant l'attribut useSendfile du connecteur, comme décrit ci-dessous, ou modifier le seuil d'utilisation de sendfile dans la configuration du DefaultServlet dans le conf/web par défaut.xml ou sur le web.xml de votre application web.

Dans mon cas, il n'a pas travaillé en raison de l'Antivirus (ESET, Windows)

il a été relié quelque part avant le navigateur. Il décompresse le corps et supprime l'en-tête "Content-Encoding". Pour la réponse du navigateur a semblé comme la réponse normale non compressée. Même dans Fiddler il était déjà décompressé.

les réponses Https fonctionnaient, mais les réponses http étaient décomposées par L'ESET.

ce n'est pas assez. Activer ESET off. J'ai dû aller à "paramètres avancés" -> "protection de l'accès Web" - >"HTTP, HTTPS" et éteignez-le là

si vous servez des dossiers du disque dur vous pouvez avoir besoin d'ajouter l'option useSendFile= "false" dans le connecteur.

j'ai été le tester similaires server.xml des changements dans mon environnement de développement local et j'étais frustré que cela ne fonctionne pas non plus.

mon problème était que je faisais des modifications à mon installation locale Tomcat (C:\apache-tomcat-8.0.5) que j'ai sélectionné en utilisant le Servers window -> (right-click) -> New -> Server boîte de dialogue dans Spring Tool Suite.

cependant, une fois publié, le répertoire tomcat utilisé se trouvait dans (espace de travail dossier.\)métadonnées.\plugins\org.Eclipse.wst.serveur.core\tmp0.

vous pouvez vérifier l'emplacement publié en faisant un clic droit sur le serveur et en choisissant "parcourir L'emplacement de déploiement..."

A partir de là, vous pouvez mettre à jour le server.xml fichier, ou vous pouvez supprimer et ajouter de nouveau le serveur.