java.lang.IllegalArgumentException: Ungültiges Zeichen im Methodennamen gefunden. HTTP-Methodennamen müssen Token sein

160

Wenn ich meine Anwendung in einer Apache Tomcat 8-Umgebung mit mehreren Servern bereitstelle, wird die Stapelverfolgung unterschritten. Ich erhalte diesen Fehler häufig und es scheint, dass er den Tomcat-Thread blockiert:

INFO [http-nio-80-exec-4461] org.apache.coyote.http11.AbstractHttp11Processor.process Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
 java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
 at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:233)
 at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1017)
 at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:684)
 at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1524)
 at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1480)
 at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
 at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
 at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
 at java.lang.Thread.run(Unknown Source)

Kann mich jemand anweisen, wie ich eine solche Ausnahme beheben oder eingrenzen kann? Ich erhalte keinen Verweis auf eine meiner Anwendungsquelldateien. Ich habe versucht, zu googeln, und in den darin enthaltenen Links versuchen Sie, über https auf die http-URL zuzugreifen, was unwahrscheinlich erscheint. Ich erhalte diesen Fehler nicht, wenn die Anwendung auf einer einzelnen Tomcat 8-Instanz ausgeführt wird. Ich bekomme das nur in einer Multi-Server-Umgebung.

Ich teile auch die Meta-Tags, die ich auf jeder Seite eingebettet habe, wenn dies hilft, die Ursache zu identifizieren.

<%
    response.setHeader("Cache-Control", "no-cache");
    response.setHeader("Cache-Control", "no-store");
    response.setDateHeader("Expires", 0);
    response.setHeader("Pragma", "no-cache");
%>


<head>
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, minimum-scale=1.0, maximum-scale=1.0">
<meta name="viewport" content="width=device-width, initial-scale=1">

Ich verwende auf einigen Seiten auch Folgendes, was im Grunde dasselbe ist wie oben:

<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta http-equiv="Expires" content="-1" />
<meta http-equiv="Cache-Control" content="private" />
<meta http-equiv="Cache-Control" content="no-store" />
<meta http-equiv="Pragma" content="no-cache" />

Selbst wenn jemand dabei hilft, meinem Fehlerbehebungsversuch eine Richtung zu geben, ist dies hilfreich, da ich derzeit keine Ahnung habe, wo ich nachsehen soll.

Danke im Voraus.

tomcat8 illegalargumentexception

— user2016012
quelle

265

Diese Ausnahme kann auftreten, wenn Sie versuchen, eine HTTPS- Anforderung vom Client auf einem Endpunkt auszuführen, der nicht HTTPS-fähig ist. Der Client verschlüsselt Anforderungsdaten, wenn der Server Rohdaten erwartet.

— Petar Tonev
quelle

1

Ich bin mir nicht sicher, ob ich diese Antwort verstehe. Ich habe eine Spring Boot 1.5.1-App und habe diese Ausnahme in meinem Protokoll gesehen. Meine App antwortet nur für SSL auf Port 8443 (von Port 443 umgeleitet) und hat nur den einen Anschluss für SSL. Wollen Sie damit sagen, dass jemand http: anstelle von https: an Port 443 ausprobieren könnte?

— Jim Archer

5

Solche Ausnahmen treten auf, wenn zwischen dem, was der Server erwartet, und dem, was er erhält, eine Nichtübereinstimmung besteht. Was Sie gesagt haben, ist eines der möglichen Szenarien. Möglicherweise gibt es auf Ihrem Server einen Endpunkt, der nicht unter https ausgeführt wird, aber jemand versucht, auf diese Weise darauf zuzugreifen?

— Petar Tonev

1

Hallo Peter ... Das Problem bestand darin, dass jemand eine IP-Tabellen-Regel erstellt hat, um Port 80 an Port 8443 weiterzuleiten. Daher hat jeder, der die Site über http auf Port 80 aufgerufen hat, diesen Fehler verursacht. Wir haben einen Tomcat-Connector hinzugefügt, um Port 8080 auf 8443 umzuleiten, und die IP-Tabellenregel eingerichtet, um Port 80 an Port 8080 weiterzuleiten, und das Problem ist so gut wie behoben. Vielen Dank für Ihre Antwort!

— Jim Archer

1

@PeterTonev: Irgendeine Idee, wie man (https zu http umleitet || https deaktiviert || den Fehler abfängt, um zumindest eine aussagekräftige Fehlermeldung anzuzeigen)?

— Crusy

1

@crusy Etwas, das Ihnen hier für die Ausnahmebehandlung helfen kann, ist Link

— Petar Tonev

56

Ich habe die gleiche Ausnahme bekommen, als ich lokal getestet habe. Das Problem war ein URL-Schema in meiner Anfrage.

Veränderung https:// to http:// in your client url.

Wahrscheinlich hilft es.

— JustCode
quelle

2

Sicher funktioniert es, aber beachten Sie, dass die Kommunikation über HTTP nicht sicher ist.

— Paramvir Singh Karwal

23

Sie rufen den lokalen Server mit http : // localhost: 8080 / foo / bar an. Rufen Sie es mit https : // localhost: 8080 / foo / bar auf. Dies löst das Problem

— Shivan Sawant
quelle

Wahrscheinlich haben Sie nicht https: // auf 8080. Ändern Sie den Aufruf von https: // localhost: 8443 / foo / bar - Hier ist das Beispiel Link - Rodrigo R. Coelho

— Rodrigo R. Coelho

9

Falls jemand Prahlerei benutzt:

Ändern Sie das Schema in HTTPoder HTTPS, je nach Bedarf, bevor Sie die Ausführung ausführen.

Briefträger:

Ändern Sie den URL-Pfad zu http://oder https://in der URL-Adresse

— Cyber
quelle

8

Ich habe diese Ausnahme erhalten, die nichts mit TLS-Problemen zu tun hat. In meinem Fall stimmte der Content-Length-Header-Wert nicht mit der Body-Länge überein.

— Mibollma
quelle

2

Ich kann dir nicht genug danken. Jede andere POST-Anfrage schlug mit Fehler 400 fehl und ich war bereit, mir die Haare auszureißen. Es stellte sich heraus, dass das Nicht-Senden eines content-lengthHeaders dieses Problem löst.

— Alexander Woodblock

2

Ich hatte eine Verzögerung von 30-90 Sekunden für Postman-Anfragen an lokale Entwickler - es stellte sich heraus, dass es dieses Problem war! Durch Deaktivieren des Content-LengthHeaders wurde die Verzögerung behoben.

— Alok

1

Wenn Sie diese alte Frage beantworten (für andere, die möglicherweise helfen)

, wird das Problem gelöst, wenn Sie Ihr httpd conf richtig konfigurieren. Installieren Sie einen beliebigen httpd-Server, falls Sie keinen haben.

Hier meine Konfiguration auflisten.

[smilyface@box002 ~]$ cat /etc/httpd/conf/httpd.conf | grep shirts | grep -v "#"

        ProxyPass /shirts-service http://local.box002.com:16743/shirts-service
        ProxyPassReverse /shirts-service http://local.box002.com:16743/shirts-service
        ProxyPass /shirts http://local.box002.com:16443/shirts
        ProxyPassReverse /shirts http://local.box002.com:16443/shirts
        ...
        ...
        ...

Bearbeiten Sie die Datei wie oben und starten Sie httpd wie unten neu

[smilyface@box002 ~]$ sudo service httpd restart

Und dann httpsfunktioniert die Anfrage mit mit ausnahmslos.
Auch Anfrage mit httpwird weiterleiten an https! Keine Sorge.

— Smilyface
quelle

1

Ich habe diesen Fehler behoben, indem ich zwei Dinge im Chrome-Browser getan habe:

Drücken Sie Strg + Umschalt + Löschen und löschen Sie alle Browserdaten von Anfang an.
Gehen Sie zu Chrome: Einstellungen -> Erweiterte Einstellungen -> Proxy-Einstellungen öffnen -> Internet-Eigenschaften. Gehen Sie dann zum Inhaltsfenster und klicken Sie auf die Schaltfläche SSL-Status löschen.

Diese Website enthält diese Informationen und andere Optionen: https://www.thesslstore.com/blog/fix-err-ssl-protocol-error/

— Ravi Shankar Kota
quelle

1

Ich weiß, dass dies ein alter Thread ist, aber es gibt einen bestimmten Fall, in dem dies passieren kann:

Wenn Sie ein AWS-API-Gateway in Verbindung mit einer VPC-Verbindung verwenden und für den Network Load Balancer das Proxy-Protokoll v2 aktiviert ist, wird auch eine 400 Bad Request ausgeführt.

Ich habe den ganzen Nachmittag gebraucht, um es herauszufinden. Wenn es jemandem helfen könnte, wäre ich froh :)

— Daniel
quelle

0

Ich bekam die gleiche Ausnahme, wenn eine Seite geladen wurde,

NFO: Error parsing HTTP request header
 Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens
    at org.apache.coyote.http11.InternalInputBuffer.parseRequestLine(InternalInputBuffer.java:139)
    at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1028)
    at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:637)
    at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.lang.Thread.run(Thread.java:748)

Ich stellte fest, dass eine meiner Seiten-URL https anstelle von http war. Als ich dieselbe änderte, war der Fehler verschwunden.

— Asif Iquebal Ajazi
quelle

0

Dies geschieht normalerweise, wenn Sie ein URI-Schema verwenden , das von dem Server, auf dem die App bereitgestellt wird, nicht unterstützt wird. Daher möchten Sie entweder überprüfen, welche Schemata Ihr Server unterstützt, und Ihre Anforderung URIentsprechend ändern , oder Sie möchten die Unterstützung für dieses Schema in Ihrem Server hinzufügen. Der Umfang Ihrer Bewerbung soll Ihnen bei der Entscheidung helfen.

— Anfänger
quelle

0

Es passierte mir, als ich denselben Port im SSH-Tunnel SOCKS zum Ausführen von Proxy im 8080-Port verwendet hatte und mein Server und mein Firefox-Browser-Proxy auf diesen Port eingestellt waren und dieses Problem hatten.

— privatejava
quelle

0

In meinem Fall musste ich den Browserverlauf / die Cookies löschen, um diesen Fehler zu beseitigen.

— Rustylepord
quelle