java.lang.IllegalArgumentException: caractere inválido encontrado no nome do método. Os nomes de métodos HTTP devem ser tokens

161

Estou ficando abaixo do rastreamento de pilha ao implantar meu aplicativo em um ambiente Apache Tomcat 8 com vários servidores. Estou recebendo esse erro frequentemente e parece que está bloqueando o thread do 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)

Alguém pode me orientar sobre como solucionar problemas ou restringir essa exceção? Não estou recebendo nenhuma referência a nenhum dos meus arquivos de origem do aplicativo. Tentei pesquisar no Google e, nos links que diz, você está tentando acessar o URL http através de https, o que parece improvável. Não estou recebendo esse erro quando o aplicativo é executado em uma única instância do Tomcat 8. Eu recebo isso apenas em um ambiente com vários servidores.

Também estou compartilhando as metatags incorporadas em cada página, se isso ajudar a identificar a 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">

Também estou usando o seguinte em algumas páginas, que basicamente é o mesmo que acima:

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

Mesmo que alguém ajude a orientar minha tentativa de solução de problemas, isso será útil, pois atualmente não tenho idéia de onde procurar.

Desde já, obrigado.

tomcat8 illegalargumentexception

— user2016012
fonte

266

Essa exceção pode ocorrer quando você tenta executar a solicitação HTTPS do cliente no nó de extremidade que não está habilitado para HTTPS. O cliente criptografará os dados da solicitação quando o servidor estiver esperando dados brutos.

— Petar Tonev
fonte

1

Não sei se entendi esta resposta. Eu tenho um aplicativo Spring Boot 1.5.1 e vi essa exceção no meu log. Meu aplicativo responde apenas por SSL na porta 8443 (redirecionada da porta 443) e possui apenas um conector para SSL. Você está dizendo que alguém poderia tentar http: em vez de https: na porta 443?

— Jim Archer

5

Essas exceções acontecem quando há uma incompatibilidade entre o que o servidor espera e o que recebe. O que você disse é um dos cenários possíveis. Talvez exista um ponto de extremidade no servidor que não seja executado em https, mas alguém tenta acessá-lo dessa maneira?

— Petar Tonev

1

Olá Peter ... O problema acabou sendo que alguém criou uma regra de Tabelas IP para encaminhar a porta 80 para a porta 8443, portanto, qualquer pessoa que acessasse o site usando http na porta 80 causou esse erro. Adicionamos um conector Tomcat para redirecionar a porta 8080 para 8443 e configuramos a regra de Tabelas IP para encaminhar a porta 80 para a porta 8080, e o problema está praticamente desaparecido. Obrigado pela sua resposta!

— Jim Archer

1

@PeterTonev: Alguma idéia de como (redirecionar https para http || desativar https || capturar o erro para mostrar pelo menos uma mensagem de erro significativa)?

— crusy 12/05/19

1

Algo @crusy que podem ajudá-lo aqui para o tratamento de exceção é ligação

— Petar Tonev

56

Recebi a mesma exceção quando testei localmente. O problema foi um esquema de URL na minha solicitação.

mudança https:// to http:// in your client url.

Provavelmente ajuda.

— JustCode
fonte

2

Claro que funciona, mas observe que a comunicação por HTTP não é segura.

— Paramvir Singh Karwal

23

Você está chamando o servidor local com http : // localhost: 8080 / foo / bar. Chame-o com https : // localhost: 8080 / foo / bar. Isso resolve o problema

— Shivan Sawant
fonte

Provavelmente você não terá https: // no 8080. Altere a chamada para https: // localhost: 8443 / foo / bar - Aqui está o exemplo de link - Rodrigo R. Coelho

— Rodrigo R. Coelho

9

Caso alguém esteja usando arrogância:

Altere o esquema para HTTPou HTTPS, dependendo das necessidades, antes de executar a execução.

Carteiro:

Alterar o caminho da URL para http://ou https://no endereço da URL

— Cyber
fonte

8

Eu recebi essa exceção não relacionada a problemas de TLS. No meu caso, o valor do cabeçalho Content-Length não correspondia ao comprimento do corpo.

— mibollma
fonte

2

Não posso agradecer o suficiente. Todos os outros pedidos POST estavam falhando com o erro 400 e eu estava pronto para arrancar meu cabelo. Acontece que o não envio do content-lengthcabeçalho resolve esse problema.

— Alexander Woodblock

2

Eu estava recebendo um atraso de 30 a 90 segundos para solicitações do Postman para desenvolvedores locais - era esse o problema! Desativar o Content-Lengthcabeçalho corrigiu o atraso.

— Alok

1

Respondendo a essa pergunta antiga (para outras que possam ajudar)

configuração correta do seu httpd conf fará com que o problema seja resolvido. Instale qualquer servidor httpd, se você não tiver um.

Listando minha configuração aqui.

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

edite o arquivo como acima e reinicie o httpd como abaixo

[smilyface@box002 ~]$ sudo service httpd restart

E, em seguida, solicitar com com httpsfuncionará sem exceção.
Também solicitar com httpencaminhará para https! Não se preocupe.

— smilyface
fonte

1

Resolvi esse erro fazendo duas coisas no navegador Chrome:

Pressione Ctrl + Shift + Delete e limpe todos os dados de navegação desde o início.
Vá para o Chrome: Configurações -> Configurações avançadas -> Abrir configurações de proxy -> Propriedades da Internet, vá para a janela Conteúdo e clique no botão Limpar estado SSL.

Este site também possui essas informações e outras opções: https://www.thesslstore.com/blog/fix-err-ssl-protocol-error/

— Ravi Shankar Kota
fonte

1

Eu sei que esse é um thread antigo, mas há um caso específico em que isso pode acontecer:

Se você estiver usando o gateway api da AWS juntamente com um link VPC e se o Network Load Balancer tiver o protocolo proxy v2 ativado, uma 400 Solicitação incorreta também ocorrerá.

Levei a tarde inteira para descobrir, então, se isso puder ajudar alguém, eu ficaria feliz :)

— Daniel
fonte

0

Eu estava recebendo a mesma exceção, sempre que uma página era carregada,

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)

Descobri que um dos URLs da minha página era https em vez de http. Quando mudei o mesmo, o erro desapareceu.

— Asif Iquebal Ajazi
fonte

0

Isso geralmente acontece quando você está usando um esquema de URI que não é suportado pelo servidor no qual o aplicativo está implantado. Portanto, convém verificar o que todos os esquemas seu servidor suporta e modificar sua solicitação URIadequadamente ou adicionar o suporte a esse esquema em seu servidor. O escopo do seu aplicativo deve ajudá-lo a decidir sobre isso.

— novato
fonte

0

Aconteceu comigo quando eu tinha uma mesma porta usada no túnel ssh SOCKS para executar o Proxy na porta 8080 e meu servidor e meu proxy do navegador firefox foram definidos para essa porta e obtive esse problema.

— privatejava
fonte

0

No meu caso, tive que limpar o histórico / cookies do navegador para me livrar desse erro.

— rustylepord
fonte