Résumé

  • Le FTP historique insérait des marqueurs dans les modes bloc ou compressé. La réponse 110 MARK mettait en correspondance une position de l'émetteur et un état du récepteur validé après écriture stable.
  • Ces valeurs étaient volontairement propres aux systèmes. Une conversion de CRLF vers LF pouvait obliger le récepteur à mémoriser jusqu'à l'état intermédiaire « CR déjà consommé ».
  • RFC 3659 simplifia le cas STREAM en nombre d'octets à omettre lors du transfert immédiatement suivant, sans faire de cet offset une preuve de version, d'intégrité ou d'achèvement.

Deux conversations se déroulaient en même temps

FTP ne confond pas le dialogue avec le fichier. Les commandes et leurs réponses numérotées passent par une connexion de contrôle ; les données empruntent une autre connexion. Cette architecture permettait au récepteur d'annoncer un point de reprise sur le premier canal pendant que le second continuait à transporter le fichier.

RFC 1123 corrige la forme et le sens de cette annonce. ssss désigne un marqueur apparu dans le flux et encodant une position que le système émetteur comprend. rrrr représente la position correspondante dans le système de fichiers du récepteur. Chaque valeur reste produite et interprétée par son propriétaire.

Le client n'avait donc pas à comparer les chaînes, encore moins à les convertir en une unité commune. Il devait garder leur correspondance. Il ne devait pas non plus attendre la réponse 110 avant de poursuivre l'envoi : les confirmations pouvaient arriver de manière asynchrone. Le dernier couple reçu décrivait une limite récupérable ; il n'était pas un mécanisme de régulation du débit.

Cette dissociation explique la différence entre progression et reprise. Un compteur d'interface peut dire combien d'octets ont franchi une socket. Il ne dit pas quel état le programme émetteur peut reconstruire, ni jusqu'où le récepteur a engagé une représentation durable.

Le mode bloc fabriquait des repères visibles

RFC 959 distingue les paramètres de représentation, de structure et de mode de transmission. En mode STREAM, la fermeture de la connexion de données marque normalement la fin. Le texte souligne le défaut de cette convention : une fermeture prématurée peut ressembler à une fin normale.

Le mode bloc possédait sa propre ponctuation. Chaque bloc commençait par un en-tête de trois octets : un descripteur de huit bits et un compteur de seize bits. La valeur de descripteur 16 annonçait un marqueur de reprise. Sa charge était une chaîne imprimable, sans espace, intégrée au flux FTP mais distincte des données du fichier.

Le repère n'était donc ni une déduction tirée des numéros de séquence TCP, ni un octet magique choisi dans le contenu. Il appartenait au langage de transfert. Les modes bloc et compressé savaient également exprimer la fin du fichier sans fermer la connexion et pouvaient porter ces marqueurs ; le mode STREAM ancien ne le pouvait pas.

Cette capacité avait un coût : les deux processus de transfert devaient comprendre l'encadrement FTP. Mais elle donnait au protocole une place explicite où rattacher l'état de récupération, même lorsque la représentation réseau ne coïncidait pas avec le stockage local.

Le récepteur devait d'abord engager les données

RFC 1123 impose un ordre prudent. Quand un marqueur arrive, le récepteur doit faire écrire sur un stockage stable tout ce qui le précède, puis seulement calculer rrrr. Le jeton ne signifie donc pas « j'ai lu jusqu'ici en mémoire ». Il signifie que le récepteur sait revenir à un état où la partie antérieure demeure disponible selon ses garanties locales.

Le mot stable ne promet pas une réplication universelle ni une conservation sans limite. Il lie la vérité du marqueur au domaine que le récepteur maîtrise. Si le serveur produit rrrr, il doit pouvoir réinterpréter plus tard ce même rrrr; nul intermédiaire n'a besoin de connaître son format.

Le User-FTP devait aussi rendre le couple durable. RFC 1123 suggère un fichier de contrôle vide créé au début, enrichi au fil des réponses, puis supprimé après réussite. Le dernier couple complet devient ainsi le candidat de reprise après un arrêt brutal. La suppression finale empêche un état ancien de paraître encore valable pour une opération suivante.

Le cycle de vie fait partie de la sémantique. Un jeton sans transfert d'origine, sans direction, sans paramètres et sans expiration est seulement une chaîne réutilisable au mauvais endroit.

Un demi-retour à la ligne suffisait à casser l'arithmétique

L'exemple le plus instructif de RFC 1123 ne concerne pas un disque exotique, mais une nouvelle ligne. En TYPE ASCII, le réseau transporte CRLF. Un hôte peut le stocker comme un seul LF. Si un marqueur survient entre CR et LF, le récepteur a déjà consommé CR sans avoir achevé la conversion.

Son état de reprise doit alors inclure la mémoire « CR vu et écarté ». Revenir uniquement à une position numérique risquerait de doubler, de perdre ou de déformer la coupure de ligne. Le point de fichier et l'état de la transformation forment ensemble la vraie position.

Ce cas rend concrète l'hétérogénéité visée par FTP. RFC 959 évoque des codes de caractères, tailles de mots et octets logiques différents. La représentation transmise servait de terrain commun ; elle n'effaçait pas les modèles de stockage. Les marqueurs opaques permettaient une précision locale sans imposer un système de coordonnées mondial.

L'opacité n'était donc pas un défaut de documentation. C'était une limite d'autorité : l'émetteur interprète son propre repère, le récepteur interprète le sien, et le protocole conserve le lien entre les deux.

Le sens du couple dépendait de la direction

Lors d'un envoi utilisateur-vers-serveur, le client place ssss dans le flux. Le serveur stabilise ce qu'il a reçu, produit rrrr et renvoie l'égalité. Pour repartir, le client retrouve sa propre position avec ssss et adresse REST rrrr au serveur.

Pour un téléchargement, le serveur génère le marqueur du flux. Le client stabilise sa copie partielle et mémorise sa position locale. À la reprise, il restaure localement cet état et restitue au serveur le jeton créé par le serveur.

FTP savait même organiser un transfert entre deux serveurs sous la conduite d'un troisième processus. Celui-ci gardait la paire sans devoir comprendre les systèmes de fichiers distants. Il renvoyait à chaque serveur uniquement le jeton que ce serveur avait produit.

Le coordinateur détenait la relation, pas les coordonnées. Cette économie de connaissance est élégante, mais fragile si l'on mélange les paires de deux fichiers ou de deux sessions. Un marqueur n'est sûr que dans son contexte d'origine.

REST préparait l'action suivante

REST est une commande de paramétrage et de service, pas un transfert autonome. La réponse positive 350 indique que le serveur a enregistré un marqueur et attend une commande d'exécution. Aucun octet supplémentaire n'est alors garanti ; aucune intégrité n'est établie.

Dans le modèle de RFC 959, la suite est RETR, STOR ou éventuellement APPE. RFC 1123 sépare deux erreurs. 554 signale que la position demandée ne peut pas être appliquée ; 555 révèle une incompatibilité du type ou de la structure avec le fichier existant. Savoir où reprendre ne suffit pas si l'on ne sait plus sous quelle représentation.

Cette construction à deux commandes laisse aussi un piège : une valeur REST enregistrée peut survivre à l'échec de la commande qui devait la consommer. La standardisation ultérieure rendra la proximité entre les deux opérations obligatoire.

REST STREAM choisit le cas courant

RFC 3659 documente la reprise sans marqueur inséré dans le flux STREAM. L'argument devient un entier décimal : le nombre d'octets que le transfert immédiatement suivant ne doit pas renvoyer. REST 802816, puis RETR, reprend donc après 802 816 octets ; REST 0 annule l'effet et redemande le fichier entier.

Cette convention convient particulièrement à TYPE I, où les octets transmis fournissent une coordonnée simple. Elle ne reproduit pas toute la richesse du couple ancien. Elle ne contient ni état de conversion, ni identifiant de version, ni preuve que le préfixe conservé par le client est correct.

RFC 3659 borne alors l'autorité par la séquence. REST doit être la dernière commande avant RETR ou STOR. Si la commande de transfert n'a pas pu partir, le client doit réémettre REST. S'il ne veut plus reprendre, il doit envoyer REST 0. Une syntaxe numérique peut être acceptée immédiatement alors qu'un offset impossible ne sera rejeté qu'au moment où la commande suivante nommera le fichier.

Le 350 demeure donc une permission conditionnelle de continuer le dialogue, pas un reçu sur le résultat.

Reprendre un dépôt pouvait réécrire le mauvais objet

Pour RETR, le client contrôle l'assemblage. Il peut demander un chevauchement, éliminer sa copie ou vérifier le résultat. Avec STOR, c'est le serveur qui écrit dans un fichier partiel. L'offset acquiert alors une capacité de modification.

RFC 3659 réserve cet usage à l'achèvement d'un transfert précédemment interrompu. Si le marqueur ne correspond pas à la fin actuelle des données stockées, le résultat est indéfini. Il l'est aussi si la suite fournie ne restaure même pas la taille antérieure. APPE, lorsqu'il est toléré après REST, doit se comporter comme STOR au point indiqué plutôt que d'ajouter aveuglément.

Le texte empêche ainsi REST de devenir un éditeur arbitraire de fichier distant. Il ne crée toutefois aucune transaction. Une seconde panne peut laisser un nouvel état partiel. La politique locale doit décider du nom, des droits, de la durée de vie et de la suppression de ces objets.

L'offset ne nommait pas la version

Un nombre exact peut être appliqué au mauvais contenu. RFC 3659 recommande de relever la date de modification du fichier avant le transfert initial et de la comparer avant RETR. Pour STOR, le client peut comparer la source qu'il s'apprête à poursuivre avec le fichier partiel. Les faits MLST apportent davantage d'indices.

Ces indices restent bornés. Les horloges peuvent diverger. Une date peut changer sans différence finale, et un contenu peut changer puis revenir. Une taille identique ne garantit pas des octets identiques. La reprise doit donc distinguer l'invalidation plausible de la preuve d'intégrité.

Après assemblage, un contrôle du fichier entier reste nécessaire lorsque l'exactitude compte. Le marqueur prouve au mieux que les deux côtés ont accepté un point de continuation selon leurs règles ; il ne certifie pas l'objet reconstruit.

Une annonce de capacité n'était pas une promesse de réussite

Un serveur conforme au mécanisme STREAM de RFC 3659 annonce REST STREAM dans FEAT. Cette chaîne exacte évite de confondre la variante numérique avec une prise en charge limitée aux modes bloc ou compressé.

Le registre IANA des commandes et extensions FTP conserve deux traces : REST dans la base avec RFC 959 et RFC 1123, puis REST+ pour STREAM avec RFC 3659. Le registre décrit une grammaire et une exigence de conformité. Il ne mesure ni le déploiement actuel, ni l'état d'un fichier, ni la qualité d'une mise en œuvre.

L'annonce répond à « ce serveur comprend-il cette forme ? ». Il reste à répondre à « s'agit-il encore du même fichier ? », « ce préfixe est-il le bon ? » et « le résultat final est-il exact ? ».

La reprise resta sûre tant qu'elle resta moins puissante que le fichier

Le modèle historique donnait à chaque système la maîtrise de sa position et de sa conversion. Le modèle STREAM réduisit la coordination à un offset pratique, mais exigea davantage d'indices autour de l'objet. Aucun des deux ne fit du checkpoint une autorité supérieure au fichier terminé.

C'est la leçon durable. Une reprise économise le travail déjà accompli en acceptant de conserver un état intermédiaire. Plus cet état vit longtemps, plus il faut savoir qui l'a produit, à quel objet il se rapporte, quelles transformations l'entouraient et quelle preuve l'invalide.

Sources et limites de preuve

Ces sources établissent les mécanismes normalisés et leur histoire documentaire. Elles ne mesurent pas l'usage contemporain, le taux de succès d'un produit ni l'intégrité d'un transfert réel. Une entrée IANA ou un FEAT ne prouve donc jamais qu'une reprise précise est sûre.