Pourquoi devriez-vous supprimer à l'aide d'un HTTP POST ou DELETE, plutôt que GET?
https://stackoverflow.com/questions/786070
-
16-09-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianQuestion
Je travaille à travers les didacticiels ASP.NET MVC de Microsoft, se terminant à cette page
http://www.asp.net/learn/mvc/ tutorial-32-cs.aspx
La déclaration suivante est faite vers le bas de cette page:
En général, vous ne voulez pas effectuer une opération HTTP GET lors de l'appel d'une action qui modifie l'état de votre application web. Lorsque vous effectuez une suppression, vous souhaitez effectuer un HTTP POST, ou mieux encore, une requête HTTP DELETE.
Est-ce vrai? Quelqu'un peut-il offrir une explication plus détaillée pour la justification de cette déclaration?
Modifier
Wikipédia déclare ce qui suit:
Certaines méthodes (par exemple, HEAD, GET, OPTIONS et TRACE) sont définis comme sûrs, ce qui signifie qu'ils sont destinés uniquement à la recherche d'information et ne devraient pas changer l'état du serveur.
En revanche, des méthodes telles que POST, PUT et DELETE sont destinés à des actions qui peuvent causer des effets secondaires soit sur le serveur
La solution
La réponse de Jon Skeet est la réponse canonique. Mais: Supposons que vous avez un lien:
href = "\myApp\DeleteImportantData.aspx?UserID=27"
et le google-bot arrive et index votre page? Qu'advient-il alors?
Autres conseils
GET est classique exempt d'effets secondaires - en d'autres termes, il ne change pas l'état. Cela signifie que les résultats peuvent être mises en cache, signets peuvent être en toute sécurité, etc.
Implementors doivent être conscients que la logiciel représente l'utilisateur dans leur interactions sur Internet, et doit être prudent pour permettre à l'utilisateur de être au courant de toutes les actions qu'ils pourraient prendre qui peut avoir un inattendu importance pour eux-mêmes ou d'autres.
En particulier, la convention a été établi que l'EEG et HEAD méthodes ne devraient pas avoir la l'importance de prendre une autre action que la récupération. Ces méthodes doivent être considéré comme « sûr ». Cela permet à l'utilisateur agents pour représenter d'autres méthodes, tels que POST, PUT et DELETE, dans un manière particulière, de sorte que l'utilisateur est fait conscient du fait que peut-être une action dangereuse est demandée.
Bien entendu, il est impossible de assurez-vous que le serveur ne fonctionne pas générer des effets secondaires à la suite de l'exécution d'une requête GET; En réalité, certaines ressources dynamiques considèrent qu'une fonctionnalité. La distinction importante ici est que l'utilisateur n'a pas demandé les effets secondaires, peut donc donc pas être tenus responsables pour eux.
En dehors des questions puristes autour d'être idempotent, il y a un côté pratique: araignées / bots / etc robots d'exploration suivront des hyperliens. Si vous avez votre action « supprimer » comme un lien hypertexte qui fait un GET, Google peut allègrement supprimer toutes vos données. Voir " Spider of Doom ".
Avec les messages, ce n'est pas un risque.
Un autre exemple ..
http://example.com/admin/articles/delete/2
Ceci supprimera l'article si vous êtes connecté et avoir les bons privilèges. Si votre site accepte les commentaires par exemple et un utilisateur soumet ce lien comme une image; comme ceci:
<img src="http://example.com/admin/articles/delete/2" alt="This will delete your article."/>
Ensuite, lorsque vous vous en tant qu'utilisateur administrateur venu pour parcourir les commentaires sur votre site le navigateur tente de récupérer cette image en envoyant une demande de cette URL. Mais parce que vous êtes connecté alors que le navigateur fait ce l'article sera effacé.
Vous ne pouvez pas même avis, sans regarder le code source comme la plupart des navigateurs montrent wont rien si elle ne peut pas trouver une image.
L'espoir qui fait sens.
S'il vous plaît voir ma réponse ici . Il applique également à cette question.
- prélecture: Beaucoup de navigateurs Web utilisera préchargement. Ce qui signifie qu'il va charger une page avant Clique sur le lien. Anticipant vous cliquez sur ce lien plus tard.
- Moteurs de recherche: Il y a plusieurs robots qui scannent et indexer l'Internet pour information. Ils seule question GET demandes. Vous ne voulez pas supprimer quelque chose d'une requête GET pour cette raison.
- Mise en cache: GET requêtes HTTP ne sont pas censés changer d'état et ils doivent être idempotents. Idempotent signifie que l'émission d'une demande une fois, ou sa délivrance plusieurs fois donne le même résultat. C'est à dire. il n'y a pas d'effets secondaires. Pour cette raison les requêtes HTTP GET sont étroitement liée à la mise en cache.
- standard HTTP dit donc : La norme HTTP dit ce que chaque méthode HTTP est pour. Plusieurs programmes sont conçus pour utiliser le standard HTTP, et ils supposent que vous utiliserez la façon dont vous êtes Supposé. Ainsi, vous aurez un comportement non défini à partir d'un grand nombre de programmes aléatoires si vous ne suivez pas.
En plus des araignées et des demandes devant être idempotente il y a aussi un problème de sécurité avec les requêtes GET. Quelqu'un peut facilement envoyer vos utilisateurs un e-mail avec
<img src="http://yoursite/Delete/Me" />
dans le texte et le navigateur se fera un plaisir aller de pair et d'essayer et d'accéder à la ressource. L'utilisation POST n'est pas un remède pour ces choses (comme vous pouvez le mettre sur pied un poste de formulaire en javascript assez facilement), mais il est un bon début.
A propos de ce sujet (méthodes HTTP utilisation), je recommande la lecture de ce blog: http://blog.codevader.com/2008/11/02/why-learning-http-does-matter/
Ceci est en fait le problème inverse: pourquoi ne pas utiliser POST lorsque aucune donnée est modifiée.
Disons que nous avons une demande de services bancaires sur Internet et nous visitons la page de transfert. L'utilisateur connecté choisit de transférer 10 $ à un autre compte.
En cliquant sur le bouton Soumettre réoriente (comme une requête GET) https: //my.bank.com/users/transfer?amount=10&destination=23lk3j2kj31lk2j3k2j
Mais la connexion Internet est lente et / ou le serveur (s) est (sont) occupés donc après avoir frappé le bouton d'envoi de la nouvelle page de chargement lent.
L'utilisateur est frustré et commence à frapper F5 (rafraîchir la page) avec fureur. Devinez ce qui va se passer? Plus d'un transfert se produira peut-être vider le compte de l'utilisateur.
Maintenant, si la demande est faite comme POST (ou toute autre chose que GET) la première F5 (page de rafraîchissement), l'utilisateur fera le navigateur va doucement demander: « êtes-vous sûr de vouloir faire ça? Il peut avoir des effets secondaires [ bla bla bla] ... «
En dehors de toutes les excellentes raisons mentionnées ici, GET demandes peuvent être enregistrées par le serveur destinataire, comme dans le access.log. Si vous envoyez à travers des données sensibles telles que les mots de passe dans la demande, ils journaliser en texte clair.
Même si elles sont hachés / salé pour le stockage sécurisé de DB, une violation (ou une personne regardant par-dessus l'épaule du gars IT) pourrait les révéler. Ces données devraient aller dans le corps POST.
Un autre problème avec GET est que la commande va à la barre d'adresse du navigateur. Donc, si vous actualisez la page, vous émettez à nouveau la commande, que ce soit « supprimer la dernière des choses », « soumettre l'ordre » ou similaire.
