Question Un corps d'entité est-il autorisé pour une requête HTTP DELETE?


Lors de l'émission d'une requête HTTP DELETE, l'URI de la requête doit identifier complètement la ressource à supprimer. Cependant, est-il permis d'ajouter des méta-données supplémentaires dans le corps de l'entité de la demande?


514
2017-11-18 18:14


origine


Réponses:


La spécification ne l'interdit pas explicitement ou ne le décourage pas, alors j'aurais tendance à dire que c'est permis.

Microsoft le voit de la même manière (je peux entendre des murmures dans le public), ils déclarent dans l'article MSDN sur le DELETE, méthode de ADO.NET Data Services Framework:

Si une requête DELETE inclut un corps d'entité, le corps est ignoré [...]

De plus, voici ce que RFC2616 (HTTP 1.1) a à dire en ce qui concerne les demandes:

  • un entité-corps est seulement présent quand un Corps du message est présent (section 7.2)
  • la présence d'un Corps du message est signalé par l'inclusion d'un Content-Length ou Transfer-Encoding en-tête (section 4.3)
  • une Corps du message ne doit pas être inclus lorsque la spécification de la méthode de requête ne permet pas d'envoyer un entité-corps (section 4.3)
  • un entité-corps est explicitement interdit dans les requêtes TRACE, tous les autres types de requêtes ne sont pas restreints (section 9, et 9.8 en particulier)

Pour les réponses, cela a été défini:

  • si un Corps du message est inclus dépend de la méthode de demande et état de la réponse (section 4.3)
  • une Corps du message est explicitement interdit dans les réponses aux requêtes HEAD (section 9, et 9.4 en particulier)
  • une Corps du message est explicitement interdit dans les réponses 1xx (informatif), 204 (pas de contenu) et 304 (non modifié) (section 4.3)
  • toutes les autres réponses incluent un corps de message, bien qu'il puisse être de longueur nulle (section 4.3)

419
2017-11-18 18:36



La dernière mise à jour de la spécification HTTP 1.1 (RFC 7231) autorise explicitement un corps d'entité dans une requête DELETE:

Une charge utile dans un message de demande DELETE n'a pas de sémantique définie; L'envoi d'un corps de charge utile sur une demande DELETE peut entraîner le rejet de la demande par certaines implémentations existantes.


117
2018-04-04 16:49



Certaines versions de Tomcat et Jetty semblent ignorer un corps d'entité s'il est présent. Ce qui peut être une nuisance si vous avez l'intention de le recevoir.


48
2018-01-15 19:56



Une raison pour utiliser le corps dans une demande de suppression est pour un contrôle de concurrence optimiste.

Vous lisez la version 1 d'un enregistrement.

GET /some-resource/1
200 OK { id:1, status:"unimportant", version:1 }

Votre collègue lit la version 1 du dossier.

GET /some-resource/1
200 OK { id:1, status:"unimportant", version:1 }

Votre collègue modifie l'enregistrement et met à jour la base de données, ce qui met à jour la version vers 2:

PUT /some-resource/1 { id:1, status:"important", version:1 }
200 OK { id:1, status:"important", version:2 }

Vous essayez de supprimer l'enregistrement:

DELETE /some-resource/1 { id:1, version:1 }
409 Conflict

Vous devriez obtenir une exception de verrouillage optimiste. Relisez le dossier, voyez que c'est important, et peut-être ne le supprimez pas.

Une autre raison de l'utiliser est de supprimer plusieurs enregistrements à la fois (par exemple, une grille avec des cases à cocher de sélection de ligne).

DELETE /messages
[{id:1, version:2},
{id:99, version:3}]
204 No Content

Notez que chaque message a sa propre version. Peut-être que vous pouvez spécifier plusieurs versions en utilisant plusieurs en-têtes, mais par George, c'est plus simple et beaucoup plus pratique.

Cela fonctionne dans Tomcat (7.0.52) et Spring MVC (4.05), éventuellement avec des versions antérieures:

@RestController
public class TestController {

    @RequestMapping(value="/echo-delete", method = RequestMethod.DELETE)
    SomeBean echoDelete(@RequestBody SomeBean someBean) {
        return someBean;
    }
}

42
2017-08-09 06:24



Il me semble que RFC 2616 ne le spécifie pas.

De la section 4.3:

La présence d'un corps de message dans une requête est signalée par le   inclusion d'un champ d'en-tête Content-Length ou Transfer-Encoding dans   les en-têtes de message de la requête. Un corps de message NE DOIT PAS être inclus dans   une requête si la spécification de la méthode de requête (section 5.1.1)   n'autorise pas l'envoi d'un corps d'entité dans les requêtes. Un serveur DEVRAIT   lire et transmettre un corps de message sur toute demande; si la méthode de demande   n'inclut pas de sémantique définie pour un corps d'entité, alors   message-body DEVRAIT être ignoré lors du traitement de la requête.

Et la section 9.7:

La méthode DELETE demande que le serveur d'origine supprime la ressource   identifié par l'URI de demande. Cette méthode PEUT être remplacée par l'humain   intervention (ou autre moyen) sur le serveur d'origine. Le client ne peut pas   être assuré que l'opération a été effectuée, même si le   le code d'état renvoyé par le serveur d'origine indique que l'action   a été complété avec succès. Cependant, le serveur NE DEVRAIT PAS   indiquer le succès sauf si, au moment où la réponse est donnée,   a l'intention de supprimer la ressource ou de la déplacer dans un endroit inaccessible   emplacement.

Une réponse réussie DEVRAIT être 200 (OK) si la réponse inclut un   entité décrivant le statut, 202 (Acceptée) si l'action n'a pas   encore été adopté, ou 204 (pas de contenu) si l'action a été adoptée   mais la réponse n'inclut pas une entité.

Si la requête passe par un cache et que l'URI de demande identifie   une ou plusieurs entités actuellement mises en cache, ces entrées DEVRAIENT être   traité comme périmé Les réponses à cette méthode ne sont pas cacheable.c

Donc, ce n'est pas explicitement autorisé ou interdit, et il y a une chance qu'un proxy en cours de route supprime le corps du message (même s'il DEVRAIT le lire et le transférer).


27
2017-11-18 18:37



Juste un coup d'oeil, si vous fournissez un corps dans votre demande DELETE et utilisez un équilibreur de charge HTTPS Google Cloud, il rejettera votre demande avec une erreur 400. Je me suis cogné la tête contre un mur et j'ai découvert que Google, pour quelque raison que ce soit, pense qu'une requête DELETE avec un corps est une requête mal formée.


11
2018-05-25 23:46



Il semble qu'ElasticSearch utilise ceci: https://www.elastic.co/guide/en/elasticsearch/reference/5.x/search-request-scroll.html#_clear_scroll_api

Ce qui signifie que Netty soutient cela.

Comme mentionné dans les commentaires, il se peut que ce ne soit plus le cas


7
2018-05-27 14:59



Ceci n'est pas défini.

Une charge utile dans un message de demande DELETE n'a pas de sémantique définie;      l'envoi d'un corps de charge utile sur une demande DELETE peut provoquer      mises en œuvre pour rejeter la demande.
https://tools.ietf.org/html/rfc7231#page-29


6
2018-01-09 07:43



Au cas où quelqu'un se heurterait à ce problème, Non, il n'est pas universellement supporté.

Je suis actuellement en train de tester avec Sahi Pro et il est très évident qu'un appel HTTP DELETE supprime toutes les données de corps fournies (une grande liste d'identifiants à supprimer en masse selon la conception du point de terminaison).

J'ai été en contact avec eux plusieurs fois ainsi que envoyé trois paquets distincts de scripts, d'images, de journaux pour qu'ils les examinent et ils n'ont toujours pas confirmé cela. Un correctif échoué et une téléconférence manquée par leur support plus tard et je n'ai toujours pas obtenu une réponse solide.

Je suis certain que Sahi ne supporte pas cela, et j'imagine que de nombreux autres outils suivent.


3
2017-08-21 20:29