java.lang.IllegalArgumentException: caractère non valide trouvé dans le nom de la méthode. Les noms de méthode HTTP doivent être des jetons

161

J'obtiens sous la trace de la pile lorsque je déploie mon application dans un environnement Apache Tomcat 8 multi-serveurs. J'obtiens fréquemment cette erreur, et il semble que cela bloque le fil Tomcat:

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)

Quelqu'un peut-il me dire comment résoudre ou réduire une telle exception? Je ne reçois aucune référence à aucun de mes fichiers source d'application. J'ai essayé de rechercher sur Google, et parmi les liens indiqués, vous essayez d'accéder à http url via https, ce qui semble peu probable. Je n'obtiens pas cette erreur lorsque l'application s'exécute sur une seule instance de Tomcat 8. Je reçois cela uniquement dans un environnement multi-serveur.

Je partage également les balises meta que j'ai intégrées sur chaque page, si cela aide à identifier la cause.

<%
    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">

J'utilise également ce qui suit dans quelques pages, ce qui est fondamentalement le même que ci-dessus:

<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" />

Même si quelqu'un m'aide à donner une direction à ma tentative de dépannage, cela sera utile, car actuellement je n'ai aucune idée de l'endroit où chercher.

Merci d'avance.

tomcat8 illegalargumentexception

— utilisateur2016012
source

267

Cette exception peut se produire lorsque vous essayez d'exécuter une demande HTTPS du client sur un point de terminaison qui n'est pas activé HTTPS. Le client cryptera les données de la demande lorsque le serveur attend des données brutes.

— Petar Tonev
source

1

Je ne suis pas sûr de comprendre cette réponse. J'ai une application Spring Boot 1.5.1 et j'ai vu cette exception dans mon journal. Mon application ne répond que pour SSL sur le port 8443 (redirigé depuis le port 443) et n'a qu'un seul connecteur pour SSL. Êtes-vous en train de dire que quelqu'un pourrait essayer http: au lieu de https: sur le port 443?

— Jim Archer

5

De telles exceptions se produisent lorsqu'il y a un décalage entre ce que le serveur attend et ce qu'il obtient. Ce que vous avez dit est l'un des scénarios possibles. Peut-être y a-t-il un point de terminaison dans votre serveur qui ne fonctionne pas sur https, mais quelqu'un essaie d'y accéder de cette façon?

— Petar Tonev

1

Salut Peter ... Le problème a fini par être que quelqu'un a créé une règle de tables IP pour transférer le port 80 vers le port 8443, donc quiconque a frappé le site en utilisant http sur le port 80 a causé cette erreur. Nous avons ajouté un connecteur Tomcat pour rediriger le port 8080 vers 8443 et avons configuré la règle des tables IP pour transférer le port 80 vers le port 8080 et le problème a pratiquement disparu. Merci pour votre réponse!

— Jim Archer

1

@PeterTonev: Une idée comment (rediriger https vers http || désactiver https || attraper l'erreur pour au moins afficher un message d'erreur significatif)?

— crusy

1

@crusy Quelque chose qui peut vous aider ici pour la gestion des exceptions est le lien

— Petar Tonev

56

J'ai eu la même exception lorsque j'ai testé localement. Le problème était un schéma d'URL dans ma demande.

Changement https:// to http:// in your client url.

Cela aide probablement.

— JustCode
source

2

Bien sûr, cela fonctionne, mais notez que la communication via HTTP n'est pas sécurisée.

— Paramvir Singh Karwal

23

Vous appelez le serveur local avec http : // localhost: 8080 / foo / bar. Appelez-le avec https : // localhost: 8080 / foo / bar. Cela résout le problème

— Shivan Sawant
source

1

Vous n'aurez probablement pas https: // sur 8080. Changez l'appel en https: // localhost: 8443 / foo / bar - Voici l'exemple de lien - Rodrigo R. Coelho

— Rodrigo R. Coelho le

9

Dans le cas où quelqu'un utilise swagger:

Modifiez le schéma en HTTPou HTTPS, en fonction des besoins, avant de lancer l'exécution.

Facteur:

Modifiez le chemin de l'URL vers http://ou https://dans l'adresse URL

— Cyber
source

8

J'ai reçu cette exception sans rapport avec aucun problème TLS. Dans mon cas, la valeur de l'en-tête Content-Length ne correspondait pas à la longueur du corps.

— mibollma
source

2

Je ne peux pas vous remercier assez. Toutes les autres demandes POST échouaient avec l'erreur 400 et j'étais prêt à m'arracher les cheveux. Il s'est avéré que ne pas envoyer d'en- content-lengthtête résout ce problème.

— Alexander Woodblock

2

J'avais un délai de 30 à 90 secondes pour les demandes de Postman aux développeurs locaux - il s'avère que c'était ce problème! La désactivation de l'en- Content-Lengthtête a corrigé le délai.

— Alok le

1

Répondre à cette vieille question (pour d'autres qui peuvent aider) La

configuration correcte de votre conf httpd résoudra le problème. Installez n'importe quel serveur httpd, si vous n'en avez pas.

Liste de ma configuration ici.

[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
        ...
        ...
        ...

éditez le fichier comme ci-dessus, puis redémarrez httpd comme ci-dessous

[smilyface@box002 ~]$ sudo service httpd restart

Et puis demander avec avec httpsfonctionnera sans exception.
Demandez également avec httpvolonté https! Pas de soucis.

— visage souriant
source

1

J'ai résolu cette erreur en faisant 2 choses dans le navigateur Chrome:

Appuyez sur Ctrl + Maj + Suppr et effacez toutes les données de navigation depuis le début.
Allez dans Chrome: Paramètres -> Paramètres avancés -> Ouvrir les paramètres du proxy -> Propriétés Internet, puis allez dans la fenêtre Contenu et cliquez sur le bouton Effacer l'état SSL.

Ce site contient également ces informations et d'autres options: https://www.thesslstore.com/blog/fix-err-ssl-protocol-error/

— Ravi Shankar Kota
source

1

Je sais que c'est un vieux fil, mais il y a un cas particulier où cela peut arriver:

Si vous utilisez la passerelle d'API AWS couplée à un lien VPC et si l'équilibreur de charge réseau a activé le protocole proxy v2, une 400 Bad Request se produira également.

Il m'a fallu tout l'après-midi pour le comprendre, donc si cela peut aider quelqu'un, je serais heureux :)

— Daniel
source

0

J'obtenais la même exception, chaque fois qu'une page était chargée,

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)

J'ai trouvé que l'une de mes URL de page était https au lieu de http, lorsque j'ai changé la même chose, l'erreur avait disparu.

— Asif Iquebal Ajazi
source

0

Cela se produit généralement lorsque vous utilisez un schéma d'URI qui n'est pas pris en charge par le serveur sur lequel l'application est déployée. Ainsi, vous souhaiterez peut-être vérifier tous les schémas pris en charge par votre serveur et modifier votre demande en URIconséquence, ou vous souhaiterez peut-être ajouter la prise en charge de ce schéma dans votre serveur. La portée de votre application devrait vous aider à prendre une décision à ce sujet.

— Noob
source

0

Cela m'est arrivé quand j'avais un même port utilisé dans le tunnel ssh SOCKS pour exécuter Proxy sur le port 8080 et que mon serveur et mon proxy de navigateur Firefox étaient définis sur ce port et ont eu ce problème.

— privatejava
source

0

Dans mon cas, j'ai dû effacer l'historique du navigateur / les cookies pour me débarrasser de cette erreur.

— rustylepord
source