Le protocole HTTP

Le Web est le plus important système client/serveur implémenté à ce jour. L'utilisation de protocoles ouverts, définis par des groupes de travail au sein de l'IETF (Internet Engineering Task Force) assure l'interopérabilité des systèmes.

Ces protocoles spécifiques à Internet sont décrits dans des documents techniques appelés RFCs (Request For Comments) qui sont le stade final des spécifications publiées par l'IETF.

HTTP (Hypertext Transfer Protocol) est le protocole utilisé pour l'échange de messages entre les clients et serveurs Web. Les clients peuvent utiliser d'autres protocoles comme FTP, Gopher, NNTP (pour les nouvelles) etc..., mais HTTP est le protocole natif.

HTTP est employé pour chaque transaction concernant un document ou un graphique du WEB, à chaque clic sur un lien hypertexte, pour chaque formulaire transmis. Les mécanismes mis en oeuvre pendant ces échanges restent transparent pour l'utilisateur. C'est un protocole ASCII (American Standard Code for Information Interchange), niveau application du modèle OSI (Open Systems Interconnection), suffisamment léger et rapide pour permettre la transmission de documents distribués et multimédia à travers un système.

Quelques RFCs (Request For Comments) :

rfc1123 : Requirements for Internet Hosts -- Application and Support
rfc1945 : HTTP 1.0
rfc2616 : HTTP 1.1
rfc2617 : HTTP Authentication: Basic and Digest Access Authentication
rfc1867 : Form-based File Upload in HTML

Le site RFC Editor permet de rechercher et de télécharger une RFC, ainsi que l'archive de plus de 20Mo contenant toutes les RFC.

Le site RFC-Editeur.org regroupe toutes les traductions françaises des RFCs.

1.1 Les versions

Depuis 1990, date d'apparition du Web, le protocole HTTP évolue lentement mais surement. La première version déployée largement a été la 1.0, définie dans la rfc1945 de mai 1996. La version 1.1, deux fois plus volumineuse, est apparue au mois de janvier 1997,.

La version courante de ce protocole est HTTP/1.1. Elle cohabite avec HTTP/0.9 et HTTP/1.0. Cependant, cette dernière reste la version la plus répandue sur Internet.

En phase de développement : HTTP-NG.

1.2 Les URL

Un des principaux mécanismes du Web est le système de nommage des objets accessibles, qui en uniformise l'accès, qu'ils appartiennent à la machine sur laquelle on travaille ou distants sur une machine en un point quelconque du réseau.

Ce système de localisation, appelé Universal Resource Locator ou URL, dérive d'un système de nommage plus général nommé Universal Resource Identifier ou URI.

Elle à la forme suivante :

protocole : / / host : port / path fichier #position

• protocole : nom du protocole utilisé pour accéder à la ressource (http, ftp, file, mailto, ...),

• host : nom du serveur hébergeant la ressource ou son adresse IP (www.wanadoo.fr ou 214.124.25.14),

• [port] : numéro du port réseau sur lequel le serveur est à l’écoute. Selon le protocole utilisé, il existe toujours une valeur par défaut. (80 pour HTTP),

• [path] : chemin d’accès à la ressource,

• [fichier] : le nom de la ressource recherchée,

• [#position] : le nom désignant une position à l’intérieur de la ressource (ancre).

Exemple : http://www.wanadoo.fr/auth_user/copyright.html

Cette URL s’interprête de la manière suivante : il s’agit d’un document accessible via le protocole HTTP, sur le serveur www.wanadoo.fr qui est l’écoute sur le port 80 – numéro par défaut, donc non précisé dans l’URL – se trouvant dans le répertoire auth_user et dont le nom est copyright.html.

1.3 Principe

Le protocole HTTP suit le modèle client/serveur (requête/réponse).

Le client envoie une requête au serveur qui lui renvoie une réponse. Avec les versions HTTP/0.9 et HTTP/1.0, cet échange est réalisé en établissant une nouvelle connexion TCP pour chaque requête.

HTTP/1.1 impose, par défaut, au serveur de maintenir la connexion ouverte jusqu'à ce que celle-ci soit explicitement fermée. Ainsi le client adresse plusieurs requêtes, sans attendre de réponse, au serveur qui transmet les ressources demandées, dans le même ordre.

HTTP reste malgré tout un protocole sans état (stateless). Chaque transaction est gérée comme un échange séparé, aucune information n'est gardée entre deux transactions. Ainsi, dire que l'on est connecté à un site web n'a pas de sens. En effet, les sites web qui donnent à l'utilisateur l'illusion d'être connecté utilisent les cookies, les sessions, et l'authentification HTTP.

1.3.1 L'échange HTTP

Le protocole HTTP s’appuie généralement sur une connexion transport TCP (Transmission Control Protocol), et utilise le port 80 par défaut.

Quand le client se connecte au serveur, il envoie plusieurs en-têtes HTTP à travers le réseau, indiquant au serveur qui il est et ce qu'il désire. Le serveur renvoie un nombre d'en-têtes de réponse, décrivant les données qui sont retournées ou expliquant pourquoi aucune donnée n'est retournée.

Echange HTTP

Une transaction HTTP se deroule de la façon suivante :

1. Connexion TCP/IP

2. Requête client HTTP

   • la ligne de requête
   • les en-têtes de requête. En plus de la ligne requête, le client va envoyer des en-têtes supplémentaires.
   • une ligne vide : obligatoire, elle indique au serveur sait que la requête est terminée, sauf si les en-têtes du message (Content-Type: et Content-Length: par exemple) indiquent qu'il y a un corps de message.
   • le corps de requête : peut contenir des données supplémentaires.

3. Réponse serveur HTTP

   • la ligne de réponse : le serveur retourne un code d'etat en première partie de la réponse indiquant si la requête a réussi ou pas.
   • des en-têtes de réponse : le serveur peut retourner plusieurs en-têtes de réponse.
   • une ligne vide
   • le corps de la réponse : si la requête a aboutie, les données requises sont ensuite retournées au client.

4. Déconnexion TCP/IP
   en HTTP/0.9 et 1.1, le serveur ferme la connection après avoir envoyé la réponse
   en HTTP/1.1, le serveur ne ferme la connexion que si le client le demande explicitement.

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 (jusqu'à la version 1.0).

Une grande partie de l'information échangée entre le client et le serveur est réalisée sous forme d'en-têtes. Un en-tête à la forme suivante :

HeaderName : Value

La spécification HTTP/1.1 définit un grand nombre d'en-têtes pouvant être utilisés. En plus de ces en-têtes, le client et le serveur peuvent élaborer leurs propres en-têtes s'ils le désirent.

1.3.2 Le message HTTP

Chaque message HTTP, qu'il s'agisse d'une requête ou d'une réponse, à la structure suivante :

• une ligne initiale : ligne dont le contenu diffère selon qu'il s'agisse d'une requête ou d'une réponse

• des en-têtes : nombre variable d'en-têtes (HeaderName: Value).

• une ligne vide

• le corps : peut ne pas exister. S'il existe, son contenu peut être au format texte (code HTML de la page par exemple) ou binaire (images, ...).

En résumé, un message HTTP à le format suivant :

ligne_REQUETE ou ligne_REPONSE

en-tête_1: valeur_1
en-tête_2: valeur_2
....
en-tête_n: valeur_n

Corps_du_message

Remarque : Toutes les lignes du protocole HTTP doivent être terminées par CR/LF (caractères ASCII 13 et 10 respectivement).

1.3.3 La requete HTTP

C'est une suite de lignes envoyé au serveur par le navigateur. Elle comprend:

• une ligne initiale: constituée de trois éléments séparé par un espace:

  • le nom de la méthode utilisée (GET, POST, ...)
  • le chemin d’accès à la ressource (URL)
  • la version du protocole HTTP utilisé par le client (HTTP/1.x)

• les en-têtes : succession de lignes, facultatives, permettant de donner des informations supplémentaires sur la requête et/ou le client (Navigateur,système d'exploitation,...).

• une ligne vide : indique la fin de la requête

• le corps de la requête: ensemble de lignes optionnel permettant de transmettre des données au serveur. (par exemple un envoi de données par une commande POST à l'intérieur d'un formulaire).

Exemple : Requête HTTP avec InternetExplorer 6

Dans cet exemple, le navigateur souhaite afficher la page d'accueil de Google :

• ligne 1 : méthode GET, l'URL http://www.google.fr et la version du protocole HTTP 1.0

• lignes 2 à 8 : champs d'en-têtes.

  La requête ne contient pas de données à transmettre au serveur.

Exemple : la même requête HTTP avec Mozilla Firebird 0.6.1

Les méthodes de la requête

La méthode est la première information de la requête. Les plus utilisées sont GET, POST et HEAD.

GET
Utilisée pour accéder à une ressource sur le serveur. Cette ressource peut-être un document HTML, une image, un fichier vidéo, etc ....

La ressource peut également être générée dynamiquement. C'est le cas lorsque l'URL pointe vers un programme. Le serveur éxécutera ce programme et retournera les résultats au client HTTP.

Exemple : GET http://www.google.fr/search?q=php&hl=fr HTTP/1.0
envoie les paramètres q et hl avec comme valeurs respectives php et fr au programme search.

Les GET conditionnels utilisent l'en-tête If-Modified-Since dans la requête pour rapatrier la ressource seulement si elle a changé. Ceci est utilisé par les serveurs cache proxy pour estimer si les documents ont changé ou s'ils sont encore valides

HEAD
Cette méthode est semblable à GET : elle demande au serveur de ne renvoyer que les entêtes de la réponse sans transmettre la ressource elle-même. Cette méthode permet de récupérer des informations sur la ressource (date de dernière modification, taille, type, ...).

POST
Permet d'envoyer les données du corps de la requête sur le serveur vers l'URL spécifiée.

Les en-têtes de la requête

Puisqu'une requête se termine par une ligne vide (HTTP 1.x), d'autres lignes peuvent être intégrées à la requête. Ces informations supplémentaires envoyées par le client permettent au serveur de répondre au mieux à sa demande.

Description de quelques en-têtes :

Authorization: accréditif
Champ à inclure par l'utilisateur souhaitant s'authentifier vis à vis du serveur auquel il est relié. C’est le cas après réception d’une réponse de code 401

Accept: type/sous-type
HTTP supporte la negociation sur le type d'objet renvoyé par le serveur. L'en-tête Accept précise les différents types MIME attendus comme réponse à la requête en cours.

From: adresse_e-mail
Indique l'adresse électronique de l'utilisateur du navigateur. Cela n'est envoyé qu'avec son autorisation, et donc rarement pratiqué.

If-Modified-Since: date
Utilisé principalement par les serveurs cache proxy avec la command GET. Cet en-tête fournit l'heure et la date d'une copie en cache de l'objet référencé. Si le serveur possède une version plus récente, elle est renvoyée normalement. Sinon, la copie en cache reste valide et il n'y a pas besoin d'envoyer l'objet. Le serveur le signale avec un code d'erreur (304), envoit les en-têtes appropriés concernant le service de cache (comme, peut-être, un nouvel en-tête Expires:) et referme la connexion.

Referer: URL
Iindique au serveur l'URL du document à l'origine de la requête en cours. Ceci est très pratique pour une maintenance automatisée des serveurs, en particulier si la requête a provoqué une erreur. Les possesseurs de documents qui ont des liens invalides peuvent en être informés, automatiquement même.

User-Agent: nom_agent/version
Indique que logiciel agent (navigateur ou client Web) de l'utilisateur requiert le document.

Le corps de la requête HTTP

En plus de la requête elle-même et des en-têtes de requête, le client HTTP peut envoyer des données supplémentaires au serveur dans le corps de la requête. On l'utilise généralement pour la transmission de données à un processus CGI avec une requête POST, mais également pour la publication d'un document vers le serveur avec une requête PUT.

La fin des en-têtes est signalée par une ligne vide. Tout ce qui suit cette ligne est considéré par le serveur comme faisant partie du corps de la requête.

Lorsque le corps de la requête contient un message, les lignes d'en-tête suivantes doivent apparaître :

• Content-type: décrit le type MIME des données (text/html, image/gif, application/octet-stream,...)

• Content-length: donne la longueur du message en octets

1.3.4 La réponse HTTP

C'est un ensemble de lignes envoyé au navigateur par le serveur. Elle comprend:

• une ligne de statut: indique la version du protocole utilisé et l'état du traitement de la requête à l'aide d'un code et d'un texte explicatif. La ligne comprend trois éléments séparé par un espace:
  - la version du protocole HTTP utilisé
  - le code de statut
  - la signification du code

• les champs d'en-tête : lignes facultatives permettant de donner des informations supplémentaires sur la réponse et/ou le serveur. Chacune de ces lignes est composé d'un nom qualifiant le type d'en-tête, suivi de deux points (:) et de la valeur de l'en-tête

• une ligne vide : indique la fin de la requête

• le corps de la réponse : contient la ressource demandée

Exemple : Réponse HTTP

Réponse du serveur, suite à la requête effectuée dans l'exemple précédent :

• ligne 11 : ligne de statut mentionne la version du protocole HTTP utilisé 1.0, le statut 200 et la signification du statut OK.

• lignes 12 à 18 : les champs d'en-têtes.

• ligne 19 : ligne vide précédent les données à transmettre au client

• lignes 20 à 22 : code HTML de la page d'accueil

Le statut de la réponse HTTP

Lorsque le client à envoyé la totalité de sa requête, le serveur HTTP retournera une ligne de statut.

Exemple : HTTP/1.0 200 OK

Cette ligne contient 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. Il existe 5 classes de statuts :

• 1xx - Informational :

• 2xx - Success : requête traitée avec succès

• 3xx - redirection. La requête n'a pas été trouvée, mais le serveur peut y accéder.

• 4xx - Client Error : requête du client incorrecte

• 5xx - Server Error : requête correcte mais non satisfaite (problème interne au serveur, ...)

Les en-têtes de la réponse HTTP

Après la ligne de statut vient un ou plusieurs en-têtes de réponse.

Le corps de la réponse HTTP

Il s'agit tout simplement de la ressource demandée par le client accompagné d'un en-tête Content-Length.. Il est possible que le corps de la réponse soit vide, si le client a effectué une requête en utilisant la méthode HEAD ou si le serveur renvoie un code statut égal à 404 (Not Found).

1.4 Autorisations

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 un en-tête 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.

1.5 Connexions persistantes

En HTTP/1.0, le serveur ferme la connexion après l'envoie de chaque ressource. Cela implique que pour chaque ressource demandée, une connexion doit être établie. Cette opération entraine un accroissement de l'utilisation CPU, de la bande passante et de la mémoire sur le serveur.

Pour améliorer les temps de réponses et diminuer la charge du réseau, les connexions en HTTP/1.1 sont persistantes. Toutefois, le client ,aussi bien que le serveur, peut notifier à l'autre son désir de fermer la connexion à la fin de la transaction courante. Les requêtes ainsi que les réponses peuvent être enchaînées les unes après les autres.

Cette façon de procéder permet de remplacer l'utilisation de l'en-tête Keep-Alive qui ne fonctionnait pas toujours correctement en présence d'un proxy.

L'en-tête Transfer-Encoding: chunked a été introduit afin de permettre de continuer à utiliser des connexions persistantes même lorsque certaines ressources transmises sont générées dynamiquement (scripts CGI) et que leur taille n'est donc pas connue (En-tête Content-Length impossible à déterminer). Lorsque cet en-tête est utilisé, la ressource est envoyée par blocs précédés chacun de l'indication de la longueur du bloc. Un bloc vide (longueur 0) marquera la fin de la ressource.

1.6 Le cache

Un cache est une zone sur la machine du client ou sur une autre machine (proxy) qui conservera les ressources échangées entre le client et le serveur. Lorsqu'une de ces ressources sera à nouveau demandée par le client, c'est la copie conservée dans le cache qui sera utilisée. Cela permet, entre autres, de gagner du temps sur les ressources très sollicitées (les pages d'un intranet par exemple) et par voie de conséquence de réduire le trafic sur le réseau.

Toute la difficulté consiste à déterminer si le document a été mis à jour.

Le client va en fait soumettre la requête à un proxy ou tout autre dispositif comportant un cache. Ce dispositif va tenter de déterminer si le document caché qu’il possède 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 :

• fera une requête complète auprès du serveur pour récupérer une nouvelle copie, l'enregistrera dans le cache, et la transmettra au client

• fournira au client la ressource enregistrée dans le cache.

C'est la répétition de ce dernier cas qui permet d'améliorer les temps de réponses.

Les en-têtes tels que Date, Expires et Last-Modified permettent de savoir quand la ressource demandée 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 de renvoyer la nouvelle ressource (en-tête Expires).

La méthode HEAD est utilisée pour déterminer si une ressource a été modifiée depuis la dernière fois. Contrairement à la méthode GET, cette méthode ne demande pas le transfert de la ressource, ce qui permet par exemple d'obtenir la date de dernière modification et donc d'en déduire si la ressource demandée a changé depuis la dernière fois, sans pour autant surchargé le réseau.

L'en-tête If-Modified-Since permet de demander au serveur de renvoyer la ressource si et seulement si cette dernière a changé depuis la date indiquée dans l'en-tête. Pour le client, il suffit juste d'envoyer la date à laquelle il a reçu la ressource pour la dernière fois. Si la ressource n'a pas été modifiée, le serveur renvoie un statut 304 Not Modified et le client sait alors qu'il n'a plus qu'a transférer la ressource conservée en cache.

L'en-tête Pragma: no-cache permet d'interdire l'enregistrement d'une ressource en cache. On peut également utiliser l'en-tête Expires: avec comme valeur une date inférieure à celle du jour.

1.7 HTTP-NG : le futur HTTP

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

Politique de connexion
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.

Flux de données multiples
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).

Protocole binaire
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 et rendu encore plus compact. 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.

Authentification et paiement
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.

1.8 HTTPS : HTTP Secure

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

1.9 PRODUITS

Les clients HTTP :

• Mozilla : basé sur le moteur de Netscape.

• Amaya : une référence pour la navigation et l'édition web

• Lynx : un navigateur en mode texte

• Beonex Communicator : un navigateur basé sur Mozilla

• K-Meleon : un navigateur simple, libre et en français

• ...

Les serveurs HTTP :

• Apache: Serveur Web rapide, modulaire, puissant, extensible, configurable, dérivé du serveur NCSA httpd.

• Roxen: Serveur HTTP haute performance, sécurisé, GPL. Fait aussi du proxy, du FTP, du gopher...

• The WN Web server: Serveur Web (HTTP) ``sûr, robuste et flexible''.

• Jigsaw: Serveur HTTP du W3C, écrit et extensible en Java.

• thttpd - tiny/turbo/throttling HTTP server: Serveur HTTP simple et rapide.

• Boa

• Xitami: Serveur gratuit, avec code source, multi-plateforme.

• Plexus: Serveur Web écrit en Perl .

• ...

Divers :

• http://livehttpheaders.mozdev.org/ : Une des meilleurs extensions de Mozilla est le « Live HTTP Headers ». Cette extension permet de voir les en-têtes HTTP qui sont échangées entre le navigateur et le serveur Web.

• http://www.blunck.info/ieHTTPHeaders.html :
  la même chose pour Internet Explorer de Microsoft

• Telnet
  Le plus ancien Protocole de l'Internet permet à tout ordinateur de se comporter comme un simple terminal raccordé à un autre ordinateur. C'est un protocole simplifié (pas de graphismes, pas de gestion de la souris) qui ne fonctionne qu'en mode texte. Telnet permet d'accéder à des ordinateurs distants, puis, en ligne de commande, lire son courrier, faire du FTP, travailler vos fichiers, etc.

• Putty
  Remplace le client Telnet de Windows trop sommaire. C'est également un client SSH.

1.10 CONCLUSION

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 vers un "service de haut niveau".