Este team redactor ha pasado mucho tiempo investigando para darle resolución a tu pregunta, te brindamos la resolución de modo que nuestro deseo es que te sea de mucha ayuda.
Solución:
Estará vacío si ya se ha consumido de antemano. Esto se hará implícitamente cada vez que llame getParameter(), getParameterValues(), getParameterMap(), getReader(), etc sobre el HttpServletRequest. Asegúrese de no llamar a ninguno de esos métodos que por sí mismos necesitan recopilar información del cuerpo de la solicitud antes de llamar getInputStream(). Si su servlet no está haciendo eso, comience a verificar los filtros de servlet que están asignados en el mismo patrón de URL.
Actualizar: esto parece ser específico de GAE 1.5. Ver también
- http://code.google.com/p/googleappengine/issues/detail?id=5161
- http://code.google.com/p/googleappengine/issues/detail?id=5898
Me temo que no hay solución hasta que lo arreglen. Tú podrías tratar para comprobar si está disponible dentro de un Filter y si es así, cópielo y guárdelo como solicitud attribute. Pero esto podría afectar el procesamiento posterior por parte de algún servlet GAE.
Tuve un problema similar al ejecutar una aplicación Spring Boot. La aplicación My Spring Boot es un simple Dispatcher servlet que lee el cuerpo de la solicitud y lo procesa.
En mi caso, el cliente (curl) establece un encabezado de tipo de contenido de application/x-www-form-urlencoded si la línea de comando curl usa -d some-data y no establece un encabezado de tipo de contenido específico a través de -Hcontent-type=some-other-media-type.
Dentro del motor de servlet de Apache Catalina que ejecuta Spring Boot, el Request la clase hace la siguiente prueba en parseParameters()
if (!("application/x-www-form-urlencoded".equals(contentType)))
success = true;
return;
Por otro content-type valores, Request vuelve aquí, listo.
Sin embargo, si el tipo de contenido partidosapplication/x-www-form-urlencoded, Request continúa:
try
if (readPostBody(formData, len) != len)
parameters.setParseFailedReason(FailReason.REQUEST_BODY_INCOMPLETE);
return;
catch (....)
que lo hará consumir el cuerpo. Así que en mi caso, aunque mi servlet no hace nada más que llamar request.getInputStream() y tratar de read() de eso, ya es demasiado tarde: el tiempo de ejecución Request ya lee la entrada y no la almacena en búfer ni la deja de leer. La única solución es establecer un diferente Content-Type.
el culpable es
OrderedHiddenHttpMethodFilter(HiddenHttpMethodFilter).doFilterInternal(HttpServletRequest, HttpServletResponse, FilterChain) línea 70
que está buscando el "_method" parámetro de consulta.
Pude deshabilitar el filtro agregando
@Bean
public FilterRegistrationBean registration(HiddenHttpMethodFilter filter)
FilterRegistrationBean registration = new FilterRegistrationBean(filter);
registration.setEnabled(false);
return registration;
(que se usó para resolver otro problema)
Tuve el problema de que mi solicitud InputStream siempre estaba vacía con Jetty 6.1.15 y descubrí que la causa era un encabezado “Content-Type” faltante o incorrecto.
Genero las solicitudes en otro programa Java con HttpUrlConnection. Cuando no configuré el encabezado Content-Type explícitamente, el InputStream devuelto por request.getInputStream() en el programa receptor siempre estaba vacío. Cuando configuro el tipo de contenido en “binary/octet-stream”, el InputStream de la solicitud contenía los datos correctos.
El único método que se llama en el objeto de solicitud antes getInputStream() es getContentLength().
Al final de todo puedes encontrar los comentarios de otros programadores, tú además puedes dejar el tuyo si te apetece.