Controlla la risposta FTP finale prima di fidarti di un caricamento

Un client FTP può accettare un comando put molto prima che il server abbia ricevuto il file, e la distanza tra questi due eventi è il luogo in cui vivono la maggior parte dei misteri del caricamento. Devono completarsi quattro fasi: si legge il file locale, il server accetta la richiesta di archiviazione, la connessione dati trasporta i byte e il trasferimento raggiunge una risposta finale positiva. Confrontare le fasi è più utile che confrontare i client, perché un accesso che funziona e un nome di file che compare si fermano entrambi prima del traguardo.

Risposta preliminare contro risposta finale

Per STOR, una risposta 125 o 150 è preliminare. Dice che il server è disposto a provare e che si apre una connessione dati, non che l'oggetto esista nella sua forma finale. L'operazione è conclusa solo quando il trasferimento raggiunge una risposta positiva di completamento, di solito 226 o 250, nel contesto di quell'operazione.

Una 426 significa che il trasferimento è stato interrotto, e un numero stampato da un altro comando non è il risultato di questo caricamento. Leggi la risposta che appartiene al STOR, non l'ultimo numero sullo schermo. Se il client esce prima che arrivi quella risposta, non hai alcuna prova di completamento.

Connessione di controllo contro connessione dati

L'autenticazione e l'elenco delle directory usano la connessione di controllo. I byte usano una connessione dati separata, e il suo punto finale viene negoziato a ogni trasferimento. Un accesso riuscito dimostra il percorso di controllo e non dice nulla sulla raggiungibilità dell'indirizzo dati dal client.

Quando il server non riesce ad aprire la connessione dati, esamina il punto finale negoziato e il percorso consentito. La modalità passiva richiede comunque un indirizzo dati e una porta utilizzabili, e un firewall o un dispositivo NAT tra client e server può consentire la sessione di controllo bloccando l'intervallo dati. Quando invece il server rifiuta la richiesta di archiviazione, guarda il nome del percorso remoto, i permessi o i limiti di archiviazione. Nessuno dei due rami è spiegato dal fatto che la connessione di controllo si sia autenticata.

FTP su TLS contro SFTP

FTP su TLS è ancora FTP: due connessioni, risposte FTP e un aggiornamento a TLS su ciascuna. SFTP è un sottosistema di SSH con una sola connessione e un insieme di comandi del tutto diverso. Condividono uno scopo e quasi nient'altro, perciò una diagnosi che passa dall'uno all'altro di solito inizia confrontando i registri sbagliati.

Non disattivare TLS per lasciare che un aiutante intermedio ispezioni la sessione, e non trattare un guasto SFTP come un problema di risposte FTP. Il manuale di curl documenta TLS esplicito, modalità passiva e opzioni di caricamento se ti serve una prova con script, ed è il riferimento per ciò che ogni opzione cambia davvero.

Scegli il protocollo che il servizio offre davvero prima di eseguirne il debug. Un server che parla solo SFTP non produrrà mai una risposta 226, per quanto il client sia configurato.

Un nome di file visibile contro un oggetto memorizzato

Un nome di file visibile può rappresentare un oggetto incompleto, soprattutto dopo un trasferimento interrotto o un client uscito troppo presto. Chiedi al proprietario del servizio di confrontare la dimensione del file di prova previsto e l'impronta del contenuto attendibile con l'oggetto memorizzato quando si prevede la conservazione dei byte.

Le modalità binaria e ASCII sono un altro confronto che cambia il risultato. La modalità ASCII può tradurre i fine riga, così i byte memorizzati differiscono dal file locale anche se il trasferimento è riuscito. Mantieni la modalità binaria per un controllo byte per byte, e non aggiungere opzioni di conversione per far sembrare diverso un trasferimento fallito.

Un normale STOR può sostituire un file esistente, e il permesso di accedere o di elencare una directory non stabilisce il permesso di crearvi o sostituirvi un oggetto. Usa per la prova un nome remoto mai usato prima.

Cosa confrontare prima di riprovare

Non aggiungere, non riprendere e non ripetere un caricamento alla cieca su un file parziale incerto. Concorda con il proprietario se ripartire con un nome nuovo, usare la procedura di ripristino supportata dal servizio o rimuovere l'oggetto di prova fallito.

Scrivi l'esito come una di quattro affermazioni: la lettura locale è fallita, l'archiviazione è stata rifiutata, il trasferimento dati è stato interrotto, oppure il trasferimento è terminato e i byte memorizzati coincidevano. Quel verbale è un risultato più solido che cambiare insieme shell, VPN e impostazioni FTP finché non compare un nome di file, e dice alla persona successiva quale fase ispezionare. Conserva il testo della risposta ripulito insieme a quell'affermazione. Allora un nuovo tentativo è una decisione, non un riflesso.