У меня была похожая проблема при запуске приложения Spring Boot. Приложение Spring Boot - это простой Dispatcher сервлет, который читает тело запроса и обрабатывает его.
В моем случае клиент (curl) устанавливает заголовок типа контента application / x-www-form-urlencoded, если в командной строке curl используется -d {some-data} и не устанавливает специальный заголовок типа контента через -Hcontent-type=some-other-media-type.
Внутри механизма сервлетов Apache Catalina, который запускается Spring Boot, класс Request выполняет следующий тест в parseParameters()
if (!("application/x-www-form-urlencoded".equals(contentType))) {
success = true;
return;
}
Для других content-type значений, Request возвращается сюда, готово.
Однако, если тип контента соответствует application/x-www-form-urlencoded, Request продолжается:
try {
if (readPostBody(formData, len) != len) {
parameters.setParseFailedReason(FailReason.REQUEST_BODY_INCOMPLETE);
return;
}
} catch (....)
, который будет поглощать тело . Так что в моем случае, даже если мой сервлет не делает ничего, кроме как вызвать request.getInputStream() и попытаться read() с него, уже слишком поздно - среда выполнения Request уже читает ввод и буферизировать или не читать его. Единственный обходной путь - установить другой Content-Type.
виновник
OrderedHiddenHttpMethodFilter(HiddenHttpMethodFilter).doFilterInternal(HttpServletRequest, HttpServletResponse, FilterChain) строка 70
, который ищет параметр запроса "_method".
Мне удалось отключить фильтр, добавив
@Bean
public FilterRegistrationBean registration(HiddenHttpMethodFilter filter) {
FilterRegistrationBean registration = new FilterRegistrationBean(filter);
registration.setEnabled(false);
return registration;
}
(который был использован для решения другой проблемы )