Résumé
- Une référence relative omet ce que fournit déjà une base connue, réduisant la répétition et permettant à des groupes de documents de déménager ensemble.
- La résolution est une transformation syntaxique déterministe : sélectionner une base absolue, hériter ou remplacer les composants, fusionner les chemins, retirer les segments
.et.., puis recomposer. - Une référence relative seule n’est pas un identifiant mondial stable ; preuve, signature et audit doivent conserver la base effective ou la cible absolue résolue.
Le document savait déjà une partie de l’adresse
Une adresse absolue répète souvent le même schéma, la même autorité et une grande partie du chemin. Le document contenant les liens est lui-même arrivé d’un lieu qui fournit ce contexte.
RFC 1630, proposition de Tim Berners-Lee en 1994, décrivait une forme partielle dans un objet dont l’URI était définie. Elle économisait des caractères et permettait surtout à des objets liés de se déplacer ensemble sans réécrire chaque arête. Les changements des niveaux supérieurs restaient cachés aux documents locaux.
La condition était explicite : hors d’un contexte bien maîtrisé, il fallait employer la forme complète. Le lien court ne transporte pas ce qu’il omet. Sa portabilité exige que la base voyage avec lui ou soit établie de manière reproductible.
La hiérarchie apparaissait déjà dans la barre oblique et les segments complets . et ... Une barre finale comptait : elle formait un segment final vide. Une base ressemblant à un répertoire et une base ressemblant à une ressource ne prêtaient pas le même chemin.
La relation devint une transformation normalisée
RFC 1808, publié en juin 1995, définit l’URL relative comme représentation compacte par rapport à une base absolue. La base pouvait fournir schéma, emplacement réseau et parties du chemin ; la référence n’exprimait que la différence.
Ce n’était pas une concaténation. Une référence portant son schéma était absolue. Une autorité remplaçait l’autorité de base. Une barre initiale remplaçait le chemin depuis sa racine. Un chemin relatif fusionnait avec la dernière partie du chemin de base. Requête et fragment obéissaient à leurs composants.
Le choix déclarait une dépendance. Une collection déplacée avec la même hiérarchie conservait ses liens relatifs. Un lien absolu continuait vers l’ancienne autorité. Aucun n’était universellement supérieur.
HTML donna au document un contexte transportable
RFC 1866, HTML 2.0 en 1995, intégra les cibles relatives aux ancres, liens, images, entrées et formulaires. Un élément facultatif BASE pouvait fournir une adresse absolue lorsque le document était lu hors du contexte de récupération.
Cette faculté concentrait aussi le contrôle. Une seule base intégrée pouvait réinterpréter toutes les références relatives. Le mécanisme était utile parce qu’il évitait de répéter le préfixe ; modifier ce préfixe touchait donc tout le graphe dépendant.
La base n’est pas une décoration de présentation. Elle participe à l’identité de la ressource. La retirer, la remplacer ou l’appliquer à une autre étape change la décision.
La syntaxe générique sépara l’héritage par composant
RFC 2396, en 1998, généralisa la résolution aux références URI. Schéma, autorité, chemin, requête et fragment étaient d’abord analysés, puis fournis, hérités ou remplacés selon la forme.
Pour un chemin relatif, on retire le dernier segment de la base, on ajoute la référence et on traite les segments-points. La barre finale reste donc déterminante. Mais le chemin URI n’est pas automatiquement un système de fichiers : seuls . et .. comme segments complets ont ce rôle générique. Des points inclus dans un autre nom restent des données.
La résolution ne contacte pas le serveur. Elle produit un identifiant cible. Déréférencement, redirection, autorisation et existence viennent ensuite.
Le contrat actuel choisit une base avant toute résolution
RFC 3986 exige une base connue, hors cas étroit du fragment seul. Cette base est absolue et perd son fragment avant usage.
Les sources suivent une priorité : base intégrée au contenu, base de l’entité englobante, URI de récupération, puis défaut de l’application. L’ordre réduit plusieurs contextes possibles à une entrée effective.
Une référence avec schéma fournit ses composants. La forme // emprunte le schéma mais remplace l’autorité. Une barre initiale emprunte schéma et autorité mais remplace le chemin. Un chemin relatif fusionne avec tout sauf le dernier segment de la base ; si l’autorité a un chemin vide, la fusion commence par /.
Un chemin de référence vide hérite du chemin de base et, sans requête propre, de la requête de base. Le fragment fourni devient celui de la cible. Ce sont des décisions composant par composant.
Les segments-points étaient des instructions temporaires
L’algorithme remove_dot_segments intervient après extraction et fusion. Un segment complet . n’ajoute aucun niveau ; .. retire le segment de sortie précédent lorsqu’il existe. Les parents excédentaires suivent l’algorithme et ne franchissent pas une racine universelle imaginaire.
La transformation est syntaxique. Elle n’interroge pas le serveur sur ses répertoires. Des implantations peuvent employer des piles plutôt que les tampons du texte, mais doivent obtenir la même cible.
Même l’état « même document » se juge après résolution, en comparant la forme absolue à la base, pas seulement en observant la brièveté du texte.
La mobilité était une dépendance maîtrisée
Les liens relatifs rendirent une collection remplaçable parce que ses relations internes ne nommaient pas un hôte permanent. Mais ils ne furent jamais sans contexte. L’adresse manquante venait du document, du conteneur, de la récupération ou de l’application.
Une preuve qui contient seulement ../source ne désigne plus une source publique après séparation de sa base. Un manifeste qui signe le texte court mais pas sa base laisse une partie de la cible hors signature. Un journal qui conserve seulement la cible ne dit pas quelle décision contextuelle l’a produite.
La preuve durable conserve la référence d’origine, la base choisie et la cible résolue lorsqu’une action a suivi.
Sources
- RFC 1630, Universal Resource Identifiers in WWW : https://www.rfc-editor.org/rfc/rfc1630.html
- RFC 1808, Relative Uniform Resource Locators : https://www.rfc-editor.org/rfc/rfc1808.html
- RFC 1866, Hypertext Markup Language — 2.0 : https://www.rfc-editor.org/rfc/rfc1866.html
- RFC 2396, Uniform Resource Identifiers (URI): Generic Syntax : https://www.rfc-editor.org/rfc/rfc2396.html
- RFC 3986, Uniform Resource Identifier (URI): Generic Syntax : https://www.rfc-editor.org/rfc/rfc3986.html
Ces normes établissent l’histoire et l’algorithme, non les particularités actuelles des navigateurs ni la sûreté d’une application donnée.
Briefing des membres
Contexte approfondi du profil
Connectez-vous avec le bon niveau d'adhésion pour débloquer le briefing complet et les notes de source.
Réservé à Strategic Circle
Strategic Circle
Ouvert à tous les lecteurs. Débloquez les briefings de profil après adhésion et connexion.
Rejoindre Strategic CircleRéservé aux membres de Leadership Alliance
Leadership Alliance
Réservé aux propriétaires et dirigeants qualifiés d'actifs IP ; connectez-vous pour débloquer les briefings Alliance.
Rejoindre Leadership Alliance
