java.lang.IllegalArgumentException: недопустимый символ в имени метода. Имена методов HTTP должны быть токенами

161

При развертывании приложения в многосерверной среде Apache Tomcat 8 я получаю трассировку ниже стека. Я получаю эту ошибку часто, и кажется, что она блокирует поток 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)

Кто-нибудь может указать мне, как устранить неполадки или сузить такое исключение? Я не получаю никаких ссылок на какие-либо исходные файлы моего приложения. Я пытался гуглить, и в одной из ссылок, которые он указал, вы пытаетесь получить доступ к http URL через https, что кажется маловероятным. Я не получаю эту ошибку, когда приложение работает на одном экземпляре Tomcat 8. Я получаю это только в многосерверной среде.

Я также делюсь метатегами, которые я встроил в каждую страницу, если это помогает определить причину.

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

Я также использую следующее на нескольких страницах, которые в основном такие же, как указано выше:

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

Даже если кто-то поможет определить направление моей попытки устранения неполадок, это будет полезно, так как в настоящее время я понятия не имею, где искать.

Заранее спасибо.

tomcat8 illegalargumentexception

— user2016012
источник

267

Это исключение может возникнуть при попытке выполнить HTTPS- запрос от клиента на конечной точке, для которой не включен HTTPS. Клиент зашифрует данные запроса, когда сервер ожидает необработанные данные.

— Петар тонев
источник

1

Я не уверен, что понимаю этот ответ. У меня есть приложение Spring Boot 1.5.1, и я увидел это исключение в своем журнале. Мое приложение отвечает только за SSL через порт 8443 (перенаправленный с порта 443) и имеет только один разъем для SSL. Вы говорите, что кто-то может попробовать http: вместо https: на порт 443?

— Джим Арчер

5

Такие исключения случаются, когда существует несоответствие между тем, что ожидает сервер, и тем, что он получает. То, что вы сказали, является одним из возможных сценариев. Может быть, на вашем сервере есть конечная точка, которая не работает по протоколу https, но кто-то пытается получить к ней доступ таким образом?

— Петар Тонев

1

Привет, Питер ... Проблема закончилась тем, что кто-то создал правило IP Tables для перенаправления порта 80 на порт 8443, поэтому любой, кто заходил на сайт, используя http на порту 80, вызывал эту ошибку. Мы добавили соединитель Tomcat для перенаправления порта 8080 на 8443 и настроили правило IP Tables для переадресации порта 80 на порт 8080, и проблема почти исчезла. Спасибо за ваш ответ!

— Джим Арчер

1

@PeterTonev: Есть идеи как (перенаправить https на http || отключить https || перехватить ошибку, чтобы хотя бы показать значимое сообщение об ошибке)?

— крутой

1

@crusy Что-то, что может помочь вам здесь для обработки исключений, это ссылка

— Петар Тонев

56

Я получил то же исключение при локальном тестировании. Проблема была в схеме URL в моем запросе.

+ Изменить https:// to http:// in your client url.

Наверное, это помогает.

— JustCode
источник

2

Конечно, это работает, но учтите, что связь по HTTP небезопасна.

— Парамвир Сингх Карвал

23

Вы вызываете локальный сервер с http : // localhost: 8080 / foo / bar. Звоните по адресу https : // localhost: 8080 / foo / bar. Это решает проблему

— Шиван Савант
источник

1

Возможно, у вас не будет https: // на 8080. Измените вызов на https: // localhost: 8443 / foo / bar - Вот примерная ссылка - Родриго Р. Коэльо

— Родриго Р. Коэльо

9

В случае, если кто-то использует чванство:

Измените Схему на HTTPили HTTPS, в зависимости от потребностей, до нажатия кнопки Выполнить.

Почтальон:

Изменить URL-адрес Путь к http://или https://в URL-адресе

— Cyber
источник

8

Я получил это исключение, не связанное с какими-либо проблемами TLS. В моем случае значение заголовка Content-Length не соответствует длине тела.

— mibollma
источник

2

Я не могу отблагодарить вас достаточно. Любой другой запрос POST терпел неудачу с ошибкой 400, и я был готов вырвать мои волосы. Оказалось, что не отправка content-lengthзаголовка решает эту проблему.

— Александр

2

Я получал задержку 30-90 секунд для запросов Почтальона к местному разработчику - оказывается, это была проблема! Отключение Content-Lengthзаголовка исправило задержку.

— Алок

1

Ответ на этот старый вопрос (для других, которые могут помочь)

Правильная настройка httpd conf решит проблему. Установите любой httpd сервер, если у вас его нет.

Список моего конфига здесь.

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

отредактируйте файл, как указано выше, а затем перезапустите httpd, как показано ниже

[smilyface@box002 ~]$ sudo service httpd restart

И тогда запрос с помощью httpsбудет работать без исключения.
Также запрос с httpпересылкой https! Не беспокойся.

— smilyface
источник

1

Я получил эту ошибку, выполнив 2 вещи в браузере Chrome:

Нажмите Ctrl + Shift + Delete и очистите все данные просмотра с начала.
Перейдите в Chrome: Настройки -> Дополнительные настройки -> Открыть настройки прокси -> Свойства Интернета, затем перейдите в окно «Содержимое» и нажмите кнопку «Очистить состояние SSL».

На этом сайте есть эта информация и другие параметры: https://www.thesslstore.com/blog/fix-err-ssl-protocol-error/

— Рави Шанкар Кота
источник

1

Я знаю, что это старая ветка, но есть конкретный случай, когда это может произойти:

Если вы используете шлюз API AWS, соединенный с каналом VPC, и если в Network Load Balancer включен прокси-протокол v2, также произойдет 400 неверных запросов.

У меня ушел целый день, чтобы понять это, так что, если это может кому-то помочь, я был бы рад :)

— Даниил
источник

0

Я получал одно и то же исключение, когда страница загружалась,

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)

Я обнаружил, что один из URL моей страницы был https вместо http, когда я изменил то же самое, ошибка исчезла.

— Асиф Икебал Аджази
источник

0

Обычно это происходит, когда вы используете схему URI, которая не поддерживается сервером, на котором развернуто приложение. Таким образом, вы можете либо проверить, какие все схемы поддерживает ваш сервер, и соответственно изменить свой запрос URI, либо добавить поддержку этой схемы на ваш сервер. Объем вашей заявки должен помочь вам принять решение об этом.

— новичек
источник

0

Это случилось со мной, когда у меня был один и тот же порт, используемый в SOCKS туннеле SOCKS для запуска прокси-сервера в 8080-м порту, и мой сервер и прокси браузера Firefox были настроены на этот порт и получили эту проблему.

— privatejava
источник

0

В моем случае мне пришлось очистить историю браузера / куки, чтобы избавиться от этой ошибки.

— rustylepord
источник