for - java.lang.IllegalArgumentException: se encontró un carácter no válido(CR o LF) en el nombre del método

spring boot no tomcat

Question

Tengo una aplicación Spring MVC que se ejecuta en Tomcat8. Una vez en uno o dos días recibo una excepción en mi archivo de registro

15-Jun-2016 10:43:39.832 INFO [http-nio-8080-exec-50] 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 (CR or LF) found in method name
at org.apache.coyote.http11.AbstractNioInputBuffer.parseRequestLine(AbstractNioInputBuffer.java:228)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1502)
at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1458)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:745)

¿Alguien tiene una idea de lo que esto podría ser?

Answer 1

Encontré este mismo error y no puede tener absolutamente nada que ver con su configuración de Tomcat. Me volvía loco tratando de encontrar el error. Estaba sirviendo múltiples aplicaciones de seis dominios con solo uno de los dominios que producen el Proxy Error 502. El mensaje ''Carácter no válido'' se encuentra en el registro catalina.out de Tomcat:

Apr 18, 2018 10:31:06 AM org.apache.coyote.http11.AbstractHttp11Processor process
INFO: Error parsing HTTP request header
Note: further occurrences of HTTP header parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character (CR or LF) found in method name
at org.apache.coyote.http11.InternalAprInputBuffer.parseRequestLine(InternalAprInputBuffer.java:177)
at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:992)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:625)
at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2454)
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)

En mi caso, estoy enviando solicitudes a las aplicaciones Tomcat desde Apache httpd usando un proxy. Las directivas de proxy se utilizan dentro del host virtual de httpd, normalmente configurado en /etc/httpd/conf.d/virtualhosts.conf. El proxy primero redirige las solicitudes http sin cifrar recibidas en el puerto 80 al puerto 443.

<VirtualHost *:80>
ServerName www.domain1.com
ServerAlias domain1.com *.domain1.com
Redirect permanent / https://domain1.com/
</VirtualHost>

La solicitud redirigida se maneja como una solicitud https cifrada entrante normal.

La configuración incorrecta. ¡NO COPIAR ESTO!

 <VirtualHost *:443>
ServerName www.domain1.com
ServerAlias domain1.com *.domain1.com
ProxyRequests off
ProxyPreserveHost on
CustomLog "/etc/httpd/logs/domain1ssl.log" "%h %l %u %t /"%r/" %>s %b"
ErrorLog "/etc/httpd/logs/domain1ssl_error.log"
SSLEngine on
SSLProxyEngine on
SSLCertificateFile /etc/pki/tls/certs/domain1.com.crt
SSLCertificateKeyFile /etc/pki/tls/private/domain1.key
SSLCertificateChainFile /etc/pki/tls/certs/ca-bundle-domain1.crt
ProxyPass / https://domain1.com:8081/
ProxyPassReverse / https://domain1.com:8081/
</VirtualHost>

Tenga en cuenta las dos líneas:

ProxyPass / https://domain1.com:8081/
ProxyPassReverse / https://domain1.com:8081/

Las directivas le dicen a Apache que envíe la solicitud al proceso que escucha en el puerto 8081 como una solicitud cifrada. Este fue un error tipográfico de mi parte. El protocolo debe ser http. Tomcat no está manejando el cifrado, httpd está manejando el cifrado. Así que Tomcat está recibiendo una solicitud cifrada en un conector no cifrado que resulta en el error de ''carácter no válido'' excepcionalmente bien explicado en la respuesta de Maciej Marczuk ( ). Muchas gracias por ayudarme a encontrar mi error tipográfico.

Las directivas proxy deben ser:

ProxyPass / http://domain1.com:8081/
ProxyPassReverse / http://domain1.com:8081/

Espero que esto ayude a alguien. Aclamaciones.

Answer 2

Este error es causado por una solicitud HTTP mal formada. En la mayoría de los casos, este mensaje es engañoso porque este error suele ocurrir cuando intenta acceder a una página no segura a través de https. Tomcat no sabe que la solicitud entrante está encriptada y está tratando de interpretarla como una solicitud http simple y no segura.

Así es como podría verse en los registros:

Solicitud HTTP estándar y adecuada ( http: // localhost: 8080 )

Received [GET /index.html HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Linux; Android 6.0; Nexus 5 Build/MRA58N) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/46.0.2490.76 Mobile Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip, deflate, sdch
Accept-Language: pl,en-US;q=0.8,en;q=0.6
Cookie: Idea-xxxxx; JSESSIONID=3dxxxxx
] 

Solicitud de HTTPS ( https: // localhost: 8080 )

Received [¹µHÄ;ß!P@<¿
#|vFBb-Ëiø/5
jÿ
hhttp/1.1uP
] 

Como puede ver en la segunda solicitud, hay caracteres desconocidos en lugar del nombre del método HTTP adecuado (por ejemplo, GET)

Entonces, si su servidor no tiene configuración SSL y el error se produce "una vez en uno o dos días", es probable que alguien esté intentando llegar a su sitio web a través de https (probablemente algún tipo de bot)

Finalmente, alguien está intentando enviar una solicitud HTTP simple no segura pero mal formada (a través de su propia aplicación: bot u otro cliente personalizado).

Answer 3

Este error puede ocurrir debido a un mal puerto.

En realidad, observe que si desea aceptar el lanzamiento de HTTPS, el puerto Tomcat predeterminado es 8443: https: // localhost: 8443

cuando cambia el conector y el almacén de claves pero sigue obteniendo 8080 en lugar de 8443

Answer 4

Solo agrega este problema también con springboot. Estaba usando una URL HTTPS pero mi servidor local no estaba usando SSL, así que cambié la URL a HTTP y funcionó.

Answer 5

También tuve el mismo problema con la solicitud HTTP POST: el problema era que "los datos JSON no eran correctos". Tenía un atributo de enumeración en la clase que estaba pasando mal (error ortográfico) en el objeto. Y estaba recibiendo esta excepción.

Answer 6

Vuelva a comprobar la solicitud enviada. Si el punto final no está habilitado para https, pase la solicitud con http.