Dans un HTTP GET les paramètres sont envoyés sous forme de chaîne de requête :
http://example.com/page**_?parameter=value&also=another_**Dans un HTTP POST les paramètres ne sont pas envoyés avec l'URI.
Ma question est la suivante , où sont les valeurs ? Dans l'en-tête de la requête ? Dans le corps de la requête ? A quoi cela ressemble-t-il ?
Les valeurs sont envoyées dans le corps de la demande, dans le format spécifié par le type de contenu.
Habituellement, le type de contenu est application/x-www-form-urlencoded Le corps de la demande utilise donc le même format que la chaîne de requête :
parameter=value&also=anotherLorsque vous utilisez le téléchargement d'un fichier dans le formulaire, vous utilisez l'attribut multipart/form-data à la place, qui a un format différent. C'est plus compliqué, mais vous n'avez généralement pas besoin de vous soucier de ce à quoi cela ressemble, donc je ne montrerai pas d'exemple, mais il peut être bon de savoir que cela existe.
Le contenu est placé après les en-têtes HTTP. Le format d'un POST HTTP est le suivant : les en-têtes HTTP, suivis d'une ligne blanche, puis du corps de la requête. Les variables POST sont stockées sous forme de paires clé-valeur dans le corps de la requête.
Vous pouvez le voir dans le contenu brut d'un message HTTP, illustré ci-dessous :
POST /path/script.cgi HTTP/1.0
From: frog@jmarshall.com
User-Agent: HTTPTool/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 32
home=Cosby&favorite+flavor=fliesVous pouvez voir cela en utilisant un outil comme Fiddler que vous pouvez utiliser pour observer les charges utiles brutes des requêtes et des réponses HTTP envoyées sur le réseau.
Réponse courte : dans les requêtes POST, les valeurs sont envoyées dans le "corps" de la requête. Avec les formulaires Web, elles sont généralement envoyées avec un type de média de application/x-www-form-urlencoded ou multipart/form-data . Les langages de programmation ou les frameworks qui ont été conçus pour traiter les requêtes web font généralement "The Right Thing™" avec ces requêtes et vous fournissent un accès facile aux valeurs facilement décodées (comme . $_REQUEST ou $_POST en PHP, ou cgi.FieldStorage() , flask.request.form en Python).
Faisons maintenant une petite digression, ce qui peut aider à comprendre la différence ;)
La différence entre GET et POST Les demandes sont en grande partie sémantiques. Elles sont également "utilisées" différemment, ce qui explique la différence dans la façon dont les valeurs sont transmises.
Lors de l'exécution d'un GET demande, vous demandez au serveur une ou un ensemble d'entités. Pour permettre au client de filtrer le résultat, il peut utiliser ce que l'on appelle la "chaîne de requête" de l'URL. La chaîne de requête est la partie située après le ? . Cela fait partie de la Syntaxe URI .
Ainsi, du point de vue du code de votre application (la partie qui reçoit la demande), vous devrez inspecter la partie requête de l'URI pour avoir accès à ces valeurs.
Notez que les clés et les valeurs font partie de l'URI. Navigateurs mai imposer une limite à la longueur des URI. La norme HTTP stipule qu'il n'y a pas de limite. Mais au moment de la rédaction de ce document, la plupart des navigateurs faire limiter les URIs (je n'ai pas de valeurs spécifiques). GET Les demandes doivent jamais être utilisé pour soumettre de nouvelles informations au serveur. Surtout pas les documents volumineux. C'est là que vous devez utiliser POST ou PUT .
Lors de l'exécution d'un POST le client soumet en réalité une nouvelle requête document à l'hôte distant. Ainsi, un requête n'a pas de sens (sémantiquement). C'est pourquoi vous n'y avez pas accès dans votre code d'application.
POST est un peu plus complexe (et chemin plus souple) :
Lorsque vous recevez une demande POST, vous devez toujours vous attendre à une "charge utile", ou, en termes HTTP, à une corps du message . Le corps du message en lui-même est plutôt inutile, puisqu'il n'y a pas de standard (pour autant que je puisse dire. Peut-être application/octet-stream ?). Le format du corps est défini par l'option Content-Type en-tête. Lorsque vous utilisez un fichier HTML FORM élément avec method="POST" c'est généralement application/x-www-form-urlencoded . Un autre type très courant est multipart/form-data si vous utilisez le téléchargement de fichiers. Mais cela pourrait être tout ce qui est allant de text/plain sur application/json ou même un application/octet-stream .
Dans tous les cas, si un POST la demande est faite avec un Content-Type qui ne peut pas être traitée par l'application, elle doit renvoyer un message de type 415 code d'état .
La plupart des langages de programmation (et/ou des frameworks web) offrent un moyen de décoder/encoder le corps du message depuis/vers les types les plus courants (tels que application/x-www-form-urlencoded , multipart/form-data ou application/json ). C'est donc facile. Les types personnalisés nécessitent potentiellement un peu plus de travail.
En utilisant un document standard codé en formulaire HTML comme exemple, l'application doit effectuer les étapes suivantes :
Content-Type champ415 code de statutLà encore, des langages comme le PHP ou des frameworks web pour d'autres langages populaires s'en chargeront probablement pour vous. L'exception à cette règle est le 415 erreur. Aucun framework ne peut prédire quels types de contenu votre application choisit de prendre en charge et/ou de ne pas prendre en charge. C'est à vous de décider.
A PUT est traitée exactement de la même manière qu'une demande de type POST demande. La grande différence est qu'une POST est censée laisser le serveur décider comment (et si) créer une nouvelle ressource. Historiquement (d'après la RFC2616, aujourd'hui obsolète), il s'agissait de créer une nouvelle ressource en tant que "subordonnée" (enfant) de l'URI vers lequel la demande était envoyée.
A PUT En revanche, la demande est censée "déposer" une ressource exactement comme prévu. à l'adresse cette URI, et avec exactement ce contenu. Pas plus, pas moins. L'idée est que le client est responsable de l'élaboration de la complet avant de la "mettre en ligne". Le serveur doit l'accepter en l'état sur l'URL donnée.
En conséquence, un POST n'est généralement pas utilisée pour remplacer une ressource existante. A PUT La demande peut faire les deux créer et remplacer.
Il existe également des " paramètres du chemin "qui peuvent être utilisés pour envoyer des données supplémentaires à l'utilisateur distant, mais ils sont si peu courants que je ne vais pas entrer dans les détails ici. Mais, pour référence, voici un extrait du RFC :
En dehors des segments de points dans les chemins hiérarchiques, un segment de chemin est considéré comme opaque par la syntaxe générique. Les applications produisant des URI utilisent souvent les caractères réservés autorisés dans un segment pour délimiter des schémas spécifiques ou des ou des sous-composants spécifiques au gestionnaire de déréférencement. Par exemple, le point-virgule (" ;") et le caractère réservé "=" sont souvent utilisés pour délimiter les paramètres et les valeurs de paramètres applicables à l'URI. les valeurs des paramètres applicables à ce segment. Le caractère réservé virgule (",") est souvent utilisé à des fins similaires. Par exemple, un producteur d'URI peut utiliser un segment tel que "name;v=1.1" pour indiquer une référence à la version 1.1 de "name". 1.1 de "nom", tandis qu'un autre pourrait utiliser un segment tel que "nom,1.1" pour indiquer la même chose. pour indiquer la même chose. Les types de paramètres peuvent être définis par une sémantique mais, dans la plupart des cas, la syntaxe d'un paramètre est spécifique à l'implémentation de la fonction d'identification de l'URI. l'implémentation de l'algorithme de déréférencement de l'URI.
Vous ne pouvez pas le taper directement dans la barre d'URL du navigateur.
Vous pouvez voir comment les données POST sont envoyées sur Internet avec En-têtes HTTP en direct par exemple. Le résultat sera quelque chose comme ça
http://127.0.0.1/pass.php
POST /pass.php HTTP/1.1
Host: 127.0.0.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:18.0) Gecko/20100101 Firefox/18.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
DNT: 1
Referer: http://127.0.0.1/pass.php
Cookie: passx=87e8af376bc9d9bfec2c7c0193e6af70; PHPSESSID=l9hk7mfh0ppqecg8gialak6gt5
Connection: keep-alive
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
username=zurfyx&pass=passwordOù il est dit
Content-Length: 30
username=zurfyx&pass=passwordseront les valeurs des postes.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
