Comprova la resposta final de FTP abans de confiar en una pujada

Un client FTP pot acceptar una ordre put molt abans que el servidor hagi rebut el fitxer, i l'esvoranc entre aquests dos esdeveniments és on viuen la majoria dels misteris de la pujada. S'han de completar quatre etapes: es llegeix el fitxer local, el servidor accepta la sol·licitud d'emmagatzematge, la connexió de dades transporta els bytes i la transferència arriba a una resposta final positiva. Comparar les etapes és més útil que comparar clients, perquè un inici de sessió que funciona i un nom de fitxer que apareix tots dos s'aturen abans del final.

Resposta preliminar versus resposta final

Per a STOR, una resposta 125 o 150 és preliminar. Diu que el servidor està disposat a intentar-ho i que s'obre una connexió de dades, no que l'objecte existeixi en la seva forma final. L'operació només es completa quan la transferència arriba a una resposta positiva de finalització, normalment 226 o 250, en el context d'aquesta operació.

Una 426 vol dir que la transferència s'ha avortat, i un número imprès per una altra ordre no és el resultat d'aquesta pujada. Llegeix la resposta que pertany a l'STOR, no l'últim número de la pantalla. Si el client surt abans que arribi aquesta resposta, no tens cap prova de finalització.

Connexió de control versus connexió de dades

L'autenticació i el llistat de directoris fan servir la connexió de control. Els bytes fan servir una connexió de dades separada, i el seu punt final es negocia per a cada transferència. Un inici de sessió correcte demostra el camí de control i no diu res sobre si l'adreça de dades és abastable des del client.

Quan el servidor no pot obrir la connexió de dades, investiga el punt final negociat i el camí permès. El mode passiu encara requereix una adreça de dades i un port utilitzables, i un tallafoc o un dispositiu NAT entre el client i el servidor pot permetre la sessió de control mentre bloqueja el rang de dades. Quan el servidor rebutja la sol·licitud d'emmagatzematge, mira el nom de camí remot, els permisos o els límits d'emmagatzematge. Cap de les dues branques no s'explica pel fet que la connexió de control s'hagi autenticat.

FTP sobre TLS versus SFTP

FTP sobre TLS encara és FTP: dues connexions, respostes FTP i una actualització de TLS a cadascuna. SFTP és un subsistema d'SSH amb una sola connexió i un conjunt d'ordres completament diferent. Comparteixen un propòsit i gairebé res més, així que un diagnòstic que passa d'un a l'altre sol començar comparant els registres equivocats.

No desactivis TLS perquè un ajudant intermedi pugui inspeccionar la sessió, i no tractis un error d'SFTP com un problema de respostes FTP. El manual de curl documenta TLS explícit, mode passiu i opcions de pujada si necessites una prova amb script, i és la referència del que canvia realment cada opció.

Tria el protocol que el servei ofereix de debò abans de depurar-lo. Un servidor que només parla SFTP no produirà mai una resposta 226, per molt que es configuri el client.

Un nom de fitxer visible versus un objecte desat

Un nom de fitxer visible pot representar un objecte incomplet, sobretot després d'una transferència avortada o d'un client que ha sortit abans d'hora. Demana al propietari del servei que compari la mida del fitxer de prova previst i el hash de contingut de confiança amb l'objecte desat quan s'espera preservar els bytes.

Els modes binari i ASCII són una altra comparació que canvia el resultat. El mode ASCII pot traduir els finals de línia, així que els bytes desats difereixen del fitxer local encara que la transferència hagi reeixit. Mantén el mode binari per a una comprovació byte a byte, i no afegeixis opcions de conversió per fer que una transferència fallida sembli diferent.

Un STOR ordinari pot substituir un fitxer existent, i el permís per iniciar sessió o llistar un directori no estableix el permís per crear-hi o substituir-hi un objecte. Fes servir un nom remot no utilitzat abans per a la prova.

Què cal comparar abans de reintentar

No afegeixis, no reprenguis ni repeteixis una pujada a cegues sobre un fitxer parcial incert. Acorda amb el propietari si cal reiniciar amb un nom nou, fer servir el procediment de recuperació suportat pel servei o eliminar l'objecte de prova fallit.

Escriu el resultat com una de quatre afirmacions: la lectura local ha fallat, s'ha refusat l'emmagatzematge, la transferència de dades s'ha avortat o la transferència s'ha completat i els bytes desats coincideixen. Aquest registre és un resultat més sòlid que canviar l'intèrpret, la VPN i els paràmetres FTP alhora fins que aparegui un nom de fitxer, i diu a la persona següent quina etapa cal inspeccionar. Guarda el text de resposta net amb aquesta afirmació. Llavors un reintent és una decisió, no un reflex.