Fait le 3 décembre 2001 par Claude PIDEIL

DESS TNI ASR 2001-2002 Université Montpellier II

 

 

Retour au sommaire

 

 

HTTP (HyperText Transfer Protocol) est le protocole du WEB, ou plus précisément du WWW (World Wide Web), le plus utilisé sur Internet depuis 1990. Il permet aujourd’hui de transmettre n’importe quel type de fichier ou de donnée et a été pensé afin de pouvoir être utilisé dans de futures applications orientées objet (c’est pour cela que chaque requête commence par un nom de méthode).

HTTP est employé pour chaque transaction, il est présent dans chaque requête concernant un document ou un graphique du WEB, à chaque fois que l’on clique sur un lien hypertexte, et pour chaque formulaire soumis. Il permet la transmission de données sous forme de requêtes entre une machine ‘Client’, et une autre ‘Serveur’.

HTTP est un protocole ASCII (American Standard Code for Information Interchange), rapide, léger. Il se situe au niveau 7 (Application) du modèle OSI (Open Systems Interconnection), au même titre que FTP (File Transfer Protocol) et TELNET . Il est défini par les spécifications HTTP, diffusées par le W3C (World Wide Web Consortium) http://www.w3.org. Il s’appuie généralement sur une connexion transport TCP (Transmission Control Protocol), et utilise le port 80 par défaut. Quoi qu’il en soit, il peut fonctionner au-dessus de tout autre service orienté connexion.

Le protocole HTTP est en perpétuelle évolution : il existe plusieurs versions en cours d’utilisation et plusieurs autres encore en phase de développement. La version 1.0 est la plus répandue, mais depuis plus d'un an, il semblerait que se soit HTTP/1.1 tant attendu qui arrive maintenant en tête du classement. Une importante révolution est à venir avec le futur HTTP-NG déjà très prometteur.

On ne peut pas parler du protocole HTTP sans parler du WEB. Le WEB a été développé en 1989 par Tim Berners-Lee au CERN (Conseil Européen pour la Recherche Nucléaire) à GENEVE. A l’origine, sa motivation était de trouver une manière de partager les résultats d’expériences physiques. La technologie mise en place derrière le WEB permettait de relier un document sur un serveur à un document sur un autre en gardant invisible pour l’utilisateur la méthode d’accès et la localisation de ceux-ci. En 1993, on a développé une interface graphique pour le WEB : Mosaic (Université de l’Illinois) qui ne fonctionne que sur UNIX et Xwindow. Bientôt, des versions pour MAC et PC voient le jour et le WEB commence d’acquérir une grande popularité. En 1994, une nouvelle interface arrive : Netscape Navigator. Les grandes entreprises commencent à développer leur site. Toujours en 1994, le CERN et le MIT (Massachusetts Institute of Technology) signent un protocole d’accord pour créer le W3C dont le rôle est de standardiser les protocoles et promouvoir l’interopérabilité entre sites.

Le concept du WEB est de permettre l’accès à des documents reliés entre eux et dispersés sur des milliers de machines réparties sur la planète. Au départ, l’idée était de relier des documents texte ; on dit que l’on utilise une technique d’hypertexte. Mais maintenant, on trouve de plus en plus d’images, de sons, de vidéos, … On parle alors d’hypermédia.

D’un point de vue technique, les fondements du WEB sont simples. Il s’agit de permettre l’accès, au moyen d’un système client-serveur, à des documents hypermédia distribués !

Dés le moment où l’on a imaginé le WEB, on a dû concevoir un mécanisme de nommage et de localisation des documents (appelé URL : Uniform Resource Locator), permettant d’identifier individuellement les différents documents accessibles à travers le WEB. Les documents hypermédia présents sur le WEB sont écrits à l’aide du langage HTML (HyperText Markup Language). Il s’agit de simples tests auxquels on a ajouté des constructions spéciales qui permettent de définir en particulier les liens vers d’autres documents au moyen des URLs.

Un URL est de la forme suivante :

Exemple : http://www.toto.fr/DessTni/http/index.html

HTTP est un protocole transactionnel, simple, basé sur le principe de Requête/Réponse. Il est dit sans état : le client envoie une requête et le serveur répond, indépendamment des requêtes précédentes et sans conserver la moindre information pour les requêtes à venir. Ensuite, il libère la connexion. Les serveurs peuvent cependant enregistrer les entêtes des requêtes à des fins statistiques et de déboggage.

HTTP n’est pas orienté session, il n’a aucun moyen d’identifier un utilisateur au cours d’une série de connexions à un site WEB.

Une transaction HTTP se décompose en quatre phases :

Remarque : C’est le client qui ouvre la connexion, mais c’est le serveur qui la ferme. Une transaction HTTP correspond au transfert d’au plus une ressource. Ainsi, cela n’a pas de sens de dire que l’on est "connecté" à un site WEB. Les sites qui donnent à l'utilisateur l'illusion d'être connecté, utilisent entre autre, les cookies.

• Le navigateur analyse l’URL
• Il demande au DNS l’adresse IP de la machine www.toto.fr
• Le DNS répond 128.178.50.32
• Le navigateur établit une connexion TCP sur le port 80 à l’adresse 128.178.50.32
• Il envoie alors la commande GET /DessTni/http/index.html
• Le serveur www.toto.fr envoie le fichier index.html
• La connexion TCP est libérée par le serveur. La transaction est terminée.
• Le navigateur interprète et affiche la page correspondante à index.html
• S’ il y trouve des références à des images, sons, etc …, il va faire une nouvelle transaction pour chacune d’entre elles et réactualisera son affichage au fur et à mesure.

Il est important de noter que le navigateur doit établir une nouvelle connexion TCP pour charger chaque composant de la page en question , ce qui n’est franchement pas efficace dans le cas de documents contenant un grand nombre d’images. (Aujourd’hui, c’est pratiquement toujours le cas, mais les dernières versions du protocole apportent des solutions que l’on abordera plus loin).

Parfois, le client demande au serveur un peu plus qu’un simple fichier : il peut lui demander d’exécuter un programme et de lui renvoyer le résultat . C’est ce qui se passe par exemple lorsque, après avoir rempli les champs d’un formulaire de recherche, l’utilisateur appuie sur le bouton [rechercher] du formulaire : les données du formulaire sont envoyées au serveur à l’aide de la requête, le serveur les communique au programme concerné, récupère les résultats et les retourne au client sous forme de réponse.

Le mécanisme par lequel le serveur et un programme échangent des données en vue de construire un document à renvoyer au client est appelé CGI (Common Gateway Interface).

Pourquoi HTTP/0.9 ? En fait, lorsque Tim Berners-Lee a inventé ce protocole, il ne lui avait pas attribué de numéro de version. Il a été baptisé HTTP/0.9 lorsque la première version correctement définie par une RFC (Request For Comments) du NWG (Network Working Group) est apparue pour HTTP/1.0. C'est donc la toute première version du protocole HTTP.

Celle-ci a été écrite pour répondre aux exigences fixées par Tim Berners-Lee quant au transport et à l'acheminement des pages HTML au CERN.

Cette version implémente des requêtes extrêmement simples permettant uniquement l’obtention de documents par la seule méthode GET du protocole. Le seul moyen d'envoyer des informations aux serveurs est l'utilisation des URL encodés ou étendus. Pour cela, on termine l'URL par un "?" et on y rajoute l'information à la suite, sur la même ligne.

Par exemple : GET http://www.toto.fr/cgi-bin/imagemap.cgi?x=15&y=20

Cette version est uniquement à base de texte. Si le document n’existe pas, le serveur ne renvoie rien : on ne peut pas savoir si le document est vide ou s’il n’existe pas. On ne peut pas faire plus simple.

Dans la pratique, il n’y a plus aucun logiciel HTTP/0.9 en service aujourd’hui. Cependant, les serveurs WEB actuels assurent la compatibilité ascendante.

HTTP/0.9 est tout ce qu'il y a de plus simple. L'information demandée arrive tout de suite sans préavis, et la connexion est coupée immédiatement après par le serveur. Conséquences :

• Le client doit ouvrir une connexion pour chaque document, y compris les images contenues dans les pages HTML : l'ouverture et la fermeture de connexion est un processus lent.
• L'utilisateur attend donc...
• Le réseau est saturé par les nombreuses requêtes d'ouverture de connexions
• Les navigateurs ouvrent plusieurs connexions simultanées (jusqu'à 4 pour Netscape), ce qui sature le réseau, mais aussi le serveur. Pour information, le site Altavista a en moyenne 20 million de connexions par jour. (ça fait rêver …)

Si le WEB se résumait simplement à la récupération de documents texte, la version 0.9 suffirait largement. Mais il en est tout autrement. C’est pour cela que la notion d’en-têtes, introduite dans la version 1.0, permet l’échange de méta-information entre clients et serveurs.

Par rapport à la version précédente, HTTP/1.0 va apporter une grande nouveauté quant à la forme de la requête, et surtout de la réponse. La première amélioration apportée est donc pour le confort de navigation. HTTP/1.0 peut maintenant gérer les caches à l'aide de certaines de ces en-têtes (le mécanisme reste toutefois assez primitif).

Cette nouvelle version est maintenant composée des méthodes  GET, HEAD et POST (voir explications plus loin).

HTTP/1.0 sait maintenant reconnaître si une requête n'a pas abouti puisqu'il introduit aussi la notion de statut de la réponse ( Le fameux "404 not Found" ).

On voit également apparaître une distinction entre les différents types de données (Texte, Images, Son, …) permettant la diffusion de documents multimédia.

Les connexions persistantes font leur apparition.

Enfin, HTTP/1.0 permet aux utilisateurs de s'authentifier, par exemple, pour accéder à une partie cachée d'une site. Les spécifications détaillées de la version 1.0 (RFC1945 – HTTP : A protocol for networked information) sont accessibles sur le site du W3C.

A partir de HTTP/1.0, on voit apparaître sur la première ligne des requêtes et des réponses, la version de protocole utilisée. HTTP/1.0 ne résoud hélas pas tous les problèmes de son prédécesseur. En effet, il faut encore ouvrir plusieurs connexions par document pour en récupérer les différents objets qui le composent, et ce, à cause des connexions persistantes que peu d'intermédiaires (Proxies, …) comprennent.

On voit tout de suite qu'il y a beaucoup plus d'informations fournies qu'avec HTTP/0.9. Notons tout d'abord l'ajout à la fin de la première ligne de la requête de "HTTP/1.0" qui indique simplement au serveur que l'on veut dialoguer avec lui avec cette version du protocole. Il en sera de même pour HTTP/1.1 et vraisemblablement aussi pour les futures versions.

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

Troisième différence importante : le serveur nous renvoie un certain nombre d'informations avant le contenu du fichier lui-même (là aussi ce sont des en-têtes). En fin, on reçoit le fichier. Et en tout dernier, le serveur coupe la connexion.

Les requêtes, en HTTP/1.0, peuvent être de 3 sortes: la méthode GET, HEAD et 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'URL.
• Le rôle de la méthode HEAD 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 le corps de l'entité.

Lorsqu'on envoie une requête à un serveur, il faut a priori envoyer une en-tête (c'est optionnel : on peut en effet terminer une requête sans même avoir donné d'en-tête).

Les lignes d'en-tête sont de la forme ( Nom : Valeur ). C'est le même format qui est utilisé pour l'envoi d'e-mail, défini par la RFC822.

L'en-tête se décompose en faite en 3 parties :

• en-tête générique qui concerne l'échange, la requête ou la réponse,
• en-tête de la requête qui concerne la requête elle-même,
• en-tête de l'entité qui concerne les donné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é renseigne sur les données. Le client n'en a vraiment l'utilité que lorsqu'il envoie des informations par 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 images 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é ne concerne une requête que lorsque le client veut envoyer des informations au serveur par la méthode POST. Dans ce cas, on place obligatoirement une info Content-Type et un Content-Length.

Une fois toutes ces informations spécifié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 à la ligne supplémentaire.

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 l’état de la transaction .

La réponse est du genre : HTTP/1.0 200 OK

On distingue trois parties dans 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 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". Ces codes sont à trois chiffres et répartis en 5 classes : le premier chiffre indique la classe de statut et les suivants la nature exacte de l’erreur. HTTP définit seulement quelques codes spécifiques par classe, bien qu’elles soient de plus en plus fournies à chaque version.

Remarque : Si le client reçoit un code qu’il ne reconnaît pas, il devra comprendre sa signification basique à partir de la classe correspondante.

Le serveur envoie des informations au client, tout comme le navigateur au serveur.

L'en-tête de la réponse du serveur se décompose également en trois parties, les trois mêmes que pour la requête du client.

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

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 code statut "404 Not Found" par exemple.

La seule chose importante : le serveur doit envoyer un Content-Length si l'en-tête est suivie des données d'un document.

Un cache, c'est une sorte de "tampon", de mémoire : une machine stocke quelque part en mémoire certains documents, de façon à ce que, lorsqu'on demande une ressource déjà cachée (présente dans le cache), on fournisse ce document caché au lieu de refaire toute la requête complète auprès du serveur. Cela permet, entre autres, 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. Cet élément va alors essayer de déterminer si le document caché qu’il dispose est valable ou non. 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 proxy va, soit refaire la requête complète auprès du serveur, cacher la nouvelle entité et la fournir 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.

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 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 donc 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 transitent).

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

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 est d'utiliser la directive Expires avec une date passée.

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. HTTP/1.0 ne propose au départ qu'une seule façon de s'authentifier.

Une amélioration de HTTP/1.0 : il s'agit de la méthode "Basic" qui fait un codage de type base64 de la chaîne de caractère "login:mote_de_passe". Le mot de passe circule codé, certes, mais pas crypté, ce qui fait qu'on peut le craquer très facilement.

Le cookie est une technique qui consiste, pour un site WEB ou une page WEB, à enregistrer localement sur le poste client des informations utiles à la consultation dudit site ou de ladite page. En effet, la consultation WEB, effectuée grâce au protocole HTTP, ne permet pas nativement de garder des informations sur le contexte d'une session de travail sur un site WEB. Ainsi, lorsque vous êtes sur un site et que vous passez d'une page à l'autre en cliquant sur des liens, chaque requête est traitée de manière complètement indépendante, comme on l'a déjà vu plus haut. Pour pallier à cette non-persistance, on a donc introduit les cookies.

En passant d'une page à l'autre sur un site, les premières pages peuvent déposer des informations sur le poste client à destination des pages visitées par la suite et donc recréer un mécanisme de session. Lorsque les informations à conserver sont nombreuses, le site WEB n'enregistre sur le poste client qu'un simple identifiant (un numéro unique lié à l'utilisateur). Les informations sont conservées alors localement sur une base, côté serveur, mais sont associées via l'identifiant contenu dans le cookie à l'utilisateur.

Les cookies sont apparus entre 1995 et 1996 à l'initiative de Netscape.

Les mécanismes de cookies utilisent le protocole HTTP pour fonctionner. Ils accompagnent les échanges en s'introduisant dans les entêtes HTTP des requêtes et des réponses. Toutes les spécifications concernant ces entêtes HTTP avec cookies sont contenues dans la (RFC2109 - HTTP State Management Mechanism).

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) : il faut encore ouvrir plusieurs connexions par document et ce, malgré une nouvelle directive (keep-alive) mais que peu d'intermédiaires comprennent. Par ailleurs, dans le cas d'un serveur hébergeant plusieurs serveurs virtuels, HTTP/1.0 ne sait pas résoudre les URL relatives, il faut en effet continuer à lui spécifier l'URL absolue.

La RFC2616 décrivant HTTP/1.1 est assez conséquente (175 pages). Ceci dit, il n'y a pas de franche différence entre HTTP/1.1 et HTTP/1.0. Cette nouvelle version est plutôt une sorte d'ultime amélioration de HTTP/1.0, qui permet une quasi parfaite utilisation et gestion des ressources avec un mécanisme de cache particulièrement amélioré.

La préoccupation principale ne se trouve plus dans la façon d'acheminer la ressource, elle se situe plutôt désormais dans la rationalisation du système dans son ensemble. Le dialogue entre le client et le serveur doit être aussi clair et précis que possible, et ne doit circuler sur le réseau que le strict nécessaire. Dans ce sens, les connexions persistantes sont devenues le comportement par défaut. La connexion entre le client et le serveur reste désormais ouverte après la première requête, histoire de laisser le temps au client de récupérer d'autres fichiers (notamment les images contenues dans un document HTML).

Les séries d’octets (Range) permettent au client de récupérer seulement une partie d’une entité, d’obtenir les données d’un très gros document en plusieurs parties ou de lire un index de document de façon sélective. Avec la directive (Transfer-Encoding : chunked) le serveur peut commencer à envoyer une réponse sans connaître sa longueur totale (car toute la réponse n'a pas encore été générée), elle sera ainsi découpée en morceaux et envoyés au fur et à mesure.

HTTP/1.1 complète également HTTP/1.0 par des statuts et des méthodes supplémentaires, et un mécanisme d'authentification par challenge (méthode "digest"). Ajoutons également une amélioration notable du système de cache, mais les bases du protocole restent celles de HTTP/1.0 : le message comporte toujours un en-tête avec un statut pour la réponse et un corps divisé comme dans HTTP/1.0 avec une entité.

De nouveaux statuts font leur apparition. Leur rôle se situe surtout au niveau de la gestion des caches et du contrôle du trafic.

La classe 1xx s’ajoute avec 2 statuts utilisés pour gérer directement le canal de transmission.

Bien évidemment, les trois méthodes de base (GET, HEAD et POST) sont toujours là et restent toujours celles majoritairement utilisées. Cependant, 5 autres nouvelles méthodes font leur apparition :

• OPTIONS : permet au client de connaître les options de communication utilisables pour obtenir la ressource. L'intérêt est de savoir ce qu'on peut faire sans pour autant devoir demander une ressource.
• PUT : permet d'envoyer au serveur un document à enregistrer à l'URI spécifiée (les statuts 2xx permettent de contrôler que tout s'est bien passé). C'est directement le serveur qui traite le document envoyé, et non pas un CGI comme c’est le cas pour la méthode POST. Cette méthode est un peu la réciproque de la méthode GET, elle permet de transférer un document sur le serveur.
• DELETE : efface la ressource spécifiée. Puisque PUT crée de nouvelles URL sur le serveur, il semble tout indiqué de disposer aussi d’un moyen pour les effacer.
• TRACE : méthode de contrôle. Demande au serveur de renvoyer la requête telle qu'elle a été reçue.
• CONNECT : cette méthode n'est pas encore bien déterminée. Elle est réservée pour les proxies permettant de faire du tunneling.

Ces nouvelles méthodes sont là pour la gestion de la communication client-serveur et la gestion des documents du serveur. On peut donc désormais concevoir une interface d'administration simple et totalement "web". Il va de soi que ces méthodes ne sont pas autorisées à tout le monde.

La liste des directives utilisables (47 au total) a été considérablement rallongée pour assurer le bon fonctionnement de toutes les nouveautés : la gestion des caches, la clarté du dialogue client-serveur, la négociation de contenu, la rationalisation du canal de communication... La liste est trop longue pour figurer ici. Elle est toutefois disponible en annexe, sur ce même document. Notons cependant que la directive "Host:" est désormais obligatoire dans toute requête HTTP/1.1, afin d'assurer une parfaite gestion des serveurs virtuels et une correcte utilisation des URL absolues et relatives (ce qui n'était pas le cas dans HTTP/1.0).

Puisqu’ ici, la connexion réseau est maintenue par défaut après chaque transaction, il faut qu’elle soit fermée explicitement par le client ou le serveur. Cependant, les clients doivent bien s’assurer qu’ils intègrent l’en-tête Connection : Close lors de leur dernière transaction, sinon la connexion restera ouverte jusqu’à ce que le serveur détecte une trop longue inactivité (time out) et décide de la fermer.

D’après le RFC2626, le mode Pipeline peut être activé par le client lors d’une connexion persistante. C’est-à-dire qu’il peut envoyer une série de requêtes au serveur sans attendre de réponses immédiate. Cela permet d’utiliser une seule connexion TCP, donc plus efficace et plus rapide. La seule obligation pour le serveur sera de donner au client les réponses correspondantes dans le même ordre.

L'idée des caches est la même qu'en HTTP/1.0, mais le mécanisme a été beaucoup amélioré dans HTTP/1.1. L'objectif principal est la réduction du nombre de requêtes "inutiles" : éviter au maximum de faire des requêtes complètes et de renvoyer des documents complets, autant que possible. Concrètement, le cache doit s'assurer au maximum de la "fraîcheur" des documents. Cela passe par l'utilisation de nouvelles directives et de nouveaux statuts.

Le cache doit pouvoir gérer 2 choses : les directives du serveur ("ne conserve pas ce document"...) et les souhaits du client ("je ne garde pas les documents plus d'un certain temps"). En fait, le type de requêtes reste le même, mais des algorithmes et des règles plus précis sur la façon de calculer et gérer l'âge des documents ainsi que les dates d'expiration ont été écrits. Tout ceci n'avait pas été fait dans HTTP/1.0 ou alors de façon trop imprécise.

Le mécanisme complet est trop complexe pour figurer dans ce document. Pour une complète description, se reporter à la RFC2616.

HTTP/1.1 essaie d'apporter une gestion "intelligente" des documents. La négociation de contenu (content negociation) est un outil qui permet de renvoyer (ou récupérer selon le cas) le document qui répondra au mieux aux attentes de l'utilisateur. Par exemple, si le serveur arrive à savoir que l'utilisateur est français (en vérifiant le nom du navigateur par exemple), il va essayer de renvoyer prioritairement les documents écrits en français. Ou bien c'est le client HTTP qui essaie de demander le "meilleur" document. La sélection se fait sur base d'une liste renvoyée par le serveur de toutes les représentations possibles pour le document demandé.

Le mécanisme d'authentification de HTTP/1.0 n'a en revanche pas beaucoup changé. Un mécanisme d'authentification plus sûr (par challenge) a toutefois été mise en place pour résoudre les faiblesses de l'authentification "basic". Il s'agit de la méthode "digest" définie dans la RFC2617 (authentification par les méthodes Basic et Digest ). La RFC2616 donne également quelques recommandations pour la sécurité générale du serveur et de son contenu.

HTTP montre des limites en matière de modularité et de performances. Simomn Spero a proposé en 1995 un HTTP-NG (pour New Generation) repris par le W3C en 1997 qui vise à améliorer les performances de son prédécesseur. Ainsi, le protocole HTTP-NG :

• Lance une seule session permanente entre le client et le serveur et rend chaque session asynchrone, ce qui permet au navigateur de gérer plusieurs chargements à la fois et non à la suite.
• Détermine une liste d'objets récurrents transitant sur le WEB et les codes, sous un format binaire (et non textuel) : il envoie en une seule fois au serveur le petit fichier résultant. Actuellement, HTTP impose au navigateur d'envoyer la liste des objets qu'il supporte en mode textuel, ce qui, multiplié par plusieurs millions de requêtes quotidiennes contribue à l'engorgement du réseau.
• Sécurise l'accès, autorise l'authentification du client, paiement et support, pour des systèmes orientés multimédia.

En plus de ces performances améliorées, HTTP-NG supporte toutes les caractéristiques de HTTP, mais implémenté de manière complètement différente. En 1995, HTTP-NG a été testé sur une liaison transatlantique et a montré de belles performances avec une utilisation entière de la bande passante disponible. En revanche, HTTP/1.0 a seulement été capable d'utiliser un dixième de la bande passante. Comme prévu, les performances de HTTP-NG ne se sont pas dégradées autant que celles de HTTP dans des conditions de congestion.; il s'est comporté nettement mieux qu'avec des connexions multiples comme le permettent des navigateurs modernes multi-tâches. Si la version NG est intéropérable avec la version 1.1, son déploiement n'en nécessite pas moins une mise à niveau des logiciels clients et serveurs longue et coûteuse. De plus sa standardisation est encore au stade de l'élaboration. (A suivre …).

La différence majeure entre HTTP 1.0 et HTTP-NG est que ce dernier tente de réutiliser des connexions pour des transactions multiples. Une fois connecté, HTTP-NG reste connecté. Cela évite la charge due aux multiples demandes de connexion. Cela donne du temps pour que le mécanisme d'évitement de la congestion puisse monter son taux de transmission en puissance. Comme il y a moins de connexions, le serveur utilise bien moins de ressources pour retenir l'historique des connexions récemment fermées.

L'unique connexion HTTP-NG est divisée en de multiples sessions virtuelles, chacune d'entre elle pouvant ramener un objet requis en parallèle. Ces dernières sont asynchrones, permettant à un client d'émettre de multiples requêtes sans attendre d'accusé de réception, sans parler de l'attente même de l'objet requis. Il existe une session dédiée, similaire à la connexion de contrôle du protocole FTP, utilisée pour envoyer toutes les requêtes et recevoir les meta-informations (auteur, détails de copyright, coûts, ou requêtes de redirection pour utiliser une connexion externe spéciale, comme par exemple un lien ATM pour de la vidéo en direct).

HTTP étant un protocole orienté texte, cela le rend aisé à debogguer. Cependant, tous ces en-têtes textuels signifient une charge considérable lorsqu'on transporte de petits objets , le transport pouvant se débrouiller avec des données binaires, ce qu'il fait d'ailleurs déjà pour le corps des objets. HTTP-NG utilise un protocole binaire, encodé en ASN.1 et rendu encore plus compact grâce aux PER (Packed Encoding Rules). Cela veut dire qu'une requête typique est très petite, mais ressemble à n'importe quoi tant qu'elle n'a pas été décodée.

Chaque message individuel lors d'une connexion avec HTTP-NG peut être authentifié. La méthode de sécurité ne fait pas partie du protocole donc n'importe quelle méthode supportée à la fois par le client et le serveur peut être utilisée; des messages individuels peuvent utiliser des mécanismes d'authentification différents si nécessaire. Les données chiffrées peuvent être transportées en toute sécurité à travers des proxies intermédiaires moins sûrs. Comme réponse dans un environnement d'authentification, le serveur peut signaler à un client que le service requis encourre un coût. Et propose une liste de méthodes de paiement acceptables. Le client peut bien sûr refuser de continuer.

C'est un protocole issu de Netscape et lié à une connexion par socket sécurisée, autrement dit du HTTP avec une pincée de SSL (Secure Socket Layer). Sa principale utilisation est le commerce électronique.

Le protocole HTTPS utilise le port 443 par défaut et son rôle est de crypter la communication entre le client et le serveur. (Suis-je bien "connecté" au serveur auquel je pense ?). Pour cela, il est nécessaire d'établir une session SSL avant la connexion HTTP, l'utilisation du protocole HTTP est ensuite complètement identique .

Habituellement, les accès à des pages WEB se font à l'aide du protocole HTTP, en empruntant le réseau Internet. Aucune garantie de confidentialité n'est assurée lors des accès à des données soumises à authentification ( échange de login - mot de passe) dans le cadre d' applications de commerce électronique, par exemple. Il faut savoir que, dans ce cas, il n'est pas très difficile à un pirate d'intercepter ces informations confidentielles, y compris le mot de passe du client , et ainsi d'usurper son identité, voire récupérer son code de carte bleue. Afin de palier à ces inconvénients, le protocole HTTPS peut être mis en œuvre.

En outre, on n'a pas une certitude absolue d'être en cours de consultation du site auquel on croit être connecté.

D'une manière très schématique, HTTPS permet d'encapsuler et de crypter le trafic HTTP; ainsi, il sera quasiment impossible à un pirate qui intercepterait des accès à des pages chargées via le protocole HTTPS, de décrypter cet échange, et donc de récupérer des informations confidentielles. De surcroît , HTTPS permet de s'assurer que le serveur auquel on accède est bien celui que l'on croit.

HTTPS offre d'autres possibilités qui ne sont pas abordées ici (par exemple, authentifier la personne qui accède au serveur). Sans entrer dans du détail technique, les échanges HTTPS sont cryptés et décryptés à l'aide d'un couple de 'clés informatiques' qui sont propres à un serveur :

• La clé privée, qui n'est connue que de ce serveur
• La clé publique qui est connue du monde entier

Le navigateur qui accède à un serveur doit récupérer la clé publique de ce serveur; celle-ci lui est transmise depuis le serveur, encapsulée dans un certificat X509 (c'est un fichier informatique). Ce certificat contient donc la clé publique du serveur, validée ("signée") par un organisme reconnu, appelé Certificate Authority (CA).

En ce qui concerne les logiciels client, Netscape Navigator et Microsoft Internet Explorer sont les deux programmes World Wide Web les plus répandus, mais ce ne sont de loin pas les seuls. Le premier est gratuit et le second est intégré au système d'exploitation Windows que l'on peut se procurer à partir de 150€. Tous ces navigateurs ne sont pas nécessairement graphiques, il en existe de purement textuels, ou adaptés à certaines formes de handicap ou de consultation :

• Des navigateurs à synthèse vocale permettent de naviguer par téléphone.
• Un service téléphonique permet de choisir, à l'aide des touches, la page que l'on veut recevoir par fax.
• On trouve aussi, en France, des accès au WEB à partir du Minitel.

Côté serveurs, il y a Apache, un logiciel libre qui est le serveur le plus répandu avec prés de 60% du marché. Ensuite, avec environ 30% du marché, on trouve Microsoft Internet Information Server, qui est un produit commercial d'un coût de quelques milliers d'euros.

Avec la possibilité de conserver ouverte une connexion jusqu’au transfert complet d’une page, la version 1.1, apporte un gain de performance non négligeable, surtout si l’on songe qu’il s’agit d’une connexion TCP qui fait l’objet d’une négociation complète entre l’appelant et l’appelé lors de son établissement.

HTTP/1.1 est finalement la version finale tant attendue de HTTP. Enormément d'améliorations ont été apportées, même par rapport à HTTP/1.0 qui était déjà un bond en avant dans l'évolution du protocole. Toute la mécanique de base du protocole est désormais mise en place, et il est à croire que peu d'autres améliorations techniques seront apportées dans les futures versions de HTTP. Ce à quoi il faut s'attendre sur les prochaines versions, c'est surtout une réponse aux nouveaux besoins du WEB : l'e-commerce, l'e-business... HTTP va certainement s'orienter de plus en plus "service de haut niveau" ; HTTP n'est plus un simple protocole de transport, c'est devenu un protocole "intelligent", supérieur.

Le reproche fait à HTTP est comme bien souvent le défaut de sa qualité : " La notion originale d’URL". Le principal défaut des URLs, est de rendre très difficile la réorganisation des espaces d’adressage des serveurs HTTP, car une information n’est pas identifiée en tant que telle, mais seulement par son chemin d’adressage. Toute modification de celui-ci rend caduques les URLs utilisées dans le monde entier pour désigner ces documents.

Pour palier à ce défaut, la notion d’URN (Uniform Resource Name) a été introduite. Le serveur responsable d’un URN a en charge de résoudre l’indirection entre le nom symbolique unique du document et son URL effective à l’instant de son utilisation.

Pour la petite histoire, aujourd'hui, Tim Berners-Lee, le père du WEB (timbl@w3.org) dirige le W3C. On trouve sur son site à l'adresse ( http://www.w3.org/People/Berners-Lee ) une foule d'informations croustillantes ainsi que des réponses à bon nombre de questions qui lui ont déjà été posées.

• Programmation des clients Web : O’reilly 1997

• Réseaux : Andrew Tanenbaum 1999

• Systèmes d'exploitation, distribués, centralisés : Andrew Tanenbaum 1994

• HTTP 1.0 Spécifications RFC 1945

• HTTP 1.1 Spécifications RFC 2616

• World Wide Web Consortium - http://www.w3.org

• Tim Berners-Lee - http://www.w3.org/People/Berners-Lee

• Etudes statistiques - http://www.netcraft.com/survey

• CUI Université de Genève – http://cui.unige.ch

• Cours de programmation autour de HTTP – http://www.reunion.fr

• WebTek - http://www.interdoc.com/webtek/

• Netscape introduction SSL - http://devedge.netscape.com/docs/manuals/security/sslin/index.htm

• The SSL protocol version 3.0 - http://www.netscape.com/eng/ssl3/draft302.txt

Voici la liste des 47 directives définies et utilisées dans les en-têtes de HTTP/1.1.

Ces statuts complètent ceux de HTTP/1.0. La grande nouveauté, c'est la définition de 2 statuts de la classe 1xx. La classe 4xx a été considérablement élargie.

1xx – Informational : Ces statuts servent à donner une réponse provisoire. Il n'y a pas d'en-tête particulier pour ces statuts. Un statut 1xx ne peut être envoyé à un client HTTP/1.0, sauf dans des conditions expérimentales.

2xx – Success : Ces statuts sont utilisés lorsque la requête a été correctement reçue, comprise et traitée.

3xx – Redirection : Ces statuts sont utilisés lorsqu'il faut une autre requête pour accéder à la ressource. A priori, le serveur sait que la ressource est accessible.

4xx - Client Error : Requête syntaxiquement incorrecte ou incomprise.

5xx - Server Error : La requête est a priori correcte, mais elle ne peut être satisfaite.

Retour au sommaire