Resumo
- O RFC 1945, de maio de 1996, descreveu
Referercomo um campo que podia levar ao servidor de destino a URI da página onde estava o link. Listas de ligações de volta, registros e conserto de endereços eram usos expressos; o mesmo trecho advertia que a origem poderia ser privada. - O RFC 2068, de janeiro de 1997, manteve o mecanismo e reconheceu a grafia errada de
Referer. Um endereço digitado não tinha página de origem a declarar, e o fragmento da URI não podia acompanhar o campo. A seção de segurança tratava da exposição de uma URI privada. - A Recomendação Candidata do W3C de 26 de janeiro de 2017 descreveu políticas para transmitir a URL completa, somente a origem do site ou nenhum dado de referência. Ela é uma especificação datada, não um levantamento de quais navegadores já a haviam instalado.
Um recibo para o servidor que recebia a visita
O RFC 1945, texto original de HTTP/1.0 publicado em maio de 1996, oferecia ao destino uma pista sobre o trajeto do visitante. Ao seguir um link, o navegador podia inserir na requisição o campo Referer com a URI da página de onde saíra. O servidor usaria essa informação para listar páginas que apontavam para seus documentos, manter registros, otimizar certas operações de cache ou encontrar ligações antigas e mal digitadas. O texto especificava essas funções sem mistério.
Pense numa biblioteca digital que muda um arquivo de endereço. Outros sites continuam enviando leitores pela ligação antiga. Com a página de partida indicada na requisição, o responsável pela biblioteca pode localizar quem precisa atualizar o link. Ele não administra o site alheio, mas recebe uma amostra do mapa de ligações do próprio público. O Referer era uma espécie de índice invertido escrito pelas visitas.
O campo nasceu com limites. Se alguém digitasse diretamente a URL, não existia documento com URI de onde ela tivesse sido obtida; nesse caso, o RFC mandava não enviar Referer. Também excluía o fragmento da URI. Chegar por um clique e chegar pelo teclado eram eventos diferentes. O servidor não tinha licença para inventar uma página anterior.
No mesmo trecho estava a conta da conveniência. A página de origem podia ser informação privada ou revelar a localização de uma fonte privada. Os autores recomendavam fortemente dar ao usuário a escolha de enviar o campo e imaginavam uma chave entre navegação aberta e anônima. A utilidade para quem recebe e o risco para quem sai já dividiam o parágrafo em 1996. O problema da privacidade não precisou esperar uma década para ser formulado.
O erro no nome continuou em serviço
O RFC 2068, especificação de HTTP/1.1 publicada em janeiro de 1997, chamou a atenção para a grafia: Referer é um erro diante de “referrer”. O nome transmitido na rede permaneceu. O destino continuava podendo construir listas de links de volta, registrar visitas e rastrear endereços equivocados. A proibição de enviar uma origem fictícia para URLs digitadas e a retirada do fragmento também seguiram.
É uma gralha que vale uma piada, mas a decisão pesada está em outro lugar. Uma requisição destinada a um servidor leva o endereço de uma página que pode pertencer a outra instituição. O operador do destino tem um interesse claro no dado; seu conserto de links não exige sempre a identificação de um perfil ou de um documento interno do site que enviou o leitor. Saber o nome do site e saber a página exata que a pessoa acabou de deixar são informações de profundidades diferentes.
Na parte de segurança, o RFC 2068 explicava que o campo permitia estudar padrões de leitura e desenhar links reversos. Mesmo após separar dados pessoais explícitos, a URI ainda poderia apontar para um documento privado. O caminho de uma conta, o nome de um processo ou um parâmetro de sessão podem contar muito por si sós. A exposição viaja no cabeçalho da requisição, sem precisar aparecer no texto visível do link.
Os dois RFCs definem um mecanismo e seus cuidados. Eles não fornecem um censo de navegadores da época nem dizem quantas URLs completas foram enviadas. A tensão documentada é suficiente: a manutenção do destino ganha precisão quando recebe o endereço de partida; a página de origem e o leitor podem perder privacidade por essa mesma precisão.
Entre o domínio e a porta de um quarto
Uma URL inteira não se resume ao domínio. O caminho pode apontar para um perfil, um espaço de trabalho ou um documento reservado. A consulta pode conter um identificador de sessão. Se o navegador põe essa URL em Referer, o servidor de chegada aprende não apenas de qual site veio a visita, mas de qual parte específica do site ela partiu. A pessoa clicou para abrir a página seguinte; não redigiu uma carta explicando a anterior.
O destinatário pode guardar o campo em seus logs. O autor da página de origem conhece melhor o significado de seus próprios caminhos e sabe se eles revelam usuários ou recursos internos. O interruptor sugerido em 1996 entregava uma decisão geral à pessoa que navega. Uma regra da própria página permite ajustar a saída ao tipo de documento e ao risco daquela URL.
Há três resultados materiais. Uma URL completa ajuda a identificar o link exato que precisa ser reparado. O envio só da origem — esquema, host e porta — permite atribuir a visita ao site, preservando o caminho individual e a consulta. A ausência total de referência guarda até o nome do site. A riqueza do recibo que o destino recebe cresce junto com a quantidade de informação cedida pela fonte.
Uma regra escrita do lado de quem sai
A Recomendação Candidata do W3C «Referrer Policy», de 26 de janeiro de 2017, abre com uma situação concreta. Uma página de perfil em uma rede social aponta para o site de uma banda. O site da banda pode querer saber que a rede lhe enviou visitantes sem receber a URL completa que identifica a pessoa dona do perfil. O documento apresenta também a URL com identificador de sessão ou com uma capacidade de acesso. Nesse caso, o endereço funciona quase como uma credencial.
O texto define graus de divulgação. no-referrer omite o campo. same-origin transmite a URL completa dentro da mesma origem e nada para outra. origin envia o esquema, o host e a porta, sem o caminho e a consulta; strict-origin acrescenta uma restrição para a saída de um contexto protegido em direção a um destino menos confiável. Outras opções combinam tratamentos para requisições internas e externas. A decisão passou a perguntar qual parte da URL seria enviada e para quem.
O autor podia comunicar a regra no cabeçalho de resposta Referrer-Policy, em um elemento meta, em atributos de determinados elementos ou pela relação noreferrer de um link. O nome da política traz a grafia correta. O velho campo da requisição que ela controla continua com a grafia Referer. A nova instrução corrigiu o inglês; a palavra já usada na rede conservou a marca do início.
O texto de 2017 era uma Recomendação Candidata naquela data. Descreve o comportamento esperado sob cada escolha. Para datar a chegada dessas opções a cada navegador seriam necessários registros de implementação com versões e datas. A mudança de desenho aparece no próprio documento: a página que conhece o risco de sua URL ganhou um instrumento para graduar o que o navegador leva embora.
O backlink também custa informação
O servidor de destino realmente se beneficia da procedência. Pode corrigir citações, saber como leitores chegam a um documento e detectar endereços quebrados. O RFC de 1996 registrou a vantagem e o perigo no mesmo lugar. Se a procedência aponta para uma página reservada, o recibo de manutenção é também uma cópia do endereço privado entregue a outro operador.
A política posterior desloca a decisão para a fonte. Ela pode informar seu domínio sem divulgar a página de perfil, ou optar pelo silêncio. O destino perde precisão em sua lista de links entrantes. Essa perda é o preço específico de guardar a parte sensível do caminho. A necessidade de manter uma página não dá a seu administrador a propriedade do endereço exato que cada visitante acabou de deixar.
A letra ausente em Referer permanece memorável. A distinção mais importante separa duas perguntas: de qual site veio a visita e de qual página concreta a pessoa saiu. Um backlink útil muda de natureza quando sua resposta revela uma sala privada.
Fontes
- RFC 1945, HTTP/1.0, maio de 1996: definição de
Referer, funções de manutenção e advertência sobre o endereço privado. - RFC 2068, HTTP/1.1, janeiro de 1997: grafia reconhecida como erro, uso contínuo do campo e risco de revelar uma URI privada.
- W3C, Recomendação Candidata «Referrer Policy», 26 de janeiro de 2017: opções de URL completa, origem do site ou nenhum dado de referência.
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Exclusivo para o Círculo Estratégico
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance





