HTTP_заголовки

В процессе перевода.

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

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

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

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

  • General headers применяется как к запросам, так и к ответам, но не имеет отношения к данным, передаваемым в теле.
  • Заголовки запросов содержит больше информации о ресурсе, который нужно получить, или о клиенте, запрашивающем ресурс.
  • Response headers содержит дополнительную информацию об ответе, например его местонахождение или о сервере, предоставившем его.
  • Entity headers содержит информацию о теле ресурса, например его длину содержимого или тип 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-MD5 Не реализовано (смотрите баг 232030)
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-Event-ID Содержит идентификатор последнего события полученного клиентом от сервера в предыдущем HTTP запросе. Используется для восстановления синхронизации потока text/event-stream. Server-Sent Events Server-Sent Events spec
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

Примечание

Note: 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