Résumé

  • FEAT permettait de connaître les extensions documentées d’un serveur FTP sans les essayer une à une ; OPTS réglait le comportement d’une commande à venir.
  • Une réponse positive conforme formait un inventaire complet, mais une erreur 500 ou 502 ne prouvait pas l’absence d’anciennes extensions, parfois déployées avant FEAT.
  • L’annonce d’une capacité, l’acceptation d’une option, l’authentification, l’autorisation, la réponse finale et le transfert constaté demeuraient des preuves distinctes.

Avant la liste, il fallait tenter

FTP avait été conçu pour durer, et cette longévité avait un prix : ses extensions n’arrivaient pas partout au même moment. Le protocole de base de la RFC 959 coexistait avec des commandes plus récentes. Un client pouvait connaître leur définition sans savoir si le serveur joint les avait mises en œuvre.

La méthode empirique consistait à envoyer la commande. Elle répondait peut-être à la question, mais en confondant deux actes. Interroger une capacité relève de l’observation ; exécuter une commande relève de l’opération. La RFC 2389 notait que cette série d’essais consommait des échanges et que certaines commandes pouvaient produire un effet indésirable. Le diagnostic devenait lui-même une intervention.

FEAT a introduit une étape de lecture. La requête ne comportait aucun argument. Le serveur pouvait répondre par la liste structurée des extensions qu’il déclarait prendre en charge. Le client choisissait ensuite, localement, celles qu’il savait comprendre. Le mécanisme ne centralisait pas le sens de toutes les extensions : chaque spécification ultérieure définissait encore son étiquette et ses paramètres.

Cette économie est caractéristique de l’Internet qui fonctionne bien. La couche commune est assez mince pour être stable, mais assez précise pour éviter qu’une exploration ne devienne une action.

Une syntaxe faite pour survivre au futur

Une liste non vide commençait par une réponse multiligne 211-. Chaque capacité occupait sa propre ligne, précédée d’un espace exactement. La réponse se terminait par 211 End. L’espace empêchait qu’une ligne de capacité soit interprétée comme la fin de la réponse. C’était un séparateur de structure, pas une question de présentation.

Le premier texte pouvait être libre. Les lignes suivantes obéissaient à une grammaire. Une étiquette n’était pas forcément le nom d’une commande ; elle pouvait désigner un mécanisme plus large. Les paramètres n’avaient de sens qu’au regard du document qui les avait définis. L’ordre n’avait aucune portée, et le serveur pouvait le modifier d’un appel à l’autre.

Surtout, un ancien client devait accepter de voir une étiquette inconnue. L’inconnu n’était pas une faute. Il indiquait seulement que le serveur avait appris quelque chose que le client ne connaissait pas encore. Ce choix préservait l’interopérabilité : les deux parties pouvaient continuer sur leur sous-ensemble commun au lieu de transformer toute nouveauté en rupture.

La liste ne citait ni FEAT ni OPTS. Le premier se prouvait par une réponse autre que 500 ou 502. Le second était obligatoire dès lors que FEAT l’était. Le protocole ne répétait pas les faits déjà établis par l’échange lui-même.

Le oui était fermé, le silence restait ouvert

La RFC 2389 a conçu une asymétrie utile. Lorsqu’un serveur mettait FEAT en œuvre, il devait annoncer toutes les extensions FTP correctement documentées qu’il supportait au-delà des RFC 959 et 2389. Dans ce contexte, une réponse positive conforme était un inventaire complet. Si une extension n’y figurait pas, le client pouvait considérer qu’elle n’était pas disponible.

La proposition inverse était interdite par l’histoire du déploiement. Un serveur ignorant FEAT répondait 500 ou 502, comme pour toute commande inconnue. Or des extensions existaient déjà avant 1998. Un serveur ancien pouvait les comprendre tout en étant incapable de les annoncer. L’échec de l’inventaire ne démontrait donc pas l’absence de capacités ; il rendait la question indécidable par cette voie.

Même le cas « aucune extension » gardait cette trace historique. Un serveur comprenant FEAT mais n’ayant rien à lister devait normalement envoyer une réponse 211 sur une ligne. Le texte autorisait pourtant 500 ou 502, puisque le client ne pouvait pratiquement pas distinguer ce cas d’un serveur qui ne connaissait pas la commande.

Ce régime évite deux mensonges symétriques. Il ne transforme pas une liste positive en promesse d’exécution. Il ne transforme pas l’absence de liste en preuve d’absence. Une information forte ne vaut que dans le périmètre qui l’a produite.

OPTS préparait le prochain acte

Une capacité peut offrir plusieurs comportements. OPTS donnait au client une enveloppe commune pour choisir celui qu’il souhaitait appliquer à une commande cible ultérieure. La syntaxe détaillée et l’effet appartenaient à la spécification de cette commande.

Une réponse 200 signifiait que la cible et les options étaient reconnues et appropriées. 501 signalait une erreur permanente tant que rien ne changeait. 451 signalait une condition temporaire du serveur. Aucune de ces réponses ne disait que le travail final avait déjà été exécuté.

La RFC 3659 en fournit un exemple parlant. La ligne MLST de FEAT pouvait énumérer les faits de fichier disponibles et marquer par un astérisque ceux qui seraient renvoyés par défaut. OPTS MLST modifiait l’ensemble retenu pour les prochaines réponses MLST et MLSD. Certains faits non sélectionnés par défaut pouvaient être coûteux à calculer ; le client était invité à ne les demander qu’en présence d’un besoin opérationnel.

On obtient ainsi quatre états distincts : le serveur sait produire un fait ; il le produit par défaut ; le client le demande ; le serveur le renvoie effectivement pour un objet auquel ce fait s’applique. Les réunir dans un booléen « supporté » détruirait l’information que la négociation voulait préserver.

La ligne AUTH TLS n’était que le début

La RFC 4217 a réutilisé FEAT pour la sécurisation de FTP avec TLS. Un serveur compatible annonçait AUTH TLS, PBSZ et PROT. Cette publicité indiquait le chemin de négociation possible, non l’existence d’une session protégée.

Le client devait encore envoyer AUTH TLS, recevoir l’acceptation 234, terminer la négociation TLS, fixer les paramètres de protection, examiner l’identité du certificat selon sa politique et réussir l’authentification FTP exigée. Une ligne de liste ne pouvait pas signer un certificat, autoriser un utilisateur ni protéger une connexion de données à venir.

La RFC 7151 illustre la même frontière avec HOST. Un serveur prenant en charge les hôtes virtuels devait annoncer HOST, mais la sélection pouvait changer l’environnement d’authentification. La correspondance entre le nom demandé et l’identité du certificat restait une vérification séparée. L’étiquette rendait une porte visible ; elle ne donnait pas la clé.

Un registre d’unicité, non un tribunal

En 2010, la RFC 5797 a créé le registre IANA des commandes et extensions FTP. Il fallait éviter que deux mécanismes utilisent le même nom avec des sens différents. Le registre notait les commandes, codes FEAT, descriptions, types, exigences de conformité et références. Il conservait aussi les entrées historiques pour empêcher leur réemploi ambigu.

Le document précisait pourtant que l’inscription ne démontrait aucune « approbation ». Une extension pouvait être enregistrée grâce à une spécification publique permanente ou à une mise en œuvre dans des clients et serveurs généralement disponibles. Des pseudo-codes réservaient des noms sans être destinés aux réponses FEAT.

Le registre protégeait donc la correspondance entre un nom et une définition. Le serveur attestait ensuite son support local. OPTS constatait un choix accepté. Les contrôles d’identité et de politique décidaient qui pouvait agir. La commande et la connexion de données produisaient enfin le résultat. Chaque couche disposait de son propre auteur et de son propre champ de vérité.

Révéler moins que l’action, assez pour décider

La RFC 2389 reconnaissait qu’une liste de capacités pouvait révéler des propriétés du serveur. Sans elle, un observateur déterminé pouvait essayer les commandes une par une, au risque de rendre sa reconnaissance plus visible dans les journaux. Le texte n’a pas jugé ce différentiel assez grave pour renoncer à la découverte structurée.

Le compromis n’était pas « transparence totale contre secret ». Il consistait à publier une surface limitée, utile à l’interopérabilité, puis à laisser chaque extension protéger ses opérations. La description devenait plus précise sans absorber l’autorité des contrôles locaux.

Le mérite durable de la RFC 2389 tient à cette modestie. Elle répondait à « quel langage optionnel ce serveur déclare-t-il parler ? » avant de poser « exécutera-t-il cette demande pour cet utilisateur, maintenant ? ». Le premier reçu pouvait guider l’action. Il ne pouvait pas la remplacer.

Sources