java.lang.IllegalArgumentException: carattere non valido trovato nel nome del metodo. I nomi dei metodi HTTP devono essere token

161

Ricevo sotto la traccia dello stack quando sto distribuendo la mia applicazione in un ambiente Apache Tomcat 8 multi-server. Ricevo spesso questo errore e sembra che stia bloccando il thread 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)

Qualcuno può dirmi come risolvere o limitare tale eccezione? Non ricevo alcun riferimento a nessuno dei miei file di origine dell'applicazione. Ho provato a cercare su Google, e tra i collegamenti che hai detto, stai provando ad accedere a http url tramite https, il che sembra improbabile. Non visualizzo questo errore quando l'applicazione viene eseguita su una singola istanza di Tomcat 8. Ottengo questo solo in un ambiente multi-server.

Condivido anche i meta tag che ho incorporato in ogni pagina, se ciò aiuta a identificare la causa.

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

Sto anche usando quanto segue in alcune pagine, che sostanzialmente è lo stesso di cui sopra:

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

Anche se qualcuno mi aiuta a dare una direzione al mio tentativo di risoluzione dei problemi, ciò sarà utile, poiché attualmente non ho idea di dove esaminare.

Grazie in anticipo.

tomcat8 illegalargumentexception

— user2016012
fonte

267

Questa eccezione può verificarsi quando si tenta di eseguire la richiesta HTTPS dal client sull'endpoint che non è abilitato HTTPS. Il client crittograferà i dati della richiesta quando il server prevede dati non elaborati.

— Petar Tonev
fonte

1

Non sono sicuro di aver capito questa risposta. Ho un'app Spring Boot 1.5.1 e ho visto questa eccezione nel mio registro. La mia app risponde solo per SSL sulla porta 8443 (reindirizzata dalla porta 443) e ha solo un connettore per SSL. Stai dicendo che qualcuno potrebbe provare http: anziché https: sulla porta 443?

— Jim Archer,

5

Tali eccezioni si verificano quando esiste una discrepanza tra ciò che il server si aspetta e ciò che ottiene. Quello che hai detto è uno dei possibili scenari. Forse c'è un endpoint nel tuo server che non funziona su HTTPS, ma qualcuno prova ad accedervi in questo modo?

— Petar Tonev,

1

Ciao Peter ... Il problema è stato che qualcuno ha creato una regola Tabelle IP per inoltrare la porta 80 alla porta 8443, quindi chiunque abbia colpito il sito usando http sulla porta 80 ha causato quell'errore. Abbiamo aggiunto un connettore Tomcat per reindirizzare la porta da 8080 a 8443 e impostato la regola Tabelle IP per inoltrare la porta 80 alla porta 8080 e il problema è quasi sparito. Grazie per la tua risposta!

— Jim Archer,

1

@PeterTonev: Qualche idea su come (reindirizzare https su http || disable https || rilevare l'errore per mostrare almeno un messaggio di errore significativo)?

— croccante

1

@crusy Qualcosa che può aiutarti qui per la gestione delle eccezioni è il link

— Petar Tonev,

56

Ho avuto la stessa eccezione quando ho testato localmente. Il problema era uno schema URL nella mia richiesta.

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

Probabilmente aiuta.

— JustCode
fonte

2

Certo che funziona, ma nota che la comunicazione su HTTP non è sicura.

— Paramvir Singh Karwal,

23

Stai chiamando il server locale con http : // localhost: 8080 / foo / bar. Chiamalo con https : // localhost: 8080 / foo / bar. Questo risolve il problema

— Shivan Sawant
fonte

1

Probabilmente non avrai https: // su 8080. Cambia la chiamata in https: // localhost: 8443 / foo / bar - Ecco il link di esempio - Rodrigo R. Coelho

— Rodrigo R. Coelho

9

Nel caso in cui qualcuno stia usando swagger:

Modificare lo schema in HTTPo HTTPS, a seconda delle esigenze, prima di eseguire l'esecuzione.

Postino:

Cambia il percorso dell'URL in http://o https://nell'indirizzo url

— Cyber
fonte

8

Ho ricevuto questa eccezione non correlata a eventuali problemi TLS. Nel mio caso il valore dell'intestazione Content-Length non corrispondeva alla lunghezza del corpo.

— mibollma
fonte

2

Non posso ringraziarti abbastanza. Ogni altra richiesta POST stava fallendo con l'errore 400 ed ero pronto a strapparmi i capelli. Si è scoperto che non inviare l' content-lengthintestazione risolve questo problema.

— Alexander Woodblock,

2

Stavo ricevendo un ritardo di 30-90 secondi per le richieste del postino agli sviluppatori locali - si scopre, era questo il problema! La disabilitazione Content-Lengthdell'intestazione ha risolto il ritardo.

— Alok

1

Rispondere a questa vecchia domanda (per altri che potrebbero essere d'aiuto)

Configurare correttamente la configurazione di httpd risolverà il problema. Installa qualsiasi server httpd, se non ne hai uno.

Elencando la mia configurazione qui.

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

modificare il file come sopra e quindi riavviare httpd come di seguito

[smilyface@box002 ~]$ sudo service httpd restart

E quindi richiedere con con httpsfunzionerà senza eccezioni.
Anche la richiesta con httpverrà inoltrata a https! Nessun problema.

— smilyface
fonte

1

Ho risolto questo errore facendo 2 cose nel browser Chrome:

Premi Ctrl + Maiusc + Elimina e cancella tutti i dati di navigazione dall'inizio.
Vai a Chrome: Impostazioni -> Impostazioni avanzate -> Apri impostazioni proxy -> Proprietà Internet, quindi vai alla finestra Contenuto e fai clic sul pulsante Cancella stato SSL.

Questo sito ha anche queste informazioni e altre opzioni: https://www.thesslstore.com/blog/fix-err-ssl-protocol-error/

— Ravi Shankar Kota
fonte

1

So che questo è un vecchio thread, ma c'è un caso particolare in cui ciò può accadere:

Se si utilizza AWS api gateway accoppiato con un collegamento VPC e se Network Load Balancer ha il protocollo proxy v2 abilitato, si verificherà anche una richiesta non valida 400.

Mi ci è voluto tutto il pomeriggio per capirlo, quindi se può aiutare qualcuno sarei felice :)

— Daniel
fonte

0

Stavo ottenendo la stessa eccezione, ogni volta che una pagina veniva caricata,

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)

Ho scoperto che uno dei miei URL della pagina era https anziché http, quando ho cambiato lo stesso, l'errore era sparito.

— Asif Iquebal Ajazi
fonte

0

Ciò si verifica in genere quando si utilizza uno schema URI che non è supportato dal server in cui è distribuita l'app. Quindi, potresti voler controllare quali sono tutti gli schemi supportati dal tuo server e modificare di conseguenza la tua richiesta URI, oppure potresti aggiungere il supporto per quello schema nel tuo server. L'ambito della tua applicazione dovrebbe aiutarti a decidere.

— novizio
fonte

0

Mi è successo quando avevo una stessa porta utilizzata nel tunnel ssh SOCKS per eseguire il proxy nella porta 8080 e il mio server e il mio proxy browser Firefox erano impostati su quella porta e ho riscontrato questo problema.

— privatejava
fonte

0

Nel mio caso ho dovuto cancellare la cronologia / i cookie del browser per eliminare questo errore.

— rustylepord
fonte