Analyseur d’en-tête Link : tous les liens, pas un par relation

Qu’est-ce que l’en-tête Link ?

L’en-tête Link fait en HTTP ce qu’un élément link fait en HTML : il pointe depuis la réponse vers une autre ressource et dit comment les deux sont liées. Chaque lien est une cible entre chevrons suivie de paramètres, dont rel est obligatoire. Une API paginée envoie rel=next et rel=prev ; un document peut envoyer rel=describedby ; une page traduite envoie un rel=alternate par langue.

La RFC 8288 le définit, et la forme qu’elle définit est une liste. Cela paraît évident et c’est précisément ce que la plupart des outils ratent, car la façon commode de livrer un en-tête Link au code applicatif est un objet indexé par type de relation, où l’on écrit links.next.url. Cette représentation ne peut pas contenir deux liens de même relation, et la spécification non seulement les autorise, elle compte dessus.

Cette page analyse l’en-tête comme une liste, applique l’ancre de chaque lien pour montrer sur quelle ressource il porte réellement, développe un rel multiple en les liens que la spécification dit qu’il établit, et indique combien de liens tiendraient dans un analyseur indexé par relation.

Comment l’utiliser

1. Collez la valeur de l’en-tête. Le champ entier, sans son nom. Les virgules séparent les liens, sauf à l’intérieur des chevrons ou d’une chaîne entre guillemets, ce qui est la façon la plus courante de rater un découpage fait maison.
2. Donnez l’URL qui accompagnait l’en-tête. Les cibles et ancres relatives s’y résolvent, et c’est d’elle que parle chaque lien sauf si une ancre en décide autrement. Un élément base dans le corps de la page n’y change rien, et la spécification le dit explicitement.
3. Lisez le décompte en dessous. Il indique combien de liens porte l’en-tête et combien de types de relation distincts ils emploient. Quand ces deux nombres diffèrent, un analyseur renvoyant une table indexée par relation écarte la différence en silence.

Où les liens disparaissent

Rien dans la RFC 8288 ne dit qu’un type de relation ne peut apparaître qu’une fois. Le contre-exemple canonique, ce sont les variantes linguistiques : une page disponible en français et en allemand envoie deux liens, tous deux rel=alternate, ne différant que par leur hreflang. Un analyseur qui renvoie un objet indexé par type de relation peut en garder un. L’autre disparaît, sans erreur et sans avertissement.

Cela a été mesuré pendant la construction de la page. De deux analyseurs d’en-tête Link publiés, l’un renvoie exactement cette table : devant deux variantes il renvoie une seule entrée, devant deux liens de relations différentes il les renvoie tous les deux. Ce contrôle compte, car il montre que la perte tient au type de retour et non à l’analyse. L’autre analyseur renvoie les deux liens à chaque fois.

Deux choses méritent d’être dites franchement, car c’étaient des suppositions de ma part qui se sont révélées fausses. Les deux analyseurs développent correctement un rel multiple en plusieurs liens, et tous deux exposent le paramètre anchor. Le problème n’est pas que l’écosystème analyse mal l’en-tête. C’est qu’une forme répandue de réponse ne peut pas exprimer ce que l’en-tête a le droit de dire.

Les types de relation se comparent sans distinction de casse, et l’algorithme d’analyse figurant en annexe de la spécification les normalise en minuscules : rel=NEXT et rel=next sont donc la même relation. Deux liens écrits ainsi se télescopent dans une table indexée, pour la même raison.

L’ancre change ce sur quoi porte un lien

Par défaut, le contexte d’un lien est la ressource qui accompagnait l’en-tête : la page demandée. Le paramètre anchor s’y substitue, et la spécification précise qu’il peut désigner un fragment de la même ressource ou une troisième ressource entière. Une réponse portant sur un document peut transporter un lien décrivant une relation qui appartient à un autre.

Ce n’est pas un détail qu’un analyseur puisse laisser à l’appelant. La RFC 8288 dit que les applications de liens ne doivent pas traiter le lien sans appliquer l’ancre, et qu’une application incapable de l’appliquer devrait ignorer le lien entièrement. Traiter anchor comme un attribut de plus dans un sac, à côté de type et hreflang, produit exactement l’erreur contre laquelle la spécification met en garde : une relation attribuée à la mauvaise ressource.

Chaque lien indique donc ce sur quoi il porte, déjà résolu, au lieu de lister anchor comme un paramètre en vous laissant le remarquer. Là où une ancre a déplacé le contexte, la ligne le dit.

Ce que cela ne peut pas vous dire

Cela ne vous dit pas ce qu’un serveur envoie. Vous collez un en-tête ; la page le lit. Pour voir les en-têtes réels d’une URL, le panneau réseau de votre navigateur ou un client HTTP en ligne de commande les affichera, y compris les plusieurs en-têtes Link distincts qu’une réponse peut envoyer et qui comptent comme une seule liste.

Cela ne vérifie pas qu’un type de relation signifie quelque chose. Les types enregistrés viennent d’un registre de l’IANA et les types d’extension sont censés être des URI, mais un en-tête plein de relations inventées reste bien formé, et cette page l’analysera sans broncher. La liste des relations enregistrées de ce site est l’endroit où vérifier qu’un nom existe.

Elle ne suit rien non plus. Une cible est résolue en URL absolue et en reste là ; rien n’est récupéré, aucun lien n’est vérifié, et une cible qui renvoie 404 ressemble exactement à une cible qui fonctionne. Quant au paramètre type, la spécification elle-même le qualifie d’indication : un lien annonçant text/html ne vous garantit rien sur ce que vous obtiendriez vraiment.

Pourquoi est-ce gratuit ?

Analyser un en-tête relève de la manipulation de chaînes, et cela se passe dans votre navigateur. Aucun serveur n’intervient, il n’y a donc rien à facturer ni de compte à créer.

Rien n’est envoyé. L’en-tête que vous collez ne quitte pas l’onglet.