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

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?

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.

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.

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:

• Issue-195: Amélioration de la génération de requêtes http à partir de formulaires
• Problème 196: Définition du comportement de traitement de la réponse http de l'agent utilisateur

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).

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.

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).

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.

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"