Summary

  • Le champ HTTP Referer décrit en 1996 permettait au serveur d’arrivée de connaître l’adresse de la page d’où venait un visiteur. Le RFC y voyait un moyen de tenir des listes de liens entrants et des journaux, tout en signalant déjà la confidentialité possible de cette origine.
  • Referrer Policy a ensuite donné aux auteurs de pages le choix de la quantité d’adresse transmise. Avec strict-origin-when-cross-origin, une requête entre sites sécurisés ne porte que l’origine ; le passage de HTTPS vers HTTP ne porte aucun referrer.

Le navigateur entre sur un autre site avec une note dans la poche : « je viens de là ». Le RFC 1945, publié en mai 1996 pour HTTP/1.0, appelait cette note Referer. La faute d’orthographe est devenue un nom de famille. Le champ aidait le serveur à reconstituer les liens entrants, lire ses journaux, améliorer certains caches et retrouver les liens erronés. Le propriétaire du site savait quelle page amenait du monde. Le visiteur n’avait pas forcément compris que son ancienne adresse voyageait avec lui.

Le texte de 1996 voyait déjà le problème. L’origine d’un lien pouvait être privée ; il recommandait de laisser l’utilisateur décider de l’envoi du champ. Une adresse tapée directement au clavier n’avait pas de page d’origine et le fragment placé après # était écarté. Pourtant, la logique de la carte de visite restait séduisante : plus l’adresse précédente était précise, plus le serveur d’arrivée savait d’où venait le clic. La précision utile aux liens entrants dessinait aussi un itinéraire de lecture.

Le W3C a choisi un exemple moins abstrait qu’une ligne de journal. Une personne place un lien vers son groupe préféré sur son profil de réseau social. Un autre visiteur suit le lien. Le site du groupe a intérêt à savoir que la visite vient du réseau ; recevoir l’URL précise du profil pourrait révéler l’identité de son propriétaire. La Candidate Recommendation Referrer Policy de janvier 2017 met cette scène au centre du problème. Dans la même enveloppe arrivent une indication utile et une adresse de trop.

La politique a ajouté plusieurs façons de fermer l’enveloppe. no-referrer n’envoie aucune carte. origin transmet seulement le protocole, le nom du site et le port, en laissant le chemin derrière. strict-origin-when-cross-origin conserve l’URL complète, nettoyée, pour une requête au même site ; vers un autre site sécurisé, il n’envoie que l’origine. Si une page HTTPS se dirige vers une destination HTTP, il n’envoie rien. Ce dernier cas compte : même le nom d’un site peut devenir visible sur un trajet non chiffré. L’auteur de la page peut exprimer ce choix par un en-tête de réponse ou les autres mécanismes prévus par la spécification.

La décision a changé de mains. Le premier en-tête HTTP donnait au navigateur un moyen de raconter au serveur d’arrivée où le lien avait commencé. La politique permettait à la page de départ de choisir la longueur du récit. Un réseau social peut annoncer sa provenance au site d’un groupe sans lui offrir l’adresse d’un membre. Le serveur garde une indication de trafic ; le nom du profil reste dans la poche de l’expéditeur.

Le RFC 9110 sur la sémantique HTTP, publié en juin 2022, conserve l’orthographe Referer et les deux faces du champ. Il sert toujours aux statistiques, aux journaux et à l’entretien des liens. Il peut aussi révéler le contexte immédiat de navigation, un nom de compte ou une ressource confidentielle contenue dans une URL. Le texte retire les fragments et les informations d’utilisateur, permet de raccourcir au-delà de l’origine et interdit l’envoi d’un referrer HTTPS dans une requête HTTP non sécurisée. La carte de visite née en 1996 est devenue un document qu’on relit avant de le tendre.

L’historique des publications du W3C va du premier projet public de 2014 à la Candidate Recommendation de 2017. Le résultat tient dans un geste quotidien : un visiteur quitte un profil et arrive chez un groupe. Le groupe peut apprendre le nom du réseau. Il n’a pas besoin du numéro d’appartement de chaque personne qui passe la porte.