Збережений файл — ще не перевірене завантаження
Перш ніж публікувати або використовувати, перевірте, що завантаження через проксі містить очікуваний файл, а не сторінку автентифікації чи неповну відповідь.
Гіпотетичний report.xlsx має розмір 8 KB і відкривається як сторінка входу. Програма успішно зберегла файл, але так і не отримала потрібну таблицю. Ім'я файлу вибирається локально; воно не доводить, що саме надійшло.
Зробіть приймання окремим кроком перед публікацією тимчасового завантаження:
- Вимагайте успішного передавання та очікуваного статусу відповіді. Зберігайте помилку, а не вважайте байти, записані до неї, повними.
- Порівняйте вміст з очікуваним типом файлу. Сторінка входу або фільтра може повернути 200. Content-Type може бути неправильним, а HTML-префікс у таблиці — це попередження, яке потребує розслідування. Файл, що починається з рядка статусу HTTP, указує радше на необроблене обрамлення відповіді.
- Перевіряйте всі збережені байти за довіреною контрольною сумою або підписом, коли вони доступні. Публікувати або використовувати підсумковий файл застосунок має лише після проходження потрібних перевірок.
Обчислення хешу без очікуваного значення визначає лише отримані байти. Непідписана контрольна сума, взята тим самим недовіреним шляхом, може поділяти слабкість файлу; використовуйте незалежне довірене очікування.
Будьте обережні й у порівняннях розміру. HTTP-клієнт може декодувати кодування вмісту під час читання, тож довжина отриманого файлу може законно відрізнятися від заголовка, що описує закодоване повідомлення. Порівнюйте очікування видавця з фактично збереженим поданням.
Якщо спроба не вдалася, зберігайте тимчасовий вивід лише для навмисного продовження або відкиньте його. Залишення неповних байтів за підсумковим шляхом змушує наступну програму вгадувати, чи вони придатні.