Vérifier la réponse FTP finale avant de faire confiance à un envoi

Un client FTP peut accepter une commande put bien avant que le serveur ait reçu le fichier, et c'est dans l'écart entre ces deux événements que logent la plupart des mystères d'envoi. Quatre étapes doivent s'achever : le fichier local est lu, le serveur accepte la demande de stockage, la connexion de données transporte les octets, et le transfert atteint une réponse finale positive. Comparer les étapes est plus utile que comparer les clients, car une connexion qui fonctionne et un nom de fichier qui apparaît s'arrêtent tous deux avant l'arrivée.

Réponse préliminaire contre réponse finale

Pour STOR, une réponse 125 ou 150 est préliminaire. Elle indique que le serveur veut bien essayer et qu'une connexion de données s'ouvre, non que l'objet existe sous sa forme finale. L'opération n'est terminée que lorsque le transfert atteint une réponse positive d'achèvement, généralement 226 ou 250, dans le contexte de cette opération.

Une 426 signifie que le transfert a été interrompu, et un numéro imprimé par une autre commande n'est pas le résultat de cet envoi. Lisez la réponse qui appartient au STOR, pas le dernier numéro à l'écran. Si le client quitte avant l'arrivée de cette réponse, vous n'avez aucune preuve d'achèvement.

Connexion de contrôle contre connexion de données

L'authentification et le listage de répertoire utilisent la connexion de contrôle. Les octets utilisent une connexion de données séparée, dont le point d'aboutissement est négocié à chaque transfert. Une connexion réussie prouve le chemin de contrôle et ne dit rien sur la joignabilité de l'adresse de données depuis le client.

Lorsque le serveur ne peut pas ouvrir la connexion de données, examinez le point d'aboutissement négocié et le chemin autorisé. Le mode passif exige encore une adresse de données et un port utilisables, et un pare-feu ou un dispositif NAT entre le client et le serveur peut autoriser la session de contrôle tout en bloquant la plage de données. Lorsque le serveur refuse plutôt la demande de stockage, regardez le nom de chemin distant, les permissions ou les limites de stockage. Aucune des deux branches ne s'explique par le fait que la connexion de contrôle s'est authentifiée.

FTP sur TLS contre SFTP

FTP sur TLS reste du FTP : deux connexions, des réponses FTP et une montée en TLS sur chacune. SFTP est un sous-système SSH avec une seule connexion et un jeu de commandes entièrement différent. Ils partagent un but et presque rien d'autre, aussi un diagnostic qui passe de l'un à l'autre commence-t-il souvent par comparer les mauvais journaux.

Ne désactivez pas TLS pour laisser un auxiliaire intermédiaire inspecter la session, et ne traitez pas un échec SFTP comme un problème de réponses FTP. Le manuel de curl documente le TLS explicite, le mode passif et les options d'envoi si vous avez besoin d'un test scripté, et il fait référence pour ce que chaque option change réellement.

Choisissez le protocole que le service propose réellement avant de le déboguer. Un serveur qui ne parle que SFTP ne produira jamais de réponse 226, quelle que soit la configuration du client.

Un nom de fichier visible contre un objet stocké

Un nom de fichier visible peut représenter un objet incomplet, surtout après un transfert interrompu ou un client qui a quitté trop tôt. Demandez au propriétaire du service de comparer la taille du fichier de test prévu et l'empreinte de contenu fiable avec l'objet stocké lorsque la préservation des octets est attendue.

Les modes binaire et ASCII sont une autre comparaison qui change le résultat. Le mode ASCII peut traduire les fins de ligne, si bien que les octets stockés diffèrent du fichier local alors même que le transfert a réussi. Gardez le mode binaire pour un contrôle octet par octet, et n'ajoutez pas d'options de conversion pour faire paraître différent un transfert échoué.

Un STOR ordinaire peut remplacer un fichier existant, et l'autorisation de se connecter ou de lister un répertoire n'établit pas le droit d'y créer ou d'y remplacer un objet. Utilisez pour le test un nom distant jamais employé auparavant.

Que comparer avant de réessayer

N'ajoutez pas, ne reprenez pas et ne répétez pas un envoi à l'aveugle sur un fichier partiel incertain. Convenez avec le propriétaire s'il faut redémarrer sous un nouveau nom, utiliser la procédure de récupération prise en charge par le service, ou supprimer l'objet de test échoué.

Écrivez le résultat comme l'une de quatre affirmations : la lecture locale a échoué, le stockage a été refusé, le transfert de données a été interrompu, ou le transfert s'est achevé et les octets stockés correspondaient. Ce relevé est un résultat plus solide que de changer le shell, le VPN et les réglages FTP en même temps jusqu'à voir apparaître un nom de fichier, et il indique à la personne suivante quelle étape inspecter. Conservez le texte de réponse nettoyé avec cette affirmation. Alors une nouvelle tentative est une décision, pas un réflexe.