Tomcat 7.0.43 " INFO: parsing Error request header"
J'utilise Tomcat 7.0.43 avec une application websocket. Mon application fonctionne très bien dans Tomcat 7.0.42 mais avec 43 j'obtiens la sortie suivante quand j'essaie d'accéder à mon serveur sur 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.
Mon navigateur de la console est le suivant:
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 requête:
"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?
8 réponses
Si vous avez ce listener:
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on"/>
sur votre serveur.xml, retirez - le et essayez. Vous ne pouvez pas utiliser un keystore si vous utilisez le connecteur APR
S'il y a trop de cookies mis en cache, cela casse le serveur (la taille d'un en-tête de requête est trop grande!). Compensation les cookies peuvent résoudre ce problème.
pour moi, le problème était de passer 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 noeud de connecteur dans le serveur.XML.
j'ai eu un problème similaire, j'envoyais une requête POST (utilisant le plugin RESTClient pour Firefox) avec des données dans le corps de la requête et je recevais le même message.
dans mon cas, cela s'est produit parce que j'essayais d'utiliser le protocole HTTPS dans une instance tomcat locale où HTTPS n'était pas configuré.
j'ai essayé tout ce qui précède, rien n'a fonctionné pour moi. Puis j'ai changé les numéros de port de tomcat à la fois HTTP/1.1 et le port admin de Tomcat et il a été résolu.
je vois que d'autres solutions ci-dessus ont fonctionné pour les gens, mais il vaut la peine d'essayer celle-ci si l'une des solutions ci-dessus ne fonctionne pas.
Merci à tous!
Mon problème survient lorsque j'essaie d'ouvrir https. Je n'utilise pas SSL.
C'est Tomcat bug.
aujourd'Hui 12/02/2017 la dernière version officielle des dépôts Debian est Tomcat 8.0.14
la Solution est de télécharger à partir du site officiel et d'installer le plus récent paquet de Tomcat 8, 8.5, 9 ou mise à niveau vers la version la plus récente ( 8.5.x) à partir de jessie-backports
Debian 8
Ajouter / etc/apt / sources.liste
deb http://ftp.debian.org/debian jessie-backports main
puis mettre à jour et installer 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 une coutume filter dans notre application qui fait HttpServletResponse sendRedirect() pour les autres url.
pour une raison quelconque, la redirection ne ferme pas le keep-alive statut de la connexion, d'où l'exception de temporisation.
Nous avons vérifié avec Tomcat Docs et quand nous avons désactivé l' maxKeepAliveRequests en définissant sa valeur à 1 et l'erreur n'apparaît plus.
Pour l'instant nous n'avons pas le réel la solution à l'erreur.
si vous ne voulez pas mettre à jour votre tomcat,
Ajoutez cette ligne dans votre catalina.properties
tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
ça marche pour moi http://www.zhoulujun.cn/zhoulujun/html/java/tomcat/2018_0508_8109.html