HTTP/1.0

Le successeur de HTTP/0.9

Quelles améliorations HTTP/1.0 apporte-t-il par rapport à son prédécesseur ? La première amélioration est pour le confort de navigation : HTTP/1.0 sait gérer les caches (le mécanisme reste toutefois assez primitif). Ensuite, on peut envoyer des informations au serveur (grâce à une nouvelle méthode : la méthode POST). HTTP/1.0 sait ensuite reconnaître quand une requête n'a pas abouti (le fameux "404 not Found"). Enfin, HTTP/1.0 permet aux utilisateurs de s'authentifier, par exemple, pour accéder à une partie cachée d'une site.

Exemple de requête HTTP/1.0

Par rapport à HTTP/0.9, HTTP/1.0 va apporter une grande nouveau quant à la forme de la requête, et surtout de la réponse :

$ telnet www.themanualpage.org 80
Trying...
Connected to www.themanualpage.org.
Escape character is '^]'.
GET http://www.themanualpage.org/http/hello.txt HTTP/1.0
User-Agent: Mozilla/4.03 [fr]

HTTP/1.1 200 OK
Date: Thu, 20 Jul 2000 06:43:02 GMT
Server: Apache/1.3.12 (Unix) PHP/3.0.9
Last-Modified: Mon, 17 Jul 2000 15:55:03 GMT
Content-Type: text/plain

Hello

Connection closed by foreign host.

On voit tout de suite qu'il y a beaucoup plus d'informations fournies que dans un requête HTTP/0.9. Notons tout d'abord l'ajout à la fin de la première ligne de la requête un "HTTP/1.0" qui indique simplement au serveur que l'on veut dialoguer avec lui en HTTP/1.0. Il en sera de même pour HTTP/1.1 et vraissemblablement aussi pour les futures versions de HTTP. Le serveur va en fait répondre en HTTP/1.1. Bon, ça peut arriver...

Deuxième différence, cette fois-ci de taille, on dit aussi au serveur quel est le navigateur utilisé pour faire la requête. Tiens ! On rajoute de l'information dans la requête... On verra plus tard quel autre genre d'information on peut donner au serveur dans ce qu'on appelle les "en-têtes de la requête".

Troisième différence importante : le serveur nous renvoie tout un baratin (des directives) avant le contenu du fichier. Encore un en-tête !

Enfin, on reçoit le fichier. En tout dernier, le serveur coupe la connexion.

Les requêtes

Présentation

Un requête HTTP/1.0 se compose de trois choses : une méthode (qui permet de dire ce qu'on fait), suivie immédiatement par des entêtes (pour donner davantages de précisions), un saut de ligne supplémentaire puis enfin l'éventuel corps de l'entité (les informations à envoyer au serveur, i.e. le contenu d'un formulaire ou un fichier). Nous verrons plus bas que les en-têtes se composent également de 3 parties (la dernière, optionnelle, renseigne sur les données qui suivent). Dans tous les cas, on peut résumer tout ceci sur l'exemple suivant de requête POST (type de requête le plus complet) :

Les méthodes

Les requêtes, en HTTP/1.0, peuvent être de 3 sortes (il existe 3 méthodes différentes) : la méthode GET, la méthode HEAD et la méthode POST.

La méthode GET est la même qu'en HTTP/0.9 : elle permet de récupérer le document spécifié par l'URI.

Le rôle de la méthode HEAD sera décrit dans la partie traitant des caches. Rapidement, elle permet de ne récupérer que la partie en-tête d'une réponse complète.

La méthode POST est en revanche beaucoup plus intéressante puisqu'elle permet cette fois-ci d'envoyer des informations au serveur, et du coup d'utiliser intelligemment des choses comme les formulaires. On envoie un certain nombre d'informations à une procédure spécifiée par l'URL. Les informations sont envoyées en même temps que la requête dans ce qu'on va appeler un "corps de l'entité".

Notons tout de suite un problème de HTTP/1.0 : il ne sait pas gérer les URL relatives lorsqu'il y a une configuration de serveur virtuel. Concrètement, si on fait une requête HTTP/1.0 sur une machine qui héberge www.bar.com et foo.bar.com (ça arrive) en ne demandant que le fichier /index.html (requête de la forme : GET /index.html HTTP/1.0), et bien le serveur ne sait pas quelle page donner : index.html de www.bar.com ou de foo.bar.com ? En HTTP/1.0, il faut spécifier l'URL absolue des documents (GET http://foo.bar.com/index.html HTTP/1.0).

Les en-têtes

Lorsque l'on fait une requête auprès d'un serveur, il faut a priori envoyer un en-tête pour préciser les choses. Cet en-tête est en fait optionnel : pour des raisons de compatibilités avec les clients HTTP/0.9, on peut terminer une requête en tapant 2 fois sur entrée sans même avoir donné d'en-tête. Sinon, l'en-tête se décompose d'au plus 3 parties, la dernière n'étant obligatoire que si on envoie des données au serveur :

• en-tête générique : concerne l'échange, la requête ou la réponse,
• en-tête de la requête : précisions sur la requête même,
• en-tête de l'entité : précisions sur les données envoyées (les métas informations)

L'en-tête générique se compose principalement de la date et l'heure à laquelle on fait la requête (directive "Date:").

Dans l'en-tête de la requête, on peut spécifier 5 choses :

Enfin ,l'en-tête de l'entité est optionnel, car il renseigne sur les éventuelles données qui suivent. Pratiquement, il n'est présent que lorsque le client utilise la méthode POST. Les principales directives, qui reprennent celles des réponses du serveur, sont :

Le point intéressant, c'est qu'on peut envoyer autre chose que des réponses à des formulaires, des fichiers par exemple (c'est comme ça que l'on peut envoyer des documents attachés avec des mails en ligne comme Caramail, Hotmail...).

Le corps de l'entité

Le corps de l'entité n'est présent dans une requête que lorsque le client veut envoyer des informations au serveur par la méthode POST (voir les formulaires HTML pour savoir comment utiliser cette méthode). Dans ce cas, on place obligatoirement une directive Content-Type et un Content-Length dans l'en-tête de l'entité. Une fois toutes ces infos précisées, on remplit à proprement parler le corps de l'entité avec le message à envoyer. Tout comme le serveur fait pour envoyer un document, il faut séparer l'en-tête et le corps de l'entité par un saut de ligne supplémentaire (voir ci-après).

La réponse du serveur

Présentation

La réponse HTTP/1.0 du serveur ressemble fortement à la requête du client vue ci-dessus, à la différence près que le serveur envoie en premier un statut et non pas une méthode. Le reste (en-têtes et corps de l'entité) fonctionnent globalement de la même façon.

Le statut de la réponse

Avec HTTP/1.0, le client connaît le type de la réponse, grâce à l'en-tête de la réponse du serveur. En fait, la première chose que renvoie le serveur, c'est comment la transaction s'est passée. La réponse est du genre :

Trois parties pour cette première information :

• la version HTTP utilisée par le serveur,
• le statut de la réponse sous forme numérique,
• le statut de la réponse mais sous forme de texte.

Le statut, c'est simplement la façon dont s'est passée la transaction. Le plus connu, hélas ! c'est le fameux "404 Not Found". Il existe 5 classes de statuts :

• 1xx : pas utilisé en HTTP/1.0
• 2xx : requête traitée avec succès (d'où "200 OK")
• 3xx : redirection. La requête n'a pas été trouvée, mais on sait ou elle est
• 4xx : requête incorrecte (mauvaise syntaxe par exemple, d'où le "404 Not Found" : il faut apprendre à taper une URL correctement !)
• 5xx : requête correcte mais non satisfaite (problème interne au serveur, pas encore implémenté...)

Voir le Détail des statuts, très utile pour comprendre ce qui s'est passé.

En-têtes de la réponse

L'en-tête de la réponse se décompose des trois mêmes parties que la requête du client (un en-tête générique, un en-tête de la réponse et un éventuel en-tête de l'entité).

L'en-tête générique peut comporter les 2 champs suivants :

L'en-tête de la réponse peut comporter 3 champs différents :

L'en-tête de l'entité peut comporter les champs suivants :

Il est également possible d'utiliser des directives non définies par la RFC (extension-header).

Le corps de l'entité

C'est tout simplement le document renvoyé. Il se peut qu'il n'y en ait pas, par exemple si on a fait une requête avec la méthode HEAD. C'est également le cas lorsque le serveur renvoie un "404 Not Found" par exemple.

Seul élément important : le serveur doit envoyer un Content-Length si ce corps d'entité n'est pas vide.

La gestion des caches

Qu'est-ce que c'est ?

Un cache, c'est une sorte de "tampon", de mémoire : une machine quelque part stocke en mémoire certains documents, de façon à ce que, lorsqu'on demande une ressource déjà caché (présente dans le cache), on fournit ce document caché au lieu de refaire toute la requête complète auprès du serveur. Cela permet entre autre de gagner du temps sur les documents fortement demandés (les pages d'un intranet par exemple) et aussi de réduire le trafic réseau.

Toute la subtilité consiste donc à savoir si le document a été mis à jour. Sur le schéma suivant, on voit le "parcours" d'une ressource au moment d'une requête :

Le client va en fait soumettre la requête à un proxy ou tout autre élément comportant un cache. Cette élément va alors essayer de déterminé si le document caché dont il dispose est valable. Pour cela, il va s'aider des directives reçues lorsque le document a été demandé pour la première fois, et éventuellement faire une requête HEAD. En fonction de la réponse, le proxie va soit refaire la requête complète auprès du serveur, cacher la nouvelle entité et la fornir au client, ou tout simplement fournir au client l'entité qu'il possède déjà. C'est ce dernier cas qui fait gagner du temps.

De nouvelles directives

HTTP/1.0 introduit des directives spéciales telles que Date, Expires et Last-Modified qui permettent de savoir quand le document demandé a été modifié depuis la dernière fois, ou de calculer le temps que doit rester une ressource dans le cache, voire tout simplement de dire à partir de quand on doit demander au serveur le nouveau document (directive Expires).

La méthode HEAD

La première idée pour savoir si une entité a été modifiée depuis la dernière fois a été d'utiliser une nouvelle méthode : la méthode HEAD.

Cette méthode permet de ne récupérer que la partie en-tête d'un requête complète GET, ce qui permet par exemple d'obtenir la date de dernière modification (via les nouvelles directives) et du coup de savoir si le document demandé a changé depuis la dernière fois, sans pour autant trop charger le réseau (le document ne voyage pas, seulement les méta-informations).

Le GET conditionnel

HTTP/1.0 introduit un autre mécanisme de cache : une méthode GET conditionnel. Ceci se fait une fois de plus grâce à une nouvelle directive : If-Modified-Since.

Le GET conditionnel permet de demander au serveur de renvoyer le document si et seulement si ce dernier a changé depuis la date indiquée en face de la directive. Pour le client, il suffit juste d'envoyer la date à laquelle il a reçu le document pour la dernière fois. Dans le cas ou la ressource n'a pas été modifiée, le serveur renvoie un très court "HTTP/1.0 304 Not Modified" et le client sait alors qu'il n'a plus qu'a distribuer l'entité cachée.

Entités non cachables

Bien sûr, certains documents ne doivent pas être cachés (par exemple, les résultats renvoyés par des scripts CGI). Pour cela, on utilise encore une directive Pragma: no-cache qui dit à tous ceux qui manipulent le document de ne pas le garder dans leur cache. L'autre solution, c'est d'utiliser la directive Expires avec une date passée.

Authentification

Une dernière nouveauté de ce protocole HTTP/1.0 : un utilisateur peut s'authentifier. Certes, de manière relativement simple. Ceci permet de protéger par exemple une partie d'un site web et de ne le rendre accessible que par mot de passe.

Lorsqu'un client essaie d'accéder à une ressource protégée, le serveur renvoie un statut "HTTP/1.0 401 Authorization Required" avec une directive WWW-Authenticate qui dit au client comment procéder pour l'authentification. A ce moment, le client demande l'authentification et la renvoie au serveur qui délivrera ou non la ressource.

Initialement, HTTP/1.0 ne proposait qu'une seule façon de s'authentifier : la méthode "Basic". Cette méthode est ultra simple (ce qui permet d'ailleurs de retrouver très facilement le login/mot de passe) : on fait un codage base64 de la chaîne de caractère "login:mot_de_passe". Le mot de passe circule codé mais pas crypté, ce qui fait qu'on peut le craquer très facilement (à vos calculatrices).

Une amélioration de HTTP/1.0 puis HTTP/1.1 proposeront une deuxième méthode d'authentification plus sûre par challenge : la méthode "Digest".

Limitations

HTTP/1.0 ne résoud hélas pas tous les problèmes de son prédécesseur. En effet : nous n'avons pas évoqué le problème des connexions multiples (quand le client doit ouvrir plusieurs connexions successives avec le serveur pour charger un document en entier). Eh bien, HTTP/1.0 ne résoud pas ce problème ! Il faut encore ouvrir plusieurs connexions par document, ce malgré une nouvelle directive (keep-alive) mais que peu d'intermédiaires comprennent.

Par ailleurs, HTTP/1.0 ne résoud pas très bien les URL relatives. Il faut en effet continuer à spécifier le l'URL absolue dans le cas d'un serveur hébergeant plusieurs serveurs virtuels.

L'authentification "Basic" est trop... basique ! Une nouvelle méthode d'authentification a été introduite : la méthode Digest. Nous la verrons dans HTTP/1.1.

Enfin, HTTP/1.0 gère les caches de manière assez simple.

Moralité : vivement HTTP/1.1 !

Références

Les RFCs :

• RFC1945 : HTTP/1.0
• RFC2617 : authentification par les méthodes Basic et Digest

 format imprimable