La regola di ortografia dietro Referer e Referrer

Qual è l'ortografia corretta, referer o referrer?

La risposta breve su referer vs referrer è che entrambe le grafie sono corrette, ciascuna al suo posto. L'header della richiesta HTTP è Referer, con una sola r in mezzo. Quasi tutti i nomi coniati dopo, tra cui document.referrer, l'header Referrer-Policy e l'attributo referrerpolicy, usano la grafia del dizionario. La forma sbagliata è il nome dell'header che viaggia in rete. La forma corretta è quella che digiti in HTML, JavaScript e negli header di risposta.

Un solo test copre la maggior parte dei casi. Se stai leggendo o scrivendo l'header grezzo della richiesta, o una variabile del server ricavata da esso, scrivi Referer. Se stai dando un nome a qualsiasi altra cosa, scrivi referrer. La tabella più sotto elenca dove il test funziona e dove un framework lo piega.

Da dove arriva l'errore di ortografia di Referer?

L'errore è entrato nei documenti ufficiali con la RFC 1945, il documento HTTP/1.0 di Tim Berners-Lee, Roy Fielding e Henrik Frystyk, datato maggio 1996. La sezione 10.13 definisce il campo senza alcun commento sulla grafia:

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

La RFC 1945 non è mai stata uno standard. La sua nota di stato dice "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind." Il documento descriveva HTTP così come browser e server già lo usavano, quindi il nome dell'header circolava nel traffico reale prima che qualcuno lo mettesse per iscritto. Correggerlo sulla carta avrebbe rotto ogni server che lo leggeva già.

La prima ammissione è arrivata otto mesi dopo. La RFC 2068, la prima specifica HTTP/1.1 e la prima nel percorso degli standard, datata gennaio 1997, apre la sezione 14.37 con "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 ha ripetuto la stessa frase a giugno 1999.

La specifica attuale mantiene sia l'errore sia la confessione. La RFC 9110, HTTP Semantics, datata giugno 2022 e pubblicata come Internet Standard 97, apre la sezione 10.1.3 con "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)." A ventisei anni dalla RFC 1945, i curatori annotano ancora il nome invece di rinominarlo, perché una modifica cambierebbe l'unica stringa che ogni server cerca.

Quali nomi usano quale grafia?

Ogni nome che la piattaforma web ha aggiunto dopo l'header usa la grafia del dizionario, e ogni nome lato server costruito in modo meccanico a partire dall'header conserva l'errore.

La bozza W3C Referrer Policy esprime la scelta nelle sue note sulla grammatica: "The header name does not share the HTTP Referer header's misspelling." MDN dice la stessa cosa nella pagina di Referrer-Policy: "The Referrer-Policy header does not share this misspelling."

I nomi lato server ereditano l'errore da una regola di denominazione, non da una decisione. Il manuale PHP dice che PHP crea le voci di $_SERVER "named HTTP_ followed by the header name, capitalized and with underscores instead of hyphens", quindi l'header Referer arriva come HTTP_REFERER. Il riferimento di Django sulla richiesta descrive HTTP_REFERER come "The referring page, if any."

Express va nella direzione opposta e accetta entrambi. Il docblock di req.get nel codice sorgente di Express recita "The Referrer header field is special-cased, both Referrer and Referer are interchangeable", e il codice restituisce this.headers.referrer || this.headers.referer. Quell'ordine significa che una richiesta con un header chiamato letteralmente Referrer prevale su quello standard, cosa che conta solo se un client invia di proposito il nome non standard.

L'errore di ortografia causa bug reali?

L'errore di ortografia causa tre bug che ricorrono continuamente nelle code review, e solo uno riguarda la r mancante.

Ricerche di header che non restituiscono nulla. Il codice che legge un header chiamato referrer da una mappa di header grezzi ottiene un risultato vuoto, perché la RFC 9110 definisce solo Referer ed è il nome che i browser inviano. Express lo nasconde controllando entrambi i nomi. PHP e Django espongono solo HTTP_REFERER.

Provare a impostare l'header da JavaScript. MDN elenca Referer tra gli header di richiesta vietati, quindi passarlo dentro gli header di fetch() non cambia ciò che il browser invia. Per questo scopo esiste l'opzione referrer di RequestInit. MDN documenta tre tipi di valore. "A same-origin relative or absolute URL" imposta l'header, "An empty string" lo omette, e about:client usa il valore predefinito per il contesto della richiesta, che è anche il comportamento quando l'opzione è assente.

Il trattino, non la r. MDN avverte che "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">." Quindi rel="noreferrer" e content="no-referrer" sono entrambi giusti, e scambiarli non produce alcun effetto, senza nessun errore.

Cosa restituisce document.referrer?

document.referrer restituisce come stringa l'indirizzo della pagina che ha linkato quella corrente. MDN scrive: "Il valore è una stringa vuota se l'utente è arrivato alla pagina direttamente (non tramite un link, ma, per esempio, da un segnalibro)." L'esempio di MDN mostra bene il taglio: dopo un clic da un articolo di MDN verso w3.org, la proprietà nella nuova pagina restituisce "il dominio precedente, come developer.mozilla.org", non l'URL completo dell'articolo.

Quel taglio dipende dalla referrer policy, che governa anche l'header. La bozza del W3C dice "La referrer policy predefinita è "strict-origin-when-cross-origin"", e MDN descrive così quella policy: "Invia origin, percorso e query string nelle richieste same-origin. Nelle richieste cross-origin invia solo l'origin finché il livello di sicurezza del protocollo resta lo stesso (HTTPS→HTTPS). Non invia l'header Referer verso destinazioni meno sicure (HTTPS→HTTP)." Gli script di analytics lato client leggono document.referrer, mentre i log del server leggono Referer. Con la policy predefinita, entrambi vedono un hostname per le visite da altri siti e niente quando si scende a HTTP. Come quell'hostname diventa un canale lo spieghiamo in cosa conta come traffico di riferimento, mentre cosa succede quando è vuoto lo trovi in traffico diretto.

Dove le specifiche non concordano?

Le specifiche non concordano in due punti, e tutti e due incidono su ciò che uno strumento di analytics può vedere.

Il primo è RFC 9110 contro il comportamento predefinito dei browser. RFC 9110 dice: "Uno user agent NON DOVREBBE inviare un campo header Referer se la risorsa di provenienza è stata raggiunta con un protocollo sicuro e la destinazione della richiesta ha un'origin diversa da quella della risorsa di provenienza, a meno che la risorsa di provenienza non consenta esplicitamente l'invio di Referer." La policy predefinita del W3C invia l'origin proprio in quella richiesta, da una pagina HTTPS a un'altra origin HTTPS, senza alcun permesso esplicito della pagina. Entrambi i testi sono in vigore. I browser seguono il default del W3C, ed è per questo che i report sul traffico di riferimento mostrano ancora gli hostname. I due documenti concordano sul caso del downgrade, dove RFC 9110 dice che uno user agent "NON DEVE inviare un campo header Referer in una richiesta HTTP non protetta se la risorsa di provenienza è stata raggiunta con un protocollo sicuro."

Il secondo punto riguarda quali elementi accettano noreferrer. Tre fonti danno tre elenchi:

L'HTML Standard definisce i link type, quindi vale il suo elenco: "La parola chiave noreferrer può essere usata con gli elementi a, area e form." La pagina di MDN su rel="noreferrer" concorda con l'HTML Standard, il che lascia la sua pagina Referrer-Policy come unica voce fuori linea.

Per il traffico delle campagne non vale la pena combattere questa battaglia. Un referrer tagliato o assente non si recupera a posteriori, mentre un tag UTM sul link porta con sé la fonte qualunque cosa la policy rimuova.

Domande frequenti

Si scrive Referer o Referrer in una richiesta HTTP?

L'header della richiesta è Referer, l'unica grafia definita da RFC 9110 e quella che inviano i browser. RFC 9110 segna il nome con "[sic]" e spiega che il nome del campo è scritto male. Le variabili del server costruite da quell'header, come HTTP_REFERER in PHP, mantengono l'errore. I nomi coniati più tardi usano Referrer, per esempio l'header di risposta Referrer-Policy.

Perché l'errore di battitura in Referer non è mai stato corretto?

L'header era già nel traffico di produzione quando RFC 1945 lo documentò nel maggio 1996, e ogni server lo legge con quel nome esatto. RFC 2068 ha aggiunto un "[sic]" nel gennaio 1997, e da allora ogni specifica HTTP ha mantenuto l'annotazione invece di rinominare il campo.

Posso impostare l'header Referer con fetch()?

No, perché MDN elenca Referer tra gli header di richiesta vietati, quindi il browser lo ignora nell'oggetto headers. Usa invece l'opzione referrer della richiesta. Una stringa vuota omette l'header, mentre un URL same-origin lo imposta.

L'header Referrer-Policy usa la grafia sbagliata?

No. La specifica W3C Referrer Policy afferma che "Il nome dell'header non condivide l'errore di ortografia dell'header HTTP Referer." Lo stesso vale per l'attributo referrerpolicy, per il nome meta referrer e per rel="noreferrer".

Perché document.referrer è vuoto?

document.referrer è vuoto quando la visita non aveva una pagina di provenienza, come un segnalibro o un indirizzo digitato, e quando una policy o il markup lo hanno soppresso. Un link con rel="noreferrer", una policy no-referrer e una pagina HTTPS che linka una pagina HTTP producono tutti un valore vuoto con le regole predefinite.

Perché PHP lo chiama HTTP_REFERER?

PHP costruisce le chiavi di $_SERVER dai nomi degli header della richiesta anteponendo HTTP_, mettendo tutto in maiuscolo e sostituendo i trattini con trattini bassi. L'header è Referer, quindi la chiave è HTTP_REFERER. Django segue lo stesso schema in request.META.

Qual è la referrer policy predefinita nei browser?

La bozza del W3C imposta come default strict-origin-when-cross-origin. Nelle richieste same-origin invia origin, percorso e query string. Nelle richieste cross-origin invia solo l'origin finché il livello di sicurezza del protocollo resta invariato, e non invia alcun header Referer da HTTPS a HTTP.

Che differenza c'è tra rel="noreferrer" e no-referrer?

rel="noreferrer" è una relazione di link e si scrive senza trattino. no-referrer è un valore di policy, quindi la forma valida per l'intero documento è <meta name="referrer" content="no-referrer">, con il trattino. Se li scambi, non succede niente e nessun errore te lo segnala.

Express accetta sia Referer sia Referrer?

Express li accetta entrambi. Il docblock di req.get definisce i due nomi intercambiabili, e il codice restituisce this.headers.referrer || this.headers.referer. Un header chiamato letteralmente Referrer ha la precedenza su quello standard.

Quale RFC ha definito per prima l'header Referer?

RFC 1945, il documento HTTP/1.0 del maggio 1996, lo definisce nella sezione 10.13 e non dice nulla sulla grafia. RFC 2068 ha aggiunto il [sic] nel gennaio 1997. RFC 9110 lo riporta ancora nel giugno 2022.