java.lang.IllegalArgumentException: se encontró un carácter no válido en el nombre del método. Los nombres de métodos HTTP deben ser tokens

161

Me encuentro debajo del seguimiento de la pila cuando estoy implementando mi aplicación en un entorno Apache Tomcat 8 de varios servidores. Recibo este error con frecuencia, y parece que está bloqueando el hilo de 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)

¿Alguien puede indicarme cómo solucionar o reducir tal excepción? No obtengo ninguna referencia a ninguno de los archivos fuente de mi aplicación. Traté de buscar en Google, y en los enlaces que decía, está intentando acceder a la URL http a través de https, lo que parece poco probable. No recibo este error cuando la aplicación se ejecuta en una sola instancia de Tomcat 8. Solo obtengo esto en un entorno de servidores múltiples.

También estoy compartiendo las metaetiquetas que he incrustado en cada página, si eso ayuda a identificar 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">

También estoy usando lo siguiente en algunas páginas, que básicamente es lo mismo que arriba:

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

Incluso si alguien me ayuda a dar una dirección a mi intento de solución de problemas, será útil, ya que actualmente no tengo idea de dónde buscar.

Gracias por adelantado.

tomcat8 illegalargumentexception

— usuario2016012
fuente

266

Esta excepción puede ocurrir cuando intenta ejecutar la solicitud HTTPS del cliente en el punto final que no está habilitado para HTTPS. El cliente cifrará los datos de la solicitud cuando el servidor esté esperando datos sin procesar.

— Petar Tonev
fuente

1

No estoy seguro de entender esta respuesta. Tengo una aplicación Spring Boot 1.5.1 y vi esta excepción en mi registro. Mi aplicación solo responde para SSL en el puerto 8443 (redirigido desde el puerto 443) y solo tiene un conector para SSL. ¿Estás diciendo que alguien podría probar http: en lugar de https: en el puerto 443?

— Jim Archer

55

Tales excepciones ocurren cuando hay una falta de coincidencia entre lo que el servidor espera y lo que obtiene. Lo que dijiste es uno de los posibles escenarios. ¿Tal vez hay un punto final en su servidor que no se ejecuta en https, pero alguien intenta acceder a él de esta manera?

— Petar Tonev

1

Hola Peter ... El problema terminó siendo que alguien creó una regla de tablas IP para reenviar el puerto 80 al puerto 8443, por lo que cualquiera que accedió al sitio usando http en el puerto 80 causó ese error. Agregamos un conector Tomcat para redirigir el puerto 8080 al 8443 y configuramos la regla de tablas IP para reenviar el puerto 80 al puerto 8080 y el problema ya no existe. Gracias por tu respuesta!

— Jim Archer

1

@PeterTonev: ¿Alguna idea de cómo (redirigir https a http || desactivar https || capturar el error para al menos mostrar un mensaje de error significativo)?

— crujiente

1

@crusy Algo que puede ayudarlo aquí para el manejo de excepciones es el enlace

— Petar Tonev

56

Obtuve la misma excepción cuando probé localmente. El problema era un esquema de URL en mi solicitud.

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

Probablemente ayude.

— JustCode
fuente

2

Claro que funciona, pero tenga en cuenta que la comunicación a través de HTTP no es segura.

— Paramvir Singh Karwal

23

Está llamando al servidor local con http : // localhost: 8080 / foo / bar. Llámalo con https : // localhost: 8080 / foo / bar. Esto resuelve el problema

— Shivan Sawant
fuente

Probablemente no tendrá https: // en 8080. Cambie la llamada a https: // localhost: 8443 / foo / bar - Aquí está el enlace de ejemplo - Rodrigo R. Coelho

— Rodrigo R. Coelho

9

En caso de que alguien use arrogancia:

Cambiar el esquema de HTTPo HTTPS, dependerá de las necesidades, antes de golpear la ejecutan.

Cartero:

Cambiar la ruta de URL para http://o https://en la dirección URL

— Cibernético
fuente

8

Recibí esta excepción no relacionada con ningún problema de TLS. En mi caso, el valor del encabezado Content-Length no coincidía con la longitud del cuerpo.

— mibollma
fuente

2

No puedo agradecerte lo suficiente. Todas las demás solicitudes POST fallaban con el error 400, y estaba listo para arrancarme el pelo. Resultó que no enviar content-lengthencabezado resuelve este problema.

— Alexander Woodblock

2

Estaba obteniendo un retraso de 30-90 segundos para las solicitudes de cartero a los desarrolladores locales, ¡resultó que era este problema! Deshabilitar el Content-Lengthencabezado solucionó el retraso.

— Alok

1

Respondiendo a esta vieja pregunta (para otros que puedan ayudar)

Configurar su httpd conf correctamente resolverá el problema. Instale cualquier servidor httpd, si no tiene uno.

Listado de mi configuración aquí.

[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 el archivo como se indica arriba y luego reinicie httpd como se muestra a continuación

[smilyface@box002 ~]$ sudo service httpd restart

Y luego solicitar con con httpsfuncionará sin excepción.
También solicite con httpreenvío a https! Sin preocupaciones.

— cara sonriente
fuente

1

Este error se resolvió haciendo 2 cosas en el navegador Chrome:

Presioné Ctrl + Shift + Delete y borré todos los datos de navegación desde el principio.
Vaya a Chrome: Configuración -> Configuración avanzada -> Abrir configuración de proxy -> Propiedades de Internet, luego vaya a la ventana Contenido y haga clic en el botón Borrar estado SSL.

Este sitio tiene esta información y otras opciones también: https://www.thesslstore.com/blog/fix-err-ssl-protocol-error/

— Ravi Shankar Kota
fuente

1

Sé que este es un hilo viejo, pero hay un caso particular cuando esto puede suceder:

Si está utilizando la puerta de enlace API de AWS junto con un enlace VPC, y si el Network Load Balancer tiene el protocolo proxy v2 habilitado, también se producirá una 400 Solicitud incorrecta.

Me llevó toda la tarde averiguarlo, así que si puede ayudar a alguien, me alegraría :)

— Daniel
fuente

0

Recibía la misma excepción, cada vez que se cargaba una página,

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)

Descubrí que una de las URL de mi página era https en lugar de http, cuando cambié la misma, el error desapareció.

— Asif Iquebal Ajazi
fuente

0

Esto generalmente ocurre cuando está utilizando un esquema de URI que no es compatible con el servidor en el que se implementa la aplicación. Por lo tanto, es posible que desee verificar qué esquemas admite su servidor y modificar su solicitud en URIconsecuencia, o puede agregar el soporte para ese esquema en su servidor. El alcance de su aplicación debería ayudarlo a decidir sobre esto.

— novato
fuente

0

Me sucedió cuando tenía un mismo puerto utilizado en SOCKS de túnel ssh para ejecutar Proxy en el puerto 8080 y mi servidor y mi proxy de navegador Firefox se configuraron en ese puerto y obtuve este problema.

— Privatejava
fuente

0

En mi caso, tuve que borrar el historial del navegador / cookies para deshacerme de este error.

— rustylepord
fuente