Pourquoi n'y a-t-il pas de méthodes PUT et DELETE sur les formulaires HTML?


265

HTML4 / XHTML1 n'autorise que GET et POST dans les formulaires, il semble maintenant que HTML5 fasse de même. Il y a une proposition pour ajouter ces deux mais cela ne semble pas gagner du terrain. Quelles étaient les raisons techniques ou politiques pour ne pas inclure PUT et DELETE dans le brouillon de la spécification HTML5?


7
HTML est le langage de balisage, HTTP est le protocole
Ratchet Freak

51
@Ratchet Freak: Je suis conscient de cela. Néanmoins, je parle spécifiquement de HTML car il définit uniquement les <form>méthodes GET et POST comme étant autorisées .
FilipK

Un scénario typique est un formulaire avec des données tabulaires, dans lequel l'utilisateur doit PUT plus de lignes ou pas, car "plus de lignes" sont une décision de l'utilisateur. L'utilisation de Javascript + POST est artificielle, peut-être que HTML6 affichera une fonctionnalité alternative de FORM pour effectuer ce type d'opération.
Peter Krauss

J'ai répondu à cette question lorsque quelqu'un d'autre l'a interrogé sur Stack Overflow, et je pense que ma contribution a quelque chose à ajouter aux excellentes réponses ci-dessus, pour tous ceux qui lisent aussi loin dans la page: o) Pourquoi les navigateurs ne prennent-ils pas en charge les requêtes PUT et DELETE et quand vont-ils?
Nicholas Shanks

Réponses:


348

C'est une question fascinante. Les autres réponses ici sont toutes spéculatives et, dans certains cas, totalement inexactes. Au lieu d'écrire mon opinion ici, j'ai en fait effectué des recherches et découvert des sources originales expliquant pourquoi supprimer et mettre ne font pas partie du format standard HTML5.

Il se trouve que ces méthodes ont été incluses dans plusieurs versions préliminaires de HTML5 (!), Mais ont ensuite été supprimées dans les versions suivantes . Mozilla l'avait également implémenté dans une version bêta de Firefox .

Pour quelle raison a-t-on retiré ces méthodes du projet? Le W3C a abordé ce sujet dans le rapport de bogue 10671 . Mike Amundsen a plaidé en faveur de ce soutien:

L'exécution de PUT et DELETE pour modifier les ressources sur le serveur d'origine est une opération simple pour les navigateurs Web modernes utilisant l'objet XmlHttpRequest. Pour les interactions de navigateur sans script, ce n'est pas si simple. [...]

Ce modèle est si souvent nécessaire que plusieurs frameworks / bibliothèques Web couramment utilisés ont créé une solution de contournement "intégrée". [...]

Autres considérations:

  • L'utilisation de POST en tant que tunnel au lieu d'utiliser PUT / DELETE peut entraîner des correspondances de cache (par exemple, les réponses POST peuvent être mises en cache , les réponses PUT ne sont pas (6), les réponses DELETE ne sont pas (7))
  • L'utilisation d'une méthode non idempotente (POST) pour effectuer une opération idempotente (PUT / DELETE) complique la récupération en raison de défaillances du réseau (par exemple, "Est-il sûr de répéter cette action?").
  • [...]

Cela vaut la peine de lire l'intégralité de son post.

Tom Wardrop fait également une remarque intéressante:

HTML est inextricablement lié à HTTP. HTML est l'interface humaine de HTTP. Il est donc automatiquement discutable de savoir pourquoi HTML ne supporte pas toutes les méthodes pertinentes de la spécification HTTP. Pourquoi les machines peuvent-elles PUT et SUPPRIMER des ressources alors que les humains ne le peuvent pas? [...]

Il est contradictoire que, bien que le HTML s'efforce de garantir le balisage sémantique, il n'a jusqu'à présent fait aucun effort pour garantir les requêtes HTTP sémantiques.

Le bogue a finalement été fermé par Ian Hickson, car il ne résout pas le problème , avec les raisons suivantes:

PUT en tant que méthode de formulaire n'a aucun sens, vous ne voudriez pas PUT une charge de formulaire. DELETE n’a de sens que s’il n’ya pas de charge utile, cela n’a donc pas beaucoup de sens avec les formulaires non plus.

Cependant, ce n'est pas la fin de l'histoire! Le problème a été fermé dans le suivi des bogues du W3C et transmis au suivi des problèmes du groupe de travail HTML:

https://www.w3.org/html/wg/tracker/issues/195

À ce stade, il semble que la principale raison pour laquelle rien ne justifie ces méthodes est simplement que personne n’a pris le temps de rédiger une spécification complète à ce sujet.


70
+1 pour mettre l'effort de recherche en place et trouver un certain nombre de références externes pour répondre correctement à la question.

6
@shivakumar Je pense que ce que vous demandez vraiment, c'est pourquoi se préoccuper de HTML alors que JavaScript peut déjà faire le travail? C'est une bonne question. Je suppose que la question du PO vient davantage d'un lieu de curiosité que de praticité. HTML et HTTP sont deux normes conçues l'une pour l'autre. Pourtant, HTML ne semble pas connaître certaines des propriétés les plus élémentaires de HTTP. "Pourquoi?" est une question naturelle à poser.
Mark E. Haase

23
Vous devez sûrement inclure une charge utile pour PUT et pour DELETE, c'est possible? Aussi, si "cela n'a pas beaucoup de sens avec les formes", alors pourquoi les gens le demandent-ils et pourquoi beaucoup le fait-il si les logiciels qu'il propose corrigent-ils les problèmes? Quelqu'un peut décider ce que le reste du monde a besoin ou veut ...
Jonathan.

4
@ mehaase En outre, c'est peut-être juste moi, mais je pense que les listes de diffusion sont un meilleur endroit pour la discussion que pour exprimer un soutien général à une proposition. Je ne suis pas enclin à créer un nouveau fil de discussion sur la liste de diffusion public-html-comments pour pouvoir dire "J'aime cette proposition; les formulaires devraient pouvoir utiliser d'autres méthodes HTTP". En tant que personne qui a grandi sur le Web moderne, ce que je veux savoir, c'est: "où est le bouton d'upvote?" ;-)
Ajedi32

6
@ Ajedi32, voici le message: lists.w3.org/Archives/Public/public-html/2015Feb/0000.html J'encourage tous ceux qui sont intéressés à répondre à ce message sur la liste de diffusion public-html.
Mark E. Haase

12

GET et POST ont une justification claire, indépendante du contenu. GET consiste à récupérer le contenu d'une URL de manière à pouvoir répéter et éventuellement mettre en cache. Le POST consiste à faire quelque chose d'une manière qu'il n'est pas sûr de répéter, d'exécuter de manière spéculative ou de mettre en cache.

Il n'y avait aucune raison similaire pour PUT ou DELETE. Ils sont tous deux complètement couverts par POST. La création ou la destruction d'une ressource sont des opérations qui ne peuvent être répétées, exécutées de manière spéculative et ne devraient pas être mises en cache. Aucune sémantique spéciale supplémentaire n'est nécessaire pour eux.

Donc, fondamentalement, il n'y a aucun avantage.


22
Bien que POST couvre PUT et DELETE, je peux toujours voir l’avantage d’avoir des méthodes séparées. Tous sont couverts par la spécification HTTP et leur utilisation est encouragée dans REST.
FilipK

10
@ David: Ce serait une fonctionnalité .
Donal Fellows

15
La raison en est que POST et DELETE ont des significations différentes, voire opposées. Vous prétendez que POST couvre complètement DELETE, mais que POST n’est pas idempotent et que DELETE l’est. Comment expliquez-vous celà? w3.org/Protocols/rfc2616/rfc2616-sec9.html
Mark E. Haase

14
Analogie intelligente, mais vous redéfinissez ce que "couvre" signifie. Dans votre réponse initiale, vous voulez dire "couvre" comme dans "prend en charge tous les mêmes cas d'utilisation". Ici, vous redéfinissez les "couvertures" pour désigner une sorte de relation taxonomique. Coupons le langage: POST ne prend pas en charge les mêmes cas d'utilisation que DELETE en raison de la différence d'idempotence. GET ne prend pas en charge les mêmes cas d'utilisation que DELETE en raison de la sémantique différente. La prise en charge de DELETE augmenterait les fonctionnalités de l'agent utilisateur.
Mark E. Haase

13
Je ne suis pas d'accord avec cette réponse. POSTn’est pas idempotent, c’est pourquoi, lorsque vous cliquez sur "retour" dans votre navigateur, une page laide qui indique que le formulaire doit être renvoyé s’affiche. Cependant , si cela avait été le cas PUT, il pourrait renvoyer en toute sécurité la PUTdemande d'afficher la page que vous devriez obtenir. À condition bien sûr, on ne gâche pas l'API en créant une sorte de DELETE /resource/latest.
arg20

12

Ce problème a été soulevé en 2010 lorsque le bogue 10671 envisageait d'ajouter le support des méthodes PUT et DELETE .

Il y avait une quantité modérée de refoulement pour cette "fonctionnalité" et une certaine lourdeur, mais finalement cela a dégénéré en deux problèmes sur le suivi des bogues du groupe de travail:

Le problème ISSUE-196 a abouti à une décision consensuelle de ne pas modifier la spécification, car la spécification HTML ne restreint pas actuellement la manière dont les réponses aux demandes POST sont traitées. Je pense que cette question particulière a été soulevée lors de la tentative de réconciliation des modèles de redirection POST couramment utilisés et de la façon dont les serveurs ReSTful fournissent souvent des réponses 2xx avec des messages courts plutôt que quelque chose d'utile à restituer dans un navigateur.

Le numéro ISSUE-195 a été présenté aux présidents. Cameron Jones s'est porté volontaire pour rédiger une proposition de modification le 18 janvier 2012 qu'il a soumise pour devenir le premier projet de travail le 29 mai 2014. Le projet suivra le processus de recommandations du W3C .

Avec un peu de chance, cette recommandation deviendra bientôt une recommandation du W3C et sera mise en œuvre par les éditeurs de navigateurs. Elle constituerait un grand pas en avant dans la suppression des bloqueurs afin de produire des services ReSTful unifiés, sémantiques et conviviaux pour les navigateurs. J'imagine que cela déclenchera une évolution intéressante des modèles de service. Il y a une bonne conversation de Jon Moore - Les API Hypermedia valent la peine d'être surveillées, cela a suscité mon intérêt mais est tombé au premier obstacle (celui-ci).


5

Je crois comprendre que les navigateurs ne savent pas quoi faire une fois qu’ils envoient un PUT ou un DELETE. Un POST redirige généralement vers une page appropriée, contrairement à PUT et DELETE. Cela les rend appropriés pour appeler via ajax ou un programme natif, mais pas à partir d'un formulaire de navigateur Web.

Je ne peux pas le cacher pour l'instant, mais je me souviens d'avoir lu l'une des listes de diffusion html5 alors qu'ils en discutaient.


4
Y a-t-il une raison pour laquelle PUT et DELETE ne peuvent ou ne peuvent pas rediriger de la même manière que POST?
Ryan H

3
@maxpolun Ceci est probablement la liste de diffusion à laquelle vous vous référez
jordanbtucker

2
@RyanH Il n'y en a pas. Chaque application que j'ai rencontrée qui envoie une demande de suppression répondra avec une redirection vers l'index.
Qwertie

5

Histoire

Je pense qu'il convient de mentionner la première apparition de formulaires HTML dans le RFC1866 (section 8.1) . Ici, l'attribut de méthode est défini comme suit:

METHOD
        selects a method of accessing the action URI. The set of
        applicable methods is a function of the scheme of the
        action URI of the form. See 8.2.2, "Query Forms:
        METHOD=GET" and 8.2.3, "Forms with Side-Effects:
        METHOD=POST".

Des explications supplémentaires se trouvent dans les sections 8.2.2 - GET et 8.2.3 - POST.

N'oubliez pas que HTML 2.0 (nov. 1995) a été spécifié avant HTTP 1.0 (mai 1996). Donc tout le monde utilisait HTTP uniquement avec GET (à partir de HTTP 0.9) ou avec l'extension POST. Mais seuls quelques serveurs Web ont pris en charge PUT et DELETE (comme indiqué dans l’ annexe HTTP 1.0 ).

Pensées

Si vous réfléchissez à la manière dont le développement du Web sémantique de Berners-Lee aurait pu évoluer, il semble évident qu'il est passé des problèmes réels à un concept général. Il voulait d'abord partager des documents. Par conséquent, il avait besoin de balisage. Ensuite, il a voulu interroger les bases de données sur le contenu, il avait donc besoin de formulaires. Ensuite, il a voulu mettre de nouvelles données dans la base de données. Il a donc utilisé des formulaires avec GET et POST. Après cela, il s'est peut-être rendu compte que toutes les opérations CRUD pouvaient être effectuées sur des données distantes. HTTP a donc été étendu mais jamais HTML car il était trop tard (seuls quelques serveurs supportaient les nouvelles opérations CRUD).


-2

Jeter juste une hypothèse improbable, mais probablement parce que HTTP n'est pas vraiment efficace avec le contrôle d'accès, et que la dernière chose dont tout le monde a besoin est encore plus de moyens pour les URL malveillantes de compromettre un site Web et / ou une application mal sécurisé (e).

HTTP n'est pas vraiment un bon protocole pour les transferts de fichiers, à part le téléchargement depuis le serveur vers le client. Utilisez FTP - ou mieux encore, SFTP.


12
La sécurité n'a aucune incidence sur cela. Vous pouvez toujours faire des requêtes PUT / Delete via HTTP. curl --request PUT http://A.B.c/indexLa question est de savoir pourquoi pouvez-vous accéder à ces commandes via HTML.
Martin York

5
-1 Les suppositions sauvages ne sont généralement pas utiles sur SO.
Mark E. Haase

-4

Get et post are sont des formats de transmission des données de la requête.

Je suppose que vous demandez de faire de la soumission de formulaire un service RESTFUL. Mais cela n’a aucun sens de changer le standard de requête http pour faire des suppositions l’objet de la requête http. Les informations relatives à la fonction remplie par la demande sont mieux traitées dans les champs de saisie.

Avoir une adresse et obtenir et poster permet au serveur d'interpréter correctement la requête et ses valeurs d'entrée. À partir de là, les valeurs d'entrée vous permettent de faire des demandes ouvertes au serveur et de faire ce que vous voulez. Par exemple, vous pouvez avoir un champ dont les valeurs sont "put" et "delete"


5
-1 "Get et post are sont des formats de transmission des données de la requête." Non, ce sont des méthodes HTTP, pas des "formats".
Mark E. Haase
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.