A regra de grafia por trás de Referer vs Referrer

Qual grafia está correta, referer ou referrer?

A resposta curta para referer vs referrer é que as duas grafias estão corretas, cada uma no seu lugar: o header de requisição HTTP é Referer, com um único r no meio, e quase todo nome criado depois dele, incluindo document.referrer, o header Referrer-Policy e o atributo referrerpolicy, usa a grafia do dicionário. A forma errada é o nome do header que trafega pela rede. A forma correta é o que os desenvolvedores digitam em HTML, JavaScript e headers de resposta.

Um teste resolve a maioria dos casos. Se você está lendo ou escrevendo o header de requisição bruto, ou uma variável de servidor construída a partir dele, escreva Referer. Se está dando nome a qualquer outra coisa, escreva referrer. A tabela mais abaixo mostra onde esse teste vale e onde um framework o contorna.

De onde veio o erro de grafia do Referer?

O erro de grafia entrou no registro escrito com a RFC 1945, o documento do HTTP/1.0 de Tim Berners-Lee, Roy Fielding e Henrik Frystyk, datado de maio de 1996. A seção 10.13 define o campo sem nenhum comentário sobre a grafia:

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

A RFC 1945 nunca foi um padrão. A nota de status dela diz "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind." O documento descrevia o HTTP como navegadores e servidores já o usavam, então o nome do header já estava no tráfego de produção antes de alguém escrevê-lo. Corrigi-lo no papel teria quebrado todos os servidores que já o liam.

A primeira admissão veio oito meses depois. A RFC 2068, a primeira especificação do HTTP/1.1 e a primeira no standards track, datada de janeiro de 1997, abre a seção 14.37 com "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.)" A RFC 2616 repetiu essa frase em junho de 1999.

A especificação atual mantém o erro e a confissão. A RFC 9110, HTTP Semantics, datada de junho de 2022 e publicada como Internet Standard 97, abre a seção 10.1.3 com "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)." Vinte e seis anos depois da RFC 1945, os editores ainda anotam o nome em vez de renomeá-lo, porque renomear mudaria a única string que todo servidor procura.

Quais nomes usam qual grafia?

Todo nome que a plataforma web adicionou depois do header usa a grafia do dicionário, e todo nome do lado do servidor construído mecanicamente a partir do header mantém o erro.

O rascunho do W3C Referrer Policy registra a escolha nas próprias notas de gramática: "The header name does not share the HTTP Referer header's misspelling." A MDN diz o mesmo na página do Referrer-Policy: "The Referrer-Policy header does not share this misspelling."

Os nomes do lado do servidor herdam o erro por uma regra de nomenclatura, não por uma decisão. O manual do PHP diz que o PHP cria entradas em $_SERVER "named HTTP_ followed by the header name, capitalized and with underscores instead of hyphens", então o header Referer chega como HTTP_REFERER. A referência de requisições do Django descreve HTTP_REFERER como "The referring page, if any."

O Express vai pelo caminho oposto e aceita os dois. O docblock de req.get no código-fonte do Express diz "The Referrer header field is special-cased, both Referrer and Referer are interchangeable", e o código retorna this.headers.referrer || this.headers.referer. Essa ordem significa que uma requisição com um header literalmente chamado Referrer vence o padrão, o que só importa se um cliente enviar o nome fora do padrão de propósito.

O erro de grafia causa bugs reais?

O erro de grafia causa três bugs que aparecem sem parar em code review, e só um deles tem a ver com o r que falta.

Leituras de header que não retornam nada. Um código que lê um header chamado referrer de um mapa de headers bruto recebe um resultado vazio, porque a RFC 9110 define apenas Referer, e esse é o nome que os navegadores enviam. O Express esconde isso verificando os dois nomes. O PHP e o Django expõem apenas HTTP_REFERER.

Tentar definir o header pelo JavaScript. A MDN lista Referer como um forbidden request header, então passá-lo dentro dos headers do fetch() não muda o que o navegador envia. A opção referrer do RequestInit existe para esse trabalho. A MDN documenta três tipos de valor: "A same-origin relative or absolute URL" define o header, "An empty string" o omite, e about:client usa o padrão do contexto da requisição, que é o comportamento quando a opção não é passada.

O hífen, não o r. A MDN avisa 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">." Então rel="noreferrer" e content="no-referrer" estão os dois certos, e trocar um pelo outro silenciosamente não faz nada.

O que document.referrer retorna?

document.referrer retorna o endereço da página que levou até a atual, como uma string. A MDN diz "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)." O exemplo da MDN deixa o corte visível: depois de um clique de um artigo da MDN para o w3.org, a propriedade na nova página exibe "the previous domain like developer.mozilla.org", e não a URL completa do artigo.

Esse corte vem da referrer policy, que também governa o header. O rascunho do W3C diz "The default referrer policy is "strict-origin-when-cross-origin"", e a MDN descreve essa política assim: "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)." Os scripts de analytics do lado do cliente leem document.referrer, e os logs de servidor leem Referer. Com a política padrão, os dois veem um hostname nas visitas entre sites diferentes e nada quando há rebaixamento para HTTP. Como esse hostname vira um canal está em o que conta como tráfego de referência, e o que acontece quando ele está vazio está em tráfego direto.

Onde as especificações discordam?

As especificações discordam em dois pontos, e os dois afetam o que uma ferramenta de analytics consegue ver.

O primeiro é a RFC 9110 contra o padrão dos navegadores. A RFC 9110 diz "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." A política padrão do W3C envia a origem exatamente nessa requisição, de uma página HTTPS para uma origem HTTPS diferente, sem permissão explícita da página. Os dois textos estão em vigor. Os navegadores seguem o padrão do W3C, e é por isso que os relatórios de referência ainda mostram hostnames. Os dois documentos concordam no caso do rebaixamento, em que a RFC 9110 diz que um user agent "MUST NOT send a Referer header field in an unsecured HTTP request if the referring resource was accessed with a secure protocol."

O segundo é quais elementos aceitam noreferrer. Três fontes dão três listas:

O HTML Standard define os tipos de link, então a lista dele é a que vale: "The noreferrer keyword may be used with a, area, and form elements." A própria página rel="noreferrer" da MDN concorda com o HTML Standard, o que deixa a página Referrer-Policy como a exceção.

Para tráfego de campanha, nada disso vale a briga. Um referrer cortado ou ausente não pode ser recuperado depois, e uma tag UTM no link carrega a origem, seja lá o que a política remover.

Perguntas frequentes

É Referer ou Referrer em uma requisição HTTP?

O header de requisição é Referer, a única grafia que a RFC 9110 define e a que os navegadores enviam. A RFC 9110 marca o nome com "[sic]" e explica que o nome do campo está escrito errado. As variáveis de servidor construídas a partir desse header, como o HTTP_REFERER do PHP, mantêm o erro. Os nomes criados depois usam Referrer, como o header de resposta Referrer-Policy.

Por que o erro de grafia do Referer nunca foi corrigido?

O header já estava no tráfego de produção quando a RFC 1945 o documentou, em maio de 1996, e todo servidor o lê por esse nome exato. A RFC 2068 acrescentou um "[sic]" em janeiro de 1997, e toda especificação HTTP desde então manteve a anotação em vez de renomear o campo.

Posso definir o header Referer com fetch()?

Não, porque a MDN lista Referer como um forbidden request header, e o navegador o ignora no objeto headers. Use a opção referrer da requisição. Uma string vazia omite o header, e uma URL de mesma origem o define.

O header Referrer-Policy usa o erro de grafia?

Não. A especificação W3C Referrer Policy afirma que "The header name does not share the HTTP Referer header's misspelling." O mesmo vale para o atributo referrerpolicy, o meta name referrer e rel="noreferrer".

Por que document.referrer está vazio?

document.referrer fica vazio quando a visita não teve página de origem, como um favorito ou um endereço digitado, e quando uma política ou a marcação o suprimiu. Um link com rel="noreferrer", uma política no-referrer e uma página HTTPS com link para uma página HTTP produzem, todos, um valor vazio pelas regras padrão.

Por que o PHP chama de HTTP_REFERER?

O PHP monta as chaves de $_SERVER a partir dos nomes dos headers de requisição colocando o prefixo HTTP_, passando tudo para maiúsculas e trocando hífens por underscores. O header é Referer, então a chave é HTTP_REFERER. O Django segue o mesmo padrão em request.META.

Qual é a política de referrer padrão nos navegadores?

O rascunho do W3C define strict-origin-when-cross-origin como padrão. Em requisições de mesma origem, ela envia a origem, o caminho e a query string. Em requisições entre origens, envia só a origem enquanto o nível de segurança do protocolo continua o mesmo, e de HTTPS para HTTP não envia o header Referer.

Qual é a diferença entre rel="noreferrer" e no-referrer?

rel="noreferrer" é uma relação de link e se escreve sem hífen. no-referrer é um valor de política, então a forma para o documento inteiro é <meta name="referrer" content="no-referrer">, com hífen. Se você trocar um pelo outro, nada acontece e nada avisa.

O Express aceita Referer e Referrer?

O Express aceita os dois. O docblock de req.get chama os nomes de intercambiáveis, e o código retorna this.headers.referrer || this.headers.referer. Um header chamado literalmente Referrer vence o header padrão.

Qual RFC definiu primeiro o header Referer?

A RFC 1945, o documento do HTTP/1.0 de maio de 1996, o define na seção 10.13 e não diz nada sobre a grafia. A RFC 2068 acrescentou o [sic] em janeiro de 1997. A RFC 9110 ainda o mantém em junho de 2022.