I had a similar problem running a Spring Boot application. My Spring Boot app is a simple Dispatcher
servlet that reads the request body and processes it.
In my case, the client (curl
) sets a content-type header of application/x-www-form-urlencoded if the curl command line uses -d {some-data}
and does not set an specific content-type header via -Hcontent-type=some-other-media-type
.
Inside the Apache Catalina servlet engine that Spring Boot runs, the Request
class makes the following test in parseParameters()
if (!("application/x-www-form-urlencoded".equals(contentType))) {
success = true;
return;
}
For other content-type
values, Request
returns here, done.
However, if the content type matches application/x-www-form-urlencoded
, Request
continues:
try {
if (readPostBody(formData, len) != len) {
parameters.setParseFailedReason(FailReason.REQUEST_BODY_INCOMPLETE);
return;
}
} catch (....)
which will consume the body. So in my case, even though my servlet does nothing other than call request.getInputStream()
and try to read()
from it, it is already too late – the runtime Request
already reads the input and does not buffer or unread it. The only workaround is to set a different Content-Type
.
The culprit is
OrderedHiddenHttpMethodFilter(HiddenHttpMethodFilter).doFilterInternal(HttpServletRequest, HttpServletResponse, FilterChain)
line 70
which is looking for the "_method"
query parameter.
I was able to disable the filter by adding
@Bean
public FilterRegistrationBean registration(HiddenHttpMethodFilter filter) {
FilterRegistrationBean registration = new FilterRegistrationBean(filter);
registration.setEnabled(false);
return registration;
}
(which was used to solve another problem)