Zapisany plik nie jest jeszcze zweryfikowanym pobraniem
Przed opublikowaniem lub użyciem sprawdź, czy pobranie przez proxy zawiera oczekiwany plik, a nie stronę logowania lub niepełną odpowiedź.
Hipotetyczny report.xlsx ma 8 KB i otwiera się jako strona logowania. Program pomyślnie zapisał plik, ale nigdy nie uzyskał zamierzonego arkusza. Nazwa pliku jest wybierana lokalnie; nie jest dowodem na to, co dotarło.
Uczyń akceptację osobnym krokiem przed opublikowaniem tymczasowego pobrania:
- Wymagaj udanego transferu i oczekiwanego statusu odpowiedzi. Zachowaj błąd, zamiast traktować bajty zapisane przed nim jako kompletne.
- Porównaj zawartość z oczekiwanym typem pliku. Strona logowania lub filtra może zwrócić 200. Content-Type może być błędny, a prefiks HTML w arkuszu to ostrzeżenie wymagające zbadania. Plik zaczynający się od wiersza statusu HTTP wskazuje raczej na surowe ramowanie odpowiedzi.
- Zweryfikuj wszystkie zapisane bajty względem zaufanej sumy kontrolnej lub podpisu, gdy są dostępne. Aplikacja powinna opublikować lub użyć ostatecznego pliku dopiero po przejściu wymaganych kontroli.
Obliczenie skrótu bez oczekiwanej wartości identyfikuje tylko otrzymane bajty. Niepodpisana suma kontrolna pobrana tą samą niezaufaną ścieżką może dzielić słabość pliku; użyj niezależnego zaufanego oczekiwania.
Uważaj też na porównania rozmiaru. Klient HTTP może dekodować kodowanie treści podczas odczytu, więc długość wynikowego pliku może zasadnie różnić się od nagłówka opisującego zakodowaną wiadomość. Porównaj oczekiwanie wydawcy z reprezentacją faktycznie zapisaną.
Jeśli próba się nie powiedzie, zachowaj tymczasowe wyjście tylko do świadomego wznowienia albo je odrzuć. Pozostawienie niekompletnych bajtów w końcowej ścieżce zmusza następny program do zgadywania, czy są użyteczne.