Résumé

  • En octobre 2000, RFC 2965 a prévu un dialogue de mise à niveau : le client compatible avec les anciens et les nouveaux cookies devait continuer à envoyer Cookie selon le contexte et annoncer également Cookie2: $Version="1". Le serveur compatible pouvait poursuivre avec Set-Cookie2 ; l’ancien serveur ignorait le signal.
  • Le nouveau champ de réponse pouvait porter Port, pour restreindre les ports auxquels le cookie reviendrait, et CommentURL, pour proposer des informations au visiteur. L’annonce de capacité, la réponse du serveur et l’action éventuelle du visiteur étaient trois étapes distinctes.
  • En avril 2011, RFC 6265 a remplacé RFC 2965, demandé son reclassement historique et déconseillé Cookie2 et Set-Cookie2. Il a décrit les champs Cookie et Set-Cookie effectivement utilisés et constaté que les cookies d’un hôte circulaient entre ses ports.

Un navigateur présente sa carte de compétence

Les sites avaient besoin de reconnaître une session entre plusieurs requêtes HTTP. Un serveur confiait une valeur au navigateur et la recevait ensuite dans les demandes auxquelles elle s’appliquait. Ce principe était déjà formalisé dans le RFC 2109 de février 1997. Le casse-tête suivant consistait à enrichir les règles sans couper les navigateurs et serveurs qui parlaient les anciens dialectes. Aucun interrupteur central ne pouvait mettre tout le Web à jour en une journée.

Le RFC 2965 d’octobre 2000 a tenté une approche négociée. Il donnait au serveur un champ de réponse nouveau, Set-Cookie2, et au client un champ pour se faire connaître, Cookie2. Un navigateur qui comprenait les deux générations devait continuer à renvoyer un Cookie ancien pour les valeurs reçues par Set-Cookie. Il devait en même temps joindre Cookie2: $Version="1", un petit message indiquant au serveur qu’un autre langage devenait possible.

Si le serveur comprenait ce langage, il devait poursuivre la session avec Set-Cookie2. S’il ne le comprenait pas, il ignorait simplement Cookie2. L’échange ancien continuait. Le plan évitait de présenter aux anciens serveurs un ultimatum qu’ils n’auraient su traiter. Un client modernisé pouvait annoncer sa capacité sans demander au reste du réseau de changer immédiatement.

Une carte de compétence n’est pourtant que la première pièce d’un échange. Il faut encore voir la réponse Set-Cookie2, puis les valeurs renvoyées dans les requêtes suivantes. Le champ Cookie2 transportait une information sur la version comprise par le client ; le champ Cookie continuait à transporter les valeurs de session pertinentes. Mélanger ces fonctions fait disparaître le mécanisme même de l’upgrade.

Le serveur gardait aussi une marge de décision. RFC 2965 décrivait la manière de créer et de finir une session grâce à Set-Cookie2, mais la présence de ce champ ne prouvait ni que l’utilisateur avait accepté le stockage ni que l’application avait accompli une opération. Le protocole alignait des messages entre machines. L’usage effectif d’un cookie restait une étape ultérieure.

Ce que la voie nouvelle voulait réparer

Le nouveau champ ne changeait pas seulement l’orthographe. Son attribut Port permettait de préciser où la valeur pouvait être renvoyée. Sans cet attribut, le cookie pouvait repartir vers n’importe quel port de l’hôte concerné. Avec Port présent sans valeur, il devait rester lié au port de la requête d’origine. Une liste de ports autorisait seulement ceux qu’elle énumérait. Le concepteur d’un service disposait ainsi d’un moyen de limiter le retour d’une valeur entre applications voisines sur la même machine.

Un autre attribut, CommentURL, proposait un endroit où expliquer l’usage du cookie. Le document recommandait au serveur d’informer les personnes, et préférait une URL à un commentaire bref parce qu’une page pouvait porter davantage d’explications dans plusieurs langues. C’était une tentative de donner une place visible à l’information des utilisateurs. L’URL ouvrait la possibilité de lire ; l’acte de lecture et la décision de la personne appartenaient à la suite de l’histoire.

Ces détails expliquent l’intérêt du détour par Cookie2. Le mécanisme ne lançait pas simplement un nouveau nom de champ dans une conversation inchangée. Il proposait un périmètre de retour plus fin, une adresse d’explication, et un moyen de reconnaître les pairs capables de s’en servir. La valeur de ces possibilités dépendait cependant d’une condition très matérielle : navigateurs et serveurs devaient les mettre en œuvre ensemble.

Le texte accordait beaucoup de place à la coexistence des deux générations. Un navigateur ancien qui ne connaissait pas Set-Cookie2 suivait les règles qu’il connaissait déjà. Un navigateur connaissant les deux devait mémoriser l’origine de chaque valeur et répondre dans le dialecte correspondant. Si le serveur envoyait dans une même réponse des champs anciens et nouveaux pour un cookie équivalent, le client compatible donnait priorité au nouveau. Le plan protégeait les vieilles sessions, tout en demandant aux nouveaux logiciels de gérer deux chemins.

Les RFC ne donnent pas ici un tableau chiffré des navigateurs qui ont émis Cookie2 et des serveurs qui ont répondu avec Set-Cookie2. Des versions de logiciels datées et des traces d’échange établiraient cette adoption. Le document de 2000 dit comment la négociation devait marcher ; celui de 2011 montre où les rédacteurs ont ensuite placé la règle commune.

En 2011, le standard prend l’autre sortie

Le RFC 6265, publié en avril 2011, a choisi de décrire les champs Cookie et Set-Cookie tels qu’ils étaient effectivement utilisés sur Internet. Son introduction juge que les descriptions antérieures, dont RFC 2109 et RFC 2965, ne rendaient pas compte de cet usage. Aux serveurs, il recommande un profil d’émission discipliné ; aux clients, des règles de réception plus souples afin de traiter les réponses déjà présentes sur le réseau. Le texte part du trafic réel.

Il demande en même temps de classer RFC 2109 et RFC 2965 comme historiques, remplace RFC 2965 et déconseille expressément Cookie2 et Set-Cookie2. Dans son registre des champs, ces deux noms portent le statut obsolète. La carte de compétence et le distributeur réservé aux nouveaux cookies quittent donc le contrat central. Les champs qu’utilisaient les applications ordinaires restent en place.

Le document de 2011 ne prétend pas que cette pratique est parfaite. Il souligne que les cookies d’un même hôte sont partagés entre ses différents ports alors que la politique d’origine des navigateurs distingue normalement le contenu de ces ports. C’est exactement la frontière qu’un attribut Port voulait pouvoir resserrer en 2000. Le nouveau centre de gravité n’a pas repris cette restriction telle quelle : il a décrit l’échange qui tenait déjà le Web ensemble.

Il serait facile de réduire cette histoire à une bataille entre deux noms de champs. L’enjeu réel était la coordination de logiciels distribués. Un serveur peut proposer Set-Cookie2 ; un navigateur peut annoncer Cookie2 ; un ancien partenaire peut ignorer le nouveau mot. Chacun possède sa propre raison de rester compatible avec l’ancienne voie. Le RFC de 2000 avait pensé cette compatibilité avec soin. Onze ans plus tard, le RFC suivant a fait de cette voie de repli le cœur de la spécification.

La décision documentaire est nette : RFC 2965 est remplacé, les deux champs sont déconseillés. Elle ne précise pas quel navigateur a cessé d’envoyer Cookie2 à telle date. Pour cette chronique des implémentations, il faudrait les publications et traces des logiciels concernés. Le contraste des deux textes officiels suffit toutefois à voir la bifurcation des standards : en 2000 un langage nouveau cherchait son public ; en 2011 le langage déjà parlé devenait l’objet principal de la norme.

L’ancien chemin avait tous les usagers

Un protocole peut être mieux équipé et progresser prudemment. Cookie2 annonçait la capacité ; Set-Cookie2 était la réponse possible ; le pair ancien gardait l’ancienne session. Cette politesse évitait la rupture. Elle laissait aussi le bénéfice de la nouvelle voie dépendre de deux décisions, celle du navigateur et celle du serveur, à chaque rencontre.

Les coûts du choix final sont visibles dans les textes eux-mêmes. Le contrôle Port et le lien explicatif CommentURL demeuraient dans la branche retirée. Le contrat de 2011 décrivait toujours le partage des cookies entre ports et renvoyait la gestion par les utilisateurs à d’autres dispositions. Écrire une voie plus fine sur papier n’avait pas suffi à y déplacer le trafic.

La chute n’a rien d’un accident spectaculaire. Il n’a fallu ni panne mondiale ni réunion dramatique. Le champ de capacité pouvait être ignoré par les anciens serveurs, comme le plan l’autorisait. Le Web a continué à vivre sur la route familière. Quand la norme est revenue relever la circulation, elle a rangé le panneau de la route nouvelle dans les archives.