Ви натискаєте «Завантажити інструкцію», отримуєте файл guide.pdf, але програма перегляду повідомляє про пошкодження. Саме перейменування не допомагає: усередині може бути сторінка входу або повідомлення про помилку. Завантаження HTML замість PDF варто перевіряти як ланцюжок відповіді, а не як проблему розширення. У цьому навчальному сценарії потрібна невелика публічна тестова інструкція без персональних даних. Ми відокремимо три запитання: яку адресу запитано, що повернув сервер і як браузеру запропонували назвати результат. Це не опис клієнтського інциденту й не команда для зміни робочого хостингу.
Почніть із запиту, який справді створює файл
У браузері відкрийте інструменти розробника та вкладку Network перед натисканням посилання. Знайдіть запит документа або завантаження, а не картинку кнопки. Зафіксуйте початковий URL, метод, статус, можливий редирект і кінцеву адресу. Не копіюйте в загальний чат cookies, заголовки авторизації або підписані посилання: вони можуть відкривати доступ до приватного документа. Для спільного протоколу замініть такі значення позначкою [REDACTED].
Якщо адреса веде до форми входу, спочатку перевіряйте доступ і термін дії посилання. Якщо замість документа повернувся звичайний HTML із кодом 200, транспортний успіх ще не підтверджує правильний файл. Водночас відмова без авторизації не доводить поломку: захищене завантаження може правильно вимагати активний сеанс. Порівнюйте однакові сценарії, а не авторизований браузер із порожнім клієнтом.
Збережіть заголовки окремо від отриманих байтів
Для незалежної діагностики потрібні термінал Linux або macOS і curl. Адміністративні права та сторонні пакети не потрібні. Спочатку виконайте curl --version: для зупинки завантаження невідомого розміру за наведеним лімітом потрібен curl не старіший за 8.4.0. У старіших випусках цей захист не діє, якщо розмір заздалегідь невідомий. Не встановлюйте оновлення на продуктивний сервер лише заради вправи; використайте підготовлений тестовий комп’ютер.
Перейдіть до окремого порожнього локального каталогу. Наступна команда створює або перезаписує два названі файли саме там: переконайтеся, що вони не містять потрібних даних. Домен downloads.example.test і шлях guide.pdf умовні, тому замініть всю адресу на відоме дозволене тестове завантаження. Не використовуйте URL операції, що створює замовлення або змінює дані. Команда робить GET, обмежує час двадцятьма секундами та розмір одним мебібайтом; для цієї вправи виберіть менший документ.
curl --silent --show-error --max-time 20 \
--max-filesize 1048576 \
--dump-header response-headers.txt \
--output response.bin \
'https://downloads.example.test/guide.pdf'Параметр --dump-header записує заголовки, а --output зберігає тіло під контрольованою локальною назвою. Навмисно немає автоматичного переходу за редиректом: так початкова відповідь не губиться. Перевірте повідомлення curl та код завершення перед висновками. Якщо ліміт або тайм-аут зупинив передачу, response.bin може бути неповним; це не доказ пошкодження документа на сервері. Точну поведінку параметрів описує офіційна документація curl.
Зіставте тип, назву та фактичний вміст
Відкрийте response-headers.txt як текст. Для навчального сценарію завантаження PDF очікувані поля можуть виглядати так; це приклад заголовків, не конфігурація Nginx або Apache й не результат перевірки вашого сайту:
Content-Type: application/pdf
Content-Disposition: attachment; filename="guide.pdf"Content-Type описує тип представлення. Content-Disposition із attachment пропонує завантаження та назву файла. Ці поля виконують різні ролі: зміна filename не перетворює HTML на PDF. Значення inline натомість допускає відображення в браузері. Правила передачі назви визначає RFC 6266; для не-ASCII назв існує параметр filename*. У цій вправі навмисно використано просту ASCII-назву, щоб не змішувати діагностику вмісту з кодуванням імені.
Не запускайте отриманий файл і не перейменовуйте його на виконуваний. Перегляньте початок response.bin у редакторі, який уміє безпечно показувати байти. HTML-розмітка з текстом входу чи помилки — вагома ознака іншої відповіді. Сама сигнатура PDF також не доводить повноту або безпечність документа. Порівняйте результат із завідомо коректним тестовим файлом і перевірте відкриття лише довіреним засобом у тестовому середовищі. Не завантажуйте приватні документи в сторонні онлайн-перевірки.
Виправляйте підтверджену причину, а не лише розширення
Зафіксуйте висновок окремо для кожного сценарію. Редирект на вхід спрямовує перевірку до прав і сеансу. HTML-помилка в тілі — до маршруту, обробника та відповідного журналу. Правильний документ із невдалою назвою — до формування заголовка. Правильне тіло з неправильним MIME-типом — до налаштування відповіді. Не підміняйте всі відповіді універсальним attachment: це може приховати сторінки помилок під виглядом файлів і не усуває першопричину.
Перед зміною коду або конфігурації збережіть поточну версію, відтворіть проблему на тестовому середовищі та підготуйте повернення цієї версії. Зміни прав доступу не повинні робити приватний документ публічним. Повторіть успішне завантаження, відмову без дозволу й випадок відсутнього документа. Перевірте браузер і незалежний GET з однаковими очікуваннями; HEAD може бути корисним попереднім оглядом, але не перевіряє отримане тіло.
Висновок: назва, статус і тип відповіді мають узгоджуватися з реальним вмістом, а часткове завантаження слід відрізняти від неправильної відповіді. Якщо потрібен контекст редиректів, прочитайте перевірку редиректів після зміни URL. AriZone допоможе зібрати безпечний протокол і знайти джерело помилки без експериментів із приватними файлами. Після вправи приберіть лише створені тестові копії; не залишайте діагностичні заголовки в публічному каталозі.
Залиште коментар