Considérez ce code HTML :

Entrez du texte:

Ensuite, les données seront envoyées à l'aide de la méthode GET.

Si, dans le cas d'une requête GET, la quantité de données que nous pouvions transférer était limitée par la longueur de la barre d'adresse du navigateur, alors dans le cas d'une requête POST, il n'y a pas une telle limitation et nous pouvons transférer des quantités importantes. d'information.

Une autre différence Méthode POST depuis GET, la méthode POST masque toutes les variables qu'elle passe ainsi que leurs valeurs dans son corps (Entity-Body). Dans le cas de la méthode GET, ils étaient stockés dans la chaîne de requête (Request-URI).

Voici un exemple de requête effectuée à l'aide de la méthode POST :

POST / HTTP/1.0\r\n
Hébergeur : www.site.ru\r\n
Référent : http://www.site.ru/index.html\r\n
Cookie : revenu=1\r\n
Type de contenu : application/x-www-form-urlencoded\r\n
Longueur du contenu : 35\r\n
\r\n
login=Dima&mot de passe=12345

Ainsi, en transmettant des données via la méthode POST, il sera beaucoup plus difficile pour un attaquant de les intercepter, car ils sont cachés à la vue directe, la méthode POST de transmission de données est donc considérée comme une méthode plus sécurisée.

De plus, en utilisant la méthode POST, vous pouvez transférer non seulement du texte, mais également des données multimédias (images, audio, vidéo). Il existe un paramètre spécial Content-Type qui détermine le type d'informations qui doivent être transmises.

Et enfin, afin de recevoir les données transmises par cette méthode sur le serveur, la variable POST est utilisée.

Voici un exemple de traitement en PHP :

echo $_POST['texte'];
?>

Dans le dernier post, nous avons décidé de ce que le navigateur (client) envoie serveur HTTP demandes et le serveur envoie des réponses HTTP au client. Ces demandes et réponses sont formatées selon certaines règles. Il existe quelque chose comme une syntaxe, comment et dans quel ordre elle doit être écrite. Il doit y avoir une structure strictement définie.

Examinons de plus près cette structure par laquelle les requêtes et les réponses sont construites dans le protocole HTTP.

Une requête HTTP se compose de trois parties principales, qui apparaissent dans l'ordre indiqué ci-dessous. Entre les en-têtes et le corps du message se trouve une ligne vide (comme séparateur), elle représente un caractère de saut de ligne.

Chaîne vide (séparateur)

Demandes Post et Get, quelle est la différence entre elles, laquelle est la meilleure et à quelles fins ?

corps du message (Entity Body) – paramètre facultatif

Chaîne de requête– précise la méthode de transfert, l'URL à laquelle accéder et la version Protocole HTTP.

Rubriques– décrire le corps des messages, transmettre divers paramètres et autres informations et informations.

Corps du message- ce sont les données elles-mêmes qui sont transmises dans la requête. Le corps du message est un paramètre facultatif et peut être manquant.

Lorsque nous recevons une demande de réponse du serveur, le corps du message est le plus souvent le contenu de la page Web. Mais, lors des requêtes au serveur, il peut aussi parfois être présent, par exemple lorsque nous transférons les données que nous avons renseignées dans le formulaire. retour au serveur.

Nous examinerons chaque élément de la demande plus en détail dans les notes suivantes.

Prenons par exemple une requête réelle adressée au serveur. J'ai mis en évidence chaque partie de la demande avec une couleur différente : la ligne de la demande est verte, les en-têtes sont orange et le corps du message est bleu.

Requête du navigateur :

Hébergeur : webgyry.info

Cookie : paramètres wp

Connexion : keep-alive

Dans l'exemple suivant, le corps du message est déjà présent.

Réponse du serveur :

Type de contenu : texte/html ; jeu de caractères = UTF-8

Encodage de transfert : fragmenté

Connexion : keep-alive

Keep-Alive : délai d'attente = 5

X-Ping : //webgyry.info/xmlrpc.php

Ce sont les messages échangés entre le client et le serveur via HTTP.

Au fait, voulez-vous savoir s'il est utile d'utiliser certains éléments de votre site Web en utilisant les « objectifs » de Yandex Metrics et de Google Analytics ?

Supprimez ce qui ne fonctionne pas, ajoutez ce qui fonctionne et doublez vos revenus.

Cours sur la définition des objectifs de Yandex Metrica.

Cours sur la configuration des objectifs Google Analytics.

Le client HTTP envoie une requête au serveur sous la forme d'un message de requête, qui a le format suivant :

• Chaîne de requête (obligatoire)
• Titre (élément facultatif)
• Chaîne vide (obligatoire)
• Corps du message (élément facultatif)

Examinons chacun de ces éléments séparément.

Chaîne de requête

La ligne de requête commence par un jeton de méthode, suivi de l'URI de la requête et de la version du protocole. Les éléments sont séparés les uns des autres par des espaces :

Regardons cet élément plus en détail.

Méthode de demande

Cet élément spécifie une méthode qui doit être appelée côté serveur à l'URI spécifié.

Il existe huit méthodes en HTTP :

• TÊTE
  Utilisé pour obtenir l'état et la chaîne d'en-tête du serveur par URI. Ne modifie pas les données.
• OBTENIR
  Utilisé pour recevoir des données du serveur à l'URI spécifié. Ne modifie pas les données.
• POSTE
  Utilisé pour envoyer des données au serveur (telles que des informations sur le développeur, etc.) à l'aide de formulaires HTML.
• METTRE
  Remplace toutes les données précédentes de la ressource par les nouvelles données chargées.
• SUPPRIMER
  Supprime toutes les données actuelles sur la ressource spécifiée par l'URI.
• CONNECTER
  Établit une connexion tunnel au serveur à l'URI spécifié.
• OPTIONS
  Décrit les propriétés de connexion pour la ressource spécifiée.
• TRACER
  Fournit un message contenant une trace de retour de l'emplacement de la ressource spécifiée dans l'URI.

URI de la demande

L'URI (Uniform Resource Identifier) ​​​​​​est l'identifiant de la ressource à laquelle la requête est envoyée. Voici le format d'URI le plus couramment utilisé :

‘*’ utilisé lorsque la requête HTTP ne concerne pas une ressource spécifique, mais le serveur. Utilisé uniquement lorsque la méthode n'a pas besoin d'être appliquée à une ressource. Par exemple,

URIabsolu utilisé lorsqu'une requête HTTP est effectuée sur un proxy. Le proxy est invité à transmettre la requête depuis le cache disponible et renvoie une réponse. Par exemple:

chemin_absolu | source le plus couramment utilisé.

Apprendre à travailler avec les requêtes GET et POST

Une ressource spécifique sur un serveur spécifique est demandée. Par exemple, un client souhaite recevoir une ressource d'un serveur via le port 80. L'adresse de la ressource est « www.proselyte.net » et envoie la requête suivante :

Interrogation des champs d'en-tête

Les champs d'en-tête permettent au client de transmettre Informations Complémentaires sur la demande et sur vous-même au serveur. Ces champs agissent comme des modificateurs de requête.

Vous trouverez ci-dessous une liste des champs d'en-tête les plus importants pouvant être utilisés :

• Accepter le jeu de caractères
• Accepter-Encodage
• Accepter la langue
• Autorisation
• Attendre
• Si-correspond
• Si-Modifié-Depuis
• Si aucune correspondance
• Si-plage
• Si-non modifié-depuis
• Gamme
• Référent
• Agent utilisateur

Si nous voulons implémenter notre propre client et notre propre serveur Web, nous pouvons alors créer nos propres champs d'en-tête.

Exemple de requête HTTP

Ceci conclut notre étude des requêtes HTTP.
Dans le prochain article, nous examinerons les réponses HTTP.

L'une des façons d'envoyer une requête HTTP à un serveur consiste à utiliser la méthode GET. Cette méthode est la plus courante et les requêtes adressées au serveur se font le plus souvent en l'utilisant.

Le moyen le plus simple de créer une requête GET consiste à saisir l'URL dans la barre d'adresse de votre navigateur.

Le navigateur enverra au serveur approximativement les informations suivantes :

OBTENIR / HTTP/1.1
Hébergeur : webgyry.info
Agent utilisateur : Mozilla/5.0 (Windows NT 6.1 ; rv:18.0) Gecko/20100101 Firefox/18.0
Accepter : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Langue acceptée : ru-RU,ru;q=0.8,en-US;q=0.5,en;q=0.3
Accepter l'encodage : gzip, dégonfler
Cookie : paramètres wp
Connexion : keep-alive

La demande se compose de deux parties :

1. Ligne de demande

2. En-têtes de message

Notez qu'une requête GET n'a pas de corps de message. Mais cela ne signifie pas qu'avec son aide, nous ne pouvons transmettre aucune information au serveur.

Différence entre les méthodes GET et POST

Cela peut être fait en utilisant des paramètres GET spéciaux.

Pour ajouter des paramètres GET à une requête, vous devez ajouter un « ? » à la fin de l'URL. et après cela, commencez à leur poser des questions selon la règle suivante :

nom_paramètre1=valeur_paramètre1& nom_paramètre2=valeur_paramètre2&…

Le séparateur entre les paramètres est le signe « & ».

Par exemple, si l’on souhaite transmettre deux valeurs au serveur, le nom d’utilisateur et son âge, alors cela peut se faire avec la ligne suivante :

http://site.ru/page.php?name=dima&age=27

Lorsque cette requête est exécutée, les données se retrouvent dans la variable d'environnement dite QUERY_STRING, à partir de laquelle elles peuvent être récupérées sur le serveur à l'aide d'un langage de programmation Web côté serveur.

Voici un exemple de la façon dont cela peut être réalisé en PHP.

echo "Votre nom : " . $_GET["nom"] . "
»;
echo "Votre âge : " . $_GET["âge"] . "
»;
?>

La construction $_GET["parameter_name"] permet d'afficher la valeur du paramètre passé.

Suite à l'exécution de ce code dans le navigateur, les éléments suivants seront affichés :

Votre nom : Dima
Votre âge : 27 ans

Nous faisons également une requête au serveur en utilisant la méthode GET.

Création de requêtes POST à ​​l'aide de PHP

La première méthode pour effectuer une requête PHP POST consiste à utiliser file_get_contents . La deuxième méthode utilisera fread en combinaison avec quelques autres fonctions. Les deux options utilisent la fonction stream_context_create pour remplir les champs d'en-tête de demande requis.

Explication du code

La variable $sPD contient les données à transférer. Il doit être au format de chaîne de requête HTTP, donc certains Symboles spéciaux doit être codé.

Dans la fonction file_get_contents et la fonction fread, nous avons deux nouveaux paramètres. Le premier est use_include_path . Puisque nous faisons une requête HTTP, elle sera fausse dans les deux exemples. Lorsque vous utilisez true pour lire ressource locale la fonction recherchera le fichier dans include_path .

Le deuxième paramètre est le contexte, qui est renseigné avec la valeur de retour de stream_context_create, qui prend la valeur du tableau $aHTTP.

Utiliser file_get_contents pour effectuer des requêtes POST

Pour envoyer une requête POST en utilisant file_get_contents en PHP, vous devez utiliser stream_context_create pour remplir manuellement les champs d'en-tête et spécifier quel "wrapper" utiliser - dans ce cas HTTP :

$sURL = "http://brugbart.com/Examples/http-post.php"; // URL DE POST $sPD = "name=Jacob&bench=150"; // Données POST $aHTTP = array("http" => // Wrapper qui sera utilisé array("method" => "POST", // Méthode de requête // Les en-têtes de requête sont définis sous "header" => "Contenu - tapez : application/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $contents = file_get_contents($sURL, false, $context); echo $contenu ;

Utiliser fread pour effectuer des requêtes POST

Vous pouvez utiliser la fonction fread pour effectuer des requêtes POST. L'exemple suivant utilise stream_context_create pour composer les en-têtes de requête HTTP nécessaires :

$sURL = "http://brugbart.com/Examples/http-post.php"; // URL DE POST $sPD = "name=Jacob&bench=150"; // Données POST $aHTTP = array("http" => // Wrapper qui sera utilisé array("method" => "POST", // Méthode de requête // Les en-têtes de requête sont définis sous "header" => "Content - tapez : application/x-www-form-urlencoded", "content" => $sPD)); $context = stream_context_create($aHTTP); $handle = fopen($sURL, "r", false, $context); $contenu = ""; while (!feof($handle)) ( $contents .= fread($handle, 8192); ) fclose($handle); echo $contenu ;

Faire des requêtes GET avec PHP

Nous allons maintenant nous concentrer sur l'utilisation de fread et file_get_contents pour télécharger du contenu depuis Internet via HTTP et HTTPS. Pour utiliser les méthodes décrites dans cet article, vous devez activer l'option fopen wrappers. Pour ce faire, vous devez définir le paramètre allow_url_fopen sur On dans le fichier php.ini.

L'exécution de requêtes POST et GET en PHP est utilisée pour se connecter à des sites Web, récupérer le contenu de pages Web ou rechercher de nouvelles versions d'applications. Nous verrons comment effectuer des requêtes HTTP simples.

Utiliser fread pour télécharger ou recevoir des fichiers sur Internet

N'oubliez pas que la lecture des pages Web est limitée à la partie accessible du paquet. Vous devez donc utiliser la fonction stream_get_contents ( similaire à file_get_contents) ou boucle while pour lire le contenu en petits morceaux jusqu'à ce que la fin du fichier soit atteinte :

Dans ce cas de traitement d'une requête PHP POST, le dernier argument de la fonction fread est égal à la taille du fragment. Il ne doit généralement pas être supérieur à 8 192 ( 8*1024 ).

DANS Dernièrement Je vois de plus en plus de questions sur le sujet dans le forum principal du RHPClub création d'un POST et GET, ainsi que des questions sur le sujet : "Comment puis-je générer une requête POST à ​​l'aide de la fonction d'en-tête." Je crois que la nécessité de mettre les points sur les « i » dans l'utilisation de cette technologie, car les programmeurs débutants ne comprennent tout simplement pas les principes du Web en tant que tels. Commençons donc notre voyage à travers le monde du protocole HTTP.

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.0\r\n\r\n

• GET (traduit de l'anglais signifie « get ») - un type de requête ; le type de requête peut être différent, par exemple POST, HEAD, PUT, DELETE (nous en examinerons quelques-uns 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 est le type et la version du protocole que nous utiliserons pour communiquer avec le serveur.
• \r\n est la fin de la ligne, qui doit être répétée deux fois ; pourquoi cela deviendra clair un peu plus tard.

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 [En-tête général | En-tête de requête | En-tête d'entité ]\r\n[ Corps d'entité ]

• Ligne de demande- chaîne de requête

Format : "URI de demande de méthode, version HTTP\r\n"

• Méthode- La méthode par laquelle la ressource Request-URI sera traitée peut être GET, POST, PUT, DELETE ou HEAD.
• URI de requête- parent 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.
• Version HTTP- 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, le Request-URI pourrait ressembler à ceci : "/index.html?param1=1¶m2=2".

• En-tête général- la partie principale du titre.
  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.
• En-tête de requête- 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.

• Permettre- définit les méthodes de traitement acceptables.
  Format : "Autoriser : GET | HEAD\n".
  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 de la personne qui a envoyé la demande.
  Format : "De : additionneurs\r\n".
  Par exemple, « De : [email protégé]\r\n".
• Si-Modifié-Depuis- indique que la demande n'a pas été modifiée depuis tel ou tel moment.
  Format : "Si-Modifié-Depuis : date\r\n"
  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\n".
  Exemple : « Référent : www.host.ru/index.html\n ».
• Agent utilisateur- type de navigateur.
  Par exemple : "Agent utilisateur : Mozilla/4.0\n"
• En-tête d'entité- partie de l'en-tête décrivant les données Entité-Corps.
  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 : Autoriser, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified, extension-header.
• Permettre- un paramètre similaire à Allow from General-Header.
• Encodage de contenu- type d'encodage des données Entité-Corps.
  Format : "Encodage de contenu : x-gzip | x-compress | autre type\n".
  Exemple : "Content-Encoding : x-gzip\n". 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 exemple pour la méthode POST : "Content-Encoding: application/x-www-form-urlencoded\n".
• Longueur du contenu- le nombre d'octets envoyés à l'Entité-Corps. 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 : "Contenu-Longueur : 26457\n".
• Type de contenu- type de données transmises.
  Par exemple : « Type de contenu : texte/html\n ».
• Expire- L'heure à laquelle la page doit être supprimée du cache du navigateur.
  Format : "Expire : date\n". Le format de date est le même que celui du paramètre Date de General-Header.
• Dernière modification- heure de la dernière modification des données transmises.
  Format : "Dernière modification : date\n". Le format de date est le même que celui du paramètre Date de General-Header.
• en-tête d'extension- une partie de l'en-tête, qui peut être destinée, par exemple, à être traitée par un navigateur ou autre programme recevant le document. Dans cette partie, vous pouvez décrire vos paramètres au format "ParameterName: Parametervalue\n". Ces paramètres seront ignorés si le programme client ne sait pas comment les traiter.
  Par exemple : "Cookie : r=1\r\n" - 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://www.site.ru/news.html HTTP/1.0\r\n
Hébergeur : www.site.ru\r\n

Cookie : revenu=1\r\n
\r\n

Cette requête nous indique que nous souhaitons 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 nouvelles de 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.0\r\n
Hébergeur : www.site.ru\r\n
Référent : http://www.site.ru/index.html\r\n
Cookie : revenu=1\r\n
\r\n

Notre identifiant est "Petya Vasechkin" Pourquoi devrions-nous écrire Petya%20Vasechkin ? En effet, des caractères 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. Une description complète de cet algorithme peut être trouvée, et PHP dispose respectivement des fonctions rawurlencode et rawurldecode pour l'encodage et le décodage. 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.

Dans le cas d'une requête HTTP POST, il existe deux options pour transférer des champs à partir de formulaires HTML, à savoir l'utilisation des 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 des 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 :

Hébergeur : www.site.ru\r\n
Référent : http://www.site.ru/index.html\r\n
Cookie : revenu=1\r\n
Type de contenu : application/x-www-form-urlencoded\r\n
Longueur du contenu : 35\r\n
\r\n

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 \r\n. 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.0\r\n
.....
\r\n
login=Petya%20Vasechkin&mot de passe=qq

3.2 Type de contenu : multipart/form-data

Dès que le monde Internet a compris qu'il serait intéressant d'envoyer des fichiers via des formulaires, le consortium W3C s'est mis à affiner le format de requête POST. À 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 de génération de messages pour créer des requêtes POST 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.0\r\n
Hébergeur : www.site.ru\r\n
Référent : http://www.site.ru/index.html\r\n
Cookie : revenu=1\r\n

Longueur du contenu : 209\r\n
\r\n
--1BEF0A57BE110FD467A \r\n
Contenu-Disposition : données de formulaire ; nom="connexion" \r\n
\r\n
Petya Vasechkine \r\n
--1BEF0A57BE110FD467A \r\n
Contenu-Disposition : données de formulaire ; nom = "mot de passe" \r\n
\r\n
qq \r\n
--1BEF0A57BE110FD467A-- \r\n

Comprenons maintenant ce qui est écrit. :-) J'ai spécialement mis en évidence certains caractères \r\n en gras afin qu'ils ne fusionnent 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'ensemble du corps d'entité, qui apparaît après le deuxième \ r\n suivant la longueur du contenu : 209\ r\n. 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.0\r\n
Hébergeur : www.site.ru\r\n
Référent : http://www.site.ru/news.html\r\n
Cookie : revenu=1\r\n
Type de contenu : multipart/form-data ; limite=1BEF0A57BE110FD467A\r\n
Longueur du contenu : 491\r\n
\r\n
--1BEF0A57BE110FD467A \r\n
Contenu-Disposition : données de formulaire ; nom="news_header" \r\n
\r\n
Exemple d'actualité \r\n
--1BEF0A57BE110FD467A \r\n
Contenu-Disposition : données de formulaire ; nom="news_file"; nom de fichier="news.txt" \r\n
Type de contenu : application/flux d'octets \r\n
Encodage de transfert de contenu : binaire \r\n
\r\n
Et voici la nouvelle, qui est dans le fichier news.txt \r\n
--1BEF0A57BE110FD467A-- \r\n

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é.

Dans notre exemple, une requête est générée dans laquelle un fichier texte est transféré. 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 de pure technologie 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.

Il existe un autre type de requête - Content-Type : multipart/mixed, j'espère qu'après avoir lu cet article, vous comprendrez facilement ce type vous-même. Vous pouvez l'étudier en détail

Cet article est une réponse à une question posée dans un commentaire sur 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

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 ont des formats différents - nous nous intéressons uniquement à la ligne de départ de la demande, 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

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

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

REST entre en jeu

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 OBTENIR/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?

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. Par conséquent, pour travailler normalement 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.