Tomcat 7.0.43 "INFO: Fehler beim Analysieren des HTTP-Anforderungsheaders"
Ich verwende Tomcat 7.0.43 mit einer Websocket-Anwendung. Meine App funktioniert in Tomcat 7.0.42 einwandfrei, aber mit 43 bekomme ich die folgende Ausgabe, wenn ich versuche, über Websockets auf meinen Server zuzugreifen:
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.
Meine Browserkonsole zeigt Folgendes:
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
Hier ist das Zugriffsprotokoll für diese Anfrage:
"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"
Was hat sich in Tomcat 7.0.43 geändert? Was muss ich ändern?
Wenn Sie diesen Zuhörer haben:
<Listener className="org.Apache.catalina.core.AprLifecycleListener" SSLEngine="on"/>
entfernen Sie die Datei in der Datei server.xml, und versuchen Sie Folgendes: Sie können keinen Keystore verwenden, wenn Sie den APR-Connector verwenden
Wenn zu viele Cookies zwischengespeichert werden, wird der Server beschädigt (die Größe eines Anforderungsheaders ist zu groß!). Das Löschen der Cookies kann dieses Problem ebenfalls beheben.
Für mich bestand das Problem darin, einen größeren als normalerweise erwarteten HTTP-Header zu übergeben. Ich habe es gelöst, indem Sie das Attribut maxHttpHeaderSize = "1048576" auf dem Connector-Knoten in server.xml festgelegt haben.
Ich hatte ein ähnliches Problem. Ich sendete eine POST -Anforderung (unter Verwendung des RESTClient-Plugins für Firefox) mit Daten im Anforderungshauptteil und erhielt dieselbe Nachricht.
In meinem Fall war dies der Fall, weil ich versuchte, das HTTPS-Protokoll in einer lokalen Tomcat-Instanz zu verwenden, in der HTTPS nicht konfiguriert war.
Mein Problem tritt auf, wenn ich versuche, https zu öffnen. Ich benutze kein SSL.
Es ist Tomcat Bug .
Heute 12/02/2017 ist die neueste offizielle Version von Debian-Repositories Tomcat 8.0.14
Die Lösung besteht darin, von der offiziellen Website herunterzuladen und das neueste Paket von Tomcat 8, 8.5, 9 zu installieren oder auf die neueste Version ( zu aktualisieren ) 8.5.x ) von jessie-backports
Debian 8
Fügen Sie zu /etc/apt/sources.list hinzu
deb http://ftp.debian.org/debian jessie-backports main
Aktualisieren und installieren Sie dann Tomcat über jessie-backports
Sudo apt-get update && Sudo apt-get -t jessie-backports install Tomcat8
Ich habe alle oben genannten Schritte ausprobiert, nichts hat bei mir funktioniert. Dann habe ich die Tomcat-Port-Nummern (HTTP/1.1 und Tomcat-Admin-Port) geändert und es wurde gelöst.
Ich sehe, dass andere Lösungen oben für die Leute funktionieren, aber es lohnt sich, diese auszuprobieren, wenn eine der oben genannten Funktionen nicht funktioniert.
Vielen Dank an alle!
In unserem Fall stellte sich heraus, dass der Fehler aufgetreten ist, weil wir in unserer Anwendung eine benutzerdefinierte filter haben, die HttpServletResponse sendRedirect() für andere URLs ausführt.
Aus irgendeinem Grund schließt die Umleitung nicht den keep-alive-Status der Verbindung, daher die Timeout-Ausnahme.
Wir haben mit Tomcat Docs nach dem Deaktivieren der maxKeepAliveRequests gesucht, indem wir den Wert auf 1 gesetzt haben und der Fehler nicht mehr angezeigt wurde.
Im Moment haben wir nicht die tatsächliche Lösung für den Fehler.
Wenn Sie Ihren Tomcat nicht aktualisieren möchten, Fügen Sie diese Zeile in Ihren catalina.properties ein.
Tomcat.util.http.parser.HttpParser.requestTargetAllow=|{}
Es funktioniert für mich http://www.zhoulujun.cn/zhoulujun/html/Java/Tomcat/2018_0508_8109.html