Tomcat 7.0.43 "INFO: Erreur lors de l'analyse de l'en-tête de requête HTTP"
J'utilise Tomcat 7.0.43 avec une application websocket. Mon application fonctionne correctement dans Tomcat 7.0.42, mais avec 43, je reçois le résultat suivant lorsque j'essaie d'accéder à mon serveur via des websockets:
Sep 16, 2013 3:08:34 AM org.Apache.coyote.http11.AbstractHttp11Processor process
INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
La console de mon navigateur affiche les informations suivantes:
WebSocket connection to 'ws://www.testapp.com/socket/notification/848df2e62fcf93e1b3?X-Atmosphere-tracking-i…Date=0&Content-Type=application/json;%20charset=UTF-8&X-atmo-protocol=true' failed: Unrecognized frame opcode: 5
Voici le journal d'accès pour cette demande:
"GET /socket/notification/848df2e62fcf93e1b3?X-Atmosphere-tracking-id=0&X-Atmosphere-Framework=2.0.2-javascript&X-Atmosphere-Transport=websocket&X-Atmosphere-TrackMessageSize=true&X-Cache-Date=0&Content-Type=application/json;%20charset=UTF-8&X-atmo-protocol=true HTTP/1.1"
Qu'est-ce qui a changé dans Tomcat 7.0.43? Que dois-je changer?
Si vous avez cet auditeur:
<Listener className="org.Apache.catalina.core.AprLifecycleListener" SSLEngine="on"/>
sur votre server.xml, supprimez-le et essayez . Vous ne pouvez pas utiliser de magasin de clés si vous utilisez le connecteur APR
S'il y a trop de cookies en cache, le serveur est cassé (la taille de l'en-tête d'une requête est trop grande!). Effacer les cookies peut également résoudre ce problème.
Pour moi, le problème passait dans un en-tête HTTP plus grand que prévu. Je l'ai résolu en définissant l'attribut maxHttpHeaderSize = "1048576" sur le nœud du connecteur dans server.xml.
J'avais un problème similaire, j'envoyais une demande POST (à l'aide du plug-in RESTClient pour Firefox) avec des données dans le corps de la demande et recevais le même message.
Dans mon cas, cela est dû au fait que j'essayais d'utiliser le protocole HTTPS dans une instance locale de Tomcat dans laquelle HTTPS n'était pas configuré.
J'ai essayé tout ce qui précède, rien ne fonctionnait pour moi ..__ Ensuite, j'ai changé les numéros de port de Tomcat, HTTP/1.1 et le port d'administration de Tomcat, et tout a été résolu.
Je vois d’autres solutions ci-dessus qui ont fonctionné pour les gens, mais cela vaut la peine d’essayer celle-ci si l’une de ces solutions ne fonctionne pas.
Merci tout le monde!
Mon problème survient lorsque j'essaie d'ouvrir https. Je n'utilise pas SSL.
C'est Tomcat bug .
Today 12/02/2017 La dernière version officielle des référentiels Debian est Tomcat 8.0.14.
La solution consiste à télécharger à partir du site officiel et d'installer le dernier package Tomcat 8, 8.5, 9 ou à une mise à niveau vers la version la plus récente (8.5.x) à partir de jessie-backports
Debian 8
Ajouter à /etc/apt/sources.list
deb http://ftp.debian.org/debian jessie-backports main
Puis mettez à jour et installez Tomcat à partir de jessie-backports
Sudo apt-get update && Sudo apt-get -t jessie-backports install Tomcat8
Dans notre cas, il s’est avéré que l’erreur s’est produite parce que nous avons dans notre application une variable filter qui fait HttpServletResponse sendRedirect() avec d’autres URL.
Pour une raison quelconque, la redirection ne ferme pas l'état keep-alive de la connexion, d'où l'exception de délai d'expiration.
Nous avons vérifié avec Tomcat Docs et lorsque nous avons désactivé la variable maxKeepAliveRequests en lui attribuant la valeur 1, l'erreur s'est arrêtée.
Pour l'instant, nous n'avons pas la solution réelle à l'erreur.
Si vous ne souhaitez pas mettre à jour votre Tomcat, ajoutez une ligne dans votre catalina.properties
Tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
Cela fonctionne pour moi http://www.zhoulujun.cn/zhoulujun/html/Java/Tomcat/2018_0508_8109.html