java.lang.IllegalArgumentException: недопустимый символ (CR или LF), найденный в имени метода

У меня есть приложение Spring MVC, работающее на Tomcat8. Один раз в день или два я получаю исключение в моем файле журнала

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)

У кого-нибудь есть идея, что это может быть?

 Narendra N17 июн. 2016 г., 14:12
@Vladimir Vagaytsev - запрос от Web, и у нас есть настройка LB с nginx. На сервере выдает вышеуказанную ошибку и выдает Bad Gateway. scalecale.com/tips/nginx/502-bad-gateway-error-using-nginx не помогло :(
 Ramesh Subramanian29 июн. 2016 г., 08:02
Привет VadOs, твой кот работает в облачной машине? если да, пожалуйста, обратитесь - (cyber4.org/three-legged-pig/...) а также (confluence.atlassian.com/confkb/...)
 Vladimir Vagaytsev15 июн. 2016 г., 15:28
Похоже, заголовок входящего HTTP-запроса искажен. Как говорится в сообщении об ошибке, заголовок запроса содержит запрещенный символ в имени метода HTTP (конец строки), поэтому анализатор запросов завершается с ошибкой за исключением. Так что это не проблема в вашем коде. Вы можете либо проигнорировать его, либо попросить отправителя проверить правильность запроса.
 xenteros29 июл. 2016 г., 11:22
Ребята, вы достигли какого-либо прогресса?
 Narendra N17 июн. 2016 г., 14:37
Я полагаю, что это исключение больше относится к настройке SSL, так как та же самая (почти похожая) война работает на компьютерах сцены - где мы получаем доступ с помощью http - тогда как тестовая настройка производства (с использованием https) - это то, с чем мы сталкиваемся вопрос. Нужно проверить нашу конфигурацию nginx. В случае, если вы нашли исправление - сделайте, дайте мне знать :)

Ответы на вопрос(6)

ен https, передайте запрос с помощью http.

Решение Вопроса

то сообщение вводит в заблуждение, поскольку эта ошибка обычно возникает при попытке доступа к незащищенной странице через https. Tomcat не знает, что входящий запрос зашифрован, и пытается интерпретировать этот запрос как простой незащищенный http-запрос.

Вот как это может выглядеть в логах:

Стандартный правильный HTTP-запрос (HTTP: // локальный: 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

] 

HTTPS-запрос (https: // локальный: 8080)

Received [¹µHÄ;ß[email protected]<¿
                                                                                                                                #|vFBb-Ëiø/5
jÿ

                   hhttp/1.1uP
                               
] 

Как вы можете видеть во втором запросе, вместо правильного имени метода HTTP есть неизвестные символы (например, GET)

Так что, если на вашем сервере нет конфигурации SSL и ошибка возникает «раз в день или два», то, возможно, кто-то пытается зайти на ваш сайт через https (возможно, какой-то бот)

В конце концов, кто-то пытается отправить незащищенный, но неправильно сформированный простой HTTP-запрос (через собственное приложение - бот или другой пользовательский клиент).

 KJEjava4803 апр. 2017 г., 12:48
Эта ошибка приводит к тому, что tomcat перестает работать ?? Я получаю это исключение много раз, и мой tomcat останавливается через регулярные промежутки времени ...
 prab211228 июл. 2017 г., 11:04
Нет, это не позволяет коту перестать работать.
 shareef23 сент. 2017 г., 13:58
это может быть бот Google?

На самом деле, обратите внимание, что если вы хотите принять команду throw HTTPS, порт Tomcat по умолчанию - 8443:https: // локальный: 8443

когда вы меняете разъем и хранилище ключей, но по-прежнему выбираете 8080 вместо 8443

 Edwin Buck18 июл. 2017 г., 20:38
Это хорошая фактическая информация, но она не была написана так, чтобы отвечать на поставленный вопрос. Пожалуйста, удалите этот ответ и добавьте его в качестве комментария к наиболее подходящему ответу.
 hadf19 июл. 2017 г., 22:11
Я не согласна Я разместил этот комментарий, потому что у меня была точно такая же ошибка из-за плохого порта
 Edwin Buck20 июл. 2017 г., 20:23
Это нормально, но, пожалуйста, перепишите свой ответ, чтобы включить вопрос каким-либо образом. Ваш ответ может также гласить: «Обратите внимание, что если вы хотите принять команду throw HTTP, порт Tomcat по умолчанию - 8080», и он будет содержать ту же информацию: информацию о портах по умолчанию. Я не говорю, что эта информация не связана с его проблемой. Факт верный, но так же как и тот факт, что по умолчанию для порта FTP используется 21. До тех пор, пока вы не покажете связь факта и проблемы, вы не отвечаете на вопрос, вы просто говорите факты.

была в том, что «данные JSON были неверны». У меня был атрибут enum в классе, который я неправильно передавал (орфографическая ошибка) в объекте. И я получал это исключение.

Я столкнулся с той же ошибкой, и она не может иметь абсолютно никакого отношения к вашей конфигурации Tomcat. Это сводило меня с ума, пытаясь найти ошибку. Я обслуживал несколько приложений из шести доменов, и только один из доменов выдал ошибку Proxy 502. Затем в журнале Tomcat catalina.out появляется сообщение «Недопустимый символ»:

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)

В моем случае я отправляю запросы приложениям Tomcat из Apache httpd с помощью прокси. Директивы прокси используются в виртуальном хосте httpd, обычно настраиваемом в /etc/httpd/conf.d/virtualhosts.conf. Прокси сначала перенаправляет все незашифрованные http-запросы, полученные через порт 80, на порт 443.

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

Затем перенаправленный запрос обрабатывается как обычный входящий зашифрованный запрос https.

Неправильная конфигурация. НЕ КОПИРУЙТЕ ЭТО!

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

Обратите внимание на две строки:

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

Директивы говорят Apache отправлять запрос процессу, прослушивающему порт 8081, как зашифрованный запрос. Это была опечатка с моей стороны. Протокол должен быть http. Tomcat не занимается шифрованием, httpd - шифрованием. Таким образом, Tomcat получает зашифрованный запрос по незашифрованному соединителю, в результате чего ошибка «Недопустимый символ» исключительно хорошо объяснена в Maciej Marczuk's (https://stackoverflow.com/users/1545775/maciej-marczuk) ответ. Большое спасибо за подсказку, чтобы я нашел мою опечатку.

Директивы прокси должны быть:

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

Надеюсь, это кому-нибудь поможет. Приветствия.

Просто добавьте эту проблему и в Springboot. Я использовал HTTPS URL, но мой локальный сервер не использовал SSL, поэтому я переключил URL на HTTP, и это сработало.

Ваш ответ на вопрос