Verifică răspunsul final FTP înainte de a avea încredere într-o încărcare

Un client FTP poate accepta o comandă put cu mult înainte ca serverul să fi primit fișierul, iar în golul dintre aceste două evenimente se află cele mai multe mistere ale încărcării. Trebuie să se încheie patru etape: fișierul local este citit, serverul acceptă cererea de stocare, conexiunea de date transportă octeții, iar transferul ajunge la un răspuns final pozitiv. Compararea etapelor este mai utilă decât compararea clienților, pentru că o autentificare care funcționează și un nume de fișier care apare se opresc amândouă înainte de linia de sosire.

Răspuns preliminar versus răspuns final

Pentru STOR, un răspuns 125 sau 150 este preliminar. Spune că serverul este dispus să încerce și că se deschide o conexiune de date, nu că obiectul există în forma sa finală. Operația este completă doar când transferul ajunge la un răspuns pozitiv de finalizare, de obicei 226 sau 250, în contextul acelei operații.

426 înseamnă că transferul a fost întrerupt, iar un număr afișat de altă comandă nu este rezultatul acestei încărcări. Citește răspunsul care aparține acelui STOR, nu ultimul număr de pe ecran. Dacă clientul se închide înainte ca acel răspuns să sosească, nu ai nicio dovadă de finalizare.

Conexiunea de control versus conexiunea de date

Autentificarea și listarea directorului folosesc conexiunea de control. Octeții folosesc o conexiune de date separată, iar punctul ei final este negociat pentru fiecare transfer. O autentificare reușită dovedește calea de control și nu spune nimic despre dacă adresa de date este accesibilă din client.

Când serverul nu poate deschide conexiunea de date, investighează punctul final negociat și calea permisă. Modul pasiv tot cere o adresă de date și un port utilizabile, iar un firewall sau un dispozitiv NAT între client și server poate permite sesiunea de control și bloca intervalul de date. Când serverul refuză cererea de stocare, uită-te la numele căii la distanță, la permisiuni sau la limitele de stocare. Niciuna dintre ramuri nu este explicată de faptul că conexiunea de control s-a autentificat.

FTP prin TLS versus SFTP

FTP prin TLS este tot FTP: două conexiuni, răspunsuri FTP și o actualizare TLS pe fiecare. SFTP este un subsistem SSH cu o singură conexiune și un set de comenzi complet diferit. Împărtășesc un scop și aproape nimic altceva, așa că un diagnostic care trece dintr-unul în altul începe de obicei prin a compara jurnalele greșite.

Nu dezactiva TLS ca un ajutor intermediar să poată inspecta sesiunea și nu trata o eșec SFTP ca pe o problemă de răspuns FTP. manualul curl documentează TLS explicit, modul pasiv și opțiunile de încărcare dacă ai nevoie de un test din script, și este referința pentru ce schimbă de fapt fiecare opțiune.

Alege protocolul pe care serviciul îl oferă de fapt înainte de a-l depana. Un server care vorbește doar SFTP nu va produce niciodată un răspuns 226, indiferent cum este configurat clientul.

Un nume de fișier vizibil versus un obiect stocat

Un nume de fișier vizibil poate reprezenta un obiect incomplet, mai ales după un transfer întrerupt sau un client care s-a închis devreme. Roagă proprietarul serviciului să compare dimensiunea fișierului de test dorit și un hash de conținut de încredere cu obiectul stocat atunci când se așteaptă păstrarea octeților.

Modurile binar și ASCII sunt o altă comparație care schimbă rezultatul. Modul ASCII poate traduce terminațiile de linie, așa că octeții stocați diferă de fișierul local chiar dacă transferul a reușit. Păstrează modul binar pentru o verificare octet cu octet și nu adăuga opțiuni de conversie ca un transfer eșuat să arate altfel.

Un STOR obișnuit poate înlocui un fișier existent, iar permisiunea de a te autentifica sau de a lista un director nu stabilește permisiunea de a crea sau înlocui un obiect în el. Folosește un nume la distanță nefolosit anterior pentru test.

Ce să compari înainte de a reîncerca

Nu adăuga, nu relua și nu repeta orbește o încărcare peste un fișier parțial incert. Stabilește cu proprietarul dacă repornești sub un nume nou, folosești procedura de recuperare suportată de serviciu sau elimini obiectul de test eșuat.

Scrie rezultatul ca una dintre patru afirmații: citirea locală a eșuat, stocarea a fost refuzată, transferul de date a fost întrerupt sau transferul s-a încheiat și octeții stocați s-au potrivit. Acea înregistrare este un rezultat mai puternic decât schimbarea simultană a shell-ului, a VPN-ului și a setărilor FTP până apare un nume de fișier și îi spune următoarei persoane ce etapă să inspecteze. Păstrează textul răspunsului curățat împreună cu acea afirmație. Atunci o reîncercare este o decizie, nu un reflex.