Résumé

  • Une entrée de menu Gopher associait un type, un nom visible, un sélecteur opaque, un hôte et un port. Le lecteur choisissait le nom ; le client exécutait les autres champs au cours d'une nouvelle transaction.
  • L'arborescence visible recouvrait donc un graphe de renvois. Publier un chemin ne donnait ni la maîtrise du serveur distant ni la preuve que son contenu était authentique, inchangé ou même encore accessible.

Un choix local pouvait provoquer un départ lointain

Imaginons un étudiant devant un menu universitaire. Il sélectionne « Horaires des cours ». Le libellé ne révèle ni le nom de machine ni le port qui vont répondre. Il ne dit pas davantage si le document appartient au service qui a composé le menu. Pourtant le client possède déjà tout ce qu'il lui faut : la même ligne contient l'itinéraire caché.

RFC 1436 décrit cette ligne avec une économie remarquable. Le premier caractère indique le type. Viennent ensuite le nom affichable, une tabulation, le sélecteur, une tabulation, l'hôte, une tabulation et le port, puis CRLF. L'utilisateur ne voit normalement que le nom. Le logiciel reçoit une instruction de prochaine étape.

La séparation permettait à un département de rendre visible le service d'un autre sans recopier ses documents. Il ajoutait une entrée. Au clic, le client pouvait quitter le serveur courant, établir une connexion TCP ailleurs et transmettre le sélecteur fourni. La continuité de l'interface ne signifiait pas continuité de l'opérateur.

Ce détail est le cœur politique du mécanisme. Le catalogue exerce un pouvoir de présentation : choisir un intitulé, inclure ou omettre une destination, ordonner les lignes. Il n'acquiert pas pour autant l'autorité de produire la réponse distante. Le renvoi coordonne ; il ne transfère pas la propriété.

L'opacité du sélecteur protégeait l'autonomie locale

Dans les exemples, le sélecteur ressemble souvent à un chemin de fichier. Il aurait été tentant pour un client de le découper, le normaliser ou en déduire une hiérarchie. La spécification lui demande au contraire de ne rien lui faire signifier et de ne jamais le modifier.

Cette réserve autorise plusieurs architectures derrière la même syntaxe. Un serveur peut utiliser le sélecteur comme chemin. Un autre peut y reconnaître un script, une application ou une requête qui fabrique le document à la demande. Le protocole commun ne force aucun éditeur à exposer son système de fichiers ni à adopter un identifiant mondial.

L'opacité ne crée toutefois aucune garantie. Les mêmes octets peuvent désigner deux choses différentes sur deux hôtes. Un serveur peut changer leur interprétation après une migration. Le sélecteur n'est ni une empreinte de contenu, ni une capacité secrète, ni une identité durable. Il est une entrée dans la grammaire locale du serveur nommé.

Pour l'audit, il faut donc conserver sa valeur exacte. « Corriger » une barre oblique, convertir un encodage privé ou deviner une structure peut transformer silencieusement la demande. La bonne discipline n'est pas de comprendre davantage le sélecteur, mais de savoir qui a le droit de lui donner un sens.

La racine n'était qu'un point d'entrée commode

Gopher adopta la métaphore du système de fichiers parce qu'une arborescence est familière. Le réseau décrit par les menus n'était pas obligé d'en être une. RFC 1436 autorise un serveur à pointer vers des serveurs secondaires, vers des services utiles ailleurs sur Internet et même vers un nœud déjà visité. Il parle explicitement d'un graphe arbitraire.

Un campus pouvait exploiter un serveur principal bien connu, enregistrer des entrées départementales et cloner ce point d'entrée pour répartir la charge. Mais un département pouvait aussi publier ses propres liens sans demander qu'une autorité mondiale enregistre chaque destination. La racine facilitait la découverte ; elle ne constituait pas le titre de propriété du réseau d'information.

Plusieurs pouvoirs restaient ainsi dissociés. L'éditeur du menu rédigeait le nom et le descripteur. L'opérateur distant interprétait le sélecteur et servait le résultat. Le DNS pouvait déplacer un alias vers une autre adresse. Le processus attaché au port décidait de ce qui répondait réellement. Le client acceptait, ignorait ou signalait le type proposé.

Une entrée n'était donc qu'une observation datée : à cet instant, ce menu recommandait cette combinaison. Un nom rassurant pouvait cacher un hôte erroné. Un sélecteur pouvait devenir caduc. Un alias DNS pouvait changer sans que le menu soit édité. Le graphe dépendait d'une coopération continue, pas d'un état central qui aurait verrouillé toutes les relations.

La mémoire de la promenade appartenait au client

La transaction de base était brève. Le client ouvrait TCP et envoyait une ligne de sélecteur, éventuellement vide. Le serveur répondait puis ne conservait aucun état client entre deux transactions. Une demande vide, réduite à CRLF, pouvait demander le menu supérieur.

Les menus et les textes se terminaient par une ligne contenant un seul point. Pour qu'une ligne de texte commençant réellement par un point ne soit pas prise pour la fin, l'émetteur en ajoutait un second et le client l'enlevait. Les objets binaires suivaient une autre règle : la fermeture de la connexion marquait leur fin.

La fermeture ne signifiait donc pas toujours panne. Inversement, une fin syntaxiquement correcte ne prouvait pas la valeur du contenu. Un menu complet pouvait ne contenir que des liens morts. Un texte bien délimité pouvait être l'ancien document. Le cadrage établissait où s'arrêtait la réponse, non ce qu'elle valait.

Le sentiment de session continue venait surtout du logiciel local. RFC 1436 envisage une pile des lieux visités pour revenir en arrière et un cache des menus déjà lus. La trajectoire du lecteur n'existait pas comme un dossier global sur les serveurs successifs. Elle était reconstruite à partir de transactions indépendantes.

Le type choisissait la procédure

Le premier caractère d'une entrée décidait de la méthode. 0 annonçait un texte, 1 un menu et 7 une recherche. D'autres valeurs aiguillaient vers des fichiers binaires, CSO, Telnet ou TN3270. Un client ne comprenant pas un type non essentiel pouvait l'ignorer ou le présenter comme inconnu.

Ce caractère n'était pas un certificat. Il ne prouvait ni le format effectif ni l'innocuité du rendu. Il ordonnait au client d'essayer une transaction. Une erreur de classement pouvait donc produire une interprétation erronée avec une syntaxe parfaitement valide.

La recherche de type 7 rend la chaîne de décisions particulièrement visible. Le client envoie le sélecteur, une tabulation et les mots recherchés. Le serveur répond par un menu virtuel. Plusieurs index ou passerelles peuvent couvrir des collections différentes sans que le client apprenne leur organisation interne.

Le résultat reste un renvoi. Le moteur décide qu'une ligne correspond à la requête et fournit ses coordonnées ; le serveur nommé décide encore de la récupération. La présence dans les résultats ne prouve ni disponibilité durable, ni exactitude du classement, ni identité du document final.

L'itinéraire devint transportable hors du menu

RFC 1738 a ensuite inscrit les coordonnées Gopher dans une URL : hôte, port éventuel, type sur un caractère et sélecteur. L'absence de port signifiait 70 ; un chemin vide pouvait désigner le menu supérieur de type 1. Une tabulation encodée séparait le sélecteur de la recherche.

RFC 4266 a préservé ce schéma sur la voie des normes lorsque RFC 1738 a été rendu obsolète. La route pouvait désormais être copiée, mise en favori ou transmise sans conserver le menu qui l'avait publiée.

Cette portabilité n'a pas rendu l'objet immuable. Le sélecteur restait local au serveur. L'hôte pouvait résoudre vers une nouvelle adresse. Le service lié au port pouvait être remplacé. L'URI conservait une recette syntaxique, pas une preuve cryptographique de continuité.

La comparaison des deux RFC révèle aussi un angle mort historique. RFC 1436 déclare ne pas traiter la sécurité. RFC 4266 rappelle plus tard l'absence de confidentialité et le danger de mots de passe transmis en clair. Une route lisible et correctement parsée n'était pas, pour cette seule raison, une route protégée.

Le petit format portait un choix institutionnel

Comment réunir de nombreux éditeurs dans un espace navigable sans confier leurs contenus à un seul administrateur ? Gopher répondit par délégation : chaque menu pouvait donner au client les coordonnées du prochain acteur. L'interface semblait unifiée ; l'exécution demeurait distribuée.

La concentration n'avait pas disparu. Un menu populaire façonnait la visibilité. Un index choisissait son périmètre. Un client rendait certains types invisibles. Mais aucun de ces pouvoirs ne devenait automatiquement la maîtrise de la destination.

La leçon dépasse Gopher. Tout catalogue qui déclenche une exécution ailleurs devrait montrer clairement ce qu'il nomme, ce qu'il recommande et ce qu'il contrôle réellement. Une adresse peut organiser l'accès à une maison ; elle ne transforme pas le rédacteur de l'annuaire en propriétaire de la maison.

Sources