La règle d'orthographe derrière Referer vs Referrer

Quelle orthographe est correcte, referer ou referrer ?

La réponse courte à la question referer vs referrer est que les deux orthographes sont correctes, chacune à sa place : l'en-tête de requête HTTP est Referer, avec un seul r au milieu, et presque tous les noms créés après lui, dont document.referrer, l'en-tête Referrer-Policy et l'attribut referrerpolicy, suivent l'orthographe du dictionnaire. La forme fautive est le nom d'en-tête qui circule sur le réseau. La forme correcte est celle que les développeurs tapent dans le HTML, le JavaScript et les en-têtes de réponse.

Un seul test couvre la plupart des cas. Si vous lisez ou écrivez l'en-tête de requête brut, ou une variable serveur construite à partir de lui, écrivez Referer. Si vous nommez n'importe quoi d'autre, écrivez referrer. Le tableau plus bas liste les cas où ce test tient et ceux où un framework le contourne.

D'où vient la faute d'orthographe de Referer ?

La faute est entrée dans les textes avec la RFC 1945, le document HTTP/1.0 de Tim Berners-Lee, Roy Fielding et Henrik Frystyk, daté de mai 1996. La section 10.13 définit le champ sans aucun commentaire sur son orthographe :

Referer        = "Referer" ":" ( absoluteURI | relativeURI )
 
Referer: http://www.w3.org/hypertext/DataSources/Overview.html

La RFC 1945 n'a jamais été un standard. Sa note de statut indique "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind." Le document décrivait HTTP tel que les navigateurs et les serveurs le faisaient déjà tourner, donc le nom d'en-tête circulait en production avant que quiconque ne l'écrive. Le corriger sur le papier aurait cassé tous les serveurs qui le lisaient déjà.

Le premier aveu est arrivé huit mois plus tard. La RFC 2068, première spécification HTTP/1.1 et première sur la voie de la normalisation, datée de janvier 1997, ouvre sa section 14.37 par "The Referer[sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained (the "referrer", although the header field is misspelled.)" La RFC 2616 a repris cette phrase en juin 1999.

La spécification actuelle garde la faute et l'aveu. La RFC 9110, HTTP Semantics, datée de juin 2022 et publiée comme Internet Standard 97, ouvre sa section 10.1.3 par "The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained (i.e., the "referrer", though the field name is misspelled)." Vingt-six ans après la RFC 1945, les éditeurs annotent toujours le nom au lieu de le renommer, car un renommage changerait la seule chaîne que chaque serveur recherche.

Quels noms utilisent quelle orthographe ?

Chaque nom que la plateforme web a ajouté après l'en-tête suit l'orthographe du dictionnaire, et chaque nom côté serveur construit mécaniquement à partir de l'en-tête garde la faute.

Le brouillon W3C Referrer Policy énonce ce choix dans ses propres notes de grammaire : "The header name does not share the HTTP Referer header's misspelling." MDN fait la même remarque sur sa page Referrer-Policy : "The Referrer-Policy header does not share this misspelling."

Les noms côté serveur héritent de la faute par une règle de nommage, pas par une décision. Le manuel PHP indique que PHP crée des entrées $_SERVER "named HTTP_ followed by the header name, capitalized and with underscores instead of hyphens," si bien que l'en-tête Referer arrive sous le nom HTTP_REFERER. La référence des requêtes de Django décrit HTTP_REFERER comme "The referring page, if any."

Express prend le chemin inverse et accepte les deux. Le docblock de req.get dans le code source d'Express indique "The Referrer header field is special-cased, both Referrer and Referer are interchangeable," et le code renvoie this.headers.referrer || this.headers.referer. Cet ordre signifie qu'une requête portant un en-tête littéralement nommé Referrer l'emporte sur l'en-tête standard, ce qui ne compte que si un client envoie volontairement le nom non standard.

La faute d'orthographe cause-t-elle de vrais bugs ?

La faute provoque trois bugs qui reviennent sans cesse en revue de code, et un seul d'entre eux concerne le r manquant.

Des lectures d'en-tête qui ne renvoient rien. Un code qui lit un en-tête nommé referrer dans une table d'en-têtes brute obtient un résultat vide, car la RFC 9110 ne définit que Referer et c'est le nom que les navigateurs envoient. Express masque le problème en vérifiant les deux noms. PHP et Django n'exposent que HTTP_REFERER.

Vouloir définir l'en-tête depuis JavaScript. MDN classe Referer parmi les en-têtes de requête interdits, donc le passer dans les en-têtes de fetch() ne change pas ce que le navigateur envoie. L'option referrer de RequestInit existe pour ce travail. MDN documente trois types de valeur : "A same-origin relative or absolute URL" définit l'en-tête, "An empty string" l'omet, et about:client utilise la valeur par défaut du contexte de la requête, qui s'applique aussi quand l'option est absente.

Le tiret, pas le r. MDN avertit que "the noreferrer link relation is written without a dash. When you specify the referrer policy for the entire document with a <meta> element, it should be written with a dash: <meta name="referrer" content="no-referrer">." Donc rel="noreferrer" et content="no-referrer" sont tous deux corrects, et les intervertir ne produit rien, sans aucun message.

Que renvoie document.referrer ?

document.referrer renvoie l'adresse de la page qui a mené à la page actuelle, sous forme de chaîne. MDN indique "The value is an empty string if the user navigated to the page directly (not through a link, but, for example, by using a bookmark)." L'exemple de MDN rend la troncature visible : après un clic depuis un article MDN vers w3.org, la propriété sur la nouvelle page affiche "the previous domain like developer.mozilla.org", et non l'URL complète de l'article.

Cette troncature vient de la politique de referrer, qui gouverne aussi l'en-tête. Le brouillon W3C indique "The default referrer policy is "strict-origin-when-cross-origin"", et MDN décrit cette politique ainsi : "Send the origin, path, and query string when performing a same-origin request. For cross-origin requests send the origin (only) when the protocol security level stays same (HTTPS→HTTPS). Don't send the Referer header to less secure destinations (HTTPS→HTTP)." Les scripts d'analyse côté client lisent document.referrer, et les journaux serveur lisent Referer. Avec la politique par défaut, les deux voient un nom d'hôte pour les visites intersites et rien du tout pour un passage vers HTTP. La façon dont ce nom d'hôte devient un canal est traitée dans ce qui compte comme trafic référent, et ce qui se passe quand il est vide dans le trafic direct.

Où les spécifications se contredisent-elles ?

Les spécifications se contredisent à deux endroits, et les deux influencent ce qu'un outil d'analyse peut voir.

Le premier oppose la RFC 9110 au comportement par défaut des navigateurs. La RFC 9110 indique "A user agent SHOULD NOT send a Referer header field if the referring resource was accessed with a secure protocol and the request target has an origin differing from that of the referring resource, unless the referring resource explicitly allows Referer to be sent." La politique par défaut du W3C envoie l'origine exactement sur cette requête, d'une page HTTPS vers une autre origine HTTPS, sans permission explicite de la page. Les deux textes sont en vigueur. Les navigateurs suivent la valeur par défaut du W3C, ce qui explique pourquoi les rapports de trafic référent affichent encore des noms d'hôte. Les deux documents s'accordent sur le cas du passage vers HTTP, où la RFC 9110 indique qu'un user agent "MUST NOT send a Referer header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol."

Le second porte sur les éléments qui acceptent noreferrer. Trois sources donnent trois listes :

Le HTML Standard définit les types de liens, donc sa liste fait foi : "The noreferrer keyword may be used with a, area, and form elements." La propre page rel="noreferrer" de MDN s'accorde avec le HTML Standard, ce qui laisse sa page Referrer-Policy comme l'exception.

Pour le trafic de campagne, rien de tout cela ne mérite qu'on se batte. Un referrer tronqué ou manquant ne peut pas être restauré après coup, et un tag UTM sur le lien transporte la source, quoi que la politique supprime.

Questions fréquentes

Est-ce Referer ou Referrer dans une requête HTTP ?

L'en-tête de requête est Referer, la seule orthographe que définit la RFC 9110 et celle que les navigateurs envoient. La RFC 9110 marque le nom d'un "[sic]" et explique que le nom du champ est mal orthographié. Les variables serveur construites à partir de cet en-tête, comme HTTP_REFERER en PHP, conservent la faute. Les noms créés plus tard utilisent Referrer, comme l'en-tête de réponse Referrer-Policy.

Pourquoi la faute de Referer n'a-t-elle jamais été corrigée ?

L'en-tête circulait déjà en production quand la RFC 1945 l'a consigné en mai 1996, et chaque serveur le lit sous ce nom exact. La RFC 2068 a ajouté un "[sic]" en janvier 1997, et chaque spécification HTTP depuis a gardé l'annotation au lieu de renommer le champ.

Peut-on définir l'en-tête Referer avec fetch() ?

Non, car MDN classe Referer parmi les en-têtes de requête interdits, donc le navigateur l'ignore dans l'objet headers. Utilisez plutôt l'option referrer de la requête. Une chaîne vide omet l'en-tête, et une URL de même origine le définit.

L'en-tête Referrer-Policy reprend-il la faute d'orthographe ?

Non. La spécification W3C Referrer Policy indique que "The header name does not share the HTTP Referer header's misspelling." Il en va de même pour l'attribut referrerpolicy, le nom meta referrer et rel="noreferrer".

Pourquoi document.referrer est-il vide ?

document.referrer est vide quand la visite n'avait pas de page référente, comme un favori ou une adresse tapée, et quand une politique ou le balisage l'a supprimé. Un lien rel="noreferrer", une politique no-referrer et une page HTTPS qui pointe vers une page HTTP produisent tous une valeur vide avec les règles par défaut.

Pourquoi PHP l'appelle-t-il HTTP_REFERER ?

PHP construit les clés de $_SERVER à partir des noms d'en-têtes de requête en ajoutant le préfixe HTTP_, en passant en majuscules et en remplaçant les tirets par des underscores. L'en-tête est Referer, donc la clé est HTTP_REFERER. Django suit le même schéma dans request.META.

Quelle est la politique de referrer par défaut dans les navigateurs ?

Le brouillon du W3C fixe strict-origin-when-cross-origin comme valeur par défaut. Pour les requêtes de même origine, elle envoie l'origine, le chemin et la query string. Pour les requêtes cross-origin, elle n'envoie que l'origine tant que le niveau de sécurité du protocole reste le même, et elle n'envoie aucun en-tête Referer de HTTPS vers HTTP.

Quelle est la différence entre rel="noreferrer" et no-referrer ?

rel="noreferrer" est une relation de lien et s'écrit sans tiret. no-referrer est une valeur de politique, donc la forme valable pour tout le document est <meta name="referrer" content="no-referrer">, avec un tiret. Si on les intervertit, rien ne se passe, sans aucun avertissement.

Express accepte-t-il Referer et Referrer ?

Express accepte les deux. Le docblock de req.get les déclare interchangeables, et le code renvoie this.headers.referrer || this.headers.referer. Un en-tête littéralement nommé Referrer l'emporte sur l'en-tête standard.

Quelle RFC a défini en premier l'en-tête Referer ?

La RFC 1945, le document HTTP/1.0 de mai 1996, le définit à la section 10.13 et ne dit rien de l'orthographe. La RFC 2068 a ajouté le [sic] en janvier 1997. La RFC 9110 le porte toujours en juin 2022.