Analyser la différence entre les demandes de publication et d'obtention

post : Soumettez les données à traiter à la ressource spécifiée. La longueur des données est illimitée, ne peut pas être mise en cache, ne peut pas être enregistrée dans l'historique du navigateur et est hautement sécurisée. POST est plus stable et fiable que GET.

1. Selon la spécification HTTP, GET est utilisé pour l'acquisition d'informations et doit être sûr et idempotent.

　 (1). Le soi-disant coffre-fort signifie que l'opération est utilisée pour obtenir des informations plutôt que pour modifier des informations. En d’autres termes, les requêtes GET ne devraient généralement pas avoir d’effets secondaires. C'est-à-dire qu'il obtient uniquement des informations sur la ressource, tout comme une requête de base de données, il ne modifiera ni n'ajoutera de données et n'affectera pas l'état de la ressource.

*Remarque : La signification du terme sécurité se réfère ici uniquement aux informations non modifiées.

　 (2). Idempotent signifie que plusieurs requêtes vers la même URL doivent renvoyer le même résultat. Ici, je vais expliquer à nouveau le concept d'idempotence :

L'idempotence (idempotent, idempotence) est un concept mathématique ou informatique courant en algèbre abstraite.
Il existe plusieurs définitions de l'idempotence :
Pour les opérations unaires, si une opération est effectuée plusieurs fois sur tous les nombres de l'intervalle, le résultat obtenu en effectuant l'opération plusieurs fois est le même que le résultat obtenu en effectuant l'idempotence. opération une fois, alors on dit que l’opération est idempotente. Par exemple, l'arithmétique des valeurs absolues est un exemple. Dans l'ensemble des nombres réels, il y a abs(a)=abs(abs(a)).
Pour les opérations binoculaires, il faut que lorsque les deux valeurs participant à l'opération soient égales, si le résultat de l'opération est égal aux deux valeurs participant à l'opération, l'opération est dite être idempotent, comme trouver la valeur de deux nombres La fonction de la valeur maximale est idempotente dans l'ensemble des nombres réels, c'est-à-dire max(x,x) = x.

Après avoir lu l'explication ci-dessus, vous devriez être capable de comprendre la signification de GET idempotent.

Mais dans la pratique, les deux réglementations ci-dessus ne sont pas si strictes. Exemples de citation d'articles d'autres personnes : Par exemple, la première page d'un site d'actualités est constamment mise à jour. Bien que la deuxième requête renvoie un lot d'informations différent, l'opération est toujours considérée comme sûre et idempotente car elle renvoie toujours les informations actuelles. Fondamentalement, si l'objectif est que lorsque l'utilisateur ouvre un lien, il puisse être sûr que la ressource n'a pas changé de son point de vue.

　2. Selon la spécification HTTP, POST représente une requête pouvant modifier les ressources sur le serveur. Pour continuer à citer l'exemple ci-dessus : prenons le site Web d'actualités comme exemple. Les commentaires des lecteurs sur l'actualité doivent être mis en œuvre via POST, car les ressources du site sont différentes ou modifiées après la soumission des commentaires.

Ce qui précède parle brièvement de certains problèmes principaux de GET et POST dans la spécification HTTP. Mais dans la pratique réelle, de nombreuses personnes ne suivent pas les spécifications HTTP. Il existe de nombreuses raisons à ce problème, telles que :

1. De nombreuses personnes sont avides de commodité et utilisent GET lors de la mise à jour des ressources, car pour utiliser POST. , vous devez vous rendre sur FORM (formulaire), ce qui sera un peu gênant.

2. L'ajout, la suppression, la modification et la vérification des ressources peuvent en fait être effectués via GET/POST, et il n'est pas nécessaire d'utiliser PUT et DELETE.

3. Un autre problème est que les premiers concepteurs du framework Web MVC n'ont pas consciemment traité et conçu les URL comme des ressources abstraites. Un problème plus grave est donc que le framework Web MVC traditionnel ne prend essentiellement en charge que les deux méthodes HTTP GET et POST, mais ne prend pas en charge les méthodes PUT et DELETE.

* Expliquez brièvement MVC : MVC existait à l'origine dans le programme Desktop. M fait référence au modèle de données, V fait référence à l'interface utilisateur et C fait référence au contrôleur. Le but de l'utilisation de MVC est de séparer les codes d'implémentation de M et V, afin que le même programme puisse utiliser des représentations différentes.

Les trois points ci-dessus décrivent généralement l'ancien style (qui n'adhère pas strictement à la spécification HTTP). Avec le développement de l'architecture, apparaît désormais REST (Representational State Transfer), un nouveau style qui prend en charge le HTTP. Ce n'est pas une spécification. Pour en dire plus, vous pouvez vous référer aux "Services Web RESTful".

Après avoir évoqué les principaux enjeux, regardons la différence entre GET et POST depuis la surface :

1. Les données demandées par GET seront jointes au URL Après cela (c'est-à-dire en plaçant les données dans l'en-tête du protocole HTTP), divisez l'URL et transférez les données avec ?, et connectez les paramètres avec &, tels que : login.action?name=hyddd&password=idontknow&verify=%E4%BD %A0%E5%A5 %BD. Si les données sont des lettres/chiffres anglais, envoyez-les telles quelles. S'il s'agit d'un espace, convertissez-les en +. S'il s'agit de caractères chinois/autres, cryptez directement la chaîne avec BASE64 et vous obtiendrez quelque chose comme : %E4. %BD%A0%E5%A5% BD, où XX dans %XX est la représentation ASCII du symbole en hexadécimal.

POST place les données soumises dans le corps du package HTTP.

2. "Les données soumises par la méthode GET ne peuvent contenir que 1024 octets. En théorie, POST n'a pas de limite et peut transférer de plus grandes quantités de données. Le maximum est de 80 Ko dans IIS4 et de 100 Ko dans IIS5" ? ? !

J'ai transféré la phrase ci-dessus d'un autre article. En fait, c'est faux et inexact de dire ceci :

(1).Tout d'abord, "les données soumises par GET ne peuvent contenir que 1024 octets". Étant donné que GET soumet les données via une URL, la quantité de données pouvant être soumises par GET est directement liée à la longueur de. l'URL. En fait, il n'y a pas de limite supérieure de paramètre pour les URL, et la spécification du protocole HTTP ne limite pas la longueur des URL. Cette limite est imposée par des navigateurs et des serveurs spécifiques. La limite d'IE en matière de longueur d'URL est de 2 083 octets (2 Ko+35). Pour les autres navigateurs, tels que Netscape, FireFox, etc., il n'y a théoriquement aucune limite de longueur, et la limite dépend du support du système d'exploitation.

Notez que cette limite correspond à la longueur totale de l'URL, et pas seulement à la longueur des données de la valeur de votre paramètre. [Voir référence 5]

　(2). Théoriquement, il n'y a pas de limite de taille pour le POST, et la spécification du protocole HTTP n'impose pas de limite de taille. Il est dit qu'"il y a une limite de taille de 80K/100K". la quantité de données POST". Inexact, il n'y a pas de limite aux données POST. Ce qui est limitant, c'est la capacité de traitement du gestionnaire du serveur.

Pour les programmes ASP, l'objet Request a une limite de longueur de données de 100 Ko lors du traitement de chaque champ de formulaire. Mais si vous utilisez Request.BinaryRead, une telle restriction n'existe pas.

Dans le prolongement de cela, pour IIS 6.0, Microsoft a augmenté les restrictions pour des raisons de sécurité. Nous devons également faire attention à :

　1). Le volume de données ASP POST par défaut d'IIS 6.0 est de 200 Ko et la limite de chaque champ de formulaire est de 100 Ko.
2).La taille maximale par défaut des fichiers téléchargés dans IIS 6.0 est de 4 Mo.
　3).L'en-tête de requête maximum par défaut d'IIS 6.0 est de 16 Ko.
De telles restrictions n'existaient pas avant IIS 6.0. [Voir référence 5]

Ainsi, les 80K et 100K ci-dessus ne sont peut-être que les valeurs par défaut (remarque : je n'ai pas confirmé les paramètres d'IIS4 et IIS5), mais elles peuvent certainement être définies par vous-même. Étant donné que chaque version d'IIS a des valeurs par défaut différentes pour ces paramètres, veuillez vous référer à la documentation de configuration IIS correspondante pour plus de détails.

3. Dans ASP, le serveur utilise Request.QueryString pour obtenir les paramètres de requête GET et Request.Form pour obtenir les paramètres de requête POST. Dans JSP, utilisez request.getParameter("XXXX") pour l'obtenir. Bien qu'il existe également une méthode request.getQueryString() dans jsp, elle est plus difficile à utiliser. Par exemple : passez un test.jsp?name=hyddd&password=. hyddd, utilisez request. getQueryString() obtient : name=hyddd&password=hyddd. En PHP, vous pouvez utiliser $_GET et $_POST pour obtenir des données respectivement dans GET et POST, tandis que $_REQUEST peut obtenir des données dans les requêtes GET et POST. Il convient de noter qu'il existe des dangers cachés à utiliser request en JSP et $_REQUEST en PHP. J'écrirai un article pour résumer cela la prochaine fois.

4. POST est plus sécurisé que GET. Remarque : La sécurité mentionnée ici n'est pas le même concept que la « sécurité » mentionnée dans GET ci-dessus. La signification du terme « sécurité » ci-dessus est simplement qu'aucune modification des données n'est effectuée, et la signification du terme sécurité ici est la véritable signification de la sécurité. Par exemple : lors de la soumission de données via GET, le nom d'utilisateur et le mot de passe apparaîtront en texte clair sur l'URL. , car (1) la page de connexion peut être le cache du navigateur, (2) d'autres personnes consultent l'historique du navigateur, d'autres peuvent alors obtenir votre compte et votre mot de passe. De plus, l'utilisation de GET pour soumettre des données peut également provoquer des attaques de falsification de requêtes intersites.

Pour résumer, Get est une demande de données adressée au serveur, tandis que Post est une demande de soumission de données au serveur. Dans FORM (formulaire), la méthode est par défaut "GET". POST n'a que des mécanismes d'envoi différents, aucun n'est pris et l'autre est envoyé !

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!