Résumé

  • Le RFC 1123 a corrigé la réponse de STOU en imposant le chemin réel dans une réponse préliminaire 125 FILE: ou 150 FILE:, avant les données et avant le verdict final.
  • Cette précision répare la grammaire d’un reçu de nom ; elle ne rend le chemin ni mondialement unique, ni durable, ni capable de prouver que deux chemins désignent le même fichier ou que celui-ci sera conservé.

Le correctif tient dans un marqueur

Le RFC 1123, publié en octobre 1989, ne réinvente pas la commande FTP « Store Unique ». Il corrige la façon dont un serveur doit annoncer le résultat de la décision qui donne son sens à cette commande. Après STOU, le chemin effectif doit apparaître dans le message préliminaire précédant le transfert. Deux grammaires sont autorisées : 125 FILE: pppp et 150 FILE: pppp.

Le marqueur FILE: accomplit une tâche que le numéro seul ne pouvait pas remplir. Les réponses FTP mêlent traditionnellement un code destiné au logiciel et un texte dépendant du serveur, souvent utile à un lecteur humain. Sans balise fixe, un client ne sait pas nécessairement quelle partie de la phrase constitue le chemin obligatoire. Avec elle, le programme reçoit un champ reconnaissable, même si la chaîne placée après le marqueur reste définie par le système distant.

Le choix du moment est tout aussi important. 125 et 150 sont des réponses préliminaires : l’une indique que la connexion de données est déjà ouverte et que le transfert commence ; l’autre que le fichier est prêt et que cette connexion va être ouverte. Le chemin désigne donc le fichier qui va être écrit. Il ne dit pas que chaque octet l’a été. Des réponses ultérieures portent l’achèvement ou l’échec, et aucune de ces étapes ne prouve à elle seule la rétention, la sauvegarde, la visibilité ou l’immuabilité futures.

Le même RFC impose aux clients FTP d’accepter les chemins distants comme des chaînes arbitraires. Un nom renvoyé après STOU ne doit pas être remodelé selon les habitudes du système local. Corriger des séparateurs, changer la casse ou réinterpréter des caractères peut détruire le reçu exact que la nouvelle grammaire venait de rendre lisible.

Le texte corrigé appelait « commencé » ce qui portait un code d’achèvement

Pour comprendre la correction, il faut revenir au RFC 959 d’octobre 1985. Ce document ajoutait STOU parmi sept nouvelles commandes FTP optionnelles. Sa syntaxe formelle, STOU <CRLF>, ne contient aucun chemin. Le serveur crée le nouveau fichier dans le répertoire courant sous un nom qui n’y entre pas en collision.

La description demandait pourtant que ce nom figure dans une réponse « 250 Transfer Started ». Ailleurs, le même RFC définit 250 comme l’achèvement satisfaisant de l’action demandée. Son tableau pour STOU place d’ailleurs 125 ou 150 avant la transmission, puis 226 ou 250 parmi les réponses finales. L’expression et le code assignaient donc le nom à deux phases incompatibles.

La faute normative ne résidait pas dans une subtilité cosmétique. Un client devait apprendre le chemin choisi assez tôt pour l’enregistrer, tandis qu’une conclusion distincte devait dire si les données étaient arrivées. La formulation de 1985 permettait à un parseur de confondre l’allocation d’un nom et la réussite du transfert. Le texte de 1989 rétablit une séquence de preuves : d’abord le chemin du fichier qui va être écrit, ensuite le résultat de l’écriture.

La portée du mot « unique » reste locale dans les deux documents. Le chemin ne doit pas déjà exister dans le répertoire courant. Il peut exister ailleurs, être renommé plus tard ou cesser d’être disponible. Rien dans STOU ne fait du nom une empreinte du contenu, un identifiant planétaire ou une promesse de permanence.

Avant l’erreur de réponse, il y eut un choix de compatibilité

Le RFC 949, publié en juillet 1985, expliquait pourquoi cette variante de stockage avait reçu son propre verbe. Les auteurs avaient envisagé de modifier STOR, de lui ajouter un argument de contrôle ou d’attribuer un sens spécial à l’absence d’argument. Ces solutions auraient exigé de « rouvrir » le code d’une commande déjà installée. Ils jugeaient plus simple d’étendre une table de dispatch fondée sur les noms de commandes.

Cette décision est un pari sur la compatibilité. Ne pas changer STOR protège son traitement existant ; ajouter STOU permet aux implémentations de reconnaître une fonction distincte. Le coût se déplace toutefois vers la découverte du nouveau verbe, ses réponses et les clients capables de les analyser. Une extension peut ménager l’ancien code tout en créant une nouvelle frontière d’interopérabilité.

Le comportement proposé était celui de STOR, sauf pour la sélection du nom. Dans le répertoire courant, le serveur devait en produire un qui soit libre. Les exemples venaient de répertoires communs alimentant des files d’impression, de télécopie ou de perforation de cartes. Dans ces espaces, le serveur connaissait les noms occupés ; le client n’avait pas besoin d’exprimer les conventions d’un système étranger.

Le RFC 949 décida aussi que le nom généré devait revenir à l’expéditeur et que cette divulgation ne devait pas être facultative. Il maintint séparément l’accès, l’authentification et la comptabilité du système hôte. Une syntaxe permettant d’obtenir un nom non collisionnel n’était pas une voie pour contourner les autorisations.

Le pool avait déjà montré que le chemin final pouvait différer

En 1973, le RFC 505 cherchait comment déposer un fichier pour un autre utilisateur sans connaître son mot de passe. Une proposition le plaçait dans un répertoire commun plutôt que directement chez le destinataire allégué. Celui-ci devait être averti et pouvait ensuite copier le fichier. Le dispositif limitait l’occupation non sollicitée de son espace et le risque d’écraser un fichier existant dans son propre répertoire.

La commande imaginée, POOL id name, transportait encore un nom souhaité. En cas de collision, le serveur devait lui ajouter un préfixe ou un suffixe. La chaîne locale pouvait donc différer de celle du client. Destinataire désigné, emplacement du pool, adaptation du nom et notification étaient déjà des responsabilités distinctes.

Ce texte reconnaissait que les protocoles de haut niveau connaissaient trop de particularités des systèmes d’exploitation. STOU en reprendra partiellement le problème en retirant complètement le chemin de la requête, mais il serait faux de transformer cette lignée en récit de déploiement. POOL était une proposition ; les sources ne montrent pas un service universel directement converti en standard.

À l’origine, le client devait parler le langage du serveur

Le RFC 172, en juin 1971, définissait une donnée comme fichier lorsqu’un chemin l’identifiait de manière unique dans un système. FTP uniformisait des opérations, pas les conventions de nommage. L’utilisateur devait suivre celles du système de fichiers distant.

Une commande normale de stockage liait ainsi deux difficultés. Le contenu traversait le réseau, tandis que le client formulait un chemin dans un espace étranger. Si ce chemin existait, son contenu pouvait être remplacé ; s’il n’existait pas, une nouvelle entrée pouvait être créée. Le pouvoir de nommer emportait à la fois une charge d’interopérabilité et une conséquence de collision.

Le contrôle sélectif restait au système résident. FTP pouvait échanger identifiants et mots de passe, mais ne remplaçait pas la protection locale. La commande sans chemin déplacera plus tard l’allocation du nom, non l’autorité générale sur le stockage.

Les preuves plus récentes refusent elles aussi de se confondre

Le RFC 3659 offre deux tests de cette discipline. Il étend d’abord REST pour reprendre une transmission en mode flux. Après un marqueur, la commande suivante devrait normalement être RETR ou STOR. Un serveur peut permettre APPE ou STOU, mais l’usage n’est pas recommandé, et la signification de STOU après REST est dite indéfinie.

Une reprise suppose un fichier de destination déjà partagé et une position dans celui-ci. STOU exige au contraire une nouvelle allocation de chemin. Le nouveau nom ne prouve pas que les données restantes appartiennent au fichier partiellement transféré auparavant. Le RFC n’interdit pas à toute implémentation d’accepter la combinaison ; il refuse de lui attribuer une sémantique générale sûre.

Le même document définit ensuite le fait de liste Unique=. Son jeton opaque, sensible à la casse, sert à savoir si deux chemins désignent le même fichier stocké. La correspondance doit rester cohérente au moins pendant la connexion de contrôle. Ce jeton n’est pas le chemin renvoyé par STOU. L’un indique si deux chemins mènent au même fichier ; l’autre réserve un nom libre dans un répertoire. Le texte avertit encore qu’une valeur interne du système de fichiers permettant de contourner des protections ne convient pas comme jeton public.

Le registre préserve la référence, pas la présence

Le RFC 5797 établit un registre destiné principalement à éviter les conflits de noms entre commandes et extensions. Le registre FTP de l’IANA conserve STOU comme commande de base optionnelle et cite les RFC 959 et 1123. Cette inscription atteste la référence protocolaire, non le soutien par un serveur donné, sa réussite commerciale ou son usage actuel.

La valeur base de la colonne FEAT est un pseudo-code immuable. Elle ne doit pas être lue comme une ligne que le serveur annoncerait dans une réponse FEAT. Là encore, une chaîne enregistrée et une capacité observée sont deux preuves différentes.

Enfin, le RFC 2577 borne toute extrapolation sécuritaire. Le FTP standard transmet mots de passe, contrôle et données sans chiffrement et connaît des risques distincts de vol ou de substitution de connexion de données. La correction de FILE: ne chiffre pas le chemin, n’authentifie pas le contenu, ne valide pas le pair et ne garantit aucune garde durable. Elle fait quelque chose de plus étroit : elle rend enfin non ambiguë la déclaration du nom que le serveur vient de choisir.