Sprawdź końcową odpowiedź FTP, zanim zaufasz wysyłaniu pliku

Klient FTP może przyjąć polecenie put na długo przed tym, zanim serwer otrzyma plik, i właśnie w szczelinie między tymi dwoma zdarzeniami mieszka większość tajemnic wgrywania. Muszą się zakończyć cztery etapy: plik lokalny zostaje odczytany, serwer przyjmuje żądanie zapisu, połączenie danych przenosi bajty, a transfer osiąga końcową odpowiedź pozytywną. Porównywanie etapów jest użyteczniejsze niż porównywanie klientów, bo udane logowanie i widoczna nazwa pliku oba zatrzymują się przed metą.

Odpowiedź wstępna a odpowiedź końcowa

Dla STOR odpowiedź 125 lub 150 jest wstępna. Mówi, że serwer jest gotów spróbować i że otwiera się połączenie danych, a nie że obiekt istnieje w swojej końcowej postaci. Operacja jest ukończona dopiero wtedy, gdy transfer osiągnie pozytywną odpowiedź zakończenia, zwykle 226 lub 250, w kontekście tej operacji.

426 oznacza, że transfer został przerwany, a numer wypisany przez inne polecenie nie jest wynikiem tego wgrywania. Czytaj odpowiedź należącą do tego STOR, a nie ostatni numer na ekranie. Jeśli klient zakończy się, zanim ta odpowiedź nadejdzie, nie masz żadnego dowodu ukończenia.

Połączenie sterujące a połączenie danych

Uwierzytelnianie i lista katalogów korzystają z połączenia sterującego. Bajty korzystają z osobnego połączenia danych, a jego punkt końcowy jest negocjowany przy każdym transferze. Udane logowanie dowodzi ścieżki sterującej i nic nie mówi o tym, czy adres danych jest osiągalny z klienta.

Gdy serwer nie może otworzyć połączenia danych, zbadaj wynegocjowany punkt końcowy i dozwoloną ścieżkę. Tryb pasywny nadal wymaga użytecznego adresu danych i portu, a zapora lub urządzenie NAT między klientem a serwerem może przepuszczać sesję sterującą, blokując zakres danych. Gdy zamiast tego serwer odrzuca żądanie zapisu, sprawdź zdalną nazwę ścieżki, uprawnienia lub limity zapisu. Żadnej z tych gałęzi nie wyjaśnia to, że połączenie sterujące zostało uwierzytelnione.

FTP przez TLS a SFTP

FTP przez TLS to nadal FTP: dwa połączenia, odpowiedzi FTP i aktualizacja TLS na każdym z nich. SFTP to podsystem SSH z jednym połączeniem i całkowicie innym zestawem poleceń. Dzielą cel i prawie nic więcej, więc diagnoza przechodząca między nimi zwykle zaczyna się od porównania niewłaściwych logów.

Nie wyłączaj TLS po to, by pośredniczące narzędzie mogło obejrzeć sesję, i nie traktuj awarii SFTP jako problemu z odpowiedzią FTP. podręcznik curl dokumentuje jawny TLS, tryb pasywny i opcje wysyłania, jeśli potrzebujesz testu ze skryptu, i jest punktem odniesienia dla tego, co naprawdę zmienia każda flaga.

Wybierz protokół, który usługa faktycznie oferuje, zanim zaczniesz ją debugować. Serwer, który mówi tylko SFTP, nigdy nie wygeneruje odpowiedzi 226, niezależnie od konfiguracji klienta.

Widoczna nazwa pliku a zapisany obiekt

Widoczna nazwa pliku może oznaczać niekompletny obiekt, zwłaszcza po przerwanym transferze lub kliencie, który zakończył się wcześnie. Poproś właściciela usługi o porównanie rozmiaru zamierzonego pliku testowego i zaufanego skrótu treści z zapisanym obiektem, gdy oczekuje się zachowania bajtów.

Tryby binarny i ASCII to kolejne porównanie, które zmienia wynik. Tryb ASCII może tłumaczyć końce wierszy, więc zapisane bajty różnią się od pliku lokalnego, nawet gdy transfer się powiódł. Zachowaj tryb binarny do kontroli co do bajtu i nie dodawaj opcji konwersji, żeby nieudany transfer wyglądał inaczej.

Zwykły STOR może zastąpić istniejący plik, a uprawnienie do logowania lub listowania katalogu nie daje uprawnienia do utworzenia lub zastąpienia w nim obiektu. Do testu użyj wcześniej nieużywanej nazwy zdalnej.

Co porównać przed ponowną próbą

Nie dopisuj, nie wznawiaj i nie powtarzaj wgrywania na ślepo na niepewnym częściowym pliku. Uzgodnij z właścicielem, czy zacząć od nowa pod nową nazwą, użyć obsługiwanej przez usługę procedury odzyskiwania, czy usunąć nieudany obiekt testowy.

Zapisz wynik jako jedno z czterech stwierdzeń: lokalny odczyt nie powiódł się, zapis został odrzucony, transfer danych został przerwany albo transfer się zakończył i zapisane bajty się zgadzały. Taki zapis jest silniejszym wynikiem niż jednoczesna zmiana powłoki, VPN i ustawień FTP, aż pojawi się nazwa pliku, i mówi następnej osobie, który etap zbadać. Zachowaj oczyszczony tekst odpowiedzi razem z tym stwierdzeniem. Wtedy ponowna próba jest decyzją, a nie odruchem.