Podczas wdrażania aplikacji w środowisku wieloserwerowym Apache Tomcat 8 pojawia się poniżej śladu stosu. Często otrzymuję ten błąd i wygląda na to, że blokuje wątek 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)
Czy ktoś może mi wskazać, jak rozwiązać problem lub zawęzić taki wyjątek? Nie otrzymuję żadnego odniesienia do żadnego z plików źródłowych mojej aplikacji. Próbowałem przeszukać go w Google, a wśród podanych linków próbujesz uzyskać dostęp do adresu URL http przez https, co wydaje się mało prawdopodobne. Nie pojawia się ten błąd, gdy aplikacja działa na jednej instancji Tomcat 8. Dostaję to tylko w środowisku wieloserwerowym.
Udostępniam również metatagi, które umieściłem na każdej stronie, jeśli pomoże to zidentyfikować przyczynę.
<%
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">
Na kilku stronach używam również tego, co w zasadzie jest takie samo jak powyżej:
<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" />
Nawet jeśli ktoś pomoże mi wskazać kierunek mojej próby rozwiązania problemu, będzie to przydatne, ponieważ obecnie nie mam pojęcia, gdzie zajrzeć.
Z góry dziękuję.
źródło
Otrzymałem ten sam wyjątek, gdy przeprowadziłem lokalne testy. Problem polegał na schemacie adresu URL w mojej prośbie.
Zmiana
https:// to http:// in your client url.Prawdopodobnie to pomaga.
źródło
Dzwonisz do lokalnego serwera z http : // localhost: 8080 / foo / bar. Wywołaj to za pomocą https : // localhost: 8080 / foo / bar. To rozwiązuje problem
źródło
W przypadku, gdy ktoś używa swaggera:
Zmień Schemat na
HTTPlubHTTPS, w zależności od potrzeb, przed wykonaniem polecenia.Listonosz:
Zmień ścieżkę adresu URL na
http://lubhttps://w adresie urlźródło
Otrzymałem ten wyjątek niezwiązany z żadnymi problemami z TLS. W moim przypadku wartość nagłówka Content-Length nie odpowiadała długości treści.
źródło
content-lengthnagłówka rozwiązuje ten problem.Content-Lengthnagłówka naprawiło opóźnienie.Odpowiedź na to stare pytanie (dla innych, którzy mogą pomóc)
Prawidłowe skonfigurowanie httpd conf rozwiąże problem. Zainstaluj dowolny serwer httpd, jeśli go nie masz.
Wymieniam tutaj moją konfigurację.
edytuj plik jak powyżej, a następnie zrestartuj httpd jak poniżej
A następnie żądanie z
httpsbędzie działać bez wyjątku.Poproś również o
httpprzekierowanie dohttps! Bez obaw.źródło
Ten błąd został rozwiązany, wykonując 2 czynności w przeglądarce Chrome:
Ta strona zawiera również te informacje i inne opcje: https://www.thesslstore.com/blog/fix-err-ssl-protocol-error/
źródło
Wiem, że to stary wątek, ale jest szczególny przypadek, w którym może się to zdarzyć:
Jeśli używasz bramy AWS API połączonej z łączem VPC i jeśli Network Load Balancer ma włączony protokół proxy v2, wystąpi również 400 złych żądań.
Zajęło mi to całe popołudnie, żeby to rozgryźć, więc jeśli to może komuś pomóc, byłbym zadowolony :)
źródło
Otrzymywałem ten sam wyjątek, gdy ładowała się strona,
Odkryłem, że jeden z adresów URL mojej strony to https zamiast http, kiedy zmieniłem to samo, błąd zniknął.
źródło
Zwykle dzieje się tak, gdy używasz schematu identyfikatora URI, który nie jest obsługiwany przez serwer, na którym aplikacja jest wdrażana. Możesz więc albo chcieć sprawdzić, jakie schematy obsługują twój serwer i odpowiednio zmodyfikować żądanie
URI, albo możesz chcieć dodać obsługę tego schematu na swoim serwerze. Zakres twojego wniosku powinien pomóc ci w podjęciu takiej decyzji.źródło
Zdarzyło mi się to, gdy miałem ten sam port używany w tunelu ssh SOCKS do uruchamiania serwera proxy na porcie 8080, a mój serwer i mój serwer proxy przeglądarki Firefox były ustawione na ten port i wystąpił ten problem.
źródło
W moim przypadku musiałem wyczyścić historię przeglądarki / pliki cookie, aby pozbyć się tego błędu.
źródło