method - metodos de peticion http
¿Se permite un cuerpo de entidad para una solicitud HTTP DELETE? (10)
Al emitir una solicitud HTTP DELETE, el URI de la solicitud debe identificar completamente el recurso a eliminar. Sin embargo, ¿es posible agregar metadatos adicionales como parte del cuerpo de la entidad de la solicitud?
Algunas versiones de Tomcat y Jetty parecen ignorar el cuerpo de una entidad si está presente. Lo cual puede ser una molestia si quisieras recibirlo.
En caso de que alguien se esté ejecutando en este problema, no está soportado universalmente.
Actualmente estoy probando con Sahi Pro y es muy evidente que una http http elimina todos los datos del cuerpo proporcionados (una gran lista de identificadores para eliminar de forma masiva según el diseño del punto final).
He estado en contacto con ellos varias veces y he enviado tres paquetes separados de scripts, imágenes, registros para que los revisen y todavía no lo han confirmado. Un parche fallido y llamadas de conferencia perdidas por su soporte más tarde y todavía no he recibido una respuesta sólida.
Estoy seguro de que Sahi no admite esto, y me imagino que muchas otras herramientas siguen suite.
La última actualización de la especificación HTTP 1.1 ( RFC 7231 ) permite explícitamente un cuerpo de entidad en una solicitud DELETE:
Una carga útil dentro de un mensaje de solicitud DELETE no tiene una semántica definida; el envío de un cuerpo de carga útil en una solicitud DELETE puede hacer que algunas implementaciones existentes rechacen la solicitud.
Me parece que RFC 2616 no especifica esto.
De la sección 4.3:
La presencia de un cuerpo de mensaje en una solicitud se señala mediante la inclusión de un campo de encabezado Content-Length o Transfer-Encoding en los encabezados de mensaje de la solicitud. Un cuerpo del mensaje NO DEBE incluirse en una solicitud si la especificación del método de solicitud (sección 5.1.1) no permite el envío de una entidad-cuerpo en las solicitudes. Un servidor DEBERÍA leer y reenviar un cuerpo de mensaje en cualquier solicitud; Si el método de solicitud no incluye semántica definida para un cuerpo de entidad, entonces el cuerpo del mensaje DEBERÍA ser ignorado al manejar la solicitud.
Y la sección 9.7:
El método DELETE solicita que el servidor de origen elimine el recurso identificado por el URI de solicitud. Este método PUEDE ser anulado por intervención humana (u otros medios) en el servidor de origen. No se puede garantizar al cliente que la operación se haya llevado a cabo, incluso si el código de estado devuelto por el servidor de origen indica que la acción se ha completado con éxito. Sin embargo, el servidor NO DEBE indicar el éxito a menos que, en el momento de la respuesta, intente eliminar el recurso o moverlo a una ubicación inaccesible.
Una respuesta exitosa DEBE ser 200 (OK) si la respuesta incluye una entidad que describe el estado, 202 (Aceptada) si la acción aún no se ha promulgado, o 204 (Sin contenido) si la acción se ha promulgado pero la respuesta no incluye una entidad.
Si la solicitud pasa a través de un caché y el URI de solicitud identifica una o más entidades actualmente en caché, esas entradas DEBEN ser tratadas como obsoletas. Las respuestas a este método no son cacheable.c
Por lo tanto, no está explícitamente permitido ni deshabilitado, y existe la posibilidad de que un proxy en el camino elimine el cuerpo del mensaje (aunque DEBE leerlo y reenviarlo).
Parece que ElasticSearch usa esto: https://www.elastic.co/guide/en/elasticsearch/reference/5.x/search-request-scroll.html#_clear_scroll_api
Lo que significa que Netty apoya esto.
Como se menciona en los comentarios, puede que ya no sea el caso.
Solo un aviso, si proporciona un cuerpo en su solicitud DELETE y está usando un equilibrador de carga HTTPS de Google Cloud, rechazará su solicitud con un error 400. Golpeé mi cabeza contra una pared y descubrí que Google, por alguna razón, piensa que una solicitud DELETE con un cuerpo es una solicitud mal formada.
Una razón para usar el cuerpo en una solicitud de eliminación es el control optimista de concurrencia.
Usted lee la versión 1 de un registro.
GET /some-resource/1
200 OK { id:1, status:"unimportant", version:1 }
Su colega lee la versión 1 del registro.
GET /some-resource/1
200 OK { id:1, status:"unimportant", version:1 }
Su colega cambia el registro y actualiza la base de datos, que actualiza la versión a 2:
PUT /some-resource/1 { id:1, status:"important", version:1 }
200 OK { id:1, status:"important", version:2 }
Intenta borrar el registro:
DELETE /some-resource/1 { id:1, version:1 }
409 Conflict
Debe obtener una excepción de bloqueo optimista. Vuelva a leer el registro, vea que es importante y tal vez no lo elimine.
Otra razón para usarlo es eliminar varios registros a la vez (por ejemplo, una cuadrícula con casillas de selección de fila).
DELETE /messages
[{id:1, version:2},
{id:99, version:3}]
204 No Content
Tenga en cuenta que cada mensaje tiene su propia versión. Tal vez pueda especificar múltiples versiones usando múltiples encabezados, pero por George, esto es más simple y mucho más conveniente.
Esto funciona en Tomcat (7.0.52) y Spring MVC (4.05), posiblemente en versiones anteriores también:
@RestController
public class TestController {
@RequestMapping(value="/echo-delete", method = RequestMethod.DELETE)
SomeBean echoDelete(@RequestBody SomeBean someBean) {
return someBean;
}
}
La especificación no lo prohíbe ni lo desalienta explícitamente, así que tiendo a decir que está permitido.
Microsoft lo ve de la misma manera (puedo escuchar murmullos en la audiencia), dicen en el artículo de MSDN sobre el método DELETE de ADO.NET Data Services Framework :
Si una solicitud DELETE incluye un cuerpo de entidad, el cuerpo se ignora [...]
Además, aquí está lo que RFC2616 (HTTP 1.1) tiene que decir con respecto a las solicitudes:
- un cuerpo-entidad solo está presente cuando un cuerpo-mensaje está presente (sección 7.2)
- la presencia de un cuerpo de mensaje se señala mediante la inclusión de un
Content-LengthoTransfer-Encoding(sección 4.3) - un cuerpo de mensaje no debe incluirse cuando la especificación del método de solicitud no permite enviar un cuerpo de entidad (sección 4.3)
- un cuerpo de entidad está explícitamente prohibido solo en las solicitudes TRACE, todos los demás tipos de solicitudes no están restringidos (sección 9 y 9.8 específicamente)
Para las respuestas, esto ha sido definido:
- si se incluye un cuerpo de mensaje depende del método de solicitud y del estado de respuesta (sección 4.3)
- un cuerpo del mensaje está explícitamente prohibido en las respuestas a las solicitudes HEAD (sección 9 y 9.4 específicamente)
- un cuerpo del mensaje está explícitamente prohibido en 1xx (informativo), 204 (sin contenido) y 304 (no modificado) respuestas (sección 4.3)
- todas las demás respuestas incluyen un cuerpo del mensaje, aunque puede ser de longitud cero (sección 4.3)
Esto no está definido .
Una carga útil dentro de un mensaje de solicitud DELETE no tiene una semántica definida; el envío de un cuerpo de carga útil en una solicitud DELETE puede hacer que algunas implementaciones existentes rechacen la solicitud.
https://tools.ietf.org/html/rfc7231#page-29