La première version stable se revèle extrèmement simple en terme d'implémantation :

  • le serveur HTTP ouvre un port en écoute (usuellement le port 80)
  • le client HTTP se connecte au port en écoute du serveur
  • le client transmet une requête à l'aide de la commande GET
  • le serveur transmet au client la réponse à sa requête
  • le serveur ferme la connexion en guise de fin de réponse

Les échanges HTTP au travers de cette version sont reconnaissables au fait que les requêtes ne sont faites qu'au travers de la commande GET suivie d'un seul argument qui est l'objet requis. Aucun numéro n'étant initialement attribué à cette version, il lui sera attribué le numéro 0.9 par la suite lorsque sortira plus tard la version 1.0.

Le développement du protocole sera par la suite porté par le World Wide Web Consortium. En mai 1996, l'IETF publie la RFC1945 qui posera les bases du protocole HTTP/1.0. Suivra en juin 1999, la RFC2616 relative à la version HTTP/1.1. Les principaux contributeurs à ces deux spécifications seront Tim Berners Lee (membre du W3 Consortium et chercheur au MIT), Roy Fielding (chercheur à Université de Californie, Irvine) et Henrik Frystyk (membre du W3 Consortium et chercheur au MIT).

Dans la littérature relative aux échanges entre un client et un serveur HTTP, il est habituellement cité :

  • l'agent utilisateur (ou User-Agent): il s'agit du client HTTP
  • le navigateur (ou Browser, ou Butineur: il s'agit du client HTTP
  • le site web: il s'agit du serveur HTTP
  • le serveur d'origine: il s'agit du serveur HTTP hébergeant les ressources
  • le proxy: il s'agit d'un serveur HTTP servant de relai vers le serveur d'origine


Les versions HTTP/1.0 et HTTP/1.1 ont permis l'enrichissement du dialogue entre le client et le serveur en intégrant notamment la transmission de la version utilisée par les deux parties, l'ajout de méthodes en supplément de GET, mais aussi l'échange d'entêtes de données. Celles-ci permettent au client de spécifier par exemple le language dans lequel il souhaite que le serveur lui réponde. Elles permettent également au serveur de spécifier par exemple la durée de vie d'un contenu.

La reqûete d'un client HTTP se décompose ainsi :

  • Ligne 1 : methode argument version
    • methode : HEAD, GET, POST, PUT, ELETE, TRACE, OPTIONS, CONNECT
    • {argument}} : chemin complet jusqu'à la ressource demandée
    • version : HTTP/1.0, HTTP/1.1
  • Lignes suivantes : les entêtes HTTP
  • Une ligne vide
  • Lignes suivantes : un message optionnel
  • Chaque ligne se terminant par les caractères CR (Carriage Return et LF Line Feed


Exemple de reqûete afin d'obtenir le fichier exemple.txt du répertoire archives sur le serveur www.monsite.fr :

GET /archives/exemple.txt HTTP/1.1
Host: www.monsite.fr
Accept-Language: fr

Requete test

La réponse d'un serveur HTTP se décompose ainsi :

  • Ligne 1 : code message
  • Lignes suivantes : le contenu de la réponse


Exemple de réponse suite à la demande du fichier http://www.monsite.fr/archives/exemple.txt :

HTTP/1.1 200 OK
Date: Mon, 30 Mar 2009 00:01:23 GMT
Content-Type: text/html; charset=utf-8

Ceci est un document texte.
This is a text document.

Les différentes méthodes de reqûetage supportées par les versions actuelles du protocole HTTP sont au nombre de 8 :

  • HEAD : requête identique à la méthode GET mais le serveur ne doit pas renvoyer le contenu de la réponse, seulement les entêtes
  • GET : requête basique d'une ressources
  • POST : requête avec soumission de données dans le corps de la requête
  • PUT : requête en téléchargement pour une ressource
  • DELETE : requête en suppression d'une ressource
  • TRACE: requête avec demande de renvoi de la demande par le serveur, permet de voir les échanges faits via des intermédiaires comme les proxys
  • OPTIONS : requête permettant de connaitre les méthodes supportées par le serveurs pour une URL précise
  • CONNECT : requête permettrant d'établir une connexion au travers d'un tunnel TCP/IP


Les méthodes HEAD, GET, OPTIONS et TRACE sont définies comme étant des méthodes sûres puisqu'elle ne solicitent le serveur que pour une interrogation et non une modification des données qu'il héberge. Par opposition, les méthodes POST, PUT et DELETE sont définies comme étant des méthodes non-sûres puisqu'elle s'inscrivent dans une démarche de modification de contenu sur le serveur.

L'un des principaux apports de la version 1.1 est sans aucun doute le mécanisme de connexions persistantes (appelé aussi mécanisme Keep-Alive). Il permet à un serveur, si le client le stipule, de conserver ouverte la connexion entre les deux. Ceci a l'avantage de réduire le temps de communication dans la mesure où les deux parties ne renégocient pas de nouvelles connexions après la première requête, et de permettre l'envoi de plusieurs requêtes simultanées par le client (exemple: le contenu d'une page HTML et les images qui lui sont associées).

Le protocole HTTP peut également être sécurisé, il est alors appelé HTTPS (ou Secure HTTP). Les spécifications des échanges sécurisées sont décrites dans le document RFC2817.