Création d'un standard de réseau Internet 2.0 a permis à l'utilisateur non seulement de recevoir des informations, mais également d'interagir activement avec d'autres utilisateurs et services Internet. Pour organiser ces retours, des balises supplémentaires ont été introduites dans le langage HTML, permettant d'envoyer les informations demandées au serveur. Par exemple, il peut s'agir d'un formulaire d'inscription, d'un formulaire de commentaires ou d'un paramètre compte personnel(pages réseau social) et ainsi de suite. Dans ce chapitre, nous examinerons un ensemble de balises qui vous permettent d'organiser l'interaction des utilisateurs avec le site.

6.1. Requêtes GET et POST

Pour organiser l'interaction des utilisateurs avec Internet, le développeur du site doit prévoir la transmission des requêtes de l'utilisateur du site vers le serveur sur lequel se trouve le site. Il existe deux types de requêtes : les requêtes GET et POST.

OBTENIR-demandes

Au début du développement d’Internet, seules les requêtes GET existaient. Ils représentent le transfert de données directement vers la barre d'adresse du navigateur, ayant la syntaxe suivante :

http://domain/page?[parameter1=value1][¶meter2=value2]...

Ici, l'ensemble des données transférées vers le serveur commence par le caractère « ? » et est séparé par le caractère « & ». Les données elles-mêmes sont une paire

paramètre=valeur

Par exemple, si vous devez transmettre le nom et prénom de l'utilisateur sur la page d'inscription (par exemple, register.php) du site monsite.com, cela ressemblerait à ceci :

http://mysite.com/register.php?fname=Ivan&lname=Ivanov

Veuillez noter que les navigateurs de versions obsolètes peuvent ne pas percevoir correctement l'alphabet cyrillique et que la transmission des lettres russes s'effectuera de manière incorrecte. Il est préférable de transmettre exclusivement les informations de service dans les requêtes GET sous forme de chiffres et de mots en latin.

L'inconvénient des requêtes GET est le nombre limité de données transférées. Côté serveur, la chaîne de requête est limitée à une valeur maximale. Par exemple, si la taille maximale de la requête peut être de 1024 caractères, alors tout ce qui dépasse cette valeur sera supprimé et une partie des informations transmises ne sera pas traitée par la page spécifiée du site. La deuxième limitation importante est la capacité à transmettre des jeux de caractères strictement définis. Par exemple, des symboles ? et & sont déjà réservés et ne peuvent pas être transmis comme valeurs de paramètre. Cependant, cette règle peut être contournée si la chaîne de requête ne contient pas le caractère lui-même, mais sa valeur de code. Pour cela, utilisez le caractère '%' suivi du code du caractère, par exemple comme ceci :

http://mysite.com/register.php?fname=%CC%DF%AD%1F%DS&lname=%DD

Ici, les valeurs du code sont données en hexadécimal pour économiser la longueur de la requête.

Malgré ces inconvénients, créer des sites sans requêtes GET serait extrêmement difficile. Par exemple, ils sont indispensables en cas d'initialisation initiale d'une page du site pour un utilisateur précis, lorsque la demande précise non seulement le site et page actuelle, mais aussi son identifiant, comme cela se fait sur le réseau social VKontakte :

http://vk.com/profile.php?id=12345678

Les requêtes GET sont également souvent utilisées pour vérifier l'exactitude de l'adresse e-mail lors de l'enregistrement d'un utilisateur. Dans ce cas, l'utilisateur reçoit un e-mail avec un lien d'activation à l'adresse e-mail spécifiée, et ce lien est une requête GET.

POSTE-demandes

Pour résoudre ces défauts des requêtes GET, des requêtes POST ont été ajoutées, permettant de transférer de grandes quantités de données sous forme binaire, c'est-à-dire sans distorsion ni modification des données transmises. De telles requêtes sont bien adaptées au téléchargement de fichiers et d'images sur le serveur. Par exemple, lorsqu'un utilisateur télécharge une image sur son profil de réseau social, des requêtes POST sont utilisées à cet effet. Plus de détails sur l'organisation des requêtes POST seront discutés ci-dessous.

Cela faisait longtemps que je voulais écrire un article dans lequel je parlerais de différence entre la méthode POST et la méthode GET, mais d'une manière ou d'une autre, d'autres sujets sont apparus et je suis passé à eux. Et maintenant, enfin, le moment est venu d'aborder ce sujet, car souvent les gens ne savent tout simplement pas quelle est la différence entre POST et GET.

Pour montrer plus clairement différence entre POST et GET, je fournis un tableau qui montre par quelles caractéristiques ils diffèrent.

Sur la base de cette caractéristique, nous pouvons conclure quand utiliser POSTE, et quand OBTENIR. Par exemple, si l'utilisateur souhaite ajouter la page générée à ses favoris. La génération devrait alors se produire par Requête OBTENIR, sinon vous ne pourrez pas ajouter la page à vos favoris. Autre exemple : lors du passage du login et du mot de passe, vous ne pouvez pas définir la méthode OBTENIR, puisqu'il est basé sur la transmission de données via la barre d'adresse. Sinon, après avoir appuyé sur le bouton " Soumettre", quelque chose comme ceci apparaîtra dans la barre d'adresse : " http://mysite.ru/login.php?log=User&pass=123456", - et tout le monde peut voir le mot de passe, qui, bien sûr, ne devrait pas être autorisé. Par conséquent, ici, vous devez utiliser la méthode POSTE.

N'oubliez pas non plus que la taille des données pouvant être transmises par la méthode POSTE, un ordre de grandeur supérieur à celui transmis par le procédé OBTENIR. De manière générale, analysez ce tableau et tirez une conclusion : quelle méthode de transfert de données doit être utilisée dans un cas particulier. En mon nom personnel, j'ajouterai cela dans 80% il faut utiliser des cas POSTE, mais n'oublie pas que c'est loin d'être 100% .

Si vous avez des questions ou souhaitez commenter cet article, vous pouvez laisser votre commentaire en bas de page.

Commentaires (15) :

dsmts 12.05.2013 14:00:18

Bon après-midi J'ai besoin de quelque chose comme ça lors de la redirection : header("Location: test.php"); La valeur $_POST a été transmise à cette page. La page à partir de laquelle cette valeur doit être transmise ne comporte aucun formulaire. Ceux. il traite simplement les données et génère demande spécifique. Sur ce moment J'effectue le transfert à l'aide de cookies. Mais je ne suis pas sûr que ce soit sûr. Ou je me trompe? Les données transmises ne doivent pas être visibles pour les utilisateurs.

Répondre

Alex_ 23.11.2013 23:56:10

Bonne journée :), Mikhaïl ! J'essaie d'écrire un plugin en PHP et j'ai naturellement découvert que je manquais de connaissances. D'où la question : si un certain site (système de paiement), après mes actions de ma part, m'envoie des données au site sur une page spécifique en utilisant la méthode POST, dois-je les voir si j'écris print_r($_POST) dans le script ? ? Juste dans mon cas, par exemple print_r($_SERVER); vous pouvez voir quelles données se trouvent dans le tableau $_SERVER, mais $_POST est vide, c'est-à-dire que soit les données n'arrivent pas, soit j'ai une vision profane de la réalité des choses.

Répondre

23.11.2013 23:59:31

Bonjour, Alexandre Habituellement systèmes de paiement transmettre des données dans l’ordre inverse sous forme cryptée et en utilisant des protocoles sécurisés. Tout dépend donc du système de paiement. Écrivez-vous un module de paiement pour un système spécifique ? Merci de clarifier vos questions sinon je ne pourrai pas vous aider.

Répondre

Alex_ 24.11.2013 02:00:41

Bonjour Alexandre, merci pour votre réponse. J'écris un plugin pour cms Wordpress, Je travaille avec Système de paiement interkassa.com. Si l'achat réussit, il redirige vers la page de paiement réussie http://my_site/success. Selon la documentation, les données qui me sont visibles arrivent sur cette page. Autrement dit, dans les paramètres, j'ai sélectionné la méthode de transfert GET et une longue URL arrive, ce lien et les paramètres http://my_site/success/?&ik_payment_id=1&ik_paysystem_alias=yandexdengir, tout est comme il se doit. J'ai essayé de sélectionner la méthode de transmission POST, puis dans le script que j'ai écrit, par exemple, if (isset($_POST["ik_trans_id"])) echo $_POST["ik_trans_id"]. Et ça a marché. Ensuite, j'ai commencé à travailler avec l'url STATUS car alors arrive ik_sign_hash, qui est généré par l'intercash à l'aide d'une clé secrète (qui est connue de moi et de l'intercash) et cette fois if (isset($_POST["ik_sign_hash"]) ne fonctionne pas car il n'est pas là. Sur mon site il y a un plugin (il ne fait pas tout comme on voudrait) écrit en POO (je suis encore loin du niveau de celui qui a écrit ça, c'est peut-être pour ça que ce n'est pas évident pour moi ce qui est utilisé là-bas). Ce plugin traite tout et calcule le hachage de son côté, car j'ai délibérément modifié la clé secrète (dans les paramètres du plugin) et un e-mail a été envoyé avec une notification concernant les données transférées de manière incorrecte (les hachages ont été ne correspond pas) et une demande de contact avec l'administrateur du site. Quelque chose comme ça.

Répondre

24.11.2013 02:09:28

Eh bien, je n'ai pas vu votre plugin, donc je ne dirai rien de spécifique. Quant à la simple implémentation...Je n'ai pas étudié l'API interkassa. Vous pouvez voir une solution simple ici : http://goo.gl/rFnpNc. Essentiellement, c'est la même chose dans tous les systèmes. Je travaille habituellement avec une caisse enregistreuse robotisée ou onpei, alors excusez-moi. En général, la structure ressemble à ceci. Vous devez écrire une implémentation conformément à la documentation de l'API http://www.interkassa.com/faq.php voir ici la section Interkassa à travers les yeux d'un programmeur et d'un administrateur + Là dans la dernière question il y a de la documentation technique à télécharger et des petites choses sur l'API en général

Répondre

Alex_ 24.11.2013 02:16:40

Merci, Alexandre. J'ai vu, j'ai lu tout ça, j'essaye depuis plusieurs jours maintenant et je cherche sur Google et je pense que peut-être je ne comprends pas quelque chose :). http://goo.gl/rFnpNc - et c'est un plugin d'Andrey Morkovin, pas entièrement écrit (probablement pour ne pas révéler tous les secrets, le script est désormais payant). Plusieurs leçons vidéo ont été créées sur cette base sur la façon d'écrire des plugins sur WP. Ce plugin http://www.icprojects.net/paid-downloads-plugin.html est disponible en version payante et version gratuite. Dans la version gratuite, seul le paiement PAYPAL est disponible. mais tout est là et si vous modifiez quelques valeurs, le mode Interkassa dans la version bêta devient disponible.

Répondre

24.11.2013 02:23:00

Oui, j'en suis conscient. Il y avait juste un plugin qui traînait. Qu'il soit complet ou non, il fonctionnait. Peut-être qu'il y a une version quelque part qui coûte 40 $. traîner. Dans tous les cas, je ne recommanderai rien de spécifique. Lisez la documentation de l'API Interkassa. Et les algorithmes sont les mêmes partout. Écrivez un gestionnaire qui envoie les données sous forme cryptée et qui les reçoit et les déchiffre sous la même forme. Vous pouvez consulter la solution de Levchuk sur sa page wp ;) Si j'ai le temps, j'examinerai ce sujet plus en détail

1. Protocole HTTP. Introduction

Je voudrais tout de suite clarifier une petite chose. Le terrible mot protocole n'est rien de plus qu'un accord de nombreuses personnes, juste à un moment donné, les gens ont décidé : « Faisons-le ainsi, et alors tout ira bien. Il n’y a rien à craindre, tout est tout simplement scandaleux et nous allons maintenant révéler cette honte. Alors, qu’est-ce que le protocole HTTP et à quoi sert-il ?

1.1 Client et serveur

Il n’y a pas de miracles dans le monde, et surtout dans le monde de la programmation et d’Internet ! Acceptez cela comme une vérité inébranlable. Et si le programme ne fonctionne pas ou ne fonctionne pas comme souhaité, il est fort probable qu'il soit mal écrit ou qu'il contienne des erreurs. Alors, comment le navigateur demande-t-il au serveur de lui envoyer quoi que ce soit ? Oui, très simple ! Vous avez juste besoin de vous détendre un peu et de commencer à profiter du processus :-)

1.2. Écrire notre première requête HTTP

Si vous pensez que tout est trop compliqué, vous vous trompez. L'homme est conçu de telle manière qu'il n'est tout simplement pas capable de créer quelque chose de complexe, sinon il s'y confondra lui-même :-) Donc, il y a un navigateur et il y a un serveur Web. Le navigateur est toujours l'initiateur de l'échange de données. Un serveur Web n'enverra jamais simplement quelque chose à quelqu'un pour qu'il envoie quelque chose au navigateur - le navigateur doit le demander. La requête HTTP la plus simple pourrait ressembler à ceci :

OBTENIR http : //www.php.net/ HTTP/1.0rnrn

* GET (traduit de l'anglais signifie « get ») - le type de requête, le type de requête peut être différent, par exemple POST, HEAD, PUT, DELETE (nous en examinerons certains ci-dessous).
* http://www.php.net/ - URI (adresse) à partir de laquelle nous souhaitons recevoir au moins certaines informations (naturellement, nous espérons connaître la page HTML).
* HTTP/1.0 - le type et la version du protocole que nous utiliserons pour communiquer avec le serveur.
* rn - la fin de la ligne, qui doit être répétée deux fois, pourquoi cela deviendra clair un peu plus tard.

Vous pouvez effectuer cette demande très simplement. Exécutez le programme telnet.exe, entrez www.php.net comme hôte, spécifiez le port 80 et tapez simplement cette demande en appuyant deux fois sur Entrée comme rnrn. En réponse, vous recevrez du code HTML page d'accueil site www.php.net.

1.3 Structure de la demande

Voyons en quoi consiste une requête HTTP. Tout est assez simple. Commençons par le fait qu'une requête HTTP est un texte tout à fait significatif. En quoi cela consiste-t-il dans le cas général ? Nous considérerons le protocole HTTP 1.0. Donc :

Ligne de demande [Général - En-tête | Demande - En-tête | Entité - En-tête ] rn [ Entité - Corps ]

* Request-Line - ligne de demande
*

Format : "Méthode Request-URI HTTP-Versionrn"
* Méthode - la méthode par laquelle la ressource Request-URI sera traitée peut être GET, POST, PUT, DELETE ou HEAD.
* Request-URI - relatif ou référence absolue vers une page avec un ensemble de paramètres, par exemple /index.html ou http://www.myhost.ru/index.html ou /index.html?a=1&b=qq. Dans ce dernier cas, le serveur recevra une requête avec un ensemble de variables a et b avec les valeurs correspondantes, et le signe « & » - une esperluette - sert de séparateur entre les paramètres.
* HTTP-Version - version du protocole HTTP, dans notre cas "HTTP/1.0".

Nous sommes extrêmement intéressés par les méthodes de traitement GET et POST. Avec la méthode GET, vous pouvez simplement transmettre des paramètres au script, et avec la méthode POST, vous pouvez émuler la soumission d'un formulaire.

Pour la méthode GET, l'URI de requête peut ressembler à ceci : "/index.html?param1=1¶m2=2".

* General-Header - la partie principale de l'en-tête.
Format:
Ne peut avoir que deux paramètres : Date ou Pragma. Date - Date de Greenwich au format « Jour de la semaine, Jour Mois Année HH:MM:SS GMT », par exemple « Mar 15 novembre 1994 08:12:31 GMT » - date de création de la demande. Pragma peut avoir une seule valeur sans cache, ce qui désactive la mise en cache des pages.

* Request-Header - partie de l'en-tête qui décrit la demande.

Request-Header peut avoir les paramètres suivants : Autoriser, Autorisation, De, Si-Modifié-Depuis, Référent, Agent Utilisateur.
Dans ce chapitre, nous ne considérerons pas le paramètre Authorization, car il est utilisé pour accéder à des ressources privées, ce qui n'est pas très souvent nécessaire. Vous pouvez apprendre à créer vous-même un en-tête d'accès autorisé sur www.w3c.org.

* Autoriser - définit les méthodes de traitement acceptables.
Format : "Autoriser : GET | HEADn".
Le paramètre est ignoré lors de la spécification de la méthode de traitement POST dans Request-Line. Spécifie les méthodes de traitement des demandes acceptables. Les serveurs proxy ne modifient pas le paramètre Allow et celui-ci atteint le serveur inchangé.

* Depuis - adresse e-mail qui a envoyé la demande.
Format : "De : adderssrn".
Par exemple, « De : [email protégé]".

* If-Modified-Since - indique que la requête n'a pas été modifiée depuis tel ou tel moment.
Format : « Si-Modifié-Depuis : datern »
Utilisé uniquement pour la méthode de traitement GET. La date est spécifiée en GMT dans le même format que pour le paramètre Date dans le General-Header.

* Référent - un lien absolu vers la page à partir de laquelle la demande a été initiée, c'est-à-dire un lien vers la page à partir de laquelle l'utilisateur est arrivé sur la nôtre.
Format : "Référent : URL".
Exemple : « Référent : www.host.ru/index.htmln ».
* Agent utilisateur - type de navigateur.
Par exemple : « Agent utilisateur : Mozilla/4.0n »

* Entity-Header - partie de l'en-tête qui décrit les données Entity-Body.
Cette partie de la requête spécifie les paramètres qui décrivent le corps de la page. Entity-Header peut contenir les paramètres suivants : Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extension-header.

* Autoriser - un paramètre similaire à Autoriser de l'en-tête général.

* Content-Encoding - Type d'encodage des données Entité-Corps.
Format : "Encodage de contenu : x-gzip | x-compress | autre type".
Exemple : « Content-Encoding : x-gzipn ». Le caractère "|" désigne le mot « ou », c'est-à-dire ceci ou cela ou cela, etc.
Un autre type peut indiquer comment les données sont codées, par ex. Méthode POST: "Content-Encoding: application/x-www-form-urlencodedn".

* Content-Length - le nombre d'octets envoyés à l'Entity-Body. La valeur Content-Length a une signification complètement différente pour les données envoyées au format MIME, où elle agit comme un paramètre pour décrire une partie des données - "externe/entité-corps". Les nombres valides sont des entiers à partir de zéro.
Exemple : « Longueur du contenu : 26457n ».

* Content-Type - type de données transmises.
Par exemple : "Content-Type : text/htmln".

* Expire - Heure à laquelle la page doit être supprimée du cache du navigateur.
Format : « Expire : daté ». Le format de date est le même que celui du paramètre Date de General-Header.

* Dernière modification - heure dernier changement données envoyées.
Format : "Dernière modification : datée". Le format de date est le même que celui du paramètre Date de General-Header.

* Extension-header - partie de l'en-tête, qui peut être destinée, par exemple, à être traitée par un navigateur ou un autre programme qui reçoit le document. Dans cette partie, vous pouvez décrire vos paramètres au format "ParameterName: Parametervaluen". Ces paramètres seront ignorés si le programme client ne sait pas comment les traiter.
Par exemple : « Cookie : r=1rn » - définit les cookies connus pour la page.

Et maintenant, après des paroles aussi terribles, essayons de nous calmer un peu et de comprendre de quoi nous avons besoin ? Naturellement, nous comprendrons avec des exemples.

Imaginons que nous devions obtenir une page du site en passant des cookies, sinon nous serons simplement envoyés comme invités non invités, et de plus, on sait que vous n'êtes autorisé à accéder à cette page qu'après avoir visité la page principale du site.

2 Méthode GET

Écrivons notre demande.

OBTENIR http :
Hébergeur : www. site. courir

Cookie : revenu = 1rn
rn

Cette demande nous dit que nous voulons obtenir le contenu de la page http://www.site.ru/news.html en utilisant la méthode GET. Le champ Hôte indique que cette page se trouve sur le serveur www.site.ru, le champ Référent indique que nous sommes venus chercher des actualités depuis la page principale du site, et le champ Cookie indique qu'on nous a attribué tel ou tel cookie. Pourquoi les champs Hôte, Référent et Cookie sont-ils si importants ? Parce que les programmeurs normaux, lors de la création de sites dynamiques, vérifient les champs de données qui apparaissent dans les scripts (y compris PHP) sous forme de variables. À quoi ça sert? Afin, par exemple, d'éviter que le site ne soit cambriolé, c'est-à-dire ils n'ont pas configuré de programme pour le téléchargement automatique, ou pour qu'une personne visitant le site y accède toujours uniquement à partir de la page principale, etc.

Imaginons maintenant que nous devions remplir les champs du formulaire sur la page et envoyer une demande à partir du formulaire, qu'il y ait deux champs dans ce formulaire : login et mot de passe (login et mot de passe) - et, bien sûr, nous connaissons le login et mot de passe.

OBTENIR http : //www.site.ru/news.html?login=Petya%20Vasechkin&password=qq HTTP/1.0rn
Hébergeur : www. site. courir
Référent : http : //www.site.ru/index.htmlrn
Cookie : revenu = 1rn
rn

Notre identifiant est "Petya Vasechkin" Pourquoi devrions-nous écrire Petya%20Vasechkin ? Ceci est dû au fait Symboles spéciaux peuvent être reconnus par le serveur comme des signes de la présence d'un nouveau paramètre ou de la fin d'une requête, etc. Par conséquent, il existe un algorithme pour coder les noms des paramètres et leurs valeurs afin d'éviter les situations d'erreur dans la requête. Description complète Cet algorithme peut être trouvé ici, et PHP possède les fonctions rawurlencode et rawurldecode pour l'encodage et le décodage respectivement. Je voudrais noter que PHP effectue le décodage lui-même si des paramètres codés ont été transmis dans la requête. Ceci conclut le premier chapitre de ma connaissance du protocole HTTP. Dans le prochain chapitre, nous examinerons la création de requêtes comme POST (traduit de l'anglais par « envoyer »), qui sera beaucoup plus intéressante, car exactement ce type request est utilisé lors de l’envoi de données à partir de formulaires HTML.

3. Méthode POST.

Quand Requête HTTP de type POST, il existe deux options pour transférer des champs à partir de formulaires HTML, à savoir en utilisant les algorithmes application/x-www-form-urlencoded et multipart/form-data. Les différences entre ces algorithmes sont assez significatives. Le fait est que le premier type d’algorithme a été créé il y a longtemps, lorsque Langage HTML n'ont pas encore fourni la possibilité de transférer des fichiers via Formulaires HTML. Examinons donc ces algorithmes avec des exemples.

3.1 Type de contenu : application/x-www-form-urlencoded.

Nous écrivons une requête similaire à notre requête GET pour transférer le login et le mot de passe, qui a été abordée dans le chapitre précédent :

POST http : //www.site.ru/news.html HTTP/1.0rn
Hébergeur : www. site. courir
Référent : http : //www.site.ru/index.htmlrn
Cookie : revenu = 1rn
Contenu - Type : application / x - www - formulaire - urlencodedrn
Contenu - Durée : 35mn
rn

Nous voyons ici un exemple d'utilisation des champs d'en-tête Content-Type et Content-Length. Content-Length indique combien d'octets la zone de données occupera, qui est séparée de l'en-tête par un autre saut de ligne rn. Mais les paramètres qui étaient auparavant placés dans le Request-URI pour une requête GET sont désormais dans le Entity-Body. On voit qu'ils se forment de la même manière, il suffit de les écrire après le titre. Je veux souligner encore une chose point important, rien n'empêche, simultanément à l'ensemble des paramètres dans l'Entity-Body, de placer des paramètres avec d'autres noms dans le Request-URI, par exemple :

POST http : //www.site.ru/news.html?type=user HTTP/1.0rn
.....
rn
login = Petya % 20Vasechkin & mot de passe = qq

3.2 Type de contenu : multipart/form-data

Dès que le monde Internet s'est rendu compte qu'il serait intéressant d'envoyer des fichiers via des formulaires, le consortium W3C s'est mis à affiner le format. Requête POST UN. À cette époque, le format MIME (MultiPurpose Internet Mail Extensions - extensions de protocole multi-usages pour la création Messages électroniques), donc, pour ne pas réinventer la roue, nous avons décidé d'utiliser une partie de ce format génération de messages pour création d'un POST requêtes dans le protocole HTTP.

Quelles sont les principales différences entre ce format et le type application/x-www-form-urlencoded ?

La principale différence est que l'Entité-Corps peut désormais être divisée en sections séparées par des frontières (limite). Ce qui est le plus intéressant, c'est que chaque section peut avoir son propre en-tête pour décrire les données qui y sont stockées, c'est-à-dire Vous pouvez transférer des données en une seule demande divers types(comment dans Lettre postale Vous pouvez transférer des fichiers simultanément avec du texte).

Alors, commençons. Reprenons le même exemple avec le transfert du login et du mot de passe, mais maintenant dans un nouveau format.

POST http : //www.site.ru/news.html HTTP/1.0rn
Hébergeur : www. site. courir
Référent : http : //www.site.ru/index.htmlrn
Cookie : revenu = 1rn

Contenu - Durée : 209rn
rn
-- 1BEF0A57BE110FD467Arn
Contenu - Disposition : forme - données ; nom = "login" rn
rn
Petya Vasechkinrn
-- 1BEF0A57BE110FD467Arn
Contenu - Disposition : forme - données ; nom = "mot de passe" rn
rn
qqrn
-- 1BEF0A57BE110FD467A -- rn

Comprenons maintenant ce qui est écrit. :-) J'ai délibérément mis en évidence certains caractères rn en gras afin qu'ils ne se confondent pas avec les données. Si vous regardez attentivement, vous remarquerez le champ limite après Content-Type. Ce champ spécifie le séparateur de section - bordure. Une chaîne composée de lettres et de chiffres latins, ainsi que de quelques autres symboles (malheureusement, je ne me souviens plus lesquels) peut être utilisée comme bordure. Dans le corps de la requête, « -- » est ajouté au début de la limite, et la requête se termine par une limite à laquelle les caractères « -- » sont également ajoutés à la fin. Notre demande comporte deux sections, la première décrit le champ de connexion et la seconde décrit le champ du mot de passe. Content-Disposition (le type de données dans la section) indique qu'il s'agira de données du formulaire et le champ de nom spécifie le nom du champ. C'est là que se termine l'en-tête de section et ce qui suit est la zone de données de section dans laquelle la valeur du champ est placée (pas besoin d'encoder la valeur !).

Je voudrais attirer votre attention sur le fait que vous n'avez pas besoin d'utiliser Content-Length dans les en-têtes de section, mais dans l'en-tête de la requête, vous devriez le faire et sa valeur est la taille de l'intégralité du corps d'entité, qui apparaît après le deuxième rn. Longueur du contenu suivante : 209rn. Ceux. Entity-Body est séparé de l'en-tête par un saut de ligne supplémentaire (qui peut également être vu dans les sections).

Écrivons maintenant une demande de transfert d'un fichier.

POST http : //www.site.ru/postnews.html HTTP/1.0rn
Hébergeur : www. site. courir
Référent : http://www.site.ru/news.htmlrn
Cookie : revenu = 1rn
Type de contenu : multipart/form-data ; limite = 1BEF0A57BE110FD467Arn
Contenu - Durée : 491rn
rn
-- 1BEF0A57BE110FD467Arn
Contenu - Disposition : forme - données ; nom = "news_header" rn
rn
Exemple d'actualité
-- 1BEF0A57BE110FD467Arn
Contenu - Disposition : forme - données ; nom = "fichier_actualités" ; nom de fichier = "news.txt" rn
Contenu - Type : application / octet - streamrn
Contenu - Transfert - Encodage : binairern
rn
Voici les nouvelles, qui est dans le fichier d'actualités. txtrn
-- 1BEF0A57BE110FD467A -- rn

DANS dans cet exemple la première section envoie le titre de l'actualité et la deuxième section envoie le fichier news.txt. Si vous êtes attentif, vous verrez les champs nom de fichier et Type de contenu dans la deuxième section. Le champ filename spécifie le nom du fichier envoyé et le champ Content-Type spécifie le type de ce fichier. Application/octet-stream dit ceci flux standard data, et Content-Transfer-Encoding: binaire indique qu'il s'agit de données binaires, non codées d'aucune façon.

Un point très important. La plupart des scripts CGI sont écrits personnes intelligentes, ils aiment donc vérifier le type du fichier entrant, qui est dans Content-Type. Pour quoi? Le plus souvent, le téléchargement de fichiers sur des sites Web est utilisé pour recevoir des images du visiteur. Ainsi, le navigateur lui-même essaie de déterminer le type de fichier que le visiteur souhaite envoyer et insère le Content-Type approprié dans la requête. Le script le vérifie à réception, et, par exemple, s'il ne s'agit pas d'un gif ou d'un jpeg, il l'ignore ce fichier. Par conséquent, lors de la création d'une requête « manuellement », veillez à ce que la valeur Content-Type soit la plus proche du format du fichier transféré.

Image/gif pour gif
image/jpeg pour jpeg
image/png pour png
image/tiff pour tiff (qui est extrêmement rarement utilisé, le format est trop volumineux)

Dans notre exemple, une requête est générée dans laquelle fichier texte. Une demande de transfert d'un fichier binaire est générée de la même manière.

4. Post-scriptum.

Je pense que cela ne vaut pas la peine de parler en détail de l'envoi de requêtes au serveur. Il s'agit d'une question purement technologique RHP :-). Il suffit de lire attentivement la section sur les fonctions permettant de travailler avec les sockets, ou sur les fonctions du module CURL dans la documentation officielle PHP.

D’après ce qui précède, j’espère que la raison de la question est désormais claire : « Comment puis-je générer une requête POST à ​​l’aide de la fonction d’en-tête ? » - sans signification. La fonction header(string) ajoute une entrée uniquement à l’en-tête de la requête, mais pas au corps de la requête.

Dos

Les ressources Web modernes fournissent non seulement des informations au visiteur, mais interagissent également avec lui. Pour interagir avec l'utilisateur, vous devez recevoir des informations de sa part. Il existe plusieurs méthodes pour obtenir des données, les méthodes les plus courantes sont OBTENIR Et POSTE. Et en conséquence dans PHP il existe un support pour ces méthodes de transfert de données OBTENIR Et POSTE. Voyons comment fonctionnent ces méthodes.
Méthode OBTENIR Données Méthode OBTENIR sont transmis en les ajoutant à l'URL du script invoqué pour traiter les informations reçues. Pour précision cette méthode Tapez l'URL de la ressource dans la barre d'adresse du navigateur et ajoutez d'abord un point d'interrogation (?) puis la ligne num=10. Par exemple

http://domain.ru/script.php?num=10

Si tu as serveur local alors généralement le domaine serait localhost et l'entrée précédente ressemblerait à

http://localhost/script.php?num=10

Dans ce cas, on passe un paramètre num égal à 10. Pour ajouter les paramètres suivants, le script doit utiliser l'esperluette (&), par exemple

http://domain.ru/script.php?num=10&type=new&v=text

Dans ce cas, nous avons passé trois paramètres au script : num avec la valeur 10, type avec la valeur "new" et v avec la valeur "text".
Pour obtenir ces paramètres dans le script, vous devez utiliser le tableau intégré $_GET$_GET["num"], $_GET["type"],$_GET["v"]. Ces éléments du tableau contiendront les valeurs des paramètres passés. Pour illustrer cet exemple, créez un fichier script.php avec le contenu suivant

écho ($_GET["num"]."
");
écho ($_GET["type"]."
");
écho ($_GET["v"]);
?>

Et maintenant, appelez ce fichier dans le navigateur

http://path/script.php?num=10&type=new&v=text

et vous verrez les paramètres transmis dans la fenêtre du navigateur. Mais si vous appelez ce fichier sans paramètres supplémentaires http://path/script.php , vous verrez les erreurs que l'interpréteur produira PHP, qu'il n'existe aucun élément de ce type dans le tableau $_GET. Plus d'un article pourrait être consacré à la vérification des données reçues de l'utilisateur, c'est pourquoi dans cet article je n'aborderai pas ce point.
Comme vous l'avez probablement compris, forcer l'utilisateur à saisir des données dans la barre d'adresse du navigateur n'est pas très bon et est totalement gênant. Par conséquent, pour recevoir des données de l'utilisateur, vous devez utiliser des formulaires HTML. Écrivons un formulaire HTML simple.

Entrez le numéro

Avez-vous un ordinateur?
Oui
Non


Votre commentaire:

Permettez-moi de commenter un peu le formulaire créé. Les formulaires sont créés avec la balise form. Les champs de formulaire sont créés à l'aide des balises input, select, textarea (vous pouvez en savoir plus). Dans la balise form, l'attribut action spécifie l'URL du script qui recevra les données du formulaire. Dans notre cas, nous avons spécifié notre fichier script.php existant. L'attribut méthode spécifie la méthode d'envoi des données. Nous avons précisé la méthode OBTENIR. Nous savons maintenant dans quel fichier les données du formulaire seront transférées et de quelle manière, il ne reste plus qu'à savoir où les chercher ?!
Les données de ce formulaire seront transmises à la ressource Web par le navigateur en les ajoutant à l'URL : il y aura d'abord un point d'interrogation (?), puis les paramètres seront présentés séparés par une esperluette (&). Le nom du paramètre sera tiré de l'attribut name, qui doit être spécifié pour tout champ de formulaire. La valeur du paramètre dépendra du type de champ. Si le champ est un champ de texte, la valeur sera le texte saisi par l'utilisateur. Si le champ est une liste, un groupe de boutons radio ou de cases à cocher, alors la valeur du paramètre sera la valeur de l'attribut value de l'élément sélectionné. Laissez-moi vous expliquer en utilisant notre formulaire comme exemple. Si l'utilisateur saisit le nombre 10 dans le champ de saisie, alors le nom du paramètre sera num (la valeur de l'attribut name de la balise d'entrée) et la valeur sera 10 (le nombre saisi par l'utilisateur). En conséquence, le navigateur générera une paire "num=10". Si l'utilisateur sélectionne l'option "Oui" dans la liste, alors le nom du paramètre sera type (la valeur de l'attribut name de la balise select) et la valeur sera yes (la valeur de l'attribut value de l'option étiqueter). En conséquence, le navigateur générera une paire « type=yes ».
Nous allons maintenant placer ce formulaire sur la page forma.php.

Entrez le numéro

Avez-vous un ordinateur?
Oui
Non


Votre commentaire:

Entrez toutes les valeurs dans les champs du formulaire et cliquez sur le bouton "Soumettre". Après avoir cliqué sur le bouton, le navigateur ouvrira une autre page (script.php) et les données que vous avez saisies seront affichées dans la fenêtre du navigateur. Je pense que la raison est claire : le navigateur transmettra les données au script script.php, et dans le script, ces données seront traitées et affichées à l'écran.
Méthode POST Voyons maintenant comment fonctionne la méthode POSTE.
Pour envoyer des données en utilisant POSTE vous devez utiliser des formulaires HTML. Comme nous nous en souvenons, l'attribut méthode de la balise form est responsable de la méthode d'envoi des données du formulaire. Par conséquent, vous devez spécifier la valeur POST dans l’attribut méthode de la balise form. Sinon, le formulaire peut être le même que pour la méthode GET. Changeons notre formulaire, que nous avons déjà utilisé pour transmettre des données via la méthode GET, pour transmettre via la méthode POST.

Entrez le numéro

Avez-vous un ordinateur?
Oui
Non


Votre commentaire:

Comme vous pouvez le constater, le formulaire reste le même à l'exception des attributs de méthode et d'action. Les données vont maintenant être transmises au script script_post.php. Plaçons notre formulaire sur la page forma_post.php.

Entrez le numéro

Avez-vous un ordinateur?
Oui
Non


Votre commentaire:

Nous devons maintenant écrire un script qui traitera les données de notre formulaire.
Pour recevoir des données dans un script en utilisant la méthode passée POSTE besoin d'utiliser un tableau intégré $_POST. Les clés de ce tableau seront les noms des paramètres. Dans notre cas, nous devons utiliser $_POST["num"], $_POST["type"],$_POST["v"]. Ces éléments du tableau contiendront les valeurs des données transférées. Comme vous pouvez le constater, la différence avec l'utilisation de la méthode GET s'exprime uniquement dans l'utilisation du tableau $_POST. Il ne nous sera donc pas difficile d'écrire le fichier script_post.php :

echo ($_POST["num"]."
");
écho ($_POST["type"]."
");
écho ($_POST["v"]);
?>

Ouvrez maintenant le fichier forma_post.php dans votre navigateur. Entrez quelques données dans les champs du formulaire et cliquez sur le bouton "Soumettre". Maintenant, vous avez probablement remarqué la différence entre la méthode POST et la méthode GET : les données du formulaire n'apparaissaient pas dans la barre d'adresse du navigateur. Données par méthode POSTE ne peuvent pas être transmis via la barre d’adresse du navigateur. C’est une différence significative à retenir.
DANS PHP Quelle que soit la manière dont les données ont été envoyées (méthode POST ou méthode GET), vous pouvez recevoir les données à l'aide du tableau $_REQUEST. Comparaison Méthodes OBTENIR et POSTER Lors de l'utilisation de la méthode GET, les données sont transférées en les ajoutant à l'URL. Ainsi, ils seront visibles par l’utilisateur, ce qui n’est pas toujours bon d’un point de vue sécurité. De plus, la quantité maximale de données transférées dépendra du navigateur - du nombre maximum de caractères autorisé dans la barre d'adresse du navigateur.
Lors de l'utilisation de la méthode POST, les données ne seront pas visibles par l'utilisateur (non affichées dans la barre d'adresse du navigateur). Et donc ils sont plus sécurisés et, par conséquent, le programme traitant ces données est plus protégé en termes de sécurité. De plus, le volume des données transmises est pratiquement illimité.
Lors du choix d'une méthode de transfert de données, vous devez prendre en compte les caractéristiques ci-dessus et choisir la méthode la plus appropriée.

Cet article est une réponse à une question posée dans l'un de mes articles.

Dans cet article, je veux vous expliquer ce que sont les méthodes HTTP GET/POST/PUT/DELETE et autres, pourquoi elles ont été inventées et comment les utiliser conformément à REST.

HTTP

Alors, quel est l’un des principaux protocoles d’Internet ? J'enverrai les pédants vers RFC2616, et je raconterai le reste humainement :)

Ce protocole décrit l'interaction entre deux ordinateurs (client et serveur), construite sur la base de messages appelés requête (Request) et réponse (Response). Chaque message se compose de trois parties : une ligne de départ, des en-têtes et un corps. Dans ce cas, seule la ligne de départ est requise.

Les lignes de départ de la demande et de la réponse sont format différent- nous ne nous intéressons qu'à la ligne de départ de la requête, qui ressemble à ceci :

URI DE LA MÉTHODE HTTP/ VERSION ,

Où METHOD est la méthode de requête HTTP, URI est l'identifiant de la ressource, VERSION est la version du protocole (actuellement la version 1.1 est actuelle).

Les en-têtes sont une collection de paires nom-valeur séparées par deux points. Les en-têtes véhiculent diverses informations sur le service : encodage du message, nom et version du navigateur, adresse d'où provient le client (Referrer), etc.

Le corps du message correspond aux données réelles transmises. Dans la réponse, les données transmises sont généralement la page HTML demandée par le navigateur, et dans la demande, par exemple, dans le corps du message, le contenu des fichiers téléchargés sur le serveur est transmis. Mais en règle générale, la demande ne contient aucun corps de message.

Exemple d'interaction HTTP

Regardons un exemple.

Demande:
GET /index.php HTTP/1.1 Hôte : example.com Agent utilisateur : Mozilla/5.0 (X11 ; U ; Linux i686 ; ru ; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5 Accepter : text/html Connexion : fermer
La première ligne est la ligne de requête, les autres sont des en-têtes ; le corps du message est manquant

Répondre:
HTTP/1.0 200 OK Serveur : nginx/0.6.31 Langage du contenu : ru Type de contenu : text/html ; charset=utf-8 Content-Length : 1234 Connexion : fermer... LA PAGE HTML ELLE-MÊME...

Ressources et méthodes

Revenons à la ligne de départ de la requête et rappelons-nous qu'elle contient un paramètre tel que URI. Cela signifie Uniform Resource Identifier - un identifiant de ressource uniforme. Une ressource est, en règle générale, un fichier sur le serveur (un exemple d'URI dans ce cas est "/styles.css"), mais en général, une ressource peut aussi être un objet abstrait ("/blogs/webdev/" - points au bloc « Web » de développement" plutôt que sur un fichier spécifique).

Le type de requête HTTP (également appelé méthode HTTP) indique au serveur quelle action nous souhaitons effectuer sur la ressource. Initialement (au début des années 90), on supposait que le client ne pouvait vouloir qu'une seule chose d'une ressource : la recevoir, mais maintenant, en utilisant le protocole HTTP, vous pouvez créer des publications, modifier un profil, supprimer des messages et bien plus encore. Et ces actions sont difficiles à combiner avec le terme « reçu ».

Pour différencier les actions des ressources au niveau des méthodes HTTP, les options suivantes ont été inventées :

• GET - obtenir une ressource
• POST - création de ressources
• PUT - mise à jour des ressources
• DELETE - suppression de ressources

Veuillez noter que la spécification HTTP n'exige pas que le serveur comprenne toutes les méthodes (il y en a en réalité bien plus que 4) - seul GET est requis et n'indique pas non plus au serveur ce qu'il doit faire lors de la réception d'une requête avec un particulier méthode. Cela signifie que le serveur en réponse à la requête DELETE /index.php HTTP/1.1 n'est pas obligé de supprimer la page index.php sur le serveur, comme pour une requête GET /index.php HTTP/1.1 n'est pas obligé de vous renvoie la page index.php, il peut la supprimer par exemple :)

REST entre en jeu

REST (REpresentational State Transfer) - ce terme a été introduit en 2000 par Roy Fielding, l'un des développeurs Protocole HTTP- comme le nom d'un groupe de principes pour la création d'applications Web. En général, REST couvre un domaine plus large que HTTP : il peut également être utilisé dans d'autres réseaux avec d'autres protocoles. REST décrit les principes d'interaction entre client et serveur, basés sur les concepts de « ressource » et de « verbe » (peut être compris comme sujet et prédicat). Dans le cas de HTTP, la ressource est identifiée par son URI et le verbe est la méthode HTTP.

REST propose d'éviter d'utiliser le même URI pour différentes ressources (c'est-à-dire les adresses de deux divers articles comme /index.php?article_id=10 et /index.php?article_id=20 - ce n'est pas une méthode REST) ​​et utilisez différentes méthodes HTTP pour différentes actions. C'est-à-dire qu'une application Web écrite à l'aide de l'approche REST supprimera une ressource lors de son accès avec la méthode HTTP DELETE (bien sûr, cela ne signifie pas qu'il est nécessaire de donner la possibilité de supprimer tout et tout le monde, mais n'importe lequel la demande de suppression de l'application doit utiliser la méthode HTTP DELETE).

REST donne aux programmeurs la possibilité d'écrire des applications Web standardisées et légèrement plus jolies qu'auparavant. En utilisant REST, l'URI pour ajouter un nouvel utilisateur ne sera pas /user.php?action=create (méthode GET/POST), mais simplement /user.php (méthode strictement POST).

En conséquence, en combinant la spécification HTTP existante et l’approche REST, diverses méthodes HTTP prennent enfin tout leur sens. GET - renvoie une ressource, POST - en crée une nouvelle, PUT - met à jour une ressource existante, DELETE - la supprime.

Problèmes?

Oui, il y a un petit problème avec l'utilisation de REST dans la pratique. Ce problème s'appelle HTML.

Les requêtes PUT/DELETE peuvent être envoyées à l'aide de XMLHttpRequest, en contactant le serveur manuellement (par exemple, via curl ou même via telnet), mais vous ne pouvez pas créer de formulaire HTML qui envoie une requête PUT/DELETE à part entière.

Le fait est que la spécification HTML ne vous permet pas de créer des formulaires qui soumettent des données autrement que via GET ou POST. Donc pour fonctionnement normal avec d’autres méthodes, il faut les imiter artificiellement. Par exemple, dans Rack (le mécanisme sur la base duquel Ruby interagit avec le serveur Web ; Rails, Merb et d'autres frameworks Ruby sont créés à l'aide de Rack), vous pouvez ajouter un champ caché au formulaire avec le nom "_method", et spécifiez le nom de la méthode comme valeur (par exemple "PUT") - dans ce cas, une requête POST sera envoyée, mais Rack pourra prétendre qu'il a reçu un PUT plutôt qu'un POST.