La regla ortográfica detrás de referer vs referrer

¿Qué ortografía es la correcta, referer o referrer?

La respuesta corta a referer vs referrer es que las dos ortografías son correctas, cada una en su sitio: la cabecera de petición HTTP es Referer, con una sola r en medio, y casi todos los nombres acuñados después de ella, incluidos document.referrer, la cabecera Referrer-Policy y el atributo referrerpolicy, usan la ortografía del diccionario. La forma con errata es el nombre de la cabecera que viaja por la red. La forma correcta es la que los desarrolladores escriben en HTML, JavaScript y cabeceras de respuesta.

Una sola prueba cubre la mayoría de los casos. Si estás leyendo o escribiendo la cabecera de petición en bruto, o una variable de servidor construida a partir de ella, escribe Referer. Si estás nombrando cualquier otra cosa, escribe referrer. La tabla de más abajo indica dónde se cumple esa prueba y dónde un framework la tuerce.

¿De dónde salió la errata de Referer?

La errata entró en el registro escrito con el RFC 1945, el documento de HTTP/1.0 de Tim Berners-Lee, Roy Fielding y Henrik Frystyk, fechado en mayo de 1996. La sección 10.13 define el campo sin ningún comentario sobre su ortografía:

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

El RFC 1945 nunca fue un estándar. Su nota de estado dice "This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind." El documento describía HTTP tal como ya lo ejecutaban navegadores y servidores, así que el nombre de la cabecera circulaba en tráfico de producción antes de que nadie lo pusiera por escrito. Corregirlo sobre el papel habría roto todos los servidores que ya lo leían.

La primera admisión llegó ocho meses después. El RFC 2068, la primera especificación de HTTP/1.1 y la primera en la vía de estándares, fechado en enero de 1997, abre la sección 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.)" El RFC 2616 repitió esa frase en junio de 1999.

La especificación actual mantiene la errata y la confesión. El RFC 9110, HTTP Semantics, fechado en junio de 2022 y publicado como Internet Standard 97, abre la sección 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)." Veintiséis años después del RFC 1945, los editores siguen anotando el nombre en lugar de cambiarlo, porque un cambio de nombre alteraría la única cadena que busca cada servidor.

¿Qué nombres usan cada ortografía?

Todos los nombres que la plataforma web añadió después de la cabecera usan la ortografía del diccionario, y todos los nombres de servidor construidos de forma mecánica a partir de la cabecera conservan la errata.

El borrador W3C Referrer Policy deja clara la elección en sus propias notas de gramática: "The header name does not share the HTTP Referer header's misspelling." MDN dice lo mismo en su página de Referrer-Policy: "The Referrer-Policy header does not share this misspelling."

Los nombres del lado del servidor heredan la errata por una regla de nombres, no por una decisión. El manual de PHP dice que PHP crea entradas de $_SERVER "named HTTP_ followed by the header name, capitalized and with underscores instead of hyphens," así que la cabecera Referer llega como HTTP_REFERER. La referencia de request de Django describe HTTP_REFERER como "The referring page, if any."

Express va en la dirección contraria y acepta las dos. El docblock de req.get en el código fuente de Express dice "The Referrer header field is special-cased, both Referrer and Referer are interchangeable," y el código devuelve this.headers.referrer || this.headers.referer. Ese orden significa que una petición con una cabecera llamada literalmente Referrer gana a la estándar, lo que solo importa si un cliente envía a propósito el nombre no estándar.

¿La errata causa bugs reales?

La errata causa tres bugs que aparecen una y otra vez en las revisiones de código, y solo uno de ellos tiene que ver con la r que falta.

Búsquedas de cabecera que no devuelven nada. El código que lee una cabecera llamada referrer de un mapa de cabeceras en bruto obtiene un resultado vacío, porque el RFC 9110 solo define Referer y ese es el nombre que envían los navegadores. Express lo oculta comprobando los dos nombres. PHP y Django solo exponen HTTP_REFERER.

Intentar fijar la cabecera desde JavaScript. MDN incluye Referer entre las cabeceras de petición prohibidas, así que pasarla dentro de las cabeceras de fetch() no cambia lo que envía el navegador. Para eso existe la opción referrer de RequestInit. MDN documenta tres tipos de valor: "A same-origin relative or absolute URL" fija la cabecera, "An empty string" la omite, y about:client usa el valor por defecto del contexto de la petición, que es lo que se aplica cuando la opción no está.

El guion, no la r. MDN avisa de 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">." Así que rel="noreferrer" y content="no-referrer" son los dos correctos, e intercambiarlos no hace nada sin avisar.

¿Qué devuelve document.referrer?

document.referrer devuelve la dirección de la página que enlazó a la actual, como cadena de texto. MDN dice "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)." El ejemplo de MDN hace visible el recorte: tras un clic desde un artículo de MDN a w3.org, la propiedad en la página nueva devuelve "the previous domain like developer.mozilla.org", no la URL completa del artículo.

Ese recorte viene de la política de referrer, que también rige la cabecera. El borrador del W3C dice "The default referrer policy is "strict-origin-when-cross-origin"", y MDN describe esa política así: "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)." Los scripts de analítica del lado del cliente leen document.referrer, y los logs del servidor leen Referer. Con la política por defecto, los dos ven un nombre de host en las visitas entre sitios y nada cuando se baja a HTTP. Cómo ese nombre de host se convierte en un canal se explica en qué cuenta como tráfico de referencia, y qué pasa cuando está vacío se explica en tráfico directo.

¿En qué discrepan las especificaciones?

Las especificaciones discrepan en dos puntos, y los dos afectan a lo que puede ver una herramienta de analítica.

El primero enfrenta al RFC 9110 con el comportamiento por defecto de los navegadores. El RFC 9110 dice "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 política por defecto del W3C envía el origen justo en esa petición, de una página HTTPS a otro origen HTTPS, sin permiso explícito de la página. Los dos textos están vigentes. Los navegadores siguen el valor por defecto del W3C, y por eso los informes de referencia siguen mostrando nombres de host. Los dos documentos coinciden en el caso de la bajada a HTTP, en el que el RFC 9110 dice que 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."

El segundo es qué elementos aceptan noreferrer. Tres fuentes dan tres listas:

El HTML Standard define los tipos de enlace, así que su lista es la que manda: "The noreferrer keyword may be used with a, area, and form elements." La propia página de MDN sobre rel="noreferrer" coincide con el HTML Standard, lo que deja a su página de Referrer-Policy como la excepción.

Para el tráfico de campañas, no merece la pena pelearse con nada de esto. Un referrer recortado o ausente no se puede recuperar después, y una etiqueta UTM en el enlace lleva la fuente pase lo que pase con lo que elimine la política.

Preguntas frecuentes

¿En una petición HTTP es Referer o Referrer?

La cabecera de petición es Referer, la única ortografía que define el RFC 9110 y la que envían los navegadores. El RFC 9110 marca el nombre con "[sic]" y explica que el nombre del campo tiene una errata. Las variables de servidor construidas a partir de esa cabecera, como HTTP_REFERER en PHP, conservan la errata. Los nombres acuñados después usan Referrer, como la cabecera de respuesta Referrer-Policy.

¿Por qué nunca se corrigió la errata de Referer?

La cabecera ya circulaba en tráfico de producción cuando el RFC 1945 la documentó en mayo de 1996, y todos los servidores la leen con ese nombre exacto. El RFC 2068 añadió un "[sic]" en enero de 1997, y todas las especificaciones de HTTP desde entonces han mantenido la anotación en lugar de cambiar el nombre del campo.

¿Puedo fijar la cabecera Referer con fetch()?

No, porque MDN incluye Referer entre las cabeceras de petición prohibidas, así que el navegador la ignora en el objeto headers. Usa en su lugar la opción referrer de la petición. Una cadena vacía omite la cabecera, y una URL del mismo origen la fija.

¿La cabecera Referrer-Policy usa la errata?

No. La especificación W3C Referrer Policy afirma que "The header name does not share the HTTP Referer header's misspelling." Lo mismo vale para el atributo referrerpolicy, el nombre de meta referrer y rel="noreferrer".

¿Por qué document.referrer está vacío?

document.referrer está vacío cuando la visita no tuvo página de referencia, como un marcador o una dirección escrita a mano, y cuando una política o el marcado lo suprimieron. Un enlace rel="noreferrer", una política no-referrer y una página HTTPS que enlaza a una página HTTP producen un valor vacío con las reglas por defecto.

¿Por qué PHP lo llama HTTP_REFERER?

PHP construye las claves de $_SERVER a partir de los nombres de las cabeceras de petición añadiendo el prefijo HTTP_, pasando a mayúsculas y sustituyendo los guiones por guiones bajos. La cabecera es Referer, así que la clave es HTTP_REFERER. Django sigue el mismo patrón en request.META.

¿Cuál es la política de referrer por defecto en los navegadores?

El borrador del W3C fija strict-origin-when-cross-origin como valor por defecto. En peticiones del mismo origen envía el origen, la ruta y la query string. En peticiones entre orígenes envía solo el origen mientras el nivel de seguridad del protocolo no cambie, y de HTTPS a HTTP no envía la cabecera Referer.

¿Qué diferencia hay entre rel="noreferrer" y no-referrer?

rel="noreferrer" es una relación de enlace y se escribe sin guion. no-referrer es un valor de política, así que la forma para todo el documento es <meta name="referrer" content="no-referrer">, con guion. Si se intercambian, no ocurre nada y tampoco hay aviso.

¿Express acepta tanto Referer como Referrer?

Express acepta ambos. El docblock de req.get los llama intercambiables, y el código devuelve this.headers.referrer || this.headers.referer. Una cabecera que se llame literalmente Referrer gana a la estándar.

¿Qué RFC definió primero la cabecera Referer?

La RFC 1945, el documento de HTTP/1.0 de mayo de 1996, la define en la sección 10.13 y no dice nada de la ortografía. La RFC 2068 añadió el [sic] en enero de 1997. La RFC 9110 sigue llevándolo en junio de 2022.