Die Schreibregel hinter Referer vs. Referrer

Welche Schreibweise ist richtig, Referer oder Referrer?

Die kurze Antwort auf Referer vs. Referrer lautet, dass beide Schreibweisen richtig sind, jede an ihrem Platz: Der HTTP-Request-Header heißt Referer, mit einem einzelnen r in der Mitte, und fast jeder danach geprägte Name, darunter document.referrer, der Header Referrer-Policy und das Attribut referrerpolicy, nutzt die Wörterbuch-Schreibweise. Die falsch geschriebene Form ist der Header-Name, der über die Leitung geht. Die richtige Form ist das, was Entwickler in HTML, JavaScript und Response-Header tippen.

Ein Test deckt die meisten Fälle ab. Wenn Sie den rohen Request-Header lesen oder schreiben oder eine daraus gebaute Servervariable, schreiben Sie Referer. Wenn Sie irgendetwas anderes benennen, schreiben Sie referrer. Die Tabelle weiter unten zeigt, wo dieser Test gilt und wo ein Framework ihn verbiegt.

Woher kommt der Tippfehler in Referer?

Der Tippfehler gelangte mit RFC 1945 in die schriftliche Überlieferung, dem HTTP/1.0-Dokument von Tim Berners-Lee, Roy Fielding und Henrik Frystyk vom Mai 1996. Abschnitt 10.13 definiert das Feld ohne jeden Kommentar zur Schreibweise:

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

RFC 1945 war nie ein Standard. Sein Statusvermerk sagt: "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind." Das Dokument beschrieb HTTP so, wie Browser und Server es bereits betrieben, der Header-Name war also schon im Produktivverkehr, bevor ihn jemand aufschrieb. Ihn auf dem Papier zu korrigieren, hätte jeden Server gebrochen, der ihn bereits las.

Das erste Eingeständnis kam acht Monate später. RFC 2068, die erste HTTP/1.1-Spezifikation und die erste auf dem Standards Track, datiert auf Januar 1997, eröffnet Abschnitt 14.37 mit "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.)" RFC 2616 wiederholte diesen Satz im Juni 1999.

Die aktuelle Spezifikation behält den Tippfehler und das Geständnis. RFC 9110, HTTP Semantics, datiert auf Juni 2022 und veröffentlicht als Internet Standard 97, eröffnet Abschnitt 10.1.3 mit "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)." Sechsundzwanzig Jahre nach RFC 1945 annotieren die Herausgeber den Namen immer noch, statt ihn umzubenennen, weil eine Umbenennung genau den einen String ändern würde, nach dem jeder Server sucht.

Welche Namen nutzen welche Schreibweise?

Jeder Name, den die Webplattform nach dem Header hinzugefügt hat, nutzt die Wörterbuch-Schreibweise, und jeder serverseitige Name, der mechanisch aus dem Header gebaut wird, behält den Tippfehler.

Der Entwurf der W3C Referrer Policy benennt die Entscheidung in seinen eigenen Grammatikhinweisen: "The header name does not share the HTTP Referer header's misspelling." MDN sagt dasselbe auf seiner Seite zu Referrer-Policy: "The Referrer-Policy header does not share this misspelling."

Die serverseitigen Namen erben den Tippfehler über eine Benennungsregel, nicht über eine Entscheidung. Das PHP-Handbuch sagt, dass PHP $_SERVER-Einträge anlegt, die "named HTTP_ followed by the header name, capitalized and with underscores instead of hyphens," sind, der Header Referer kommt also als HTTP_REFERER an. Die Request-Referenz von Django beschreibt HTTP_REFERER als "The referring page, if any."

Express geht den anderen Weg und akzeptiert beide. Der Docblock zu req.get im Express-Quellcode lautet "The Referrer header field is special-cased, both Referrer and Referer are interchangeable," und der Code gibt this.headers.referrer || this.headers.referer zurück. Diese Reihenfolge bedeutet, dass ein Request mit einem Header, der wörtlich Referrer heißt, gegenüber dem Standard-Header gewinnt, was nur zählt, wenn ein Client den nicht standardkonformen Namen absichtlich sendet.

Verursacht der Tippfehler echte Bugs?

Der Tippfehler verursacht drei Bugs, die im Code-Review immer wieder auftauchen, und nur einer davon betrifft das fehlende r.

Header-Abfragen, die nichts zurückgeben. Code, der aus einer rohen Header-Map einen Header namens referrer liest, bekommt ein leeres Ergebnis, weil RFC 9110 nur Referer definiert und Browser genau diesen Namen senden. Express verdeckt das, indem es beide Namen prüft. PHP und Django stellen nur HTTP_REFERER bereit.

Der Versuch, den Header aus JavaScript zu setzen. MDN führt Referer als verbotenen Request-Header, ihn in den Headern von fetch() mitzugeben, ändert also nichts an dem, was der Browser sendet. Für diese Aufgabe gibt es die Option referrer auf RequestInit. MDN dokumentiert drei Arten von Werten: "A same-origin relative or absolute URL" setzt den Header, "An empty string" lässt ihn weg, und about:client nutzt den Standard für den Request-Kontext, der auch gilt, wenn die Option fehlt.

Der Bindestrich, nicht das r. MDN warnt: "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">." rel="noreferrer" und content="no-referrer" sind also beide richtig, und wer sie vertauscht, bewirkt stillschweigend nichts.

Was gibt document.referrer zurück?

document.referrer gibt die Adresse der Seite zurück, die auf die aktuelle Seite verlinkt hat, als String. MDN sagt: "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)." Das Beispiel von MDN macht das Kürzen sichtbar: Nach einem Klick von einem MDN-Artikel auf w3.org gibt die Property auf der neuen Seite "the previous domain like developer.mozilla.org" aus, nicht die volle Artikel-URL.

Dieses Kürzen kommt von der Referrer Policy, die auch den Header steuert. Der W3C-Entwurf sagt "The default referrer policy is "strict-origin-when-cross-origin"", und MDN beschreibt diese Policy so: "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)." Clientseitige Analytics-Skripte lesen document.referrer, Server-Logs lesen Referer. Unter der Standard-Policy sehen beide bei websiteübergreifenden Besuchen einen Hostnamen und bei einem Downgrade auf HTTP nichts. Wie aus diesem Hostnamen ein Kanal wird, erklärt was als Referral-Traffic zählt, und was passiert, wenn er leer ist, erklärt Direct Traffic.

Wo widersprechen sich die Spezifikationen?

Die Spezifikationen widersprechen sich an zwei Stellen, und beide beeinflussen, was ein Analytics-Tool sehen kann.

Die erste ist RFC 9110 gegen den Browser-Standard. RFC 9110 sagt: "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." Die W3C-Standard-Policy sendet genau bei diesem Request den Origin, von einer HTTPS-Seite zu einem anderen HTTPS-Origin, ohne ausdrückliche Erlaubnis der Seite. Beide Texte sind gültig. Browser folgen dem W3C-Standard, und deshalb zeigen Referral-Reports weiterhin Hostnamen. Beim Downgrade sind sich beide Dokumente einig, dort sagt RFC 9110, ein User Agent "MUST NOT send a Referer header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol."

Die zweite betrifft die Frage, welche Elemente noreferrer akzeptieren. Drei Quellen nennen drei Listen:

Der HTML Standard definiert die Linktypen, also ist seine Liste maßgeblich: "The noreferrer keyword may be used with a, area, and form elements." MDNs eigene Seite zu rel="noreferrer" stimmt mit dem HTML Standard überein, womit die MDN-Seite zu Referrer-Policy die Ausnahme bleibt.

Für Kampagnen-Traffic lohnt sich dieser Kampf nicht. Ein gekürzter oder fehlender Referrer lässt sich im Nachhinein nicht wiederherstellen, und ein UTM-Tag am Link transportiert die Quelle, egal was die Policy entfernt.

Häufig gestellte Fragen

Heißt es Referer oder Referrer in einem HTTP-Request?

Der Request-Header heißt Referer, die einzige Schreibweise, die RFC 9110 definiert, und die, die Browser senden. RFC 9110 markiert den Namen mit "[sic]" und erklärt, dass der Feldname falsch geschrieben ist. Servervariablen, die aus diesem Header gebildet werden, etwa HTTP_REFERER in PHP, behalten den Tippfehler. Später geprägte Namen nutzen Referrer, etwa der Response-Header Referrer-Policy.

Warum wurde der Tippfehler in Referer nie korrigiert?

Der Header war bereits im Produktivverkehr, als RFC 1945 ihn im Mai 1996 dokumentierte, und jeder Server liest ihn unter genau diesem Namen. RFC 2068 fügte im Januar 1997 ein "[sic]" hinzu, und jede HTTP-Spezifikation seitdem hat die Anmerkung beibehalten, statt das Feld umzubenennen.

Kann ich den Referer-Header mit fetch() setzen?

Nein, weil MDN Referer als verbotenen Request-Header führt, der Browser ignoriert ihn also im Objekt headers. Nutzen Sie stattdessen die Option referrer auf dem Request. Ein leerer String lässt den Header weg, eine URL mit demselben Origin setzt ihn.

Nutzt der Header Referrer-Policy die falsche Schreibweise?

Nein. Die Spezifikation W3C Referrer Policy stellt fest: "The header name does not share the HTTP Referer header's misspelling." Dasselbe gilt für das Attribut referrerpolicy, den Meta-Namen referrer und rel="noreferrer".

Warum ist document.referrer leer?

document.referrer ist leer, wenn der Besuch keine verweisende Seite hatte, etwa bei einem Lesezeichen oder einer eingetippten Adresse, und wenn eine Policy oder das Markup ihn unterdrückt hat. Ein Link mit rel="noreferrer", eine Policy no-referrer und eine HTTPS-Seite, die auf eine HTTP-Seite verlinkt, erzeugen unter den Standardregeln alle einen leeren Wert.

Warum nennt PHP ihn HTTP_REFERER?

PHP bildet $_SERVER-Schlüssel aus den Namen der Request-Header, indem es HTTP_ voranstellt, in Großbuchstaben umwandelt und Bindestriche durch Unterstriche ersetzt. Der Header heißt Referer, also lautet der Schlüssel HTTP_REFERER. Django folgt in request.META demselben Muster.

Welche Referrer-Policy gilt in Browsern standardmäßig?

Der W3C-Entwurf legt strict-origin-when-cross-origin als Standard fest. Bei Same-Origin-Anfragen sendet er Origin, Pfad und Query-String. Bei Cross-Origin-Anfragen sendet er nur die Origin, solange das Sicherheitsniveau des Protokolls gleich bleibt, und von HTTPS zu HTTP sendet er keinen Referer-Header.

Was ist der Unterschied zwischen rel="noreferrer" und no-referrer?

rel="noreferrer" ist eine Link-Relation und wird ohne Bindestrich geschrieben. no-referrer ist ein Policy-Wert, daher lautet die dokumentweite Form <meta name="referrer" content="no-referrer"> mit Bindestrich. Vertauscht man beide, passiert stillschweigend nichts.

Akzeptiert Express sowohl Referer als auch Referrer?

Express akzeptiert beide. Der Docblock von req.get nennt die beiden Namen austauschbar, und der Code gibt this.headers.referrer || this.headers.referer zurück. Ein Header, der wörtlich Referrer heißt, gewinnt gegen den Standard-Header.

Welche RFC hat den Referer-Header zuerst definiert?

RFC 1945, das HTTP/1.0-Dokument vom Mai 1996, definiert ihn in Abschnitt 10.13 und sagt nichts zur Schreibweise. RFC 2068 ergänzte das [sic] im Januar 1997. RFC 9110 trägt es im Juni 2022 immer noch.