Résumé

  • FTP permettait au client d’annoncer, avec ALLO, le nombre d’octets logiques dont un prochain STOR ou APPE aurait besoin.
  • Un serveur pour lequel l’allocation préalable n’avait aucun sens devait néanmoins laisser avancer un client simple : 202 constituait une fin positive tout en disant que la commande était superflue.
  • Ni 200, ni 202, ni le début du transfert ne suffisaient à prouver le stockage. La séquence de réponses, l’état du système et le fichier résultant formaient ensemble la preuve utile.

Une réponse positive dont le verbe changeait de sens

Imaginons une sauvegarde de 20 millions d’octets. Avant d’ouvrir le flot de données, le client envoie ALLO 20000000. Pour lui, le nombre exprime un besoin. Sur un système qui réserve physiquement des blocs avant l’écriture, la commande peut déclencher un acte concret. Sur une autre machine, l’espace se consomme au fil des écritures et aucune opération préparatoire n’est nécessaire. Le même dialogue doit servir les deux mondes.

Le RFC 354, publié en 1972, posait déjà cette bifurcation. Certains serveurs pouvaient exiger ALLOCATE afin de réserver assez de stockage pour le nouveau fichier. Le nombre décimal désignait des octets selon la taille d’octet choisie, et la commande devait précéder STORE ou APPEND. Mais un serveur n’ayant pas besoin de connaître le maximum à l’avance devait traiter la commande comme une opération nulle.

Cette règle paraît modeste. Elle résout pourtant un conflit d’architecture. Si le client interprète « je ne fais pas d’allocation préalable » comme un refus, il abandonne un transfert que le serveur aurait pu accomplir. Si le serveur prétend avoir réservé pour calmer le client, il fabrique une garantie que son système ne sait pas produire. FTP choisit une troisième voie : reconnaître le vocabulaire, accepter la continuation et laisser la réalité du stockage se manifester plus tard.

Le RFC 765, en 1980, rendit la demande plus expressive. Le premier entier comptait les octets logiques du fichier. Pour une structure par enregistrements ou par pages, un second entier pouvait annoncer la taille maximale d’un enregistrement ou d’une page. La séparation était littéralement <SP> R <SP>. Un serveur intéressé seulement par cette deuxième grandeur devait accepter une première valeur factice et l’ignorer.

La commande portait donc moins une mesure universelle du disque qu’une description située dans la représentation FTP. Un octet logique n’est pas automatiquement un bloc physique. La taille d’un enregistrement n’est pas un débit de réseau. Une valeur déclarée n’est ni un relevé d’espace libre ni une décision du moteur de quotas. Ce sont des éléments que le serveur peut utiliser pour préparer une écriture selon son propre système.

202 disait : continuez, mais ne concluez pas

Le RFC 959, en 1985, conserva la syntaxe ALLO <entier> [R <entier>] et l’obligation de faire suivre la commande par STOR ou APPE. Il conserva surtout l’opération nulle lorsque la déclaration préalable du maximum n’était pas requise.

La finesse apparaît dans les réponses. Une commande comme TYPE ou ALLO, exécutée avec succès mais n’apportant aucune information nouvelle au processus utilisateur, pouvait recevoir 200. Si ALLO n’était pas mise en œuvre parce qu’elle n’avait aucune pertinence pour le système local, le serveur devait tout de même fournir une fin positive afin qu’un client élémentaire sache qu’il pouvait poursuivre. Le code choisi était 202, illustré par le texte « No storage allocation necessary ».

La définition générique de 202 est encore plus instructive : commande non mise en œuvre, superflue sur ce site. Ce n’est pas la négation de la requête dans la classe des erreurs. C’est une réponse positive qui nie la nécessité de l’action demandée. FTP séparait ainsi deux propositions que les tableaux de bord modernes confondent volontiers : « le protocole m’autorise à passer à l’étape suivante » et « la ressource annoncée a été engagée ».

Une réponse 502 aurait indiqué qu’une action non spécifique au site n’était pas mise en œuvre. 504 désignait un paramètre non pris en charge. Le choix de 202 pour ALLO n’était donc pas une manière vague de masquer un échec. Il encode le jugement local selon lequel l’allocation préalable n’est pas pertinente, tout en protégeant l’interopérabilité avec un client qui connaît la commande.

Même 200 ne doit pas être surinterprété. Le RFC l’associe précisément aux commandes dont la réussite n’offre pas forcément d’information nouvelle. Un serveur peut avoir effectué une réservation réelle ; un autre peut avoir validé une opération locale dont les effets ne sont pas décrits comme un reçu durable. Le code seul ne révèle ni les blocs engagés, ni leur durée, ni la manière dont un quota ou une écriture concurrente pourra agir.

La capacité attendait derrière STOR

ALLO n’envoie pas le fichier. Son rôle est préparatoire. STOR demande ensuite au serveur d’accepter les données sur la connexion dédiée et de les conserver sous un nom. Si le fichier existe, la spécification prévoit son remplacement ; sinon, sa création. C’est là que le plan rencontre le chemin de données, les permissions, la capacité et les règles du système de fichiers.

Le tableau des réponses du RFC 959 montre plusieurs temps. 125 signifie que la connexion de données est déjà ouverte et que le transfert commence. 150 annonce que le statut du fichier est correct et qu’une connexion va être ouverte. Ces réponses préliminaires ne terminent pas l’histoire. 226 ou 250 peuvent clore positivement le travail ; 425, 426, 451, 551 ou 552 décrivent d’autres issues, auxquelles s’ajoutent notamment 450, 452 et 553.

Deux codes rendent la frontière de preuve particulièrement nette. 452 dit que l’action demandée n’a pas été effectuée faute d’espace dans le système. 552 dit que l’action sur le fichier a été abandonnée parce qu’une allocation — par exemple celle du répertoire ou du jeu de données — a été dépassée. Une conversation peut donc contenir un ALLO positif puis un STOR incapable d’aboutir. Ce n’est pas une contradiction du protocole ; c’est la conséquence exacte de la séparation entre compatibilité préparatoire et exécution.

La même prudence réapparaît dans le RFC 3659. À propos des permissions publiées par les listes lisibles par machine, il avertit qu’un indicateur d’écriture ne garantit jamais que la commande appropriée réussira. L’espace disponible et d’autres limites propres au système peuvent faire échouer l’opération. L’indicateur n’est qu’un guide. Cette remarque ne redéfinit pas ALLO, mais elle rappelle qu’une possibilité annoncée n’est pas un résultat observé.

Une commande optionnelle pouvait rester accessible

Le RFC 1123, qui formula les exigences applicatives des hôtes en 1989, plaça la prise en charge serveur de ALLO dans la colonne facultative. Cette optionnalité ne signifiait pas que le mot devait devenir invisible. Le programme FTP utilisateur devait offrir QUOTE, une voie permettant d’envoyer une chaîne arbitraire au serveur et d’afficher ses réponses.

La discussion cite justement SITE et ALLO : un utilisateur pouvait atteindre une fonction propre au système ou optionnelle même si son client ne la comprenait pas comme une commande de premier rang. Cette solution distribuait l’évolution. Le client générique n’avait pas besoin d’incorporer toute particularité ; le serveur restait libre d’exposer ce qui comptait localement ; l’utilisateur conservait un passage explicite.

Le registre IANA des commandes et extensions FTP répertorie toujours ALLO comme commande de base « Allocate » et renvoie au RFC 959. Cette inscription fixe un vocabulaire et une référence. Elle ne constitue pas un recensement des serveurs qui réservent réellement des octets, ni une mesure de l’espace libre, ni un journal de transferts achevés.

Ce qu’un journal doit conserver

Un enregistrement limité à « ALLO successful » détruit l’information qui rendait le mécanisme intelligible. Il faut garder la ligne de commande exacte, ses deux entiers éventuels, la représentation active, le code numérique et le texte complet de la réponse. 200 et 202 appartiennent à la même famille positive, mais ils ne racontent pas la même décision.

Il faut surtout relier cette préparation au STOR ou à APPE qui suit. La connexion de données s’est-elle ouverte ? Combien d’octets ont traversé ? Une réponse préliminaire a-t-elle été suivie d’une fin positive ou d’un abandon ? Le fichier attendu existe-t-il, avec quelle taille et quel condensat ? Le quota et l’espace libre vus par le serveur au moment pertinent confirment-ils ou contredisent-ils l’hypothèse ?

Le protocole ne promet pas à lui seul la durabilité à long terme, la réplication ou la lisibilité future. Même une fin positive doit être rapprochée de l’objet créé lorsque l’enjeu est élevé. L’histoire de ALLO enseigne précisément à ne pas demander à une étape ce que seule la suivante peut prouver.

Sources