HTTP 1.0 et HTTP 1.1

HTTP est officiellement défini, en V 1.0 par la RFC 1945 (août 1996)

Ce protocole a l'avantage de sa rusticité. Toutefois, il présente certains inconvénients.

1. Nombreuses sessions (lourde charge des routeurs et DNS)

   Chaque demande de ressource fait appel à une nouvelle session TCP/IP. Par exemple, une page contenant 10 images peut créer 11 sessions TCP/IP, en l'espace de quelques secondes.

   Ces ouvertures de session alourdissent inutilement le réseau, les routeurs etc..

2. Les fureteurs ne peuvent savoir si une demande identique produira les mêmes effets.

   Certains documents rendus ne sont mis à jour qu'exceptionnellement, d'autres le sont chaque minute. Le fureteur ne sait pas différencier ces documents, et ne peut facilement gérer la mémorisation locale des ressources, dans son cache.

   Un serveur intermédiaire (proxy) rencontre les mêmes problèmes, et ne connaît pas précisément la durée de vie de chaque ressource copiée dans les fichiers locaux.

3. Protection (mot de passe) très faible.

   La protection des accès par mots de passe pourrait être utile. Sa mise en oeuvre en HTTP fait que ce mot de passe est envoyé par le fureteur - très légèrement codé - lors de chaque demande de ressource. L'appel d'une page et de ses 10 images provoque la transmission du mot de passe ... 11 fois.

Ces points sont pris en compte dans HTTP 1.1 (à l'état de proposition) décrit par la RFC 2068 (août 1996)

... et déjà utilisée.

Le système de protection par mots de passe est décrit en RFC 2069, mais reste sommaire : "[this system] is better than nothing" (ligne 157 de la RFC 2069)