error parsing http request header

На чтение 6 мин. Опубликовано

Я пытаюсь отправить запрос POST из браузера на мой сервер (локальный хост). Мой URL-адрес запроса:

requestData является json String (для этой цели я использую GSON). Все работает нормально, пока данные в строке json не превысят определенный предел. Скажем, я посылаю массив объектов в строку json. Если количество объектов в списке превышает 67 , тогда я получаю следующую ошибку:

Почему это так? Я совершенно смущен. Почему это происходит и что нужно сделать, чтобы исправить это? Я хочу понять причину этого, потому что я не понимаю, что после определенного количества объектов он внезапно перестает работать, и я получаю эту ошибку в своей консоли.

java http servlets

Содержание
  1. 5 ответов
  2. 9 Answers 9
  3. Debian 8
  4. 3 Answers 3

5 ответов

4 nkatsar [2015-06-18 12:07:00]

У меня была аналогичная проблема, я отправлял POST-запрос (используя плагин RESTClient для Firefox) с данными в теле запроса и получал одно и то же сообщение.

В моем случае это произошло из-за того, что я пытался использовать протокол HTTPS в локальном экземпляре tomcat, где HTTPS не был настроен.

4 AlexR [2014-10-22 12:29:00]

Похоже, что вы используете POST неправильно. Хотя вы используете POST, вы отправляете JSON в качестве параметра запроса, который является стилем GET. При использовании POST вы должны отправлять контент в качестве тела запроса. В этом случае не существует разумного ограничения размера.

1 Daria [2017-03-14 14:53:00]

В моем случае проблема была вызвана проблемами безопасности, я использовал csfr для аутентификации, и все мои почтовые формы должны иметь вход с _csrf

IMHO проблема разбора заголовков может быть вызвана многочисленными причинами.

В моем случае это было связано с тем, что был отправлен следующий XML:

Пустой элемент заголовка был создан SoapUI. После удаления из XML WS, все было в порядке.

-1 轩加振 [2017-11-13 08:55:00]

Приношу свои извинения за то, что я не отвечал на вопросы серьезно.

1. Возможно, это вызвано специальными символами. Вы можете получить детали из этого URL. https://bz.apache.org/bugzilla/show_bug.cgi? >

или измените вашу версию tomcat на 7.0.67 или ниже. По мнению разработчиков, разработчики tomcat в следующих версиях устанавливают возможность разрешить ‘|, <,>‘. Получить детальную информацию http://tomcat.apache.org/tomcat-8.0-doc/config/systemprops.html#Other

Новая переменная среды будет включена в: — соединительная линия для 9.0.0.M18 и далее

8.5.x для 8.5.12 и далее

8.0.x для 8.0.42 и далее

7.0.x для 7.0.76 и далее2.

Другая причина может быть, что заголовок запроса слишком велик. Вы можете решить эту проблему, изменив server.xml.

redirectPort = «8443» acceptCount = «100» connectionTimeout = «20000» disableUploadTimeout = «true» /» >

I use Tomcat 7.0.43 with a websocket application. My app works fine in Tomcat 7.0.42 but with 43 I get the following output when I try to access my server on websockets:

My browser console shows the following:

Here is the access log for that request:

What has changed in Tomcat 7.0.43? What do I have to change?

9 Answers 9

If you have this listener:

on your server.xml, remove it and try. You can not use a keystore if you are using the APR connector

If there are too many cookies cached, it breaks the server (the size of a request header is too big!). Clearing the cookies can fix this issue as well.

For me, the problem was passing in a larger than normally expected HTTP header. I resolved it by setting maxHttpHeaderSize=»1048576″ attribute on the Connector node in server.xml.

I had a similar issue, I was sending a POST request (using RESTClient plugin for Firefox) with data in the request body and was receiving the same message.

In my case this happened because I was trying to use HTTPS protocol in a local tomcat instance where HTTPS was not configured.

My problem occurs when I try to open https. I don’t use SSL.

Today 12/02/2017 newest official version from Debian repositories is Tomcat 8.0.14

Solution is to download from official site and install newest package of Tomcat 8, 8.5, 9 or upgrade to newest version(8.5.x) from jessie-backports

Debian 8

Add to /etc/apt/sources.list

Then update and install Tomcat from jessie-backports

I tried all of the above, nothing worked for me. Then I changed tomcat port numbers both HTTP/1.1 and Tomcat admin port and it got solved.

I see other solutions above worked for the people but it is worth to try this one if any of the above doesn’t work.

In our case it turned out that the error happened because we have a custom filter in our application which does HttpServletResponse sendRedirect() to other url.

For some reason, the redirection is not closing the keep-alive status of the connection, hence the timeout exception.

We checked with Tomcat Docs and when we disabled the maxKeepAliveRequests by setting it’s value to 1 and the error stopped showing up.

For now we do not have the actual solution to the error.

I am running SpringBoot Application just checked server logs and got several errors like this. I can’t understand what can cause it as the error appears everyday after 12/24 hours.

Tomcat Version running on 8.5.11

3 Answers 3

This may happen because of parsing HTTPS headers instead of HTTP. Try:

  1. Adding:
    logging.level.org.springframework.web: trace
    logging.level.org.apache: trace
    to your application.properties and see what does Spring says to you.
  2. Check if there are any scheduled activity at that time which refers to other resource encrypted by SSL. See also: java.lang.IllegalArgumentException: Invalid character found in method name. HTTP method names must be tokens

I had this error in a Spring Boot 2 (2.0.1.RELEASE) application that was configured to serve HTTPS on port 8443 and redirect port 8080 HTTP traffic to port 8443.

On Microsoft Edge, the application worked as expected, with http://localhost:8080 redirecting to https://localhost:8443 . On Chrome 66 however, this would only work once, and then Chrome would complain that «localhost sent an invalid response» ( ERR_SSL_PROTOCOL_ERROR ).

The server log said: DEBUG 11440 — [nio-8080-exec-1] o.a.coyote.http11.Http11InputBuffer: Received [ > ] INFO 11440 — [nio-8080-exec-1] o.apache.coyote.http11.Http11Processor: Error parsing HTTP request header

It turns out that Chrome was adding localhost to its HSTS list because Spring Boot sent back a Strict-Transport-Security: max-age=31536000 ; includeSubDomains header back for https://localhost:8443. So essentially, this issue happened because the client (i.e., browser) was trying to speak HTTPS to an HTTP endpoint.

Adding a .headers().httpStrictTransportSecurity().disable(); in .configure fixed the issue, as noted in this StackOverflow question.

Оцените статью