Поиск 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 нет. Сервер, прокси или приложение могут отклонить слишком длинный 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, введенные в инструмент?

Введенные URL передаются по HTTPS на сервер, где выполняется проверка, и не сохраняются. Не указывай URL с паролями, токенами доступа или конфиденциальными параметрами запроса, поскольку при выполнении запроса эти значения также получит целевой сервер.

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

Обычно самих HTTP-заголовков для этого недостаточно. TLS-соединение устанавливается до отправки HTTP-ответа, поэтому из-за просроченного сертификата, несовпадения имени хоста или недоверенного центра сертификации заголовки могут вообще не вернуться. Если браузер показывает предупреждение до загрузки страницы, отдельно проверь сертификат и его цепочку.

Почему сервер возвращает несколько заголовков Set-Cookie?

Один ответ может устанавливать несколько cookie, и для каждого используется отдельное поле Set-Cookie. Не объединяй их в список с разделителями-запятыми, поскольку даты истечения срока действия cookie сами могут содержать запятые. Проверяй домен, путь и атрибуты безопасности каждого cookie отдельно.

Можно ли сравнить результат с curl?

Да. Команда curl -D - https://example.com/ -o /dev/null выводит заголовки ответа и отбрасывает его тело. Версия curl, заголовки запроса, настройки перенаправлений и расположение в сети могут повлиять на результат. Прежде чем считать различие ошибкой сервера, убедись, что эти условия совпадают.