This page was translated from English by the community.Learn more and join the MDN Web Docs community.
Заголовки 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-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 andServer Side Access Control | W3C Cross-Origin Resource Sharing | |
Access-Control-Allow-Origin | HTTP Access Control andServer Side Access Control | W3C Cross-Origin Resource Sharing | |
Access-Control-Allow-Methods | HTTP Access Control andServer Side Access Control | W3C Cross-Origin Resource Sharing | |
Access-Control-Allow-Headers | HTTP Access Control andServer Side Access Control | W3C Cross-Origin Resource Sharing | |
Access-Control-Max-Age | HTTP Access Control andServer Side Access Control | W3C Cross-Origin Resource Sharing | |
Access-Control-Expose-Headers | HTTP Access Control andServer Side Access Control | W3C Cross-Origin Resource Sharing | |
Access-Control-Request-Method | HTTP Access Control andServer Side Access Control | W3C Cross-Origin Resource Sharing | |
Access-Control-Request-Headers | HTTP Access Control andServer 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 inHTTP 1.1's RFC 2068, section 19.6.2.4, it was removed in the finalHTTP 1.1 spec, then reintroduced, with some extensions, inRFC 5988 |
Location | |||
Max-Forwards | |||
Negotiate | HTTP Content Negotiation | RFC 2295, §8.4 | |
Origin | HTTP Access Control andServer Side Access Control | More recently defined in theFetch spec (seeFetch API.) Originally defined inW3C Cross-Origin Resource Sharing | |
Pragma | for the pragma: nocache value seeHTTP 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, likeContent-MD5: while transmitting the data. Note that theTrailer: header must not list theContent-Length:,Trailer: orTransfer-Encoding: headers. | RFC 2616, §14.40 | |
Transfer-Encoding | |||
Upgrade | |||
User-Agent | for Gecko's user agents see theUser 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 | UsingContent 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. TheConnection orProxy-Connection header is still sent, however, with the value "keep-alive".