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