Fonctionnement du HTTP

Comment ça marche ?

Le principe de base est une connexion de type client/serveur : un client (le navigateur) se connecte sur un serveur, émet une requête et le serveur répond. La connexion est une simple ouverture de socket TCP/IP généralement sur port 80, mais on utilise aussi de temps en temps le port 8080 (pour les connexions sur proxy, par exemple).

HTTP est un protocole relativement simple. Tellement simple en fait que l'on peut communiquer soi-même directement avec les serveurs web. Il suffit pour cela de se connecter à un serveur par telnet et de taper les commandes à la main. Voici un exemple (il suffit de taper ce qui est en gras ; [CR] signifie qu'il faut sauter une ligne) :

$ telnet www.themanualpage.org 80[CR]
Trying...
Connected to web.pro.proxad.net.
Escape character is '^]'.
GET http://www.themanualpage.org/http/hello.txt[CR]
Hello

Connection closed by foreign host.

En tapant GET http://www.themanualpage.org/http/hello.txt, on demande le document /http/hello.txt au serveur www.themanualpage.org, et ce dernier l'a renvoyé. C'est la base de HTTP : on tape une requête avec des "mots" simples, et le serveur répond également derrière avec des "mots" simples et renvoie le réultat de la requête.

Internet Explorer, Netscape et tous les autres navigateurs, lorsque vous tapez une URL, ne font que parler aux serveurs de cette façon.

Les versions de HTTP

HTTP en est donc à la version HTTP/1.1. Avant cette version, il y en a eu 2 autres : HTTP/0.9 et HTTP/1.0. HTTP/1.0 est certainement la version la plus répandue sur Internet. Lorsque l'on donne les versions du protocole HTTP, on donne "HTTP/" suivi de la version du protocole.

Lorsque l'on se connecte à un serveur, on doit a priori lui dire dans quelle version de HTTP on veut lui parler. Par défaut, si on ne dit rien, on utilise HTTP/0.9. C'est ce qui s'est passé dans l'exemple ci-dessus. Lorsque l'on demande à utiliser une version de HTTP que le serveur n'implémente pas, ce dernier renvoie en premier la version de HTTP qu'il va utiliser pour le reste de la transmission. C'est finalement au client de s'assurer qu'il va comprendre ce que va répondre le serveur. Exemple :

$ telnet www.themanualpage.org 80
Trying...
Connected to web.pro.proxad.net.
Escape character is '^]'.
HEAD http://www.themanualpage.org/http/hello.txt HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 14 Oct 1999 06:43:02 GMT
Server: Apache/1.3.6 LV/LM-1.3 (Unix) PHP/3.0.9
Last-Modified: Sat, 08 Feb 1997 15:55:03 GMT
ETag: "afc0-8-32fca1d7"
Accept-Ranges: bytes
Content-Length: 8
Connection: close
Content-Type: text/plain

Connection closed by foreign host.

On s'aperçoit que la réponse du serveur est plus compliquée qu'avant, et qu'elle contient surtout des données supplémentaires. Ces données supplémentaires, aussi bien pour le client que pour le serveur, sont précisées par ce qu'on appelle des directives. Par exemple, "Content-Type:" est une directive qui précise le format de la ressource renvoyée (ici, du texte brut).

Les requêtes

Une requête est ce qu'on demande au serveur. Dans le premier exemple, il s'agissait d'une requête GET, utilisée pour obtenir un document. Dans le deuxième exemple, il s'agissait d'une requête HEAD qui permet de ne récupérer que la partie en-tête de la réponse à une requête GET (nous verrons que cela est fort utile pour ne pas charger inutilement le réseau).

Les différentes requêtes

Les requêtes HTTP se font avec ce qu'on appelle des méthodes. Voici les différentes méthodes possibles, avec la version de HTTP dans laquelle elles sont apparues :

La méthode figure forcément sur la première ligne de la requête.

Format des requêtes

Les requêtes n'ont un format bien précis que depuis HTTP/1.0.

Pour HTTP/0.9, la seule requête envisageable est celle vue dans le premier exemple :

Pour HTTP/1.0 et au-delà, les requêtes sont composées de 2 parties distinctes (si on élimine la première ligne constituée uniquement de la méthode) : l'en-tête et le corps de la requête (au sein d'une requête donnée, ce corps est également appelé corps de l'entité). L'en-tête permet de préciser la requête en ajoutant des directives (qui demande la ressource, type de navigateur...). En toute rigueur, cet en-tête est indispensable, mais comme HTTP/0.9 en est dépourvu, ce n'est pas obligatoire pour HTTP/1.0. Le corps de la requête, en revanche, figure rarement dans une requête : il n'est là que lorsque le client envoie des données au serveur en utilisant la méthode POST ou PUT.

Pour plus de renseignement, voir les en-têtes de HTTP/1.0.

Réponse du serveur

En HTTP/0.9, la réponse n'est constitué que de la réponse (page HTML, image...), et rien d'autre.

En revanche, à partir de HTTP/1.0, la réponse du serveur a le format qu'une requête, en se composant en 2 parties (hormis la toute première ligne) : l'en-tête de la réponse et le corps de la réponse (au sein d'un réponse donnée, ce corps est également appelé corps de l'entité). L'en-tête contient des informations (de nouveau précisées avec des directives) sur la réponse et l'entité renvoyée. Par exemple, le serveur donne le format de la ressource renvoyée, sa taille... Le corps de l'entité est le résultat même de la requête.

La première ligne de toute réponse précise le statut de la réponse. Le statut sert à préciser la manière dont s'est passé le traitement de la requête (si elle a abouti ou pas, par exemple).

Pour plus de renseignement, voir la réponse du serveur en HTTP/1.0.

Ce qu'est ou n'est pas HTTP

HTTP est de plus en plus utilisé. Pourquoi ? Parce qu'il est simple et modulaire (voir HTTP/1.1) et est très facile à contrôler. Il faut cependant bien comprendre ses limitations provenant de son fonctionnement intrinsèque : le modèle requête-réponse sans connexion permanente :

• Le modèle requête-réponse : il faut bien comprendre les rôles du client et du serveur HTTP et ce que chacun peut faire (i.e. quelles technologies chacun peut comprendre et utiliser). Il faut se rappeler que c'est toujours le client qui est l'initiative des échanges avec le serveur. Deux conséquences : si on veut que le serveur envoie quelque chose au client, il faut d'abord que ce dernier contacte le serveur, et sans mécanisme spécifique particulier, le serveur n'exétera rien sans sollicitation de la part d'un client.
• Pas de connexion permanente : cela implique une sorte de fonctionnement en mode déconnecté d'un point de vue applicatif : d'une requête à l'autre, le serveur ne reconnaît pas le client. Difficile dans ces conditions de faire avec HTTP ce qu'on peut faire avec un système transactionnel ou client-serveur traditionnel tel qu'AS/400. C'est pour répondre à ce problème qu'on peut être amené à utiliser les cookies.

 format imprimable