Question Comment les paramètres sont-ils envoyés dans une requête HTTP POST?


Dans un HTTP OBTENIR demande, les paramètres sont envoyés en tant que chaîne de requête:

http://example.com/page? parameter = value & aussi = autre

Dans un HTTP POSTER demande, les paramètres ne sont pas envoyés avec l'URI.

Où sont les valeurs? Dans l'en-tête de la requête? Dans le corps de la requête? À quoi cela ressemble-t-il?


1165
2018-01-27 19:19


origine


Réponses:


Les valeurs sont envoyées dans le corps de la demande, au format spécifié par le type de contenu.

Habituellement, le type de contenu est application/x-www-form-urlencoded, de sorte que le corps de la requête utilise le même format que la chaîne de requête:

parameter=value&also=another

Lorsque vous utilisez un téléchargement de fichier dans le formulaire, vous utilisez le multipart/form-data encodage à 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 quoi il ressemble, donc je ne vais pas montrer un exemple, mais il peut être bon de savoir qu'il existe.


962
2018-01-27 19:32



Le contenu est placé après les en-têtes HTTP. Le format d'un HTTP POST est d'avoir les en-têtes HTTP, suivis d'une ligne vide, suivi du corps de la requête. Les variables POST sont stockées en tant que paires clé-valeur dans le corps.

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=flies

Vous pouvez le voir en utilisant un outil comme Violoneux, que vous pouvez utiliser pour regarder la demande HTTP brute et les charges utiles de réponse envoyées sur le réseau.


349
2018-01-27 19:21



Réponse courte: Dans les requêtes POST, les valeurs sont envoyées dans le "corps" de la requête. Avec les formulaires Web, ils sont très probablement envoyés avec un type de média application/x-www-form-urlencoded ou multipart/form-data. Les langages de programmation ou les frameworks qui ont été conçus pour gérer les requêtes web font généralement "The Right Thing" avec de telles 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).


Maintenant, digressons un peu, ce qui peut aider à comprendre la différence;)

La différence entre GET et POST les demandes sont largement sémantiques. Ils sont également «utilisés» différemment, ce qui explique la différence dans la façon dont les valeurs sont transmises.

GET (section RFC pertinente)

Lors de l'exécution d'un GET demande, vous demandez au serveur un, ou un ensemble d'entités. Pour permettre au client de filtrer le résultat, il peut utiliser la "chaîne de requête" de l'URL. La chaîne de requête est la partie après le ?. Cela fait partie du Syntaxe URI.

Donc, du point de vue de votre code d'application (la partie qui reçoit la demande), vous devrez inspecter la partie de requête URI pour accéder à ces valeurs.

Notez que les clés et les valeurs font partie de l'URI. Navigateurs mai imposer une limite à la longueur de l'URI. La norme HTTP indique qu'il n'y a pas de limite. Mais au moment de l'écriture, la plupart des navigateurs faire limiter les URI (je n'ai pas de valeurs spécifiques). GET les demandes devraient jamais être utilisé pour soumettre de nouvelles informations au serveur. Surtout pas de plus gros documents. C'est là que vous devriez utiliser POST ou PUT.

POST (section RFC pertinente)

Lors de l'exécution d'un POST demande, le client soumet actuellement une nouvelle document à l'hôte distant. Donc, un question la chaîne n'a pas (sémantiquement) de sens. C'est pourquoi vous n'y avez pas accès dans votre code d'application.

POST est un peu plus complexe (et façon plus flexible):

Lors de la réception d'une requête POST, vous devez toujours attendre une "charge", ou, en termes HTTP: Corps du message. Le corps du message en soi est assez inutile, car il n'y a pas la norme (pour autant que je sache, peut-être le format application / octet-stream?) Le format du corps est défini par le Content-Type entête. Lors de l'utilisation d'un HTML FORM élément avec method="POST", c'est habituellement application/x-www-form-urlencoded. Un autre type très commun est multipart / forme-données si vous utilisez des téléchargements de fichiers. Mais pourrait être n'importe quoi, allant de text/plain, plus de application/json ou même une coutume application/octet-stream.

En tout cas, si un POST demande est faite avec un Content-Type qui ne peut pas être géré par l'application, il devrait retourner un 415 code d'état.

La plupart des langages de programmation (et / ou web-frameworks) offrent un moyen de coder / décoder le corps du message de / vers les types les plus communs (comme application/x-www-form-urlencoded, multipart/form-data ou application/json). Donc c'est facile. Les types personnalisés nécessitent potentiellement un peu plus de travail.

À l'aide d'un document codé de formulaire HTML standard par exemple, l'application doit effectuer les étapes suivantes:

  1. Lis le Content-Type champ
  2. Si la valeur n'est pas l'un des types de support pris en charge, renvoyez une réponse avec un 415 code d'état
  3. sinon, décoder les valeurs du corps du message.

Encore une fois, des langages comme PHP ou des frameworks web pour d'autres langages populaires vont probablement gérer cela pour vous. L'exception à ceci est le 415 Erreur. Aucun cadre 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 toi qui décides.

PUT (section RFC pertinente)

UNE PUT demande est à peu près traitée de la même manière que POST demande. La grande différence est qu'un POST La requête est supposée laisser le serveur décider comment (et si jamais) créer une nouvelle ressource. Historiquement (à partir de la RFC2616 désormais obsolète, il s'agissait de créer une nouvelle ressource en tant que "subordonné" (enfant) de l'URI où la requête a été envoyée).

UNE PUT demande en revanche est censé "déposer" une ressource exactement à cet URI, et avec exactement ce contenu. Ni plus ni moins. L'idée est que le client est responsable d'élaborer le Achevée ressource avant de "PUT". Le serveur devrait l'accepter comme si sur l'URL donnée.

En conséquence, un POST demande n'est généralement pas utilisé pour remplacer une ressource existante. UNE PUT demande peut faire les deux créer et remplacer.

Side-Note

Il y a aussi "paramètres de chemin"qui peut être utilisé pour envoyer des données supplémentaires à la télécommande, mais ils sont si rares, que je ne vais pas entrer dans trop de détails ici, mais, pour référence, voici un extrait de la RFC:

En dehors des segments de points dans les chemins hiérarchiques, un segment de chemin est considéré   opaque par la syntaxe générique. Les applications produisant des URI utilisent souvent   caractères réservés autorisés dans un segment pour délimiter un   sous-composants spécifiques à dereference-handler. Par exemple, le point-virgule (";")   et equals ("=") les caractères réservés sont souvent utilisés pour délimiter les paramètres et   valeurs de paramètres applicables à ce segment. La virgule (",") réservée   caractère est souvent utilisé à des fins similaires. Par exemple, un producteur d'URI   pourrait utiliser un segment tel que "name; v = 1.1" pour indiquer une référence à la version   1.1 de "name", tandis qu'un autre pourrait utiliser un segment tel que "name, 1.1" pour   indique la même chose. Les types de paramètres peuvent être définis par un schéma spécifique   sémantique, mais dans la plupart des cas, la syntaxe d'un paramètre est spécifique à   implémentation de l'algorithme de déréférencement des URI.


287
2017-11-03 15:54



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=password

Où il est dit

Content-Length: 30
    username=zurfyx&pass=password

seront les valeurs de poste.


48
2018-01-27 19:29



Le type de média par défaut dans une requête POST est application/x-www-form-urlencoded. C'est un format pour encoder des paires clé-valeur. Les clés peuvent être dupliquées. Chaque paire clé-valeur est séparée par un & caractère, et chaque clé est séparée de sa valeur par un = personnage.

Par exemple:

Name: John Smith
Grade: 19

Est codé comme:

Name=John+Smith&Grade=19

Ceci est placé dans le corps de la requête après les en-têtes HTTP.


18
2018-06-16 05:33



Les valeurs de formulaire dans HTTP POST sont envoyées dans le corps de la requête, dans le même format que la chaîne de requête.

Pour plus d'informations, voir spec.


13
2018-01-27 19:20



Certains des webservices exigent que vous fassiez une demande Les données et métadonnées séparément. Par exemple, une fonction distante peut s'attendre à ce que la chaîne de métadonnées signée soit incluse dans un URI, tandis que les données sont publiées dans un corps HTTP.

La requête POST peut ressembler sémantiquement à ceci:

POST /?AuthId=YOURKEY&Action=WebServiceAction&Signature=rcLXfkPldrYm04 HTTP/1.1
Content-Type: text/tab-separated-values; charset=iso-8859-1
Content-Length: []
Host: webservices.domain.com
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: identity
User-Agent: Mozilla/3.0 (compatible; Indy Library)

name    id
John    G12N
Sarah   J87M
Bob     N33Y

Cette approche combine logiquement QueryString et Body-Post en utilisant un seul Content-Type qui est un "parsing-instruction" pour un serveur web.

Notez s'il vous plaît: HTTP / 1.1 est enveloppé avec le #32 (espace) sur la gauche et avec #10 (Saut de ligne) sur la droite.


13
2017-07-31 14:01



Tout d'abord, faisons la différence entre GET et POST 

Obtenir: C'est le défaut HTTP requête qui est faite au serveur et est utilisé pour récupérer les données du serveur et la chaîne de requête qui vient après ? dans un URI est utilisé pour récupérer une ressource unique.

c'est le format

GET /someweb.asp?data=value HTTP/1.0

ici data=value est la valeur de chaîne de requête transmise.

POSTER: Il est utilisé pour envoyer des données au serveur en toute sécurité afin que tout ce qui est nécessaire, c'est le format d'un POST demande

POST /somweb.aspHTTP/1.0
Host: localhost
Content-Type: application/x-www-form-urlencoded //you can put any format here
Content-Length: 11 //it depends
Name= somename

Pourquoi POST sur GET?

Dans GET la valeur envoyée aux serveurs est généralement ajoutée à l'URL de base dans la chaîne de requête, ce qui permet de pirater vos données (c'était un problème depuis quelques jours pour Facebook où vos informations d'identification étaient exposées). POSTest utilisé pour envoyer des données au serveur qui a utilisé Request Body pour envoyer vos données au serveur qui est plus sécurisé car il cache vos données plus il obtient vos données des champs calculer la longueur d'entre eux et les ajouter à la header pour content-length et aucune donnée importante n'est directement jointe au URL

maintenant que votre demande est sécurisée, toutes les valeurs envoyées au serveur peuvent être envoyées dans le Request Body Comme son nom l'indique, il contiendra l'utilisateur de données que vous souhaitez envoyer (et il est envoyé dans le URL Encoded format) et le Request Headers gardera la demande sécurisée en comparant les valeurs dans Request Body avec le Request Headers

Vous pouvez utiliser la section réseau des outils de développement Google pour afficher des informations de base sur la manière dont les demandes sont adressées aux serveurs.

et vous pouvez toujours ajouter plus de valeurs dans votre Request Headers comme Cache-Control , Origin , Accept.


0
2017-07-19 07:04