Résumé

  • Avec STRU R et MODE S, FTP employait une sentinelle tout-à-un suivie de 1 pour EOR, de 2 pour EOF et de 3 lorsque fin d’enregistrement et fin de fichier coïncidaient.
  • Si cette sentinelle était une donnée réelle, elle devait être répétée. Le décodage exigeait donc le contexte négocié et un état conservé entre les lectures.
  • BLOCK et COMPRESSED plaçaient les mêmes frontières dans des descripteurs. La structure appartenait au fichier ; ni les segments TCP, ni les lignes visibles, ni le stockage local ne pouvaient la deviner seuls.

Attendre le deuxième octet

Le cas le plus simple est aussi le plus révélateur. Deux octets tout-à-un consécutifs ne représentent pas deux commandes : ils restituent un seul octet de données. La répétition rend au fichier la valeur que le protocole avait réservée comme caractère d’échappement.

Avec un autre second octet, le sens bascule. La valeur 1 annonce la fin d’un enregistrement ; 2, la fin du fichier ; 3, les deux au même endroit. RFC 765 puis RFC 959 conservent exactement cette convention du mode STREAM.

La première sentinelle n’est donc jamais une preuve suffisante. Il faut son successeur et le couple de paramètres déjà choisi sur la connexion de contrôle. Un analyseur qui livre immédiatement la sentinelle comme donnée perd les limites. Celui qui la transforme immédiatement en commande détruit les valeurs littérales.

La structure et le transport répondaient à deux questions

STRU R disait que le fichier était une suite d’enregistrements. MODE S disait comment cette suite traversait la connexion de données. FTP n’attendait pas du flux ordonné qu’il fournisse gratuitement des frontières applicatives.

Les textes imposaient un EOR explicite pour chaque enregistrement, y compris le dernier. Le système émetteur convertissait sa notation locale—compteur, marque physique ou autre convention—vers la représentation FTP. Le destinataire réalisait l’opération inverse vers son propre stockage.

Cette traduction répondait à une difficulté historique concrète. Un champ de longueur issu d’un système IBM n’avait aucune raison d’être compris par un autre hôte. Le standard portait le sens commun, pas le détail du disque d’origine.

Une citation réversible de la sentinelle

Le doublement est un mécanisme de citation. Une valeur de l’alphabet est réservée pour introduire du contrôle ; la même valeur répétée signifie qu’il faut la lire littéralement. Le flux brut peut donc être plus long que les données reconstruites sans qu’il y ait compression, copie supplémentaire ou corruption.

Les quatre suites autorisées distinguent proprement donnée, EOR, EOF et EOR+EOF. Le code combiné évite de créer un faux enregistrement vide après le dernier. La valeur doublée garantit qu’aucun octet possible n’est interdit au fichier.

L’analyseur doit garder un état « échappement en attente ». Il ne peut supposer que les deux octets arrivent dans le même tampon. RFC 9293 décrit TCP comme un flux fiable et ordonné ; les limites des segments et des appels de lecture ne sont pas celles des enregistrements FTP. C’est une conséquence de l’association des deux contrats : la paire doit survivre à n’importe quel découpage local.

Sous STRU F, la même valeur redevenait ordinaire

La portée de la négociation apparaît nettement en structure de fichier. Avec STRU F et STREAM, tous les octets sont des données, et la fermeture de la connexion de données indique EOF. La sentinelle tout-à-un n’y ouvre aucune grammaire spéciale.

Avec STRU R, les paires de contrôle deviennent actives. Une capture privée de la chronologie STRU/MODE ne permet donc pas d’interpréter sûrement les mêmes octets. Même un hachage du flux brut ne dit pas combien d’octets de fichier et combien de frontières seront reconstruits.

La fermeture ne suffit pas non plus à prouver qu’un transfert structuré était complet. Le dernier EOR devait être déclaré ; un état d’échappement restant à la fermeture révèle une représentation inachevée, même si TCP n’a signalé aucune perte.

Les autres modes déplaçaient les marqueurs

En mode BLOCK, un descripteur et une longueur précédaient chaque bloc. Un bit marquait EOR, un autre EOF ; les deux pouvaient être présents ensemble. D’autres bits signalaient des données suspectes ou un marqueur de reprise.

Le mode COMPRESSED gardait des descripteurs pour les frontières tout en ajoutant ses représentations de répétition et de remplissage. Le sens « fin d’enregistrement » restait stable, mais sa forme sur le fil dépendait du mode.

Il faut donc conserver trois vues : la négociation, l’encodage brut et la carte décodée des enregistrements. Comparer seulement les octets utiles efface la preuve de structure ; comparer seulement le flux brut confond des formes différentes d’un même résultat logique.

Une fin de ligne n’était pas un EOR universel

FTP séparait aussi la ligne imprimable de l’enregistrement. Un fichier ASCII sans structure d’enregistrements pouvait employer CRLF ; un texte EBCDIC, NL. Avec STRU R, les EOR étaient explicites.

Dans certains fichiers, ligne et enregistrement coïncidaient. Ce hasard n’autorisait pas à remplacer l’un par l’autre. Un enregistrement pouvait contenir plusieurs lignes, une ligne pouvait être une convention de présentation, et des données binaires pouvaient n’avoir aucune ligne.

RFC 959 demandait l’acceptation de la structure d’enregistrements pour les textes ASCII et EBCDIC et recherchait des transformations utiles et inversibles entre hôtes. La lisibilité du résultat ne prouvait jamais que les divisions d’origine avaient survécu.

Une obligation devenue plus étroite

RFC 1123 limita ensuite l’obligation : la structure d’enregistrements n’était requise que pour les hôtes dont le système de fichiers la supportait. Un autre hôte pouvait néanmoins accepter STRU R et enregistrer littéralement le flux.

Cette option protège éventuellement la syntaxe encodée, mais elle ne signifie pas que les applications locales voient des enregistrements natifs. Il faut distinguer reconstruction, archivage du flux, aplatissement avec perte et refus. Un unique indicateur « succès » cache ces résultats incompatibles.

RFC 5797 et le registre IANA des commandes FTP maintiennent STRU et MODE dans le vocabulaire de base. Ils ne testent ni l’argument R, ni la machine d’état, ni la restitution après stockage.

Prouver le décodage

Une trace exploitable associe TYPE, STRU, MODE, hachage brut, hachage décodé, longueurs, positions EOR/EOF, état final de l’analyseur et résultat de la reconstruction. Elle ne transforme jamais une frontière de paquet en frontière d’enregistrement.

Les tests doivent couper la paire entre deux lectures, entourer chaque code par une sentinelle littérale doublée et comparer STREAM à BLOCK pour la même carte logique. Un échappement suspendu, un second octet impossible, un EOR final absent ou un changement de mode sans remise à zéro sont des défauts de sens, même si chaque octet est arrivé.

L’octet devait paraître deux fois parce que FTP voulait garder à la fois le contrôle et la donnée. La solution n’était fiable qu’à condition de préserver le contexte qui les séparait.

Sources