Résumé

  • En 1994, marketplaceMCI devait préserver les informations de commande, de facturation et de livraison entre plusieurs requêtes Web. MCI a écarté la première proposition de Netscape, qui plaçait l’état sur le serveur, et demandé un stockage côté client.
  • Netscape a transformé ce besoin en fonction générale du navigateur. Le serveur pouvait transmettre une valeur d’état que le navigateur renverrait lors de requêtes ultérieures correspondant à son périmètre. Cette valeur ne permettait pas, à elle seule, d’identifier la personne qui tenait le navigateur.
  • RFC 2109 a ensuite tenté de formaliser un mécanisme déjà façonné par le code et la compatibilité. Le texte reconnaissait les limites du contrôle utilisateur, de la lisibilité des valeurs et de leur transport non protégé.

Un panier a transformé l’oubli du protocole en problème de produit

Le modèle courant du Web avait un angle mort pratique. Une requête HTTP demandait une ressource et recevait une réponse, mais la suivante ne transportait pas automatiquement l’historique de l’application. Un commerçant pouvait conserver cet historique sur son serveur, au prix d’une gestion des données et des traces laissées après le départ du navigateur.

MCI préparait marketplaceMCI, un espace d’achat en ligne articulé autour d’un navigateur de marque MCI, d’un serveur Web, de serveurs marchands chargés de recevoir et d’honorer les commandes, puis de systèmes de soutien et de gestion des comptes marchands. Il fallait faire circuler des informations de commande, de facturation et de livraison au fil de plusieurs échanges.

Le choix de conception ressort d’une décision judiciaire ultérieure, plutôt que d’un récit héroïque rétrospectif. Lors d’une réunion du 10 août 1994, MCI a refusé l’idée initiale de Netscape de garder l’état sur un serveur. MCI exigeait que les informations soient enregistrées sur l’ordinateur du client. La décision décrit cet accord général comme non contesté, tout en signalant des désaccords sur certains détails techniques.

Cette exigence déplaçait la mémoire temporaire de l’application. Le navigateur garderait un petit objet d’état entre les échanges avec le serveur. Lou Montulli, programmeur chez Netscape, fut chargé du problème. Il se souvenait d’une demande estivale visant une méthode de panier adaptée au caractère sans session d’HTTP, sans se rappeler que MCI était le client précis. Marc Andreessen a témoigné que le projet MCI avait finalement conduit aux cookies et que Netscape en avait fait un mécanisme général. Ces témoignages relient le besoin commercial à une décision produit, sans rendre chaque détail de la conception certain.

Le navigateur est devenu porteur de l’état de l’application

La copie conservée de la spécification Netscape décrit le mécanisme simplement. Un serveur pouvait joindre un objet d’état à une réponse HTTP. Le navigateur le stockait, puis l’ajoutait à ses requêtes ultérieures dont l’URL correspondait au périmètre du cookie. L’application du serveur choisissait la valeur et lui donnait un sens ; le navigateur la retenait et la retournait.

Un panier, une valeur d’inscription ou une préférence pouvait ainsi traverser plusieurs requêtes. HTTP n’est pas devenu un protocole à connexion continue. Une page n’avait pas besoin de contenir le panier individuel de chaque visiteur, ce qui importait pour la mise en cache. Et le serveur ne cessait pas d’intervenir : il pouvait utiliser la valeur reçue comme clé vers des données conservées ailleurs.

Le document Netscape se présentait comme une spécification préliminaire à utiliser avec prudence. Ses règles définissaient notamment l’hôte ou le domaine, le chemin, la durée de vie et la transmission sécurisée. Ces paramètres délimitaient les circonstances où le navigateur renverrait l’état. Ils ne prouvaient ni le nom de la personne, ni son consentement, ni sa présence continue.

La décision situe du code brouillon dans le dépôt Netscape au 3 ou 4 octobre 1994, avec d’autres modifications les 6 et 13 octobre. Les parties au procès divergeaient sur la date précise de réduction à la pratique. La chronologie défendable associe donc une conception et un besoin client en été, du code au début d’octobre selon la décision, puis la généralisation de la fonction dans le navigateur. Elle ne fournit pas un jour d’invention incontestable.

La norme a suivi une proposition déjà implantée

En février 1997, David Kristol et Montulli ont publié la RFC 2109, « HTTP State Management Mechanism ». Elle décrivait les réponses Set-Cookie et les requêtes Cookie, avec une grammaire de référence. Une section historique prévoyait explicitement la compatibilité avec la proposition initiale de Netscape. Normaliser consistait aussi à composer avec du code et des usages déjà diffusés.

La RFC rendait visibles les limites du mécanisme. Le navigateur devait laisser l’utilisateur décider si les cookies étaient envoyés et conservés. Les en-têtes circulaient sans protection : une valeur sensible pouvait être exposée ou modifiée. La valeur était opaque pour le navigateur, mais pouvait rester lisible. Dans l’exemple de connexion, la personne commence par s’identifier au moyen d’un formulaire ; le serveur lui renvoie ensuite un cookie qui reflète cette identité. Le cookie prolonge l’état de l’application après cette étape : il ne constitue pas lui-même une preuve indépendante d’identité.

Cette distinction compte parce qu’une valeur stockée dans un navigateur peut servir un service sans prouver quelle personne le tient. Si l’application traite la possession de cette valeur comme une autorité, elle crée une capacité de session au porteur. Quiconque obtient la valeur peut parfois la réutiliser pendant sa durée de vie et dans son périmètre. La sûreté dépend de son émission, de sa protection, de son expiration et de sa révocation, que l’échange de base ne définit pas à lui seul.

L’histoire du cookie est moins mystérieuse que son nom. Un parcours d’achat a obligé une équipe produit à choisir où résiderait la continuité. Le navigateur est devenu le transporteur d’un état choisi par le serveur ; un besoin client a pris la forme d’une fonction réutilisable ; puis une norme a consigné la compatibilité avec la pratique déployée. Le Web pouvait ainsi se souvenir d’une transaction entre des requêtes séparées. Le navigateur n’est jamais devenu témoin de l’identité humaine qui se trouvait derrière elles.

Sources et limites