También disponible en: English · Português · Français · العربية
Analizador de la cabecera Link: todos los enlaces, no uno por relación
Pega una cabecera Link de HTTP y verás cada enlace, de qué trata y cuántos descartaría un analizador indexado por relación.
¿Qué es la cabecera Link?
La cabecera Link hace en HTTP lo que un elemento link hace en HTML: apunta desde la respuesta a otro recurso y dice cómo se relacionan los dos. Cada enlace es un destino entre signos de menor y mayor seguido de parámetros, de los cuales rel es obligatorio. Una API paginada envía rel=next y rel=prev; un documento puede enviar rel=describedby; una página con traducciones envía un rel=alternate por idioma.
La define el RFC 8288, y la forma que define es una lista. Suena obvio y es justo lo que la mayoría de las herramientas se salta, porque la manera cómoda de entregar una cabecera Link al código de la aplicación es como un objeto indexado por tipo de relación, donde puedes escribir links.next.url. Esa representación no puede guardar dos enlaces con la misma relación, y la especificación no solo los permite: cuenta con ellos.
Esta página analiza la cabecera como una lista, aplica el ancla de cada enlace para que veas de qué recurso trata en realidad, expande un rel múltiple en los varios enlaces que la especificación dice que establece, y te dice cuántos enlaces cabrían en un analizador indexado por relación.
Cómo usarlo
- Pega el valor de la cabecera. El campo entero, sin el nombre. Las comas separan enlaces, salvo dentro de los signos de menor y mayor o de una cadena entrecomillada, que es la forma más habitual de que un split casero salga mal.
- Indica la URL con la que llegó la cabecera. Los destinos y anclas relativos se resuelven contra ella, y es de lo que trata cada enlace salvo que un ancla diga otra cosa. Un elemento base en el cuerpo de la página no influye, y la especificación lo dice expresamente.
- Mira el recuento de abajo. Muestra cuántos enlaces lleva la cabecera y cuántos tipos de relación distintos usan. Cuando esas dos cifras difieren, un analizador que devuelve un mapa indexado por relación está descartando la diferencia en silencio.
Dónde desaparecen los enlaces
Nada en el RFC 8288 dice que un tipo de relación pueda aparecer una sola vez. El contraejemplo canónico son las alternativas de idioma: una página disponible en francés y en alemán envía dos enlaces, ambos rel=alternate, que solo se diferencian en su hreflang. Un analizador que devuelve un objeto indexado por tipo de relación puede guardar uno de los dos. El otro desaparece, sin error y sin aviso.
Esto se midió mientras se construía la página. De dos analizadores de cabecera Link publicados, uno devuelve exactamente ese mapa: ante dos alternativas devuelve una sola entrada, y ante dos enlaces con relaciones distintas devuelve los dos. Ese control importa, porque demuestra que la pérdida es una propiedad del tipo de retorno y no del análisis. El otro analizador devuelve los dos enlaces siempre.
Dos cosas conviene decirlas claramente, porque eran suposiciones mías que resultaron falsas. Los dos analizadores expanden correctamente un rel múltiple en varios enlaces, y los dos exponen el parámetro anchor. El problema no es que el ecosistema analice mal la cabecera. Es que una forma popular de dar la respuesta no puede expresar lo que la cabecera tiene permitido decir.
Los tipos de relación se comparan sin distinguir mayúsculas, y el algoritmo de análisis del propio apéndice de la especificación los normaliza a minúsculas, así que rel=NEXT y rel=next son la misma relación. Dos enlaces escritos así chocan en un mapa indexado por la misma razón.
El ancla cambia de qué trata un enlace
Por defecto el contexto de un enlace es el recurso con el que llegó la cabecera: la página que pediste. El parámetro anchor lo sustituye, y la especificación es explícita en que puede apuntar a un fragmento del mismo recurso o a un tercer recurso entero. Una respuesta sobre un documento puede llevar un enlace que describe una relación que pertenece a otro.
Eso no es un detalle que un analizador pueda dejar a quien lo llama. El RFC 8288 dice que las aplicaciones de enlaces no deben procesar el enlace sin aplicar el ancla, y que una aplicación incapaz de aplicarla debería ignorar el enlace por completo. Tratar anchor como un atributo más en un saco, junto a type y hreflang, produce exactamente el error del que avisa la especificación: una relación anotada contra el recurso equivocado.
Por eso cada enlace de aquí muestra de qué trata, ya resuelto, en lugar de listar anchor como parámetro y dejarte a ti darte cuenta. Cuando un ancla ha movido el contexto, la fila lo dice.
Lo que esto no puede decirte
No puede decirte qué envía un servidor. Tú pegas una cabecera; la página la lee. Si quieres ver las cabeceras reales de una URL, el panel de red de tu navegador o un cliente HTTP de línea de órdenes te las enseñará, incluidas las varias cabeceras Link separadas que una respuesta puede enviar y que cuentan como una sola lista.
No comprueba que un tipo de relación signifique algo. Los tipos registrados salen de un registro de IANA y los de extensión se supone que son URIs, pero una cabecera llena de relaciones inventadas sigue estando bien formada, y esta página la analizará tan contenta. La lista de relaciones registradas de este sitio es el sitio donde comprobar si un nombre existe.
Tampoco sigue nada. Un destino se resuelve a una URL absoluta y ahí se queda; no se descarga nada, no se verifica ningún enlace, y un destino que da 404 se ve exactamente igual que uno que funciona. Y el parámetro type es una pista según las propias palabras de la especificación, así que un enlace que dice text/html no te garantiza nada sobre lo que obtendrías de verdad.
¿Por qué es gratis?
Analizar una cabecera es manipulación de cadenas, y se ejecuta en tu navegador. No hay servidor de por medio, así que no hay nada que facturar ni cuenta que crear.
No se sube nada. La cabecera que pegas no sale de la pestaña.