Перегляд HTTP заголовків

Перегляд HTTP заголовків, це безкоштовний інструмент, який отримує всі заголовки HTTP-відповіді, повернуті вказаною URL-адресою на типовий GET-запит.

Що таке заголовки HTTP-відповіді?

Заголовки HTTP-відповіді, це метадані, які вебсервер надсилає перед тілом відповіді, наприклад HTML-сторінкою, зображенням або документом JSON. Вони повідомляють клієнту, як обробляти, кешувати, переспрямовувати або захищати відповідь.

Відповідь HTTP/1.x зазвичай починається з рядка стану HTTP, після якого йдуть заголовки. В HTTP/2 та HTTP/3 відповідний статус передається в псевдозаголовку :status. Формально рядок стану HTTP/1.x не належить до заголовків, але його часто показують разом із ними, оскільки він указує, чи був запит успішним. Статус 200 означає, що ресурс повернуто, 301 або 302 вказує на переспрямування, 404 означає, що ресурс не знайдено, а 500 повідомляє про помилку на боці сервера.

Заголовки можуть надходити від вихідного сервера, зворотного проксі або мережі доставки вмісту, наприклад Cloudflare. Під час проходження відповіді через ці системи деякі заголовки додаються або видаляються. Тому результат може описувати не лише застосунок, який сформував сторінку.

Як переглянути HTTP заголовки?

Введи повну URL-адресу, яку потрібно перевірити, включно зі схемою, наприклад https://www.example.com/account. Інструмент надсилає зі свого сервера типовий GET-запит і повертає HTTP заголовки, отримані від цієї URL-адреси.

Щоб точно порівняти заголовки відповідей, перевіряй саме ті варіанти URL-адрес, які тебе цікавлять. Заголовки для http://example.com, https://example.com і https://www.example.com можуть відрізнятися, оскільки кожна адреса може мати власні переспрямування, правила кешування та конфігурацію сервера.

Синтаксис URL-адреси також впливає на запит:

• Пробіли не можна використовувати в URL-адресах безпосередньо. Зазвичай їх потрібно кодувати у відсотковому форматі, найчастіше як %20 у шляху.
• ? позначає початок компонента запиту, а & і = часто використовуються у форматі параметрів, подібному до кодування даних форм. Однак не в кожному рядку запиту вони мають саме таке призначення.
• Доменні імена з діакритичними або нелатинськими символами обробляються за допомогою IDNA та подаються як ASCII-мітки, що зазвичай починаються з xn--. Символи шляху переважно спочатку кодуються як байти UTF-8, а потім у відсотковому форматі.
• Фрагмент, що починається з #, обробляється браузером і не надсилається в HTTP-запиті.
• Універсальної максимальної довжини URL-адреси немає. Сервер, проксі або застосунок може відхилити надто довгу адресу.

Як читати результат перевірки HTTP заголовків?

Перевір заголовки, пов'язані з проблемою, яку намагаєшся знайти. Регістр символів у назвах заголовків не має значення, але синтаксис їхніх значень може бути чутливим до регістру.

Інші заголовки можуть бути специфічними для конкретного застосунку. Наприклад, Access-Control-Allow-Origin визначає, яким джерелам дозволено читати відповідь через міжджерельні запити браузера. Заголовок Server може містити назву програмного забезпечення або проксі, але це не надійний доказ використання певної платформи, оскільки адміністратори можуть змінити або видалити його.

Типові сценарії пошуку несправностей

Одна з поширених причин перевірити заголовки, це проблема з переспрямуванням. Припустімо, https://example.com/old-page повертає статус 301 із заголовком Location: https://example.com/new-page. Це означає, що сервер указує клієнту звернутися за новою адресою. Послідовна перевірка кожної адреси призначення може виявити цикл переспрямувань або неочікуваний перехід між HTTP та HTTPS.

Якщо сторінка за Cloudflare або іншою CDN показує застарілий вміст, перевір Cache-Control, Age, ETag і всі заголовки кешування, специфічні для цього провайдера. Велике значення Age показує обчислений вік кешованої відповіді, потенційно з урахуванням часу в проміжних кешах, а не тривалість її зберігання конкретним посередником. Це не доводить, що всі регіональні кеші містять однакову версію.

Якщо API працює в серверному скрипті, але не в браузері, перевір Content-Type і заголовки відповіді CORS, зокрема Access-Control-Allow-Origin. Кінцева точка JSON, яка повертає text/html, насправді може віддавати сторінку помилки або форму входу. За відсутності дозволу на міжджерельний доступ браузер може заблокувати відповідь, навіть якщо сервер повернув статус 200.

Заголовки також можуть допомогти з'ясувати, чому сайт здається недоступним. Відповідь 503 вказує на тимчасову несправність сервера або проміжної системи, а 404 означає, що запитаний шлях не знайдено. Проте заголовки дають змогу діагностувати не всі збої. Якщо розпізнавання DNS, TCP-з'єднання або узгодження TLS завершується помилкою до отримання HTTP-відповіді, заголовків для перевірки може не бути. Інструмент Пінг дає змогу окремо перевірити з'єднання, а Перевірка HTTP/2 визначає підтримку протоколу.

Чому правильний результат може здаватися помилковим?

Правильний результат може відрізнятися від того, що показує браузер, оскільки через кеші, записи DNS і контекст запиту два звернення можуть отримати різні відповіді. Ця перевірка виконується на сервері, тому запит може потрапити на інший вузол CDN або отримати нещодавно змінений запис DNS раніше чи пізніше, ніж твоя локальна мережа.

Крім того, браузери надсилають власні файли cookie, прийнятні типи вмісту, мовні налаштування та валідатори кешу. Тому сторінка WordPress для авторизованого користувача може повертати інші правила кешування, ніж анонімний запит із сервера. Географічна маршрутизація та системи керування ботами також можуть змінювати відповідь залежно від вихідної мережі або заголовків запиту.

Після зміни DNS кешувальні резолвери можуть і далі використовувати попередній запис, доки не завершиться його час життя. Навіть коли трафік уже надходить на новий сервер, старий об'єкт CDN або кеш браузера все ще може повертати попередній вміст. Окремо перевір, на яку адресу розпізнається хост, за потреби очисть кеші та порівняй точні URL-адреси, замість припускати, що всі імена хостів мають однакову конфігурацію.

Поширені запитання

Чи показує інструмент заголовки запиту?

Ні. Він отримує заголовки відповіді, які URL-адреса повертає на типовий GET-запит. Заголовки запиту, це метадані, що надсилаються серверу. Для їх повної перевірки потрібні окремі інструменти розробника в браузері, журнали сервера або клієнт командного рядка.

Чи залишаються введені URL-адреси конфіденційними?

Перевірка виконується на сервері. Введені дані передаються на цей сервер через HTTPS і не зберігаються. Не вводь URL-адреси з паролями, токенами доступу або конфіденційними параметрами запиту, оскільки під час звернення сервер призначення також отримає ці значення.

Чи можна за HTTP заголовками визначити причину попередження про сертифікат?

Зазвичай лише за ними визначити причину не вдасться. TLS-з'єднання встановлюється до надсилання HTTP-відповіді, тому через прострочений сертифікат, невідповідність імені хоста або недовіреного видавця заголовки можуть узагалі не повернутися. Якщо браузер показує попередження до завантаження сторінки, окремо перевір сертифікат і його ланцюжок.

Чому повертається кілька заголовків Set-Cookie?

Відповідь може встановлювати кілька файлів cookie, кожен з яких використовує власне поле Set-Cookie. Не об'єднуй їх як список, розділений комами, оскільки дата завершення терміну дії cookie також може містити коми. Окремо перевір домен, шлях і атрибути безпеки кожного файлу cookie.

Чи можна порівняти результат із curl?

Так. Команда на зразок curl -D - https://example.com/ -o /dev/null виводить заголовки відповіді та відкидає її тіло. Різні версії Curl, заголовки запиту, налаштування переспрямувань і мережеве розташування можуть дати інший результат. Перш ніж вважати відмінність помилкою сервера, переконайся, що ці умови збігаються.