Também disponível em: English · Español · Français · العربية
Analisador do cabeçalho Link: todos os links, não um por relação
Cole um cabeçalho Link do HTTP e veja cada link, sobre o que ele fala e quantos um analisador indexado por relação descartaria.
O que é o cabeçalho Link?
O cabeçalho Link faz no HTTP o que um elemento link faz no HTML: aponta da resposta para outro recurso e diz como os dois se relacionam. Cada link é um alvo entre sinais de menor e maior seguido de parâmetros, dos quais rel é obrigatório. Uma API paginada envia rel=next e rel=prev; um documento pode enviar rel=describedby; uma página com traduções envia um rel=alternate por idioma.
A RFC 8288 o define, e a forma que ela define é uma lista. Parece óbvio e é justamente o que a maioria das ferramentas erra, porque o jeito cômodo de entregar um cabeçalho Link ao código da aplicação é como um objeto indexado por tipo de relação, onde dá para escrever links.next.url. Essa representação não consegue guardar dois links com a mesma relação, e a especificação não apenas os permite: conta com eles.
Esta página analisa o cabeçalho como uma lista, aplica a âncora de cada link para você ver sobre qual recurso ele realmente fala, expande um rel múltiplo nos vários links que a especificação diz que ele estabelece, e informa quantos links caberiam num analisador indexado por relação.
Como usar
- Cole o valor do cabeçalho. O campo inteiro, sem o nome. Vírgulas separam links, exceto dentro dos sinais de menor e maior ou de uma string entre aspas, que é o jeito mais comum de um split caseiro dar errado.
- Informe a URL com que o cabeçalho veio. Alvos e âncoras relativos são resolvidos contra ela, e é sobre ela que cada link fala, a menos que uma âncora diga o contrário. Um elemento base no corpo da página não afeta isso, e a especificação diz isso explicitamente.
- Veja a contagem abaixo. Ela mostra quantos links o cabeçalho carrega e quantos tipos de relação distintos eles usam. Quando esses números diferem, um analisador que devolve um mapa indexado por relação está descartando a diferença em silêncio.
Onde os links somem
Nada na RFC 8288 diz que um tipo de relação pode aparecer uma única vez. O contraexemplo canônico são as alternativas de idioma: uma página disponível em francês e alemão envia dois links, ambos rel=alternate, diferindo apenas no hreflang. Um analisador que devolve um objeto indexado por tipo de relação consegue guardar um deles. O outro some, sem erro e sem aviso.
Isso foi medido enquanto a página era construída. De dois analisadores de cabeçalho Link publicados, um devolve exatamente esse mapa: diante de duas alternativas devolve uma única entrada, e diante de dois links com relações diferentes devolve os dois. Esse controle importa, porque mostra que a perda é uma propriedade do tipo de retorno e não da análise. O outro analisador devolve os dois links sempre.
Duas coisas valem ser ditas claramente, porque eram suposições minhas que se revelaram falsas. Os dois analisadores expandem corretamente um rel múltiplo em vários links, e os dois expõem o parâmetro anchor. O problema não é que o ecossistema analise mal o cabeçalho. É que um formato popular para a resposta não consegue expressar o que o cabeçalho tem permissão de dizer.
Tipos de relação são comparados sem diferenciar maiúsculas, e o algoritmo de análise do próprio apêndice da especificação os normaliza para minúsculas, então rel=NEXT e rel=next são a mesma relação. Dois links escritos assim colidem num mapa indexado pelo mesmo motivo.
A âncora muda sobre o que o link fala
Por padrão o contexto de um link é o recurso com que o cabeçalho veio: a página que você pediu. O parâmetro anchor substitui isso, e a especificação é explícita ao dizer que ele pode apontar para um fragmento do mesmo recurso ou para um terceiro recurso inteiro. Uma resposta sobre um documento pode carregar um link que descreve uma relação pertencente a outro.
Isso não é um detalhe que um analisador possa deixar para quem o chama. A RFC 8288 diz que aplicações de links não devem processar o link sem aplicar a âncora, e que uma aplicação incapaz de aplicá-la deveria ignorar o link por completo. Tratar anchor como mais um atributo num saco, ao lado de type e hreflang, produz exatamente o erro do qual a especificação avisa: uma relação registrada contra o recurso errado.
Por isso cada link aqui mostra sobre o que fala, já resolvido, em vez de listar anchor como parâmetro e deixar você notar. Onde uma âncora moveu o contexto, a linha diz.
O que isto não diz
Não diz o que um servidor envia. Você cola um cabeçalho; a página o lê. Se quiser ver os cabeçalhos reais de uma URL, o painel de rede do seu navegador ou um cliente HTTP de linha de comando os mostra, incluindo os vários cabeçalhos Link separados que uma resposta pode enviar e que contam como uma lista só.
Não verifica se um tipo de relação significa algo. Os tipos registrados vêm de um registro da IANA e os de extensão deveriam ser URIs, mas um cabeçalho cheio de relações inventadas continua bem formado, e esta página o analisará sem reclamar. A lista de relações registradas deste site é onde conferir se um nome existe.
Também não segue nada. Um alvo é resolvido para uma URL absoluta e fica por isso; nada é buscado, nenhum link é verificado, e um alvo que dá 404 parece exatamente igual a um que funciona. E o parâmetro type é uma dica pelas próprias palavras da especificação, então um link que diz text/html não garante nada sobre o que você realmente receberia.
Por que é grátis?
Analisar um cabeçalho é manipulação de strings, e roda no seu navegador. Não há servidor no meio, então não há o que cobrar nem conta a criar.
Nada é enviado. O cabeçalho que você cola não sai da aba.