HTTP définit différentes façons d’interagir avec le serveur, et il existe 4 méthodes de base, à savoir GET, POST, PUT et DELETE. Le nom complet de l’URL est un descripteur de ressource, on peut le considérer ainsi : une adresse URL, elle sert à décrire une ressource sur un réseau, et GET, POST, PUT, DELETE en HTTP correspond aux quatre opérations de vérification, modification, ajout et suppression de cette ressource. À ce stade, vous devriez avoir une compréhension générale : GET est généralement utilisé pour obtenir/interroger des informations sur les ressources, tandis que POST sert généralement à mettre à jour les informations.
1. Selon la spécification HTTP, GET est utilisé pour la récupération d’informations et doit être sécurisé et idempotent.
(1). La soi-disant sécurité signifie que l’opération est utilisée pour obtenir de l’information plutôt que pour la modifier. En d’autres termes, les demandes GET ne devraient généralement pas avoir d’effets secondaires. Autrement dit, elle n’obtient que des informations sur les ressources, tout comme une requête de base de données, et ne modifiera pas, n’ajoutera pas de données et n’affectera pas l’état de la ressource.
* Note : La signification de sécurité ici ne concerne qu’une information non modifiée.
(2). idempotent signifie que plusieurs requêtes vers la même URL doivent donner le même résultat.
Cependant, en pratique, les deux règlements ci-dessus ne sont pas aussi stricts. Exemples de citation d’articles d’autres personnes : Par exemple, la page d’accueil d’un site d’actualités est constamment mise à jour. Bien que la seconde requête renvoie un lot différent d’informations, l’opération reste considérée comme sûre et idempotente car elle renvoie toujours les nouvelles en cours. Fondamentalement, si l’objectif est que, lorsqu’un utilisateur ouvre un lien, il puisse être sûr que la ressource n’a pas été modifiée de son point de vue.
2. Selon la spécification HTTP, POST représente une requête qui peut modifier une ressource sur le serveur. Pour continuer à citer l’exemple ci-dessus : Actualités fixes Prenons le site web comme exemple, les lecteurs devraient poster leurs propres commentaires sur l’actualité, car les ressources du site sont différentes après la soumission du commentaire ou la modification des ressources.
Ce qui précède explique en gros certains principes de GET et POST dans la spécification HTTP. Cependant, beaucoup de personnes ne respectent pas la spécification HTTP lorsqu’elles le font réellement, ce qui peut entraîner de nombreuses raisons à ce problème, telles que :
1. Beaucoup de gens utilisent GET pour mettre à jour les ressources car ils doivent aller sur FORM pour utiliser POST, ce qui sera un peu problématique.
2. L’opération d’ajout, de suppression, de modification et de vérification des ressources peut effectivement être réalisée via GET/POST, sans avoir besoin d’utiliser PUT et DELETE.
3. Un autre est que les premiers concepteurs de frameworks Web MVC ne traitaient pas consciemment et ne concevaient pas les URL comme des ressources abstraites, donc un problème sérieux est que le framework traditionnel Web MVC ne prend en charge que deux méthodes HTTP, GET et POST, mais ne prend pas en charge les méthodes PUT et DELETE.
* Une brève explication de MVC : MVC existait à l’origine dans le programme de bureau, M fait référence au modèle de données, V à l’interface utilisateur, et C au contrôleur. Le but de l’utilisation du MVC est de séparer le code d’implémentation de M et V, afin que le même programme puisse utiliser des représentations différentes.
Les 3 points ci-dessus décrivent généralement l’ancien style (sans respecter strictement la spécification HTTP), avec le développement de l’architecture, il existe désormais REST (Representational State Transfer), un nouveau style qui prend en charge la spécification HTTP.
Après avoir abordé le problème principal, examinons la différence entre GET et POST par rapport au phénomène de surface :
1. Les données de la requête GET seront attachées à l’URL (c’est-à-dire que les données sont placées dans l’en-tête du protocole HTTP), et à la ? Séparez l’URL et transmettez les données, et les paramètres sont reliés par &, par exemple : login.action ?name=hyddd&password=idontknow&verify= %E4 %BD %A0 %E5 %A5 %BD. Si les données sont des lettres ou des chiffres anglais, envoyez-les telles quelles, si c’est un espace, convertissez-les en +, si elles sont chinoises ou autres caractères, puis chiffrez directement la chaîne avec BASE64 pour obtenir un échantillon tel que : %E4 %BD %A0 %E5 %A5 %BD, où XX en %XX est l’ASCII représenté par le symbole en hexadécimal.
POST place les données soumises dans le corps du paquet HTTP.
2. « Le maximum de données soumis par la méthode GET ne peut être que de 1024 octets, théoriquement il n’y a pas de limite à POST, et une grande quantité de données peut être transférée, jusqu’à 80 Ko en IIS4 et 100 Ko en IIS5 » ??!
La phrase ci-dessus est redirigée depuis d’autres articles, en fait, il est faux et inexact de dire ceci :
(1). Tout d’abord, « les données soumises par la méthode GET ne peuvent faire que 1024 octets au maximum », car GET envoie les données via URL, donc la quantité de données pouvant être soumise par GET est directement liée à la longueur de l’URL. En fait, il n’existe pas de limite supérieure de paramètres pour les URL, et la spécification du protocole HTTP ne limite pas la longueur des URL. Cette limite est imposée par un navigateur et un serveur spécifiques. La limite d’URL d’IE est de 2083 octets (2K+35). Pour d’autres navigateurs comme Netscape, Firefox, etc., il n’existe pas de limite théorique de longueur, et cette limite dépend du support du système d’exploitation.
Notez que cela limite la longueur totale de l’URL, pas seulement la longueur de la valeur de vos paramètres. [Voir Réf. 5]
(2). Théoriquement, POST n’a pas de limite de taille, et la spécification du protocole HTTP n’a pas de limite de taille, et il est inexact de dire qu'« il existe une limite de taille de 80K/100K pour les données POST », et qu’il n’y a pas de limite aux données POST, et c’est la puissance de traitement du gestionnaire du serveur qui joue un rôle limitant.
Pour les programmes ASP, l’objet Request a une limite de longueur de données de 100K lors du traitement de chaque champ de formulaire. Mais avec Request.BinaryRead, il n’y a pas de telle limitation.
En plus de cela, pour IIS 6.0, Microsoft a renforcé les restrictions pour des raisons de sécurité. Nous devons également prêter attention à :
1). IIS 6.0 est par défaut un maximum de 200 Ko de données ASP POST, et la limite est de 100 Ko par champ de formulaire.
2). La taille par défaut des fichiers d’envoi IIS 6.0 est de 4 Mo.
3). IIS 6.0 met par défaut un en-tête de requête maximum de 16 Ko.
Ces limitations n’étaient pas disponibles avant IIS 6.0. [Voir Réf. 5]
Donc les 80K et 100K ci-dessus peuvent être simplement les valeurs par défaut (note : je n’ai pas encore confirmé les paramètres d’IIS4 et IIS5), mais vous pouvez tout à fait les définir vous-même. Puisque les valeurs par défaut de ces paramètres diffèrent selon la version d’IIS, veuillez consulter le document de configuration de l’IIS concerné pour plus de détails.
3. Dans ASP, le serveur utilise Request.QueryString pour obtenir le paramètre de requête GET et Request.Form pour obtenir le paramètre de requête POST. En JSP, utilisez request.getParameter(\"XXXX\ ») pour l’obtenir, bien qu’il existe aussi une méthode request.getQueryString() en jsp, mais elle est plus difficile à utiliser, par exemple : envoyez un test.jsp ?name=hyddd&password=hyddd, et utilisez request.getQueryString() pour obtenir :name= hyddd&password=hyddd。 En PHP, vous pouvez utiliser $_GET et $_POST pour obtenir des données respectivement de GET et POST, tandis que $_REQUEST peut obtenir des données à la fois des requêtes GET et POST. Il est important de noter qu’il existe des dangers cachés à utiliser la requête en JSP et _REQUEST $ en PHP, qui seront résumés dans un article la prochaine fois.
4.POST est plus sécurisé que GET. Note : La sécurité mentionnée ici n’est pas le même concept que la « sécurité » mentionnée dans le GET ci-dessus. Par exemple, si vous soumettez des données via GET, votre nom d’utilisateur et votre mot de passe apparaîtront en clair sur l’URL, car (1) la page de connexion peut être mise en cache par le navigateur, (2) d’autres consulteront l’historique du navigateur, afin que d’autres puissent obtenir votre compte et votre mot de passe Attaque de contrefaçon.
Pour résumer, Get est une demande de données au serveur, tandis que Post est une demande de soumission de données au serveur, dans FORM, Method est par défaut « GET », en essence, GET et POST sont simplement des mécanismes d’envoi différents, pas un seul prend et envoie un seul !
|
Publié sur 06/12/2014 10:54:55
|
|
|
Publié sur 07/12/2014 17:24:18
