Список заголовков HTTP

Заголовок Referrer-Policy позволяет управлять тем, какой объём информации об источнике запроса будет включён в заголовок Referer. Для повышения конфиденциальности пользователей значением по умолчанию в большинстве современных браузеров является политика strict-origin-when-cross-origin^[12].

User-Agent[править | править код]

Указывает программное обеспечение клиента и его характеристики. Аналогичным ему является Server для серверов и Via для прокси. Современные браузеры (в частности, Google Chrome и Safari) замораживают или сокращают передаваемые в строке User-Agent данные для защиты конфиденциальности пользователей и уменьшения возможностей для создания цифровых отпечатков (фингерпринтинга)^[13][14]. На смену этому заголовку в браузерах на базе Chromium пришёл механизм User-Agent Client Hints (включающий заголовки вида Sec-CH-UA)^[15].

Заголовки ответа (англ. Response Headers) включаются только в ответы сервера.

К важным современным заголовкам ответа относятся Alt-Svc, который широко используется браузерами для обнаружения и перехода на протокол HTTP/3^[16], а также Proxy-Status (RFC 9209), предназначенный для передачи детальной информации об ошибках и обработке ответов от HTTP-посредников (прокси-серверов и CDN)^[17].

Allow[править | править код]

Список поддерживаемых методов целевого ресурса. Согласно спецификации RFC 9110, сервер обязан генерировать заголовок Allow в ответе со статусом 405 Method Not Allowed^[1], а также может отправлять его в любых других ответах (например, на метод OPTIONS или со статусом 501).

Пример: Allow: GET, HEAD, OPTIONS

Термин «Заголовки сущности» (англ. Entity Headers) официально признан устаревшим с выходом стандарта RFC 9110^[5]. В современной спецификации HTTP вместо него введены заголовки представления (англ. Representation Headers, например, Content-Type, Content-Encoding), которые описывают формат и кодировку передаваемых данных, и заголовки полезной нагрузки (англ. Payload Headers, например, Content-Length, Transfer-Encoding), содержащие информацию о самой полезной нагрузке в том виде, в котором она передаётся^[3].

Content-Language[править | править код]

Указывает один или несколько естественных языков содержимого, для носителей которых оно предназначается. Языки перечисляются через запятую, порядок значения не имеет. Если данный заголовок опущен, то предполагается, что содержимое предназначено для людей, понимающих любой язык (или же язык вообще значения не имеет). При этом возможно, что человек не отыщет там информацию на понятном ему языке.

Обратите внимание, что в этом поле следует указывать не все используемые в документе языки, а только те, которые, по вашему мнению, понимает конечный пользователь. Например, если это страница учебника по английскому языку для русскоговорящей аудитории, то указывать следует только русский язык, так как для англоговорящих людей она не нужна. А если это страница с сообщением об ошибке на двух языках, то указывать нужно оба.

В RFC сказано, что язык содержимого можно указывать для любых медиатипов, а не только для текста. Например, если это видео, где люди говорят на английском, в котором сбоку расположено окошко с сурдопереводом на амслене, а внизу расположен перевод субтитрами на русском, то заголовок Content-Language должен иметь значение «en, ase, ru». При этом, если это видео, где герои говорят на японском, и присутствует голосовой перевод на русском, то следует указать только русский язык, так как японцам, скорее всего, будет трудно расслышать родную речь.

Требования к заголовку Content-Language определяются актуальным стандартом RFC 9110^[1], заменившим устаревший RFC 3282. Допустимые значения (языковые субтеги) берутся из постоянно обновляемого реестра IANA Language Subtag Registry^[18]. Ссылку на этот реестр вы найдёте в конце данной статьи.

Заголовки безопасности HTTP — это набор инструкций, которые сервер отправляет браузеру для усиления защиты веб-приложения от распространённых атак. К ключевым заголовкам относятся:

• Strict-Transport-Security (HSTS) — принудительно активирует защищённое соединение через протокол HTTPS^[19].
• Content-Security-Policy (CSP) — позволяет контролировать, какие ресурсы браузер может загружать для данной страницы, обеспечивая защиту от межсайтового скриптинга (XSS)^[20].
• X-Content-Type-Options — используется со значением nosniff, которое запрещает браузеру анализировать содержимое файла для определения его типа (MIME-sniffing)^[21].
• Permissions-Policy — позволяет контролировать, какие функции браузера (например, доступ к камере, микрофону или геолокации) могут использоваться на странице^[22].

Заголовок X-XSS-Protection признан устаревшим, современные браузеры прекратили его поддержку, поэтому его использование не рекомендуется^[23].

Кэширование в HTTP — это механизм, позволяющий временно сохранять копии веб-ресурсов для их повторного использования, что сокращает задержки, нагрузку на сеть и сервер. Основным стандартом, описывающим базовые принципы кэширования, является RFC 9111^[24].

Управление кэшированием Основным заголовком для управления политикой кэширования является Cache-Control^[24][25]. Он задаёт правила с помощью набора директив:

• public — разрешает сохранять ответ в любом кэше, включая браузеры и промежуточные серверы (например, CDN).
• private — указывает, что ответ предназначен для одного пользователя и может быть кэширован только локально в браузере клиента.
• max-age — определяет максимальное время (в секундах), в течение которого ресурс считается актуальным и может использоваться без обращения к серверу.
• no-cache — обязывает клиента перед каждым использованием кэшированной версии отправлять запрос на сервер для проверки её актуальности (ревалидации).
• no-store — полностью запрещает кэширование ответа, что применяется для защиты конфиденциальной информации^[24][25].

Валидация кэша Для проверки актуальности устаревших ресурсов применяется механизм валидации с помощью заголовка ETag. Он представляет собой уникальный идентификатор конкретной версии ресурса. При повторном запросе клиент отправляет сохранённое значение в заголовке If-None-Match. Если ресурс на сервере не изменился, возвращается ответ со статусом 304 Not Modified без тела сообщения, и браузер продолжает использовать свою копию^[26].

Вариативность контента Заголовок Vary используется для управления вариативностью контента. Он указывает кэширующим серверам, что ответ на один и тот же URL может различаться в зависимости от значений определённых заголовков запроса. Например, Vary: Accept-Encoding сообщает о необходимости хранить отдельные копии для разных алгоритмов сжатия, а Vary: User-Agent применяется при отдаче различного содержимого для мобильных и десктопных устройств^[27].

При использовании обратных прокси-серверов критически важной задачей является перезапись HTTP-заголовка ответа Location для обеспечения корректной работы перенаправлений (редиректов). Внутренние приложения часто генерируют ответы с кодами состояния 3xx, указывая в заголовке Location свои внутренние, недоступные извне адреса. Обратный прокси-сервер перехватывает такой ответ и заменяет внутренний адрес на публичный URL. Для этого применяются встроенные механизмы веб-серверов: директива proxy_redirect в Nginx, ProxyPassReverse в Apache HTTP Server и модуль URL Rewrite в IIS^[28].^[29]

Заголовок Server содержит информацию о программном обеспечении исходного сервера. Для снижения рисков безопасности, связанных с раскрытием информации (что может позволить злоумышленникам идентифицировать известные уязвимости конкретных версий ПО), применяется практика маскировки (обфускации) этого заголовка. Хотя сокрытие версии считается «безопасностью через неясность», оно рекомендуется как дополнительная мера защиты, усложняющая разведку для автоматизированных сканеров. На практике заголовок либо полностью удаляют, либо скрывают номер версии (например, с помощью директивы server_tokens off; в Nginx), оставляя только общее название продукта^[30].^[31]

Заголовок Via добавляется прямыми и обратными прокси-серверами для отслеживания пути прохождения сообщения, предотвращения циклов запросов и определения возможностей протокола. Каждый прокси-сервер в цепочке добавляет свою запись, включающую версию протокола, идентификатор узла и информацию о программном обеспечении. Использование заголовка Via создаёт риски утечки данных о топологии внутренней сети и облегчает создание цифрового отпечатка инфраструктуры. Для снижения этих рисков применяются использование псевдонимов вместо реальных имён хостов и IP-адресов, а также модификация или полное удаление заголовка на границе сети перед отправкой ответа клиенту^[32].^[33]

Основные RFC по протоколу HTTP (по убыванию даты публикации):

• RFC 9745 «Deprecation»  (англ.); IETF, март 2025.
• RFC 9651 «Structured Field Values for HTTP»{{ref name="RFC9651">Structured Field Values for HTTP  (неопр.). IETF Datatracker (январь 2024). Дата обращения: 27 апреля 2026.</ref>}}  (англ.); IETF, январь 2024.
• RFC 9111 «HTTP Caching»  (англ.); IETF, июнь 2022.
• RFC 9110 «HTTP Semantics»  (англ.); IETF, июнь 2022.
• RFC 2616 Draft standard «Hypertext Transfer Protocol — HTTP/1.1»  (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.1»); IETF, июнь 1999; Fielding Roy (UC Irvine), Gettys Jim (Compaq/W3C), Mogul J. (Compaq), Frystyk Henrik (MIT/W3C), Masinter L. (Xerox), Leach P. (Microsoft), Berners-Lee Tim (W3C/MIT) — обновление протокола HTTP версии 1.1.
• RFC 2068 Proposed standard «Hypertext Transfer Protocol — HTTP/1.1»  (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.1»); IETF, январь 1997; Fielding Roy (UC Irvine), Gettys Jim (DEC), Mogul J. (DEC), Frystyk Henrik (MIT/LCS), Berners-Lee Tim (MIT/LCS) — ранняя спецификация по HTTP версии 1.1.
• RFC 1945 Informational «Hypertext Transfer Protocol — HTTP/1.0»  (англ.) (русск. «Протокол передачи гипертекста — HTTP/1.0»); IETF, май 1996; Berners-Lee Tim (MIT/LCS), Fielding Roy (UC Irvine), Frystyk Henrik (MIT/LCS) — самая первая спецификация по протоколу HTTP. Так же включает в себя описание HTTP/0.9.

Материалы по натуральным языкам:

• RFC 3282 Draft standard «Content Language Headers»  (англ.) (русск. «Заголовки языка содержимого»); IETF, июнь 2002; Alvestrand H. (Cisco Systems).
• RFC 5646 Best current practice «Tags for Identifying Languages»  (англ.) (русск. «Метки для обозначения языков»); IETF, сентябрь 2009; Phillips A. (Lab126), Davis M. (Google).
• Language Subtag Registry (англ.). IANA (13 января 2010). — реестр зарегистрированных языковых меток. Дата обращения: 15 января 2010. Архивировано 17 марта 2012 года.