Заголовки 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
Non-standard |
Список конфигурационных данных, которые могут быть учтены сервером при выборе соответствующего ответа клиенту. | 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 |
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".