Résumé

  • La RFC 2109 a normalisé Set-Cookie et Cookie pour former une session logique à partir d’échanges HTTP distincts, sans confondre cette session avec une connexion réseau persistante.
  • Domain, Path, Max-Age, Secure et les règles de cache limitaient la circulation de l’état ; le texte exigeait aussi un contrôle par l’utilisateur et encadrait les requêtes automatiques intégrées ou redirigées.
  • Le retour d’une valeur attestait une sélection d’état par l’agent utilisateur. Il ne prouvait ni la personne présente, ni son consentement, ni l’autorisation, la fraîcheur, l’intention ou le résultat.

La boutique se souvenait

L’exemple de la RFC 2109 ressemble à une petite pièce de théâtre. Le serveur envoie un cookie Customer, puis un Part_Number, puis un choix Shipping. À chaque requête, le navigateur renvoie les valeurs applicables au chemin /acme. Le panier acquiert une continuité que chaque message HTTP, pris seul, ne possédait pas.

Ce mécanisme est réel et précis. Le serveur nomme une valeur opaque ; l’agent utilisateur la conserve ; Domain, Path et l’âge décident de son retour. En revanche, le mot Customer reste une interprétation de l’application. Rien dans le champ ne vérifie que la personne devant l’écran est celle que le serveur avait en tête, qu’elle a relu la destination, qu’un pouvoir d’achat subsiste ou que la commande a abouti.

Une session logique au-dessus du transport

La RFC insiste : « session » ne signifie pas connexion persistante. Une connexion peut porter plusieurs messages puis disparaître ; une session issue des cookies peut continuer sur d’autres connexions. À l’inverse, une connexion encore ouverte ne garantit pas que le serveur accepte toujours la session applicative. Le réseau, le stockage du navigateur et la décision du serveur produisent trois preuves différentes.

L’origine ouvre le contexte avec Set-Cookie. L’agent utilisateur peut le poursuivre avec Cookie. L’un ou l’autre peut l’interrompre ; Max-Age=0 demande la suppression. Cette architecture ajoutait de la mémoire sans redéfinir la connexion comme identité. La RFC 9110 aide aujourd’hui à conserver la même discipline entre sémantique des messages et état du transport.

Une portée, pas un mandat

La valeur était opaque pour le navigateur et pouvait pourtant être lisible dans l’en-tête. Domain suivait les règles historiques de correspondance de la RFC 2109. Path retenait des préfixes d’URI. Max-Age fixait une durée souhaitée. Version=1 signalait ce modèle. Plusieurs cookies du même nom pouvaient être renvoyés, les chemins les plus précis étant placés en premier.

Ces règles répondent à « où et quand cette valeur est-elle applicable ? ». Elles ne répondent pas à « qui a autorité pour cette opération ? ». Path n’est pas une barrière de confidentialité. Un domaine partagé ne rend pas tous ses services également dignes de confiance.

La formulation de Secure est instructive : il s’agissait d’un conseil, et l’agent utilisateur pouvait déterminer ce qu’il considérait comme un moyen sûr. L’attribut ne chiffrait pas lui-même la valeur et ne liait aucune personne à une instruction. La section sécurité avertissait séparément que des en-têtes en clair pouvaient être lus ou modifiés.

L’état restait distinct du contenu mis en cache

La séparation entre état, URL et contenu devait préserver l’échelle permise par les caches. Un document public pouvait rester réutilisable ; un contenu propre à une session ne devait pas entrer dans un cache partagé. Le proxy devait transmettre Cookie et Set-Cookie, appliquer les règles ordinaires de validité et respecter private ou no-cache="set-cookie".

Une représentation en cache, un en-tête de création, un cookie effectivement conservé et une session acceptée plus tard sont donc quatre événements. Les confondre masque les défaillances. La RFC 2068 fournissait le vocabulaire HTTP/1.1 mobilisé par la RFC 2109 ; les caches HTTP/1.0, eux, ne pouvaient pas toujours empêcher la conservation de l’en-tête.

Les requêtes invisibles étaient déjà un problème

La RFC distinguait les transactions vérifiables, dont l’utilisateur pouvait examiner l’URI, des transactions non vérifiables : objets intégrés chargés automatiquement et redirections, notamment. Elle cherchait à empêcher une page de faire commencer ou continuer, à l’insu du lecteur, une session avec un domaine sans rapport. L’option de contournement devait être désactivée par défaut.

Le vocabulaire a vieilli, mais la question demeure : le navigateur renvoie un état parce que des règles correspondent, non parce qu’une personne vient de délibérer. Le texte exigeait donc des moyens de désactiver cookies et sauvegarde, de signaler une session, d’inspecter les valeurs et de décider de la conservation selon Domain. Il reconnaissait aussi qu’un suivi pouvait être intrusif avant même que l’identité soit connue, puis devenir identifiable après un formulaire.

La RFC 2964 a ensuite mis l’accent sur le consentement éclairé. La RFC 2965 a remplacé la RFC 2109 après l’expérience d’implémentation. La RFC 6265, puis le texte actuel de revue de la RFC 10025, appartiennent à d’autres générations. Cette chronologie prouve l’évolution des normes, pas la conformité d’un navigateur précis.

Un reçu d’état, rien de plus

Un en-tête Cookie peut prouver que des octets sont arrivés avec une requête. Avec des journaux adjacents, il peut établir une émission, une admission, une sélection et une session serveur reconnue. Il ne nomme pas nécessairement l’humain actuel, n’atteste pas son consentement informé et ne confirme ni autorisation, ni fraîcheur, ni résultat externe.

Running-Code Primacy de Lu Heng ramène les affirmations au système exécuté. Minimum Initial Specification sépare le noyau commun des décisions locales. Reality Layers empêche une trace d’emprunter l’autorité d’une autre. La RFC 2109 illustre cette discipline : la mémoire de protocole est utile précisément parce qu’elle n’est pas le verdict humain ou commercial.

Sources