Résumé

  • Le premier mécanisme de reprise associait une position propre à l’émetteur à une position propre au récepteur, avec l’état de stockage et de conversion nécessaire pour repartir exactement.
  • REST STREAM transforma ensuite le marqueur en nombre d’octets omis au début du transfert suivant. Cette coordonnée restait celle d’une représentation, pas celle d’une version du fichier.
  • L’exemple de RFC 3659 ne reprend qu’après vérification que le fichier du serveur n’a pas changé. REST n’effectue pas ce contrôle d’identité.

Une réponse positive à une question trop étroite

Un téléchargement s’interrompt après 802 816 octets. Le client revient, choisit TYPE I, envoie REST 802816, reçoit 350, puis demande RETR. Le serveur accepte de poursuivre à la position indiquée.

Il n’a pourtant répondu qu’à une question de position. Le chemin distant peut désormais désigner une autre version. Le fragment local peut venir d’une session antérieure ou avoir été altéré. Même une taille identique ne suffit pas à rapprocher ces deux morceaux. Un suffixe neuf peut donc s’assembler sans erreur de transport à un préfixe ancien.

Quand une position ne pouvait pas être un entier universel

RFC 765 présente déjà la reprise comme un moyen de récupérer après une défaillance. La commande REST ne déplace aucun contenu : elle positionne le serveur sur un marqueur, avant la commande de service interrompue.

Cette indirection correspondait à la diversité que FTP devait absorber. Le format stocké, l’octet logique et l’octet de transfert n’étaient pas nécessairement les mêmes. TYPE choisissait la représentation, STRU la structure, MODE le format du flux. Une adresse de disque sur une machine n’était pas une langue commune pour une autre.

RFC 959 conserva trois modes. Block et Compressed encadraient le flux, donc pouvaient y insérer des blocs de reprise distincts des données. L’émetteur plaçait un état qu’il saurait relire ; le récepteur l’associait à son propre emplacement de sauvegarde. La coordination portait sur une paire de repères, pas sur un compteur mondial.

Le point durable et l’état invisible du convertisseur

RFC 1123 corrigea la description du message 110. ssss représentait une position dans le système émetteur et rrrr la position correspondante chez le récepteur. Leur encodage pouvait rester privé, puisque chaque valeur reviendrait au système qui l’avait produite.

Avant de répondre avec sa position, le récepteur devait pousser les données précédentes vers un stockage stable. Sans cette précaution, un marqueur survivrait peut-être au crash tandis que les octets qu’il prétendait garantir disparaîtraient.

Le repère pouvait également inclure un état de transformation. En TYPE A, un hôte peut convertir CR LF en un seul LF local. Si le marqueur arrive entre CR et LF, la reprise doit se souvenir que CR a déjà été vu et supprimé. La position du fichier seule ne contient pas cette mémoire.

RFC 1123 ajouta donc deux échecs précis : 554 lorsque la position ne peut être rétablie, 555 lorsque TYPE ou STRU ne correspond plus au fichier partiel. La validité syntaxique d’un marqueur ne lui donne pas un contexte valide.

Le flux simple rendit le compteur possible

Ce mécanisme complet était lourd. En 1989, RFC 1123 citait Restart, ABOR et Block mode comme fonctions utiles de robustesse mais peu répandues, et ne plaçait pas REST dans le minimum obligatoire. Ce constat historique ne mesure pas les logiciels actuels.

En mode Stream, un marqueur explicite serait confondu avec les données. RFC 3659 normalisa donc REST STREAM comme un nombre décimal d’octets que le prochain transfert ne doit pas renvoyer.

Cette capacité s’annonce avec FEAT, défini par RFC 2389. La ligne REST STREAM indique une sémantique comprise par le serveur ; elle ne certifie ni l’immuabilité d’un chemin ni l’origine d’un fragment local.

Le compteur demeure dépendant de la représentation. Dans l’exemple de RFC 3659, un même texte mesure 1 830 octets avec TYPE I et 1 942 avec TYPE A, parce que les fins de ligne sont modifiées pendant la transmission. La valeur de reprise se situe dans le flux produit par les paramètres courants. Elle ne correspond pas toujours directement à l’offset natif du stockage.

Lors d’un envoi repris, SIZE aide le client à savoir combien le serveur a correctement reçu et sauvegardé. Il fournit une longueur de transfert, jamais une empreinte du préfixe.

La condition que l’exemple ne cache pas

Avant son REST 802816, RFC 3659 précise que le transfert précédent utilisait TYPE I et que le fichier sur le serveur a été vérifié inchangé. La formulation est essentielle : le protocole ne déduit pas cette continuité du nombre.

Pour RETR, le client garde la responsabilité de fusionner les nouvelles données avec son fichier partiel. Pour STOR, les limites sont plus strictes. Le résultat devient indéfini si l’opération ne complète pas réellement le transfert précédemment échoué, si la position n’est pas à la fin des données stockées, ou si le suffixe n’étend pas le fichier au moins jusqu’à son ancienne longueur.

APPE n’offre pas une autre interprétation : lorsqu’il est accepté après REST, il doit agir comme STOR à l’emplacement choisi.

L’ordre des commandes appartient au checkpoint

REST doit être la dernière commande avant RETR ou STOR. Le serveur peut accepter le nombre avec 350 puis ne découvrir qu’à la commande suivante qu’il est hors limite ou impossible à appliquer. Si le client ne réussit pas à envoyer cette commande, il doit répéter REST plutôt que supposer la position encore active.

La reprise complète réside donc dans le fragment, les paramètres de représentation, la capacité annoncée, le marqueur, sa persistance, l’ordre du dialogue et la preuve externe que le chemin désigne toujours le même objet.

Portée des sources

RFC 765 documente l’origine, RFC 959 les modes, RFC 1123 les positions appariées et le stockage stable, RFC 2389 la découverte, RFC 3659 le décalage STREAM et SIZE. Ces textes ne donnent ni taux de déploiement actuel ni garantie de conservation des versions. La reprise FTP n’est pas une authentification, un hachage, un instantané de stockage ou une livraison exactement une fois.