Заголовки HTTP

Заголовки HTTP позволяют клиенту и серверу отправлять дополнительную информацию с HTTP запросом или ответом. В HTTP-заголовке содержится не чувствительное к регистру название, а затем после (:) непосредственно значение. Пробелы перед значением игнорируются.

Пользовательские собственные заголовки исторически использовались с префиксом X, но это соглашение было объявлено устаревшим в июне 2012 года из-за неудобств, вызванных тем, что нестандартные поля стали стандартом в RFC 6648; другие перечислены в реестре IANA, исходное содержимое которого было определено в RFC 4229. IANA также поддерживает реестр предлагаемых новых заголовков HTTP.

HTTP-заголовки сопровождают обмен данными по протоколу HTTP. Они могут содержать описание данных и информацию, необходимую для взаимодействия между клиентом и сервером. Заголовки и их статусы перечислены в реестре IANA, который постоянно обновляется.

Заголовки могут быть сгруппированы по следующим контекстам:

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

Заголовки также могут быть сгруппированы согласно тому, как прокси (proxies) обрабатывают их:

Сквозные заголовки Эти заголовки должны быть переданы конечному получателю сообщения: серверу для запроса или клиенту для ответа. Промежуточные прокси-серверы должны повторно передавать эти заголовки без изменений, а кеши должны их хранить.

Хоп-хоп заголовки (Хоп-хоп заголовки) Эти заголовки имеют смысл только для одного соединения транспортного уровня и не должны повторно передаваться прокси или кешироваться. Обратите внимание, что с помощью общего заголовка Connection могут быть установлены только заголовки переходов.

Аутентификация

WWW-Authenticate Определяет метод аутентификации, который должен использоваться для доступа к ресурсу. Authorization Содержит учётные данные для аутентификации агента пользователя на сервере. Proxy-Authenticate Определяет метод аутентификации, который должен использоваться для доступа к ресурсам на прокси-сервере. Proxy-Authorization Содержит учётные данные для аутентификации агента пользователя с прокси-сервером.

Ниже перечислены основные HTTP заголовки с кратким описанием:

Заголовок	Описание	Подробнее	Стандарт
`Accept`	Список MIME типов, которые ожидает клиент.	HTTP Content Negotiation	HTTP/1.1
`Accept-CH` Не стандартно	Список конфигурационных данных, которые могут быть учтены сервером при выборе соответствующего ответа клиенту.	HTTP Client Hints
`Accept-Charset`	Список кодировок, которые ожидает клиент.	HTTP Content Negotiation	HTTP/1.1
`Accept-Features`		HTTP Content Negotiation	RFC 2295, §8.2
`Accept-Encoding`	Список форматов сжатия данных, которые поддерживает клиент.	HTTP Content Negotiation	HTTP/1.1
`Accept-Language`	Определяет языковые предпочтения клиента.	HTTP Content Negotiation	HTTP/1.1
`Accept-Ranges`
`Access-Control-Allow-Credentials`		HTTP Access Control and Server Side Access Control	W3C Cross-Origin Resource Sharing
`Access-Control-Allow-Origin`		HTTP Access Control and Server Side Access Control	W3C Cross-Origin Resource Sharing
`Access-Control-Allow-Methods`		HTTP Access Control and Server Side Access Control	W3C Cross-Origin Resource Sharing
`Access-Control-Allow-Headers`		HTTP Access Control and Server Side Access Control	W3C Cross-Origin Resource Sharing
`Access-Control-Max-Age`		HTTP Access Control and Server Side Access Control	W3C Cross-Origin Resource Sharing
`Access-Control-Expose-Headers`		HTTP Access Control and Server Side Access Control	W3C Cross-Origin Resource Sharing
`Access-Control-Request-Method`		HTTP Access Control and Server Side Access Control	W3C Cross-Origin Resource Sharing
`Access-Control-Request-Headers`		HTTP Access Control and Server Side Access Control	W3C Cross-Origin Resource Sharing
`Age`
`Allow`
`Alternates`		HTTP Content Negotiation	RFC 2295, §8.3
`Authorization`
`Cache-Control`		HTTP Caching FAQ
`Connection`	Определяет, остаётся ли сетевое соединение открытым после завершения текущей транзакции (запроса).
`Content-Encoding`
`Content-Language`
`Content-Length`
`Content-Location`
`Content-Range`
`Content-Security-Policy`	Реализует механизм защиты от угроз межсайтового выполнения скриптов.	CSP (Content Security Policy)	W3C Content Security Policy
`Content-Type`	Позволяет клиенту определить MIME тип документа.
`Cookie`			RFC 2109
`DNT`	With a value of 1, indicates that the user explicitly opts out of any form of online tracking.	Supported by Firefox 4, Firefox 5 for mobile, IE9, and a few major companies.	Tracking Preference Expression (DNT)
`Date`
`ETag`		HTTP Caching FAQ
`Expect`
`Expires`		HTTP Caching FAQ
`From`
`Host`
`If-Match`
`If-Modified-Since`		HTTP Caching FAQ
`If-None-Match`		HTTP Caching FAQ
`If-Range`
`If-Unmodified-Since`
`Last-Modified`		HTTP Caching FAQ
`Link`	Содержит ссылки на связанные ресурсы и определяет их отношение к отправленному документу.	For the `rel=prefetch` case, see Link Prefetching FAQ	Introduced in HTTP 1.1's RFC 2068, section 19.6.2.4, it was removed in the final HTTP 1.1 spec, then reintroduced, with some extensions, in RFC 5988
`Location`
`Max-Forwards`
`Negotiate`		HTTP Content Negotiation	RFC 2295, §8.4
`Origin`		HTTP Access Control and Server Side Access Control	More recently defined in the Fetch spec (see Fetch API.) Originally defined in W3C Cross-Origin Resource Sharing
`Pragma`		for the pragma: nocache value see HTTP Caching FAQ
`Proxy-Authenticate`
`Proxy-Authorization`
`Range`
`Referer`	Содержит URL-адрес ресурса, из которого был запрошен обрабатываемый запрос. Если запрос поступил из закладки, прямого ввода адреса пользователем или с помощью других методов, при которых исходного ресурса нет, то этот заголовок отсутствует или имеет значение "about:blank". Это ошибочное имя заголовка (referer, вместо referrer) было введено в спецификацию HTTP/0.9, и ошибка должна была быть сохранена в более поздних версиях протокола для совместимости.
`Retry-After`
`Sec-Websocket-Extensions`			Websockets
`Sec-Websocket-Key`			Websockets
`Sec-Websocket-Origin`			Websockets
`Sec-Websocket-Protocol`			Websockets
`Sec-Websocket-Version`			Websockets
`Server`
`Set-Cookie`			RFC 2109
`Set-Cookie2`			RFC 2965
`Strict-Transport-Security`		HTTP Strict Transport Security	IETF reference
`TCN`		HTTP Content Negotiation	RFC 2295, §8.5
`TE`
`Trailer`	lists the headers that will be transmitted after the message body, in a trailer block. This allows servers to compute some values, like `Content-MD5:` while transmitting the data. Note that the `Trailer:` header must not list the `Content-Length:,` `Trailer:` or `Transfer-Encoding:` headers.		RFC 2616, §14.40
`Transfer-Encoding`
`Upgrade`
`User-Agent`		for Gecko's user agents see the User Agents Reference
`Variant-Vary`		HTTP Content Negotiation	RFC 2295, §8.6
`Vary`	lists the headers used as criteria for choosing a specific content by the web server. This server is important for efficient and correct caching of the resource sent.	HTTP Content Negotiation & HTTP Caching FAQ
`Via`
`Warning`
`WWW-Authenticate`
`X-Content-Duration`		Configuring servers for Ogg media
`X-Content-Security-Policy`		Using Content Security Policy
`X-DNSPrefetch-Control`		Controlling DNS prefetching
`X-Frame-Options`		The XFrame-Option Response Header
`X-Requested-With`	Often used with the value "XMLHttpRequest" when it is the case		Not standard

Примечание

Примечание: The Keep-Alive request header is not sent by Gecko 5.0; previous versions did send it but it was not formatted correctly, so the decision was made to remove it for the time being. The Connection or Proxy-Connection header is still sent, however, with the value "keep-alive".

Смотрите также

Wikipedia page on List of HTTP headers