Partager cet article

RSS
BOURSE

RUBRIQUES

 
 PRATIQUE ALGO/METHODES 
Expliquez-moi... Le fonctionnement d'une liaison client/serveur avec HTTP
 
Le voyage d'une page Web sur le réseau Internet est semé de requêtes aux contenus abscons. Découvrez le processus d'exécution de ces commandes HTTP, et apprenez à déchiffrer leurs en-têtes. (28/12/2006)
  Forum

Réagissez dans les forums de JDN Développeurs

Les pages Web utilisent le protocole HTTP pour passer du serveur où elles sont hébergées, au client qui les exploitera - le plus souvent un navigateur. En anglais, le client est communément appelé "user agent". L'ergonomie d'un navigateur peut porter à croire que les pages sont envoyées telles quelles à la demande de celui-ci, mais en réalité tous les échanges entre client et serveur sont composés d'un en-tête et d'un corps, la page Web étant contenue dans ce dernier.

La connexion entre client est serveur est tout d'abord réalisée par le biais de TCP (Transmission Control Protocol, l'un des principaux protocoles de transmission de données sur Internet) sur un port prédéfini, le plus souvent le port 80, sur lequel le serveur "écoute" les requêtes entrantes.

La requête envoyée par le navigateur au serveur prend la forme suivante (dans le cas d'un accès à JDN Développeurs avec Firefox) :

GET /index.shtml HTTP/1.1
Host: developpeur.journaldunet.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1
Connection: close
 [ligne vide]


La première ligne établit la méthode HTTP utilisée, le fichier demandé, et la version du protocole. La version 1.1 est la version qui a cours, une version étendue, HTTP/1.2, étant encore dans les cartons. GET, avec HEAD, OPTIONS et TRACE, est considéré comme une méthode sûre, car elle ne risque normalement pas de modifier les données du serveur par inadvertance. C'est donc la plus utilisée.
La seconde ligne indique simplement l'adresse, sans le préfix http:// vu que celui-ci est désormais connu.
La ligne User-Agent donne la chaîne d'identification du navigateur ayant émis la requête. Connection: close indique que la connexion au serveur sera fermée après réception de sa réponse.
Enfin, la requête se termine par une ligne vide, ou plus précisément un CRLF : un retour chariot (carriage return) suivi d'un saut à la ligne (line feed), sans autre caractère.

Ce sont là les en-têtes d'une requête typique. En la recevant, le serveur produit une réponse, comprenant un en-tête indiquant l'état de la demande, suivi après la ligne vide, du code HTML de la page, par exemple. Celle-ci comprendra sans doute des appels à des fichiers sur le serveur, ce qui produira autant de nouvelles requêtes.

Voici l'entête précédent la page demandée par notre requête ci-dessus :

HTTP/1.0 200 OK
Date: Fri, 29 Dec 2006 15:48:35 GMT
Server: Apache
P3P: policyref="/developpeur/w3c/p3p.xml", CP="NOI DEVa TAIa OUR BUS UNI
Content-Type: text/html
X-Cache: MISS from squid.benchmark.fr
X-Cache-Lookup: MISS from squid.benchmark.fr:80
Connection: close
 [ligne vide]


La ligne la plus importante est la première, qui indique la version du protocole utilisée, et surtout le code d'état correspondant à cette réponse, avec sa signification en anglais. 200 signifie que la requête a réussi. En général, les codes d'état commençant par 2xx indiquent que la requête a bien été reçue, comprise et acceptée. 3xx indique qu'une action supplémentaire est attendue, 4xx que la requête n'a pas été comprise (dont le fameux code 404). On dispose également de codes 1xx et 5xx pour d'autres cas.

Les autres en-têtes sont le plus souvent informatives : date, marque du serveur, type du contenu, présence d'un cache côté serveur... Un point intéressant ici : l'en-tête P3P, qui n'a rien à voir avec le Peer-to-Peer, mais signifie Platform for Privacy Preferences, une recommandation du W3C décrivant un protocole pour préciser les usages faits par le site des données de l'utilisateur ou du navigateur.

 
Xavier Borderie, JDN Développeurs
 
 
Accueil | Haut de page
 
 



A VOIR EGALEMENT