Summary

  • La description de HTTP mise en œuvre pour le Web de 1991 montre une requête GET suivie d’un document HTML, dont la fin correspondait à la fermeture de la connexion par le serveur.
  • Cet échange ne comportait ni ligne d’état ni en-têtes. Les notes de conception indiquent qu’une erreur revenait comme un document et ne se distinguait d’une réponse réussie que par son texte.
  • HTTP a ensuite ajouté version, en-têtes et codes d’état tout en conservant l’échange simple pour la compatibilité ; cette trace ne mesure pas l’ampleur de l’usage de HTTP/0.9.

La page faisait toute la réponse

Dans la mise en œuvre du World Wide Web décrite en 1991, le client ouvrait une connexion au serveur, utilisait le port 80 par défaut si l’adresse n’en indiquait aucun, puis envoyait une ligne GET avec l’identifiant du document. Le serveur répondait par un flux de texte HTML. Une fois le document transmis, il fermait la connexion. Aucun état de réponse ne précédait la page et aucun en-tête ne suivait : les premiers octets reçus appartenaient au document.

L’archive de Tim Berners-Lee ne décrit pas une enveloppe HTTP invisible entourant chaque page. Elle précise que la réponse était un message HTML, que la fermeture terminait le transfert et qu’une erreur pouvait être fournie sous forme de texte lisible en HTML. Elle nomme aussi la limite : il n’existait aucun moyen de distinguer une erreur d’une réponse satisfaisante autrement qu’en lisant le texte. Le navigateur pouvait afficher le contenu ; le format ne fournissait pas de code machine pour un document absent, une redirection ou une erreur serveur.

Le résumé de juin 1992 expose le compromis. Le navigateur n’envoyait qu’une commande, GET, suivie d’un identifiant pouvant inclure des mots-clés pour interroger un index nommé. Le serveur ne conservait pas d’état lié au navigateur. La réponse pouvait être HTML ou texte brut, et contenir un document, un menu ou une liste de résultats. La simplicité était un avantage : rien d’autre que du texte balisé ne sortait du serveur. Mais le résumé souligne aussi l’absence de séparation lexicale entre les informations HTTP, le contenu du document et son type. Un message d’erreur restait un document ; un lecteur pouvait passer à côté.

Cette ambiguïté décrit la syntaxe, pas la fréquence des pannes ni l’incapacité d’un humain à comprendre une page d’erreur. Le lecteur pouvait interpréter le texte. Un programme ne disposait d’aucun champ d’état à examiner. Et la fermeture de connexion servait à marquer la fin normale d’un document comme à interrompre un échange. Elle indiquait que le flux s’était arrêté, mais pas pourquoi.

Le premier modèle ne se limitait pas aux pages statiques. Une balise ISINDEX pouvait indiquer au navigateur de construire une requête en ajoutant des mots-clés à l’identifiant du document ; le serveur pouvait renvoyer une liste de résultats en HTML. Dans son texte sur les raisons d’un nouveau protocole, Berners-Lee cite aussi la recherche dans un index, la négociation de format et la possibilité de renvoyer le client vers un autre serveur parmi les capacités souhaitées. Ce sont des objectifs de conception, pas la preuve que l’échange simple offrait déjà toutes ces fonctions.

Élargir l’échange sans oublier l’ancien

Dans un message public de décembre 1992, Berners-Lee propose une évolution : les nouveaux serveurs doivent toujours reconnaître GET <url>, mais un client peut ajouter un jeton de version sur la même ligne, puis des en-têtes tels que From, Accept et Accept-Encoding. Son exemple de réponse comporte une version, un champ de réponse, un type MIME et les méthodes prises en charge. C’est une proposition discutée, pas une capture définitive du protocole déployé. Elle montre toutefois le besoin d’exprimer des informations sur la réponse, en plus du contenu renvoyé.

Le RFC 1945, publié comme RFC Informational en 1996, décrit ensuite les deux formes. La requête simple reste un GET et un URI, sans en-têtes ; la réponse simple est uniquement le corps et se termine à la fermeture du serveur. Une réponse complète commence par une ligne d’état et peut comporter des en-têtes de réponse et d’entité. Le RFC avertit que la requête simple ne permet pas au serveur d’indiquer le type de média retourné. La compatibilité permettait aux systèmes HTTP ultérieurs de reconnaître l’ancien échange sans prétendre qu’il avait le même format.

La chronologie importe : la définition rétrospective du RFC est utile pour comprendre la compatibilité, mais ne prouve pas qu’un standard HTTP/0.9 distinct ait été ratifié en 1991. Berners-Lee se souvient que le premier serveur Web et les premiers clients, dont le navigateur en mode texte de Nicola Pellow, furent diffusés dans la communauté de la physique des hautes énergies puis dans les milieux de l’hypertexte et de NeXT à l’été 1991. Les spécifications URI, HTML et HTTP étaient publiées sur le premier serveur pour encourager discussion et adoption.

Ces sources situent l’expérience ; elles ne comptent pas les installations utilisant chaque forme de message.

Une réponse constituée du document rendait le système simple à comprendre : demander une ressource et recevoir du contenu affichable. La limite apparaissait lorsque le client devait traiter la réponse comme un événement de protocole. Sans ligne d’état, page et erreur occupaient la même place. Les messages HTTP plus complets ont séparé résultat, métadonnées et représentation ; l’échange simple est resté reconnaissable pour préserver la compatibilité.

Sources