Génération de requêtes HTTP. Qu'est-ce qu'une requête HTTP (message HTTP)

Dans cet article, nous examinerons à quoi servent les en-têtes, sans entrer dans les détails sur lequel est responsable de quoi. Les rôles des rubriques les plus courantes seront décrits dans les articles suivants.

Tous les articles de la série :

• Que sont les en-têtes HTTP ? Théorie générale.

HTTP signifie HyperText Transfer Protocol. Un protocole est un ensemble de règles selon lesquelles différents appareils échangent des données. Elle a été créée dans les années 1990. Aujourd’hui, il est utilisé presque partout sur Internet. Tout ce que vous voyez dans la fenêtre de votre navigateur a été obtenu grâce à ce protocole. Les en-têtes http sont peut-être l'élément principal de la communication entre les appareils. Ils transmettent des informations de base sur la connexion en cours d'établissement et les informations transmises via cette connexion.
Jetons un coup d'œil au schéma de communication entre les deux appareils. Laissez ces appareils être votre ordinateur et un serveur sur Internet :

Comme vous pouvez le constater, le navigateur a envoyé une requête http. Cela pourrait ressembler à ceci :

GET /other-19 HTTP/1.1 Hôte : www.scriptsite.ru Agent utilisateur : Mozilla/5.0 (Windows ; U ; Windows NT 6.0 ; ru ; rv : 1.9.1.5) Gecko/20091102 Firefox/3.5.5 (.NET CLR 3.5.30729) Accepter : text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accepter la langue : ru,en-us;q=0.7,en;q= 0.3 Accept-Encoding : gzip,deflate Accept-Charset : windows-1251,utf-8;q=0.7,*;q=0.7 Keep-Alive : 300 Connexion : keep-alive

Dans ce cas, la première ligne est la ligne de requête, toutes les autres lignes sont des en-têtes http qui contiennent des informations supplémentaires sur la requête, sur le client qui demande ces informations et sur bien d'autres choses.
En réponse à notre demande, le serveur peut envoyer les en-têtes suivants :

Serveur : Apache/2.0.61 (Unix) mod_ssl/2.0.61 OpenSSL/0.9.8k mod_dp20/0.99.2 PHP/5.2.5 mod_python/3.3.1 Python/2.5.1 mod_ruby/1.2.6 Ruby/1.8.6 (2007-09-24) X-Powered-By : PHP/5.2.5 Set-Cookie : PHPSESSID=ft47gokfee6amv3eda3k1p93s3 ; chemin=/ Cache-Control : pas de stockage, pas de cache, revalidation obligatoire, post-check=0, pre-check=0 Pragma : sans cache Keep-Alive : délai d'attente = 10, max = 1024 Connexion : Keep-Alive Encodage de transfert : fragmenté Type de contenu : texte/html

La première ligne est la ligne d'état. Les lignes restantes sont des en-têtes. Le diagramme montre que le contenu de la page est également chargé. Mais ce contenu n’est généralement pas affiché dans les plugins de visualisation d’en-tête. Et le contenu de la page n’est qu’un cas particulier. Selon le protocole, la page ne doit pas nécessairement être transmise. Au lieu de cela, une image, un fichier son et une vidéo peuvent être transmis. Et tous auront des titres très différents.

Comment voir les en-têtes http ?

Afin de voir les en-têtes http, je recommande les plugins suivants pour le navigateur Firefox :

Si vous utilisez le navigateur Chrome, vous pouvez visualiser toutes les informations en cliquant sur le bouton paramètres - outils - outils de développement. Onglet Réseaux.
Je ne peux donner aucun conseil aux utilisateurs du navigateur Opera, car je ne suis pas ami avec ce navigateur. Une fois les plugins installés et exécutés, essayez d’actualiser la page. Vous verrez immédiatement d'énormes listes de demandes et de réponses par lesquelles votre navigateur a communiqué avec le serveur.

En-têtes HTTP et accès à ceux-ci en php

Si vous êtes un développeur PHP, vous pouvez accéder aux en-têtes de requête à l'aide de la fonction getallheaders(). Pour comprendre comment cela fonctionne, exécutons le code suivant :

Et nous obtenons une impression du tableau d'en-tête.

Mais le plus souvent, on y accède via la variable globale $_SERVER. Presque tous les en-têtes http ont un nom d'élément similaire dans cette variable, formé selon le principe HTTP_header_name. Ainsi, pour le même 'User_Agent', il existe une variable $_SERVER['HTTP_USER_AGENT'] ;

Pour obtenir les en-têtes que le serveur va envoyer à l'utilisateur, la fonction headers_list() est utilisée. En règle générale, le serveur compose les en-têtes requis manquants à la fin de tous les scripts. Par conséquent, ce tableau contiendra les en-têtes soit ceux que le serveur a créés avant le début de l'exécution du script (et ils ne seront pas modifiés), soit ceux que nous avons définis manuellement. Ils peuvent être définis manuellement à l'aide de la fonction header("header text");
Exécutons le code suivant :

Nous verrons une impression des en-têtes prêts à être envoyés au moment où la fonction est appelée :

Le premier en-tête a été défini automatiquement et porte le nom du serveur sur lequel le script est exécuté. Le second a été installé manuellement par nos soins. Si le navigateur avait besoin de l'en-tête "Fruit", il le prendrait dans la réponse http du serveur et l'utiliserait. Mais comme notre navigateur n’en a pas besoin, il ignore simplement la ligne qu’il ne comprend pas.

Structure de la requête HTTP

Notre demande ressemble à ceci :

La première ligne, comme mentionné précédemment, est la ligne de requête. Il se compose de trois parties :

• méthode(méthode) - indique quel type de demande. Les méthodes les plus courantes : GET, POST, HEAD. Ils seront décrits dans le paragraphe suivant.
• chemin(chemin) - il s'agit généralement de la partie de l'URL qui vient après le domaine. Par exemple, si vous saisissez http://www.scriptsite.ru/about/ dans la barre d'adresse, la valeur du chemin sera /about/.
• protocole(protocole) — le protocole utilisé. Se compose généralement de « HTTP » et de la version du protocole. Généralement, les navigateurs modernes utilisent la version 1.1

Viennent ensuite les en-têtes sous forme de chaînes au format « Nom : valeur ».
À propos, les données des cookies sont également transmises dans cette requête comme l'un des en-têtes. La plupart de ces lignes sont facultatives. La requête peut être réduite à seulement deux lignes :

OBTENIR /article/show/4/ HTTP/1.1 Hébergeur : scriptsite.ru

Méthodes de demande

OBTENIR

Une requête get est généralement utilisée pour demander un document et transmettre certains paramètres.
C'est la principale méthode utilisée pour obtenir des pages HTML, des images, des fichiers CSS et JavaScript, etc.
Étant donné que les paramètres peuvent être n'importe quoi et que le serveur n'a aucune restriction sur la manière dont ils peuvent être traités, la méthode de demande de données est souvent utilisée pour transférer des informations. Par exemple, nous aurons un formulaire comme celui-ci

Dans ce cas, ces paramètres seront visibles dans la barre d'adresse du navigateur.

POSTE

La publication est la méthode utilisée pour envoyer des données au serveur. Bien que vous puissiez envoyer des données au serveur en utilisant la méthode GET via la barre d'adresse du navigateur, dans la plupart des cas, il est préférable d'utiliser POST. L'envoi de grandes quantités de données via GET n'est pas pratique. De plus, GET présente certaines limitations qui ne permettent pas, par exemple, de publier cet article sur mon site Web via une seule ligne de navigateur. Les requêtes POST sont le plus souvent utilisées pour soumettre des formulaires Web. Modifions le formulaire de l'exemple précédent pour lui donner une méthode POST

Les en-têtes Content-Type et Content-Length sont ajoutés automatiquement. Ils contiennent des informations sur le type et la taille des données.
Toutes les données sont transférées après l'envoi des en-têtes sous la même forme que dans la ligne de requête GET

La méthode POST est couramment utilisée en AJAX, cURL, etc.
Les formulaires de téléchargement de fichiers fonctionnent uniquement via la méthode POST

TÊTE

Beaucoup d’entre vous ne sont peut-être pas au courant de ce type de demande.
Cette méthode fonctionne de la même manière que la publication, seul le serveur ne renvoie aucun contenu supplémentaire autre que les en-têtes.
L'utilisation de cet en-tête est justifiée dans de nombreux cas. Par exemple, lorsque le navigateur a mis en cache un fichier et souhaite maintenant savoir s'il a changé sur le serveur. Le navigateur peut demander des informations à ce sujet sans télécharger lui-même l'intégralité du fichier.
De plus, cette méthode est souvent utilisée dans les services qui vérifient l'état des liens. Il permet de savoir quelles URL contiennent encore des fichiers et lesquelles n’en ont plus, mais là encore les fichiers ne sont pas téléchargés.

Structure de réponse HTTP

Le serveur répond à chaque requête avec les réponses suivantes :

La première ligne est la version du protocole.
Vient ensuite le code d’état du serveur. Dans ce cas, la valeur du code est 200. Le code d'état indique au navigateur ce qui s'est exactement passé sur le serveur lors du traitement de la demande. Le 200ème statut signifie que notre demande a été traitée avec succès et que le serveur enverra le document demandé immédiatement après l'envoi des en-têtes.
Les lignes restantes indiquent toutes sortes d'informations sur le fichier transféré.

Aux informations sur les statuts, vous pouvez également ajouter l'erreur 404. Son nom vient précisément du code 404 que le serveur envoie lorsqu'il ne trouve pas un fichier sur ses disques.
Plus de détails sur les états du serveur sont écrits dans l'article suivant.

Veuillez également noter

HTTP. C'est basé sur l'interaction" client-serveur", c'est-à-dire qu'il est supposé que :

1. Consommateur- client après avoir initié une connexion avec le fournisseur-serveur, lui envoie une requête ;
2. Fournisseur- serveur, après avoir reçu la demande, effectue les actions nécessaires et renvoie une réponse avec le résultat au client.

   Dans ce cas, il existe deux manières possibles d'organiser le travail de l'ordinateur client :

   • Client léger est un ordinateur client qui transfère toutes les tâches de traitement de l'information vers le serveur. Un exemple de client léger est un ordinateur doté d'un navigateur utilisé pour travailler avec des applications Web.
   • Gros client, au contraire, traite les informations indépendamment du serveur, en utilisant ce dernier principalement uniquement pour le stockage des données.

Avant de passer aux technologies Web client-serveur spécifiques, examinons les principes de base et la structure du protocole HTTP de base.

Protocole HTTP

HTTP (HyperText Transfer Protocol - RFC 1945, RFC 2616) est un protocole de couche application pour le transfert d'hypertexte.

L'entité centrale de HTTP est ressource L'URL pointée dans la demande du client. Généralement, ces ressources sont des fichiers stockés sur le serveur. Une particularité du protocole HTTP est la possibilité de préciser dans la requête et la réponse la méthode de représentation d'une même ressource selon différents paramètres : format, encodage, langue, etc. C'est grâce à la possibilité de spécifier la méthode d'encodage d'un message que le client et le serveur peuvent échanger des données binaires, bien qu'initialement ce protocole soit conçu pour transmettre des informations symboliques. À première vue, cela peut ressembler à un gaspillage de ressources. En effet, les données sous forme symbolique occupent plus de mémoire, les messages créent une charge supplémentaire sur les canaux de communication, mais ce format présente de nombreux avantages. Les messages transmis sur le réseau sont lisibles, et après analyse des données reçues, administrateur du système peut facilement trouver l’erreur et la corriger. Si nécessaire, une personne peut jouer le rôle de l'une des applications en interaction en saisissant manuellement des messages au format requis.

Contrairement à de nombreux autres protocoles, HTTP est un protocole sans mémoire. Cela signifie que le protocole ne stocke pas d'informations sur les demandes précédentes des clients et les réponses du serveur. Les composants utilisant HTTP peuvent conserver indépendamment les informations d'état associées aux demandes et réponses récentes. Par exemple, une application client Web envoyant des requêtes peut suivre les délais de réponse, et un serveur Web peut stocker les adresses IP et les en-têtes de requête des derniers clients.

Tous logiciel pour travailler avec le protocole HTTP est divisé en trois catégories principales :

• Serveurs- les prestataires de services de stockage et de traitement d'informations (traitement des demandes).
• Clientèle- les consommateurs finaux des services serveur (envoi de requêtes).
• Serveurs proxy pour soutenir le travail des services de transport.

Les principaux clients sont navigateurs par exemple : Internet Explorateur, Opéra, Mozilla Firefox, Netscape Navigateur et autres. Les implémentations de serveur Web les plus populaires sont : Internet Information Services (IIS), Apache, lighttpd, nginx. Les implémentations de serveurs proxy les plus connues : Squid, UserGate, Multiproxy, Naviscope.

Le schéma de session HTTP « classique » ressemble à ceci.

1. Établir une connexion TCP.
2. Demande du client.
3. Réponse du serveur.
4. Terminer la connexion TCP.

Ainsi, le client envoie une requête au serveur, en reçoit une réponse, après quoi l'interaction s'arrête. En règle générale, la demande du client est une demande de transfert d'un document HTML ou d'une autre ressource, et la réponse du serveur contient le code de cette ressource.

La requête HTTP envoyée par le client au serveur comprend les composants suivants.

• Ligne d'état (parfois les termes ligne d'état ou ligne de requête sont également utilisés pour y faire référence).
• Champs d'en-tête.
• Chaîne vide.
• Corps de la demande.

Barre d'état avec champs d'en-tête parfois aussi appelé en-tête de demande.

Riz. 2.1.

Barre d'état a le format suivant :

méthode_requête URL_pecypca version_protocole HTTP

Examinons les composants de la barre d'état, avec une attention particulière aux méthodes de requête.

Méthode spécifié dans la ligne d'état détermine comment la ressource dont l'URL est spécifiée dans la même ligne est affectée. La méthode peut prendre les valeurs GET, POST, HEAD, PUT, DELETE, etc. Malgré l'abondance des méthodes, seules deux d'entre elles sont vraiment importantes pour un programmeur Web : GET et POST.

• OBTENIR. Selon la définition formelle, la méthode GET est destinée à obtenir une ressource avec une URL spécifiée. Lors de la réception d'une requête GET, le serveur doit lire la ressource spécifiée et inclure le code de la ressource dans la réponse au client. La ressource dont l'URL est transmise dans le cadre de la requête ne doit pas nécessairement être une page HTML, un fichier image ou d'autres données. L'URL de la ressource peut pointer vers un code de programme exécutable qui, si certaines conditions sont remplies, doit être exécuté sur le serveur. Dans ce cas, le client ne reçoit pas le code du programme, mais les données générées lors de son exécution. Bien que, par définition, la méthode GET soit destinée à récupérer des informations, elle peut être utilisée à d’autres fins. La méthode GET est tout à fait adaptée pour transférer de petites données vers le serveur.
• POSTE. Selon la même définition formelle, le but principal de la méthode POST est de transférer des données vers le serveur. Cependant, comme la méthode GET, la méthode POST peut être utilisée de différentes manières et est souvent utilisée pour récupérer des informations sur un serveur. Comme pour la méthode GET, l'URL spécifiée dans la barre d'état pointe vers une ressource spécifique. La méthode POST peut également être utilisée pour démarrer un processus.
• Les méthodes HEAD et PUT sont des modifications des méthodes GET et POST.

Version du protocole HTTP est généralement spécifié au format suivant :

HTTP/version.modification

Champs d'en-tête, en suivant la ligne de statut, permettent d'affiner la demande, c'est-à-dire transmettre des informations complémentaires au serveur. Le champ d'en-tête a le format suivant :

Nom du champ : valeur

L'objectif d'un champ est déterminé par son nom, qui est séparé de la valeur par deux points.

Les noms de certains des champs d'en-tête les plus courants dans une demande client et leur objectif sont présentés dans le tableau 2.1.

Tableau 2.1.

Champs d'en-tête Champs d’en-tête de requête HTTP. HTTP	-demande
Signification	Hôte
Nom de domaine ou adresse IP de l'hôte auquel le client accède	Référent
URL du document qui référence la ressource répertoriée dans la barre d'état	Depuis
Adresse e-mail de l'utilisateur travaillant avec le client	Accepter
Types de données MIME traitées par le client. Ce champ peut avoir plusieurs valeurs, séparées par des virgules. Souvent, le champ d'en-tête Accepter est utilisé pour indiquer au serveur quels types de fichiers graphiques le client prend en charge.	Accepter la langue
Un ensemble d'identifiants à deux caractères, séparés par des virgules, qui indiquent les langues prises en charge par le client	Accepter le jeu de caractères
Liste des jeux de caractères pris en charge	Type de contenu
Type MIME de données contenues dans le corps de la requête (si la requête ne consiste pas en un seul en-tête)	Longueur du contenu
Nombre de caractères contenus dans le corps de la requête (si la requête ne comporte pas un seul en-tête)	Gamme
Présent si le client ne demande pas l’intégralité du document, mais seulement une partie	Connexion
Utilisé pour gérer la connexion TCP. Si le champ contient Close, cela signifie que le serveur doit fermer la connexion après avoir traité la requête. La valeur Keep-Alive suggère de garder la connexion TCP ouverte afin qu'elle puisse être utilisée pour les requêtes ultérieures	Agent utilisateur

Informations clients

Dans de nombreux cas, lorsque l'on travaille sur le Web, il n'y a pas de corps de requête. Lorsque des scripts CGI sont exécutés, les données qui leur sont transmises dans la requête peuvent être placées dans le corps de la requête.

HTTP (Hyper Text Transfer Protocol) est un protocole de transfert de données de couche application conçu spécifiquement pour l'échange d'informations entre un site Web et un agent utilisateur (navigateur). C’est l’une des normes sur lesquelles repose l’ensemble du World Wide Web. L'interaction entre les moteurs de recherche et les sites Web s'effectue également au sein du protocole HTTP.

Cela n'a aucun sens de raconter ici le contenu de la RFC dans son intégralité et en détail - vous trouverez ci-dessous des liens vers des informations détaillées. Seul le minimum nécessaire pour comprendre le processus d’échange d’informations au sein du protocole est décrit ici.

De nombreux termes peuvent être compris dans des sens différents. Il faut tout de suite se mettre d'accord dans quel sens tel ou tel terme est utilisé dans cet article.

Serveur Web (serveur)- non pas un ordinateur situé dans un data center, mais un programme exécuté sur cet ordinateur qui reçoit les requêtes et envoie les documents demandés.
Agent utilisateur (client, agent utilisateur)- un programme qui envoie des requêtes à un serveur Web et en reçoit des documents. Il peut s'agir de votre navigateur ou d'un robot d'exploration d'un moteur de recherche.
Document- toute information individuelle possédant sa propre adresse dans le domaine. Par défaut, une page HTML est supposée, mais les fichiers d'images, CSS, scripts Java, etc. sont également considérés comme des documents.

Procédure d'échange d'informations

HTTP n'a que deux types de messages : la demande du client et la réponse du serveur. Le client envoie une requête au serveur, indiquant le nom de domaine et l'adresse au sein du domaine où doit se trouver le document requis. Le serveur reçoit le message, recherche le document (ou exécute le script qui génère ce document) et, une fois terminé, envoie un message de réponse.
La structure de ces messages est la même :

Ligne de départ

Rubriques

Corps du message

La ligne de départ et les lignes d'en-tête sont souvent appelées collectivement en-tête « demande » (ou réponse).
Exemple de ligne de requête de départ :

OBTENIR /index.php HTTP/1.1

La méthode de requête (GET), l'adresse du document dans le domaine et la version du protocole utilisée sont transmises.
Exemple de ligne de départ de réponse :

HTTP/1.1 200 OK

La version du protocole, le code d'état numérique (200) et le décodage d'état (OK) ont été transmis.

Rubriques

Les en-têtes de requête contiennent des informations supplémentaires qui peuvent affecter la suite de l'échange de messages. Le nom du domaine à partir duquel le document est demandé est obligatoire. Le type de média attendu du document, la capacité de réception dans un format compressé, la langue attendue pour les documents texte et le nom de l'agent utilisateur qui a envoyé la demande peuvent également être transmis. L'en-tête peut également transmettre les conditions de la demande. Par exemple, If-Modified-Since : [horodatage] - demande un document à condition que son contenu ait changé depuis l'heure spécifiée dans l'en-tête.

L'en-tête de réponse contient également des informations supplémentaires - nom du serveur, heure actuelle, type de support et encodage du document transmis, éventuellement d'autres données (langue des documents texte, date de modification, taille en octets, etc.). Tout cela accompagne les informations du document, qui seront transmises après les en-têtes (dans le corps du message) si la demande aboutit.

S'il est impossible de transférer un document, le code d'état dans le message du serveur correspond à la nature de l'erreur, et à la place du corps du document, une page HTML spéciale avec le texte du message d'erreur est envoyée. Veuillez noter que l'état d'erreur n'empêche pas le navigateur d'afficher cette page.

Méthodes de demande

Le protocole tel que modifié par RFC 2616 décrit huit méthodes pour accéder au serveur. Mais aujourd'hui, tous ne sont pas implémentés pour la plupart des serveurs Web, et seuls deux sont reconnus comme obligatoires pour la mise en œuvre. Les principales méthodes qui nous intéressent et sont supportées par presque tous les serveurs web sont GET, HEAD et POST.

Méthode OBTENIR

Il s'agit de la méthode de requête la plus courante pour récupérer une page Web ou un autre document. En réponse à cette demande, le serveur doit trouver (ou générer) un document et, une fois terminé, l'envoyer au client.
Format de la demande :

OBTENIR HTTP [version du protocole]

Méthode HEAD

Cette méthode est similaire à GET, mais avec une différence : en réponse à une requête HEAD, le serveur effectue une recherche (ou génération de document), mais envoie uniquement les en-têtes de réponse, sans transmettre le corps du message. De cette manière, vous pouvez vérifier l'existence ou la disponibilité d'un document à une adresse donnée, et obtenir toutes les informations sur le document transmises dans les en-têtes, sans recevoir le document lui-même.
Format de la demande :

HEAD HTTP[version du protocole]

Il n'y a pas de corps de message dans la demande.

Méthode POST

Cette méthode est destinée à transférer des données vers le serveur - par exemple, les données saisies dans un formulaire sont généralement transférées à l'aide de la méthode POST.
Format de la demande :

POST HTTP[version du protocole]

Le champ [URI] contient l'adresse du script du gestionnaire de formulaire qui reçoit et traite les données. Le corps du message contient les données saisies dans les champs du formulaire sous la forme [field_name=entered_value].

Codes d'état

Les codes d'état (statut) affichent le résultat de la demande en cours de traitement par le serveur. Le code est représenté par un nombre décimal à trois chiffres, dont le chiffre le plus significatif indique la classe de la réponse. Ainsi, jusqu'à cent codes d'état différents sont réservés pour chaque classe de réponses. Au total, cinq classes sont définies :

1xx : Informatif - informatif

Les codes de 100 à 199 inclus dans cette classe informent le client que la demande a été reçue. Les messages avec de tels statuts contiennent uniquement la ligne de début et (si nécessaire) les en-têtes, mais ne contiennent pas le corps du message. Le client ne doit rien envoyer en réponse à cela.

2xx : Succès - avec succès

Les messages de cette classe indiquent que la demande a été reçue, interprétée et traitée avec succès. Parmi ces codes de statut, nous ne nous intéressons qu'à 200 « OK » - signe d'achèvement normal, après quoi le document demandé est envoyé au client dans le corps du message.

HTTP est un protocole de transfert d'hypertexte entre systèmes distribués. En fait, http est un élément fondamental du Web moderne. En tant que développeurs Web qui se respectent, nous devrions en savoir le plus possible à ce sujet.

Examinons ce protocole à travers le prisme de notre profession. Dans la première partie, nous passerons en revue les bases et examinerons les demandes/réponses. Dans le prochain article, nous examinerons des fonctionnalités plus détaillées, telles que la mise en cache, le traitement des connexions et l'authentification.

Également dans cet article, je ferai principalement référence à la norme RFC 2616 : Hypertext Transfer Protocol -- HTTP/1.1.

Bases du HTTP

HTTP permet la communication entre plusieurs hôtes et clients et prend en charge une gamme de paramètres réseau.

Fondamentalement, TCP/IP est utilisé pour la communication, mais ce n'est pas la seule option possible. Par défaut, TCP/IP utilise le port 80, mais d'autres peuvent être utilisés.

La communication entre l'hôte et le client se déroule en deux étapes : demande et réponse. Le client génère une requête HTTP, en réponse à laquelle le serveur fournit une réponse (message). Un peu plus tard, nous examinerons ce schéma de travail plus en détail.

La version actuelle du protocole HTTP est la 1.1, dans laquelle quelques nouvelles fonctionnalités ont été introduites. À mon avis, les plus importants d'entre eux sont : la prise en charge d'une connexion constamment ouverte, un nouveau mécanisme de transfert de données, un codage de transfert fragmenté, de nouveaux en-têtes pour la mise en cache. Nous en examinerons certains dans la deuxième partie de cet article.

URL

Le cœur de la communication Web est la requête, qui est envoyée via l'Uniform Resource Locator (URL). Je suis sûr que vous savez déjà ce qu'est une URL, mais par souci d'exhaustivité, j'ai décidé de dire quelques mots. La structure de l'URL est très simple et se compose des éléments suivants :

Le protocole peut être soit http pour des connexions régulières, soit https pour un échange de données plus sécurisé. Le port par défaut est 80. Il est suivi du chemin d'accès à la ressource sur le serveur et d'une chaîne de paramètres.

Méthodes

À l'aide d'une URL, nous définissons le nom exact de l'hôte avec lequel nous voulons communiquer, mais l'action que nous devons effectuer ne peut être communiquée qu'en utilisant la méthode HTTP. Bien entendu, il existe plusieurs types d’actions que nous pouvons entreprendre. HTTP implémente les plus nécessaires, adaptés aux besoins de la plupart des applications.

Méthodes existantes :

OBTENIR: Accédez à une ressource existante. L'URL répertorie toutes les informations nécessaires pour que le serveur puisse trouver et renvoyer la ressource demandée en réponse.

POSTE: Utilisé pour créer une nouvelle ressource. Une requête POST contient généralement toutes les informations nécessaires pour créer une nouvelle ressource.

METTRE: Mettre à jour la ressource actuelle. La requête PUT contient les données à mettre à jour.

SUPPRIMER: Utilisé pour supprimer une ressource existante.

Ces méthodes sont les plus populaires et sont le plus souvent utilisées par divers outils et frameworks. Dans certains cas, les requêtes PUT et DELETE sont envoyées par l'envoi d'un POST dont le contenu indique l'action à réaliser sur la ressource : créer, mettre à jour ou supprimer.

HTTP prend également en charge d'autres méthodes :

TÊTE: Similaire à GET. La différence est qu'avec ce type de requête aucun message n'est transmis. Le serveur ne reçoit que les en-têtes. Utilisé, par exemple, pour déterminer si une ressource a été modifiée.

TRACER: lors de la transmission, la requête transite par de nombreux points d'accès et serveurs proxy, dont chacun saisit ses propres informations : IP, DNS. En utilisant cette méthode, vous pouvez voir toutes les informations intermédiaires.

OPTIONS: utilisé pour définir les capacités, les paramètres et la configuration du serveur pour une ressource spécifique.

Codes d'état

En réponse à une demande du client, le serveur envoie une réponse, qui contient également un code d'état. Ce code a une signification particulière afin que le client puisse mieux comprendre comment interpréter la réponse :

1xx : Messages d'information

Un ensemble de ces codes a été introduit dans HTTP/1.1. Le serveur peut envoyer une requête de la forme : Expect : 100-continue, ce qui signifie que le client envoie toujours le reste de la requête. Les clients exécutant HTTP/1.0 ignorent ces en-têtes.

2xx : messages de réussite

Si le client a reçu un code de la série 2xx, la demande a été envoyée avec succès. L'option la plus courante est 200 OK. Avec une requête GET, le serveur envoie une réponse dans le corps du message. Il existe également d'autres réponses possibles :

• 202 Accepté: La requête est acceptée, mais ne peut pas contenir la ressource dans la réponse. Ceci est utile pour les requêtes asynchrones côté serveur. Le serveur détermine s'il doit envoyer la ressource ou non.
• 204 Aucun contenu: Il n'y a aucun message dans le corps de la réponse.
• 205 Réinitialiser le contenu: Demande au serveur de réinitialiser la présentation du document.
• 206 Contenu partiel: La réponse ne contient qu'une partie du contenu. Des en-têtes supplémentaires déterminent la longueur totale du contenu et d'autres informations.

3xx : redirection

Une sorte de message au client sur la nécessité d'entreprendre une action supplémentaire. Le cas d'utilisation le plus courant consiste à rediriger le client vers une autre adresse.

• 301 Déménagé définitivement: La ressource peut désormais être trouvée à une URL différente.
• 303 Voir Autre: La ressource peut temporairement être trouvée à une URL différente. L'en-tête Location contient une URL temporaire.
• 304 Non modifié: Le serveur détermine que la ressource n'a pas été modifiée et le client doit utiliser la version mise en cache de la réponse. Pour vérifier l'identité des informations, ETag (Entity Tag hash) est utilisé ;

4xx : erreurs client

Cette classe de message est utilisée par le serveur s'il décide que la requête a été envoyée par erreur. Le code le plus courant est 404 Not Found. Cela signifie que la ressource n'a pas été trouvée sur le serveur. Autres codes possibles :

• 400 requêtes incorrectes: La question a été mal formulée.
• 401 Non autorisé: Une authentification est requise pour faire une demande. Les informations sont transmises via l’en-tête Authorization.
• 403 Interdit: Le serveur n'a pas autorisé l'accès à la ressource.
• Méthode 405 non autorisée: Une méthode HTTP non valide a été utilisée pour accéder à la ressource.
• 409 Conflit: le serveur ne peut pas traiter entièrement la requête car essaie de modifier une version plus récente d'une ressource. Cela arrive souvent avec les requêtes PUT.

5xx : erreurs de serveur

Une série de codes utilisés pour détecter une erreur de serveur lors du traitement d'une demande. La plus courante : 500 Erreur interne du serveur. Autres options :

• 501 Non mis en œuvre: Le serveur ne prend pas en charge la fonctionnalité demandée.
• Service 503 indisponible: Cela peut arriver si le serveur a une erreur ou est surchargé. Habituellement, dans ce cas, le serveur ne répond pas et le délai imparti pour la réponse expire.

Formats de message de demande/réponse

Dans l'image suivante, vous pouvez voir un processus schématique d'envoi d'une requête par le client, de traitement et d'envoi d'une réponse par le serveur.

Regardons la structure d'un message transmis via HTTP :

Message = *() CRLF [ ] = Ligne de demande | Ligne d'état = Nom du champ ":" Valeur du champ

Il doit y avoir une ligne vide entre l'en-tête et le corps du message. Il peut y avoir plusieurs rubriques :

Le corps de la réponse peut contenir tout ou partie des informations si la fonctionnalité correspondante est activée (Transfer-Encoding : chunked). HTTP/1.1 prend également en charge l'en-tête Transfer-Encoding.

Rubriques générales

Voici plusieurs types d’en-têtes utilisés à la fois dans les requêtes et les réponses :

En-tête général = Cache-Control | Connexion | Dates | Pragma | Remorque | Transfert-Encodage | Mise à niveau | Par | Avertissement

Nous avons déjà abordé certaines choses dans cet article, certaines seront abordées plus en détail dans la deuxième partie.

L'en-tête via est utilisé dans une requête TRACE et est mis à jour par tous les serveurs proxy.

L'en-tête Pragma est utilisé pour répertorier les en-têtes personnalisés. Par exemple, Pragma : no-cache est identique à Cache-Control : no-cache. Nous en parlerons davantage dans la deuxième partie.

L'en-tête Date est utilisé pour stocker la date et l'heure de la demande/réponse.

L'en-tête Upgrade est utilisé pour modifier le protocole.

Transfer-Encoding est destiné à diviser la réponse en plusieurs morceaux à l'aide de Transfer-Encoding: chunked. Il s'agit d'une nouvelle fonctionnalité dans HTTP/1.1.

En-têtes d'entité

Les en-têtes d'entité transmettent des méta-informations sur le contenu :

En-tête d'entité = Autoriser | Encodage de contenu | Contenu-Langage | Longueur du contenu | Emplacement du contenu | Contenu-MD5 | Gamme de contenu | Type de contenu | Expire | Dernière modification

Tous les en-têtes préfixés par Content- fournissent des informations sur la structure, l'encodage et la taille du corps du message.

L'en-tête Expires contient l'heure et la date d'expiration de l'entité. La valeur « n'expire jamais » signifie le temps + 1 code à partir du moment actuel. Last-Modified contient l'heure et la date auxquelles l'entité a été modifiée pour la dernière fois.

A l'aide de ces en-têtes, vous pouvez préciser les informations nécessaires à vos tâches.

Format de demande

La requête ressemble à ceci :

Ligne de requête = Méthode SP URI SP HTTP-Version Méthode CRLF = "OPTIONS" | "TÊTE" | "OBTENIR" | "POST" | "METTRE" | "SUPPRIMER" | "TRACER"

SP est le séparateur entre les jetons. La version HTTP est spécifiée dans HTTP-Version. La requête réelle ressemble à ceci :

GET /articles/http-basics HTTP/1.1 Hôte : www.articles.com Connexion : keep-alive Cache-Control : no-cache Pragma : no-cache Accepter : text/html,application/xhtml+xml,application/xml; q=0,9,*/*;q=0,8

Liste des en-têtes de requête possibles :

En-tête de requête = Accepter | Accepter-Charset | Accepter-Encodage | Accepter-Langue | Autorisation | Attendez-vous | De | Hôte | Si-Match | Si-Modifié-Depuis | Si aucune correspondance | Si-Plage | Si-non modifié-depuis | Max-Forwards | Autorisation par procuration | Gamme | Référent | TE | Agent utilisateur

L'en-tête Accept spécifie les types MIME, la langue et le codage de caractères pris en charge. Les en-têtes From, Host, Referer et User-Agent contiennent des informations sur le client. Les préfixes If- sont destinés à créer des conditions. Si la condition ne répond pas, une erreur 304 Not Modified se produira.

Format de réponse

Le format de réponse ne diffère que par le statut et le nombre d'en-têtes. Le statut ressemble à ceci :

Ligne d'état = Version HTTP SP Code d'état SP Raison-Phrase CRLF

• Version HTTP
• Code d'état
• Message d'état lisible par l'homme

L'état normal ressemble à ceci :

HTTP/1.1 200 OK

Les en-têtes de réponse peuvent être les suivants :

En-tête de réponse = Accept-Ranges | Âge | Etag | Localisation | Authentification par proxy | Réessayer après | Serveur | Varier | WWW-Authentifier

• L'âge est le temps en secondes pendant lequel le message a été créé sur le serveur.
• ETag Entités MD5 pour vérifier les changements et modifications de la réponse.
• L'emplacement est utilisé pour la redirection et contient la nouvelle URL.
• Serveur spécifie le serveur sur lequel la réponse a été générée.

Je pense que c'est assez de théorie pour aujourd'hui. Jetons maintenant un coup d'œil aux outils que nous pouvons utiliser pour surveiller les messages HTTP.

Outils de détection du trafic HTTP

Il existe de nombreux outils pour surveiller le trafic HTTP. En voici quelques-uns :

Les outils de développement Chrome les plus couramment utilisés sont :

Si nous parlons d'un débogueur, vous pouvez utiliser Fiddler :

Pour surveiller le trafic HTTP, vous aurez besoin de curl, tcpdump et tshark.

Bibliothèques pour travailler avec HTTP - jQuery AJAX

Étant donné que jQuery est si populaire, il dispose également d'outils pour gérer les réponses HTTP pour les requêtes AJAX. Des informations sur jQuery.ajax (paramètres) sont disponibles sur le site officiel.

En passant un objet settings et en utilisant la fonction de rappel beforeSend, nous pouvons définir les en-têtes de requête à l'aide de la méthode setRequestHeader().

$.ajax(( url : "http://www.articles.com/latest", tapez : "GET", beforeSend : function (jqXHR) ( jqXHR.setRequestHeader("Accepts-Language", "en-US,en "); ) ));

Si vous souhaitez traiter le statut de la demande, vous pouvez le faire comme ceci :

$.ajax(( statusCode: ( 404: function() ( alert("page not found"); ) ) ));

Conclusion

Le voici, un tour des bases du protocole HTTP. La deuxième partie contiendra des faits et des exemples encore plus intéressants.

HTTP (HyperText Transfer Protocol) a été développé comme base du World Wide Web.

Le protocole HTTP fonctionne comme suit : le programme client établit une connexion TCP avec le serveur (numéro de port standard 80) et lui envoie une requête HTTP. Le serveur traite cette requête et émet une réponse HTTP au client.

Structure de la requête HTTP

Une requête HTTP se compose d'un en-tête de requête et d'un corps de requête, séparés par une ligne vide. Le corps de la requête est peut-être manquant.

L'en-tête de la demande se compose de la (première) ligne principale de la demande et des lignes suivantes qui clarifient la demande dans la ligne principale. Les lignes suivantes peuvent également manquer.

La requête de ligne principale se compose de trois parties, séparées par des espaces :

Méthode(en d'autres termes, la commande HTTP) :

OBTENIR- demande de documents. La méthode la plus couramment utilisée ; en HTTP/0.9, disent-ils, il était le seul.

TÊTE- demande de titre de document. Il diffère de GET en ce sens que seul l'en-tête de la requête contenant des informations sur le document est renvoyé. Le document lui-même n'est pas délivré.

POSTE- cette méthode est utilisée pour transférer des données vers des scripts CGI. Les données elles-mêmes apparaissent dans les lignes suivantes de la requête sous forme de paramètres.

METTRE- placer le document sur le serveur. À ma connaissance, il est rarement utilisé. Une requête avec cette méthode a un corps dans lequel le document lui-même est transmis.

Ressource- c'est le chemin d'accès à un fichier spécifique sur le serveur que le client souhaite recevoir (ou placer - pour la méthode PUT). Si la ressource est simplement un fichier à lire, le serveur doit la renvoyer dans le corps de la réponse à cette requête. S'il s'agit du chemin d'accès à un script CGI, alors le serveur exécute le script et renvoie le résultat de son exécution. D'ailleurs, grâce à cette unification des ressources, le client est pratiquement indifférent à ce qu'il représente sur le serveur.

Version du protocole-version du protocole HTTP avec lequel fonctionne le programme client.

Ainsi, une simple requête HTTP pourrait ressembler à ceci :

Cela demande le fichier racine au répertoire racine du serveur Web.

Les lignes après la ligne de requête principale ont le format suivant :

Paramètre : valeur.

C'est ainsi que les paramètres de la requête sont définis. Ceci est facultatif ; toutes les lignes après la ligne de requête principale peuvent être manquantes ; dans ce cas, le serveur accepte leur valeur par défaut ou en fonction des résultats de la requête précédente (lorsque l'on travaille en mode Keep-Alive).

Je vais énumérer certains des paramètres de requête HTTP les plus couramment utilisés :

Présent si le client ne demande pas l’intégralité du document, mais seulement une partie(connexion) - peut prendre les valeurs Keep-Alive et fermer. Keep-Alive signifie qu'après l'émission de ce document, la connexion au serveur n'est pas interrompue et d'autres requêtes peuvent être émises. La plupart des navigateurs fonctionnent en mode Keep-Alive, car il vous permet de « télécharger » une page HTML et ses images en une seule connexion au serveur. Une fois défini, le mode Keep-Alive est maintenu jusqu'à la première erreur ou jusqu'à ce que la prochaine demande Connection: close soit explicitement spécifiée.
close ("close") - la connexion est fermée après avoir répondu à cette demande.

Utilisé pour gérer la connexion TCP. Si le champ contient Close, cela signifie que le serveur doit fermer la connexion après avoir traité la requête. La valeur Keep-Alive suggère de garder la connexion TCP ouverte afin qu'elle puisse être utilisée pour les requêtes ultérieures- la valeur est le "code" du navigateur, par exemple :

Mozilla/4.0 (compatible ; MSIE 5.0 ; Windows 95 ; DigExt)

Adresse e-mail de l'utilisateur travaillant avec le client- une liste des types de contenus supportés par le navigateur par ordre de préférence pour un navigateur donné, par exemple pour mon IE5 :

Accepter : image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-excel, application/msword, application/vnd.ms-powerpoint, */*

Ceci est évidemment nécessaire dans le cas où le serveur peut sortir le même document dans différents formats.

La valeur de ce paramètre est utilisée principalement par les scripts CGI pour générer une réponse adaptée à un navigateur donné.

Nom de domaine ou adresse IP de l'hôte auquel le client accède- URL à partir de laquelle vous êtes arrivé à cette ressource.

Signification- le nom de l'hôte auprès duquel la ressource est demandée. Utile si le serveur possède plusieurs serveurs virtuels sous la même adresse IP. Dans ce cas, le nom du serveur virtuel est déterminé par ce champ.

Types de données MIME traitées par le client. Ce champ peut avoir plusieurs valeurs, séparées par des virgules. Souvent, le champ d'en-tête Accepter est utilisé pour indiquer au serveur quels types de fichiers graphiques le client prend en charge.- langue prise en charge. Important pour un serveur qui peut servir le même document dans différentes versions linguistiques.

Format de réponse HTTP

Le format de réponse est très similaire au format de requête : il comporte également un en-tête et un corps séparés par une ligne vide.

L'en-tête se compose également d'une ligne principale et de lignes de paramètres, mais le format de la ligne principale est différent de celui de l'en-tête de la requête.

La chaîne de requête principale se compose de 3 champs séparés par des espaces :

Version du protocole- similaire au paramètre de requête correspondant.

Code d'erreur- désignation du code du « succès » de la demande. Le code 200 signifie « tout est normal » (OK).

Description verbale de l'erreur- "déchiffrer" le code précédent. Par exemple, pour 200, c'est OK, pour 500, c'est une erreur interne du serveur.

Les paramètres de réponse http les plus courants :

Présent si le client ne demande pas l’intégralité du document, mais seulement une partie- similaire au paramètre de requête correspondant.
Si le serveur ne prend pas en charge Keep-Alive (il y en a), alors la valeur Connection dans la réponse est toujours proche.

Par conséquent, à mon avis, la bonne tactique de navigation est la suivante :
1. émettre Connection: Keep-Alive dans la demande ;
2. L'état de la connexion peut être jugé par le champ Connexion dans la réponse.

Liste des jeux de caractères pris en charge(« type de contenu ») - contient une désignation du type de contenu de la réponse.

En fonction de la valeur Content-Type, le navigateur interprète la réponse comme une page HTML, une image gif ou jpeg, un fichier à enregistrer sur le disque ou autre chose et prend les mesures appropriées. La valeur Content-Type pour le navigateur est la même que la valeur de l'extension de fichier pour Windows.

Quelques types de contenu :

text/html - texte au format HTML (page Web) ;
text/plain - texte brut (similaire au Bloc-notes) ;
image/jpeg - image au format JPEG ;
image/gif - le même, au format GIF ;
application/octet-stream - un flux d'"octets" (c'est-à-dire juste des octets) à écrire sur le disque.

Il existe en réalité bien d’autres types de contenu.

Type MIME de données contenues dans le corps de la requête (si la requête ne consiste pas en un seul en-tête)("content length") - la longueur du contenu de la réponse en octets.

Dernière modification(« Dernière modification ») - la date à laquelle le document a été modifié pour la dernière fois.