Коды состояния ответа HTTP - HTTP

Коды состояния ответа HTTP
==========================

Код состояния ответа HTTP показывает, был ли успешно выполнен определённый HTTP запрос. Ответы сгруппированы в 5 классов:

1. Информационные ответы (`100` – `199`)
2. Успешные ответы (`200` – `299`)
3. Сообщения о перенаправлении (`300` – `399`)
4. Ошибки клиента (`400` – `499`)
5. Ошибки сервера (`500` – `599`)

Коды состояния определены в RFC 9110.

**Примечание:** Если вы получили код ответа, которого нет в данном списке, то он является не стандартизированным, вероятнее всего он специфичен для конкретного сервера.

Информационные ответы
---------------------

`100 Continue`

Промежуточный ответ, он указывает, что клиент должен продолжить запрос или игнорировать этот ответ, если запрос уже завершен.

`101 Switching Protocols`

Этот код отправляется в ответ на заголовок запроса `Upgrade` (en-US) от клиента и указывает протокол, на который переключается сервер.

`102 Processing` (en-US) (WebDAV (en-US))

Сервер получил и обрабатывает запрос, но ответа пока нет.

`103 Early Hints`

Этот код в первую очередь предназначен для использования с заголовком `Link` (en-US), позволяя пользовательскому агенту начать предварительную загрузку (en-US) ресурсов или осуществить предварительное соединение (en-US) к источнику ресурсов, пока сервер готовит ответ.

Успешные ответы
---------------

`200 OK`

Запрос успешно выполнен. Значение результата «успех» зависит от метода HTTP:

* `GET`: Ресурс был получен и передан в теле сообщения.
* `HEAD`: Ответ содержит заголовки, но тела сообщения нет.
* `PUT` или `POST`: Ресурс, описывающий результат действия, передан в теле сообщения.
* `TRACE`: Тело сообщения содержит сообщение запроса, полученное сервером.

`201 Created`

Запрос выполнен успешно, и в результате был создан новый ресурс. Обычно это ответ, отправляемый на запросы `POST` или `PUT`.

`202 Accepted`

Запрос получен, но еще не обработан. Это «уклончивый» ответ, поскольку в HTTP нет возможности позже отправить асинхронный ответ с результатом обработки запроса. Этот код предназначен для случаев, когда запрос обрабатывается другим процессом или сервером, а также для пакетной обработки.

`203 Non-Authoritative Information`

Возвращенные метаданные не полностью совпадают с теми, которые доступны на исходном сервере, а получены из другого источника. Чаще всего это используется для зеркал или резервных копий ресурсов. За исключением таких случаев предпочтительнее использовать ответ `200 OK`.

`204 No Content`

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

`205 Reset Content`

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

`206 Partial Content`

Этот код ответа используется, когда от клиента отправляется заголовок `Range` для запроса только части ресурса.

`207 Multi-Status` (en-US) (WebDAV (en-US))

Передаёт информацию о нескольких ресурсах в случаях, когда могут быть уместны несколько кодов состояния.

`208 Already Reported` (en-US) (WebDAV (en-US))

Используется внутри элемента ответа `<dav:propstat>`, чтобы избежать повторного перечисления «привязок» и дублирования данных.

`226 IM Used` (en-US) (HTTP Delta encoding)

Используется для ответа на запросы `GET` в тех случаях, когда сервер хочет отправить только изменённую часть ресурса (то есть «дельту»).

Сообщения о перенаправлении
---------------------------

`300 Multiple Choices`

У запроса более одного возможного ответа. Пользовательский агент или пользователь должен выбрать один из них. Не существует стандартизированного способа выбора одного из ответов, но рекомендуется использовать HTML-ссылки на возможные варианты, чтобы у пользователя была возможность выбора.

`301 Moved Permanently`

URL-адрес запрошенного ресурса был изменен навсегда. Новый URL-адрес указан в ответе.

`302 Found`

URI запрошенного ресурса был *временно* изменен. В будущем могут быть внесены дальнейшие изменения в URI. Следовательно, этот же URI должен использоваться клиентом в будущих запросах.

`303 See Other`

Клиенту необходимо получить запрошенный ресурс по другому URI с помощью запроса `GET`.

`304 Not Modified`

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

`305 Use Proxy`
Устарело

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

`306 unused`

Этот код ответа зарезервирован. Использовался в предыдущей версии спецификации HTTP/1.1.

`307 Temporary Redirect`

Клиенту необходимо получить запрошенный ресурс по другому URI тем же методом, который использовался в предыдущем запросе. Он имеет ту же семантику, что и код ответа `302 Found`, за исключением того, что пользовательский агент *не должен* изменять используемый метод: если в первом запросе использовался `POST`, то `POST` должен использоваться и во втором запросе.

`308 Permanent Redirect`

Ресурс теперь находится по другому URI, указанному в заголовке ответа `Location`. Он имеет ту же семантику, что и код ответа `301 Moved Permanently`, за исключением того, что пользовательский агент не должен изменять используемый метод: если в первом запросе использовался `POST`, то `POST` должен использоваться и во втором запросе.

Ошибки клиента
--------------

`400 Bad Request`

Сервер не может или не будет обрабатывать запрос из-за чего-то, что воспринимается как ошибка клиента (например, неправильный синтаксис, формат или маршрутизация запроса).

`401 Unauthorized`

Хотя стандарт HTTP определяет этот ответ как «неавторизованный», семантически он означает «неаутентифицированный». Это значит, что клиент должен аутентифицировать себя, чтобы получить запрошенный ответ.

`402 Payment Required`
Экспериментальная возможность

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

`403 Forbidden`

Клиент не имеет прав доступа к контенту, то есть он неавторизован, поэтому сервер отказывается предоставить запрошенный ресурс. В отличие от `401 Unauthorized`, личность клиента известна серверу.

`404 Not Found`

Сервер не может найти запрошенный ресурс. В браузере это означает, что URL-адрес не распознан. В API это также может означать, что адрес правильный, но ресурс не существует. Сервер также может отправить этот код ответа вместо `403 Forbidden`, чтобы скрыть существование ресурса от неавторизованного клиента. Это самый известный код ответа из-за его частого появления в сети.

`405 Method Not Allowed`

Метод запроса известен серверу, но не поддерживается целевым ресурсом. Например, API может не разрешать вызов `DELETE` для удаления ресурса.

`406 Not Acceptable`

Сервер после выполнения согласования контента не нашёл содержимого, соответствующего критериям, заданным пользовательским агентом.

`407 Proxy Authentication Required`

Этот код ответа похож на `401 Unauthorized`, но аутентификация должна выполняться через прокси-сервер.

`408 Request Timeout`

Сервер может отправить этот код ответа при неиспользовании соединения, даже без предварительного запроса со стороны клиента. Он означает, что сервер хотел бы закрыть это соединение. Этот ответ используется сравнительно часто, поскольку некоторые браузеры (такие как Chrome, Firefox 27+ или IE9) для ускорения используют механизмы предварительного подключения HTTP. Некоторые серверы просто закрывают соединение, не отправляя это сообщение.

`409 Conflict`

Запрос конфликтует с текущим состоянием сервера.

`410 Gone`

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

`411 Length Required`

Запрос отклонён, потому что сервер требует указание поля заголовка `Content-Length`, но оно не определено.

`412 Precondition Failed`

Клиент указал в заголовках запроса условия, которым сервер не соответствует.

`413 Payload Too Large`

Размер объекта запроса превышает ограничения, определенные сервером. Сервер может закрыть соединение или вернуть поле заголовка `Retry-After`.

`414 URI Too Long`

Запрошенный клиентом URI слишком длинный для того, чтобы сервер смог его обработать.

`415 Unsupported Media Type`

Запрос отклонён, потому что медиа формат запрашиваемых данных не поддерживается сервером.

`416 Range Not Satisfiable`

Сервер не может корректно обработать запрос с учётом диапазона, указанного в поле заголовка `Range`.

`417 Expectation Failed`

Сервер не может выполнить ожидание, указанное в поле заголовка запроса `Expect`.

`418 I'm a teapot`

«Шуточный» ответ: сервер отклоняет попытку заварить кофе в чайнике.

`421 Misdirected Request` (en-US)

Сервер не может дать ответ. Возможно сервер не настроен для комбинации схемы и полномочий, указанных в URI запроса.

`422 Unprocessable Content` (WebDAV (en-US))

Запрос сформирован правильно, но его невозможно выполнить из-за семантических ошибок.

`423 Locked` (en-US) (WebDAV (en-US))

Запрашиваемый ресурс заблокирован.

`424 Failed Dependency` (en-US) (WebDAV (en-US))

Запрос не выполнен из-за проблем в предыдущем запросе.

`425 Too Early`
Экспериментальная возможность

Клиент отправил порцию данных слишком рано, до того как сервер установил безопасное соединение.

`426 Upgrade Required`

Сервер отказывается выполнять запрос с использованием текущего протокола, но может быть готов сделать это после смены протокола на указанный в заголовке ответа `Upgrade` (en-US).

`428 Precondition Required`

Сервер требует, чтобы запрос содержал условия. Этот ответ предназначен для предотвращения проблемы одновременного изменения ресурса несколькими пользователями.

`429 Too Many Requests`

Пользователь отправил слишком много запросов в определённый промежуток времени.

`431 Request Header Fields Too Large`

Сервер не будет обрабатывать запрос, потому что поля заголовка слишком велики. Запрос может быть отправлен повторно после уменьшения размера полей заголовка.

`451 Unavailable For Legal Reasons`

Пользовательский агент запросил ресурс, который не может быть предоставлен по закону, например веб-страницу, подвергнутую цензуре со стороны правительства.

Ошибки сервера
--------------

`500 Internal Server Error`

На сервере произошла ошибка, в результате которой он не может успешно обработать запрос.

`501 Not Implemented`

Метод запроса не поддерживается сервером и поэтому он не может быть обработан. Методы `GET` и `HEAD` должны всегда поддерживаться сервером и для них не должен возвращаться этот код.

`502 Bad Gateway`

Такой ответ может прислать сервер, который выступает в качестве шлюза, если в процессе обработки запроса он получил недопустимый ответ от целевого сервера.

`503 Service Unavailable`

Сервер не готов обработать запрос в данный момент. Распространёнными причинами являются техническое обслуживание или перегрузка сервера. Вместе с таким ответом следует отправлять удобную для пользователя страницу с объяснением проблемы, а также HTTP-заголовок `Retry-After` с расчётным временем решения проблемы. Кроме того, полезно отправлять заголовки с информацией о кешировании, поскольку эти временные ответы обычно не следует кэшировать.

`504 Gateway Timeout`

Такой ответ может прислать сервер, который выступает в качестве шлюза, если в процессе обработки запроса он не может вовремя получить ответ от целевого сервера.

`505 HTTP Version Not Supported`

Используемая в запросе версия HTTP не поддерживается сервером.

`506 Variant Also Negotiates` (en-US)

На сервере произошла внутренняя ошибка конфигурации: выбранный в процессе согласования вариант ресурса не является подходящим.

`507 Insufficient Storage` (en-US) (WebDAV (en-US))

Запрос не выполнен, потому что серверу не удалось сохранить данные.

`508 Loop Detected` (en-US) (WebDAV (en-US))

Запрос не выполнен, потому что на сервере был обнаружен бесконечный цикл обработки данных.

`510 Not Extended` (en-US)

Для выполнения запроса необходимо его расширить.

`511 Network Authentication Required`

Клиенту необходимо пройти аутентификацию для получения доступа к сети.

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* Список кодов состояния HTTP в Википедии
* IANA official registry of HTTP status codes


Feature Policy - HTTP

Feature Policy
==============

**Экспериментальная возможность:** **Это экспериментальная технология**
Так как спецификация этой технологии ещё не стабилизировалась, смотрите таблицу совместимости по поводу использования в различных браузерах. Также заметьте, что синтаксис и поведение экспериментальной технологии может измениться в будущих версиях браузеров, вслед за изменениями спецификации.

Feature Policy позволяет веб-разработчику выборочно включать, отключать и изменять поведение определённых функций и API в браузере. Это похоже на Content Security Policy, но контролирует функции вместо политик безопасности.

Краткое описание
----------------

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

С помощью заголовка Feature Policy вы можете включить набор "политик" для браузера, чтобы использовать определённые функции, необходимые веб-сайту. Эти политики определяют какие API сайта могут получать доступ или изменять поведение по умолчанию для определённых функций.

Примеры того, что можно сделать с заголовком Feature Policy:

* Изменить поведение автозапуска видео на мобильных устройствах.
* Ограничить доступ сайта к камере и микрофону.
* Разрешить использование API полноэкранного режима в iframe.
* Блокировать использование устаревших API, например synchronous XHR and `document.write()`.
* Проверять соответствие размера изображений размерам области просмотра.
Concepts and usage
------------------

Feature Policy allows you to control which origins can use which features, both in the top-level page and in embedded frames. Essentially, you write a policy, which is an allowed list of origins for each feature. For every feature controlled by Feature Policy, the feature is only enabled in the current document or frame if its origin matches the allowed list of origins.

For each policy-controlled feature, the browser maintains a list of origins for which the feature is enabled, known as an allowlist. If you do not specify a policy for a feature, then a default allowlist will be used. The default allowlist is specific to each feature.

### Writing a policy

A policy is described using a set of individual policy directives. A policy directive is a combination of a defined feature name, and an allowlist of origins that can use the feature.

### Specifying your policy

Feature Policy provides two ways to specify policies to control features:

* The `Feature-Policy` (en-US) HTTP header.
* The `allow` (en-US) attribute on iframes.

The primary difference between the HTTP header and the `allow` attribute is that the allow attribute only controls features within an iframe. The header controls features in the response and any embedded content within the page.

Types of policy-controlled features
-----------------------------------

Though Feature Policy provides control of multiple features using a consistent syntax, the behavior of policy controlled features varies and depends on several factors.

The general principle is that there should be an intuitive or non-breaking way for web developers to detect or handle the case when the feature is disabled. Newly introduced features may have an explicit API to signal the state. Existing features that later integrate with Feature Policy will typically use existing mechanisms. Some approaches include:

* Return "permission denied" for JavaScript APIs that require user permission grants.
* Return `false` or error from an existing JavaScript API that provides access to feature.
* Change the default values or options that control the feature behavior.

The current set of policy-controlled features fall into two broad categories:

* Enforcing best practices for good user experiences.
* Providing granular control over sensitive or powerful features.
### Best practices for good user experiences

There are several policy-controlled features to help enforce best practices for providing good performance and user experiences.

In most cases, the policy-controlled features represent functionality that when used will negatively impact the user experience. To avoid breaking existing web content, the default for such policy-controlled features is to allow the functionality to be used by all origins. Best practices are then enforced by using policies that disable the policy-controlled features. For more details see "Enforcing best practices for good user experiences".

The features include:

* Layout-inducing animations
* Legacy image formats
* Oversized images
* Synchronous scripts
* Synchronous XMLHTTPRequest
* Unoptimized images
* Unsized media
### Granular control over certain features

The web provides functionality and APIs that may have privacy or security risks if abused. In some cases, you may wish to strictly limit how such functionality is used on a website. There are policy-controlled features to allow functionality to be enabled/disabled for specific origins or frames within a website. Where available, the feature integrates with the Permissions API, or feature-specific mechanisms to check if the feature is available.

The features include:

* Accelerometer
* Ambient light sensor
* Autoplay
* Camera
* Encrypted media
* Fullscreen
* Geolocation
* Gyroscope
* Lazyload
* Microphone
* Midi
* PaymentRequest
* Picture-in-picture
* Speaker
* USB
* VR / XR
Examples
--------

* See Feature Policy Demos for example usage of many policies.
Specifications
--------------

| Specification |
| --- |
| Permissions Policy # permissions-policy-http-header-field |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* `Feature-Policy` (en-US) HTTP header
* `allow` (en-US) attribute on iframes
* Introduction to Feature Policy
* Feature policies on www.chromestatus.com
* Feature-Policy Tester (Chrome Developer Tools extension)


HTTP сессия - HTTP

HTTP сессия
===========

Так как HTTP — это клиент-серверный протокол, HTTP сессия состоит из трёх фаз:

1. Клиент устанавливает TCP соединения (или другое соединение, если не используется TCP транспорт).
2. Клиент отправляет запрос и ждёт ответа.
3. Сервер обрабатывает запрос и посылает ответ, в котором содержится код статуса и соответствующие данные.

Начиная с версии HTTP/1.1, после третьей фазы соединение не закрывается, так как клиенту позволяется инициировать другой запрос. То есть, вторая и третья фазы могут повторяться.

Установка соединения
--------------------

Так как HTTP это клиент-серверный протокол, соединение всегда устанавливается клиентом. Открыть соединение в HTTP — значит установить соединение через соответствующий транспорт, обычно TCP.

В случае с TCP, в качестве порта HTTP сервера по умолчанию на компьютере используется порт 80, хотя другие также часто используются, например 8000 или 8080. URL загружаемой страницы содержит доменное имя и порт, который можно и не указывать если он соответствует порту по умолчанию.

**Примечание:** Клиент-серверная модель не позволяет серверу посылать данные клиенту без явного запроса этих данных. Чтобы обойти эту проблему, веб разработчики используют различные техники: периодически пингуют сервер используя XMLHTTPRequest Javascript объект, HTML WebSockets API, или похожие протоколы.

Отправка запроса клиента
------------------------

Когда соединение установлено user-agent может послать запрос. (user-agent это обычно веб браузер, но может им не быть) Клиентский запрос это текстовые директивы, разделённые между собой при помощи CRLF (переноса строки). Сам запрос включает в себя три блока:

1. Первые строки содержат метод запроса и его параметры:
    * путь к документу - абсолютная URL без указания протокола и доменного имени
    * версию HTTP протокола
2. Каждая последующая строка представляет собой HTTP заголовок и передаёт серверу некоторую информацию о типах предпочитаемых данных (например, какой язык , какие MIME типы) или инструкции меняющие поведение сервера (например, не отправлять ответ, если он уже в кеше) . Эти HTTP заголовки формируют блок, который заканчивается пустой строкой.
3. Последний блок является не обязательным и содержит дополнительные данные. По большей части используется методом POST.
### Примеры запросов

Получаем главную страницу developer.mozilla.org, http://developer.mozilla.org/, и говорим серверу, что user-agent предпочитает страницу на французском, если это возможно:
```

GET / HTTP/1.1
Host: developer.mozilla.org
Accept-Language: fr
```

Обращаем внимание на пустую строку в конце, которая отделяет блок данных от блока заголовков. Так как в запросе отсутствует `Content-Length:` HTTP заголовок, блок с данными пуст и сервер может начать обработку запроса, как только получит пустую строку, означающую конец заголовков.

Отправляем результат сабмита формы:
```

POST /contact_form.php HTTP/1.1
Host: developer.mozilla.org
Content-Length: 64
Content-Type: application/x-www-form-urlencoded

name=Joe%20User&request=Send%20me%20one%20of%20your%20catalogue
```

### Методы запроса

HTTP определяет набор методов запроса с указанием желаемого действие на ресурсе. Хотя они также могут быть и существительными, эти запросы методы иногда называют HTTP-командами. Наиболее распространённые запросы `GET` и `POST`:

* `GET` используется для запроса содержимого указанного ресурса. Запрос с использованием `GET` должен только получать данные.
* `POST` метод отправляет данные на сервер, так что он может изменять своё состояние. Этот метод часто используется для HTML форм.
Структура ответа от сервера
---------------------------

После того как присоединённый агент отправил свой запрос, веб сервер обрабатывает его и отправляет ответ. По аналогии с клиентским запросом, ответ сервера — это текстовые директивы разделённые между собой CRLF, сгруппированные в три разных блока:

1. Первая строка — строка статуса, состоит из подтверждения используемой HTTP версии и статуса запроса (и его значения в виде, понятном человеку).
2. Последующие строки представляют собой HTTP заголовки, дающие клиенту некоторую информацию о посылаемых данных (прим. тип, размер, алгоритм сжатия, подсказки по кешированию). Так же как и в случае клиентского запроса, эти HTTP заголовки формируют блок, заканчивающийся пустой строкой.
3. Последний блок содержит данные (если таковые имеются).
### Примеры ответов

Успешное получение веб страницы:
```

HTTP/1.1 200 OK
Date: Sat, 09 Oct 2010 14:28:02 GMT
Server: Apache
Last-Modified: Tue, 01 Dec 2009 20:18:22 GMT
ETag: "51142bc1-7449-479b075b2891b"
Accept-Ranges: bytes
Content-Length: 29769
Content-Type: text/html

<!DOCTYPE html... (здесь идут 29769 байтов запрошенной веб-страницы)
```

Сообщение о том, что запрашиваемый ресурс был перемещён:
```

HTTP/1.1 301 Moved Permanently
Server: Apache/2.2.3 (Red Hat)
Content-Type: text/html; charset=iso-8859-1
Date: Sat, 09 Oct 2010 14:30:24 GMT
Location: https://developer.mozilla.org/ (это новый адрес запрошенного ресурса, ожидается, что клиент запросит его)
Keep-Alive: timeout=15, max=98
Accept-Ranges: bytes
Via: Moz-Cache-zlb05
Connection: Keep-Alive
X-Cache-Info: caching
X-Cache-Info: caching
Content-Length: 325 (Контент содержит стандартную страницу, которая будет показана, если клиент не может перейти по ссылке)

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://developer.mozilla.org/">here</a>.</p>
<hr>
<address>Apache/2.2.3 (Red Hat) Server at developer.mozilla.org Port 80</address>
</body></html>
```

Сообщение о том, что запрашиваемый ресурс не существует:
```

HTTP/1.1 404 Not Found
Date: Sat, 09 Oct 2010 14:33:02 GMT
Server: Apache
Last-Modified: Tue, 01 May 2007 14:24:39 GMT
ETag: "499fd34e-29ec-42f695ca96761;48fe7523cfcc1"
Accept-Ranges: bytes
Content-Length: 10732
Content-Type: text/html

<!DOCTYPE html... (содержит пользовательскую страницу, помогающую пользователю найти отсутсвующий ресурс)
```

### Коды статусов ответа

HTTP-коды ответов показывают, выполнен ли успешно определённый HTTP-запрос. Ответы сгруппированы в пять классов: информационные ответы, успешные ответы, редиректы, ошибки клиента и ошибки сервера.

* `200`: OK. Запрос завершился успехом.
* `301`: Moved Permanently. Этот код значит, что URI запрошенного ресурса был изменён.
* `404`: Not Found. Сервер не может найти запрошенный ресурс.
Смотрите также
--------------

* Определение ресурсов в Интернете
* HTTP заголовки
* Методы HTTP запроса
* Коды ответа HTTP


Strict-Transport-Security - HTTP

Strict-Transport-Security
=========================

**HTTP `Strict-Transport-Security`** - заголовок ответа (часто используется аббревиатура HSTS (en-US)), позволяющий web-сайтам уведомить браузер о том, что доступ к ним должен быть осуществлён только посредством HTTPS вместо HTTP.

|  |  |
| --- | --- |
| Header type | Response header (en-US) |
| Forbidden header name | no |

Syntax
------
```

Strict-Transport-Security: max-age=<expire-time>
Strict-Transport-Security: max-age=<expire-time>; includeSubDomains
Strict-Transport-Security: max-age=<expire-time>; preload
```

Директивы
---------

`max-age=<expire-time>`

Время, в секундах, которое браузер должен помнить, что сайт доступен только с помощью HTTPS.

`includeSubDomains` Необязательный

Если этот опциональный параметр задан, то правило также применяется ко всем саб-доменам сайта.

`preload` Необязательный

Смотри Предзагрузка Strict Transport Security для большей информации. Не часть спецификации.

Описание
--------

Если сайт поддерживает доступ с помощью HTTP и перенаправляет на HTTPS, посетители могут изначально коммуницировать с незащищённой версией сайта до перенаправления, если, к примеру, введут `http://www.foo.com/` или даже просто foo.com. Это открывает возможности для атак посредников. Перенаправление может быть использовано для перевода посетителей на сайт злоумышленников вместо защищённой версии оригинального сайта.

HTTP Strict Transport Security заголовок сообщает браузеру, что тот никогда не должен загружать сайт через HTTP и всегда должен автоматически конвертировать все попытки доступа к сайту с помощью HTTP в HTTPS.

**Примечание:** `Strict-Transport-Security` заголовок **игнорируется** браузером, если сайт может быть доступен с помощью HTTP, потому что атакующий может перехватить HTTP соединение и внедрить заголовок или убрать его. Когда сайт доступен по HTTPS без ошибок сертификата, браузер знает, что сайт может работать по HTTPS и примет `Strict-Transport-Security` заголовок.

### Пример сценария

Вы залогинились через бесплатную точку доступа WiFi в аэропорту и начали серфить в сети, посещая ваш сервис online-банкинга для того, чтобы проверить баланс и оплатить пару счетов. К сожалению, точка доступа на самом деле хакерский ноутбук, и они перехватывают ваш оригинальный HTTP запрос и перенаправляют вас на клонированную версию вашего банковского сайта. Теперь ваша личная информация доступна хакерам.

Strict Transport Security разрешает эту проблему; пока вы подключены к вашему банковскому сайту с помощью HTTPS и тот использует Strict Transport Security, ваш браузер знает, что должен автоматически использовать только HTTPS, который не позволяет хакерам производить подобные атаки посредников.

### Как ведёт себя браузер

При первом доступе к сайту с помощью HTTPS и возврате `Strict-Transport-Security` заголовка, браузер сохраняет эту информацию, чтобы в дальнейшем при загрузке сайта через HTTP тот автоматически использовал HTTPS.

Когда время истечения, заданное Strict-Transport-Security заголовком, заканчивается, следующая попытка загрузки сайта с помощью HTTP будет воспринята, как обычная без автоматического использования HTTPS.

Каждый раз, когда браузер получает Strict-Transport-Security заголовок, он обновляет время истечения этого сайта, так что сайт может обновлять эту информацию и предотвратить его завершение. Если необходимо отключить Strict-Transport-Security, установите max-age в 0 (через https соединение) и тот моментально завершит `Strict-Transport-Security` заголовок, открывая доступ через http.

Предзагрузка Strict Transport Security
--------------------------------------

Google поддерживает HSTS preload service. Следуя инструкциям и удачно отправив свой домен, браузер никогда не подключится к вашему домену через незащищённое соединение. Так как сервис хостится Google, все браузеры должны изъявить о намерении использовать (или на самом деле начать пользоваться) предзагруженным списком. Однако, это не часть HSTS спецификации и не должно считаться официальным.

* Информация о списке HSTS предзагрузки в Chrome : https://www.chromium.org/hsts
* Консультация о списке HSTS предзагрузки от Firefox: nsSTSPreloadList.inc
Пример
------

Все текущие и будущие субдомены будут HTTPS по max-age на 1 год. Это блокирует доступ к страницам или субдоменам, которые могут быть доступны только по HTTP.
```

Strict-Transport-Security: max-age=31536000; includeSubDomains
```

Specifications
--------------

| Specification |
| --- |
| HTTP Strict Transport Security (HSTS) # section-6.1 |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

See also
--------

* Blog post: HTTP Strict Transport Security has landed!
* Blog post: HTTP Strict Transport Security (force HTTPS)
* OWASP Article: HTTP Strict Transport Security
* Browser test site: HSTS and HPKP test
* Features restricted to secure contexts (en-US)


Accept-Patch - HTTP

Accept-Patch
============

HTTP-заголовок запроса **`Accept-Patch`** показывает, какой медиа-тип понимает сервер внутри запроса `PATCH`.

Наличие **`Accept-Patch`** в ответе к любому методу означает, что сервер принимает `PATCH`-запросы. Как правило, из этого вытекает следующее:

Сервер, принимающий `PATCH`-запрос с неподдерживаемым медиа-типом может ответить кодом ошибки `415` `Unsupported Media Type` и заголовком **`Accept-Patch`**, в котором перечислены поддерживаемые медиа-типы.

**Примечание:** Хранилище IANA поддерживает полный список официальных кодировок.

**Примечание:** Иногда также используются две другие кодировки, `bzip` и `bzip2`, но они не входят в стандарт. Они применяют алгоритм, который используются в этих двух UNIX-программах. Стоит учесть, что поддержка первой кодировки прекратилась из-за проблем с лицензированием.

|  |  |
| --- | --- |
| Тип заголовка | Заголовок ответа (en-US) |
| Запрещённое имя заголовка | да |

Синтаксис
---------
```

Accept-Patch: application/example, text/example
Accept-Patch: text/example;charset=utf-8
Accept-Patch: application/merge-patch+json
```

Директивы
---------

Нет

Примеры
-------
```

Accept-Patch: application/example, text/example

Accept-Patch: text/example;charset=utf-8

Accept-Patch: application/merge-patch+json
```

Спецификации
------------

| Спецификация | Название |
| --- | --- |
| RFC 5789, раздел 3.1: Accept-Patch | HTTP PATCH |

Совместимость с браузерами
--------------------------

Совместимость с браузерами не играет роли для данного заголовка, так как заголовок посылается сервером и спецификация не определяет поведение клиента.

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

* HTTP-метод `PATCH`
* Семантика и контекст RFC 7231, раздел 4.3.4: PUT


Vary - HTTP

Vary
====

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

Заголовок `Vary` должен быть установлен для ответа `304` `Not Modified` точно так же, как он был бы установлен для эквивалентного ответа `200` `OK`.

|  |  |
| --- | --- |
| Тип заголовка | Response header (en-US) |
| Forbidden header name | no |

Syntax
------
```

Vary: *
Vary: <header-name>, <header-name>, ...
```

Directives
----------

\*

Каждый запрос должен рассматриваться как уникальный и не кешируемый. Лучший способ указать это - использовать `Cache-Control`: `no-store`, который удобнее для чтения и также сигнализирует о том, что объект не должен храниться никогда.

<header-name>

Разделённый запятыми список имён заголовков, которые необходимо учитывать при принятии решения о том, можно ли использовать кешированный ответ.

Examples
--------

### Dynamic serving

When using the `Vary: User-Agent` header, caching servers should consider the user agent when deciding whether to serve the page from cache. For example, if you are serving different content to mobile users, it can help you to avoid that a cache may mistakenly serve a desktop version of your site to your mobile users. It can help Google and other search engines to discover the mobile version of a page, and might also tell them that no Cloaking is intended.
```

Vary: User-Agent
```

Specifications
--------------

| Specification | Title |
| --- | --- |
| RFC 7231, раздел 7.1.4: Vary | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Compatibility notes
-------------------

* Vary with care – Vary header problems in IE6-9
See also
--------

* Understanding The Vary Header - Smashing Magazine
* Best Practices for Using the Vary Header – fastly.com
* Content negotiation


X-XSS-Protection - HTTP

X-XSS-Protection
================

Заголовок ответа HTTP **`X-XSS-Protection`** это особенность Internet Explorer, Chrome и Safari, которая останавливает загрузку страниц при обнаружении (XSS (en-US)) атаки. Хотя эти меры защиты не требуются в большинстве случаев для современных браузеров, когда сайты внедряют сильную политику безопасности контента `Content-Security-Policy` (en-US), которая отключает использование встроенного JavaScript (`'unsafe-inline'`), они могут обеспечить защиту для пользователей, использующих устаревшие версии браузеров, не поддерживающих CSP.

|  |  |
| --- | --- |
| Тип заголовка | Response header (en-US) |
| Запрещённое имя заголовка
Forbidden header name | no |

Синтаксис
---------
```

X-XSS-Protection: 0
X-XSS-Protection: 1
X-XSS-Protection: 1; mode=block
X-XSS-Protection: 1; report=<reporting-uri>
```

0

Отключает фильтрацию XSS.

1

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

1; mode=block

Включает фильтрацию XSS. Вместо того, чтобы очищать содержимое страницы, браузер предотвратит отображение страницы, если заметит атаку.

1; report=<reporting-URI> (Chromium only)

Включает фильтрацию XSS. При обнаружении атаки межсайтового скриптинга, браузер очистит страницу от небезопасного содержимого и сообщит о нарушении. Для отправки отчёта используется функциональные возможности директивы CSP `report-uri` (en-US).

Пример
------

Блокировка загрузки страницы, при обнаружении отражённой (непостоянной) XSS:

```bash
X-XSS-Protection: 1; mode=block
```

PHP

```php
header("X-XSS-Protection: 1; mode=block");
```

Apache (.htaccess)

```bash
<IfModule mod_headers.c>
  Header set X-XSS-Protection "1; mode=block"
</IfModule>
```

Спецификации
------------

Не является частью каких-либо специфика или черновиков.

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `Content-Security-Policy` (en-US)
* Controlling the XSS Filter – Microsoft
* Understanding XSS Auditor – Virtue Security
* The misunderstood X-XSS-Protection – blog.innerht.ml


Access-Control-Allow-Headers - HTTP

Access-Control-Allow-Headers
============================

Заголовок ответа **`Access-Control-Allow-Headers`** используется в ответ на preflight request (en-US), чтобы указать, какие заголовки HTTP могут использоваться во время фактического запроса.

The simple headers, `Accept`, `Accept-Language`, `Content-Language`, `Content-Type` (но только с MIME-типом, найденным в этом значении (исключая параметры), либо `application/x-www-form-urlencoded`, `multipart/form-data` или `text/plain`), всегда доступны и не должны быть перечислены в этом заголовке.

Этот заголовок обязателен, если запрос содержит заголовок `Access-Control-Request-Headers` (en-US).

|  |  |
| --- | --- |
| Тип заголовка | Response header (en-US) |
| Forbidden header name | нет |

Синтаксис
---------
```

Access-Control-Allow-Headers: <header-name>, <header-name>, ...
```

Директивы
---------

<header-name>

Список поддерживаемых заголовков разделённых запятыми.

Пример
------
```

Access-Control-Allow-Headers: X-Custom-Header
```

Спецификации
------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-headers |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Примечания по совместимости
---------------------------

* Подстановочное значение (\*), указанное в последней спецификации, ещё не реализовано в браузерах:
    + Chromium: Issue 615313
    + Firefox: Firefox bug 1309358
    + Servo: Issue 13283
    + WebKit: Issue 165508
Смотрите также
--------------

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers` (en-US)
* `Access-Control-Allow-Methods`
* `Access-Control-Request-Headers` (en-US)


ETag - HTTP

ETag
====

`Заголовок HTTP ответа ETag` является идентификатором специфической версии ресурса. Он позволяет более эффективно использовать кеш и сохраняет пропускную способность, позволяя серверу отправлять не весь ответ, если содержимое не изменилось. С другой стороны, если контент все-таки поменялся, `Etag` помогает предотвратить одновременное обновление ресурса от перезаписи друг друга ("воздушная коллизия").

Если ресурс по заданному URL изменился, будет сгенерированно новое значение `Etag`. Поэтому `Etag` чем-то похож на отпечаток ("fingerprints") и может также быть использован для отслеживания предназначения некоторых серверов. Сравнение этих заголовков позволяет быстро определить являются ли два представления ресурса одними и теме же. Отслеживаемый сервер также может задать сохранять их постоянно.

|  |  |
| --- | --- |
| Тип заголовка | Заголовок ответа |
| Запрещённое имя заголовка | нет |

Синтаксис
---------
```

ETag: W/"<etag_value>"
ETag: "<etag_value>"
```

Директивы
---------

`W/` Необязательный

`'W/'` (чувствителен к регистру) указывает, что используется слабый валидатор. Слабые валидаторы легко сгенерировать, но они намного реже используются для сравнения. Сильные валидаторы идеальны для сравнения, но их может быть очень сложно сгенерировать эффективно. Слабое значение `Etag` двух представлений одного и того же ресурса может быть семантически одинаково, но не байт-в-байт.

"<etag\_value>"

Тэг сущности, уникально представляющий запрашиваемый ресурс. Это строка ASCII кодов, заключённая в двойные кавычки (например, `"675af34563dc-tr34"`). Метод, по которому генерируются значения `ETag`, не определён. Обычно, используется хэш контента, хэш последнего времени модификации или просто номер ревизии. Например, MDN использует шестнадцатеричных хэш wiki-содержимого.

Примеры
-------
```

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
ETag: W/"0815"
```

### Как избежать коллизий в процессе работы приложения

С помощью заголовков `ETag` и `If-Match`, существует возможность обнаружить коллизии в процессе работы приложения.

Например, при редактировании MDN, текущее содержимое статьи захешировано и помещено в ответ при помощи заголовка `Etag`:
```

ETag: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

При сохранении изменений в статье (данные отправляются), `POST` запрос будет содержать заголовок `If-Match`, значение которого эквивалентно значению `ETag`. Это позволяет проверить актуальность данных.
```

If-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

Если хэши из заголовков не совпадают, это означает что данные уже были изменены между запросами (in-between) и будет возвращена ошибка `412` `Precondition Failed`.

### Кеширование неизменяемых ресурсов

Другая типичная ситуация для использования `ETag` — кеширование ресурсов, которые не будут изменяться. Если пользователь повторно посещает URL-адрес (с установленным заголовком `ETag`), и при этом данные слишком устарели и не могут быть использованы, тогда клиент отправит значение `ETag` внутри заголовка `If-None-Match` (en-US):
```

If-None-Match: "33a64df551425fcc55e4d42a148795d9f25f89d4"
```

После чего сервер сравнит клиентский `ETag` (отправленный с помощью `If-None-Match`) с `ETag` для текущей версии ресурса и, если их значения совпадают (т.е. ресурсы не были изменены), сервер вернёт статус `304` `Not Modified`, без тела ответа. Такой ответ сервера сообщает клиенту, что закешированная версия ресурса актуальна и готова к использованию.

Спецификации
------------

| Specification | Title |
| --- | --- |
| RFC 7232, раздел 2.3: ETag | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `If-Match`
* `If-None-Match` (en-US)
* `304` `Not Modified`
* `412` `Precondition Failed`
* W3C Note: Editing the Web – Detecting the Lost Update Problem Using Unreserved Checkout


Expires - HTTP

Expires
=======

Заголовок **`Expires`** содержит дату/время, по истечении которой ответ сервера считается устаревшим.

Прошедшая или невалидная дата, например 0, обозначает, что ресурс уже устарел.

Если в ответе с сервера установлен заголовок `Cache-Control` с директивами "max-age" или "s-maxage" , заголовок `Expires` игнорируется.

|  |  |
| --- | --- |
| Тип заголовка | Response header (en-US) |
| Запрещённое имя заголовка | нет |
| CORS безопасный заголовок (en-US) | да |

Синтаксис
---------
```

Expires: <http-date>
```

Директивы
---------

<http-date>

HTTP-дата и время.

Примеры
-------
```

Expires: Wed, 21 Oct 2015 07:28:00 GMT
```

Спецификация
------------

| Specification |
| --- |
| HTTP Caching # field.expires |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `Cache-Control`
* `Age` (en-US)


Date - HTTP

Date
====

**`Date`** основной HTTP заголовок содержащий дату и время, в которое сообщение было создано.

|  |  |
| --- | --- |
| Тип заголовка | Основной |
| Запрещённое имя заголовка | да |

Синтаксис
---------
```

Date: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

Директивы
---------

<day-name>

Одно из "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", или "Sun" (регистрозависимое значение).

<day>

Номер дня с ведущим нулём, например "04" или "23".

<month>

Один из "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (регистрозависимое значение).

<year>

Год из 4-х символов, например "1990" или "2016".

<hour>

Часы с ведущим нулём, например "09" или "23".

<minute>

Минуты с ведущим нулём, например "04" или "59".

<second>

Секунды с ведущим нулём, например "04" или "59".

GMT

Время по Гринвичу. HTTP даты всегда представлены в GMT, а не в локальном времени

Примеры
-------
```

Date: Wed, 21 Oct 2015 07:28:00 GMT
```

Спецификации
------------

| Спецификация | Название |
| --- | --- |
| RFC 7231, раздел 7.1.1.2: Date | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `Age` (en-US)


Referer - HTTP

Referer
=======

Заголовок запроса **`Referer`** содержит URL исходной страницы, с которой был осуществлён переход на текущую страницу. Заголовок `Referer` позволяет серверу узнать откуда был осуществлён переход на запрашиваемую страницу. Сервер может анализировать эти данные, записывать их в логи или оптимизировать процесс кеширования.

Обратите внимание, что слово «Referer» на самом деле является неправильным написанием слова «Referrer». См. HTTP referer.

**Предупреждение:** Заголовок `Referer` может раскрыть информацию пользователя об истории посещённых страниц, что может привести к нарушению приватности.

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

К примеру, по умолчанию URL страницы сброса пароля будет попадать на хосты, размещающие контент на странице, и хосты ссылок, нажатых на этой странице. В обоих случаях сторонний хост получит `Referer` пользователя.

Существует риск, что содержимое, загруженное на страницу получит доступ к `Referer` из объекта document.referrer.

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

Некоторые браузеры, такие как Firefox, также отправляют `Referer` в представлениях, отличных от страниц HTML. К примеру, JsonView отправит `Referer` хосту, когда в JSON будет переход по URL-адресу, это может раскрыть приватные данные. Иногда передача `Referer` случается при работе с API, при некорректных параметрах запроса в API ключах.

Браузер не отправляет заголовок `Referer`, если:

* исходный ресурс — локальный "файл" или "data" URI,
* используется незащищённый HTTP-запрос, а исходная страница была получена с защищённым протоколом (HTTPS).

|  |  |
| --- | --- |
| Тип заголовка | Request header |
| Forbidden header name | yes |

Синтаксис
---------
```

Referer: <url>
```

Указания
--------

<url>

Абсолютный или частичный адрес предыдущей веб-страницы, с которой был осуществлён переход на запрашиваемую страницу. Фрагменты URL-адреса (т.к. #якорь") и данные пользователя(т.к. "логин:пароль" в "https://username:password@example.com/foo/bar/") не включать.

Пример
------
```

Referer: https://developer.mozilla.org/ru/docs/Web/JavaScript
```

Спецификация
------------

| Specification |
| --- |
| HTTP Semantics # field.referer |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `Referrer-Policy` (en-US)


Accept-Charset - HTTP

Accept-Charset
==============

Заголовок **`Accept-Charset`** запроса HTTP сообщает какую кодировку клиент может понять. Используя согласование контента, сервер выбирает один из предложенных вариантов, использует его и информирует клиент о своём выборе в `Content-Type` ответном заголовке. Браузер обычно не устанавливает этот заголовок, т.к. значение по умолчанию для каждого контентного типа обычно корректный и передача его позволит с большей лёгкостью получить цифровой отпечаток.

Если сервер не может обслужить никакую из предоставленных кодировок, теоретически он может вернуть `406` (Not Acceptable) код ошибки. Но, для более лучшего пользовательского опыта, это редко делается и более частый способ в этом случае, это просто игнорирование заголовка `Accept-Charset`.

**Примечание:** В более ранних версиях HTTP/1.1, кодировка по умолчанию (`ISO-8859-1`) была определена. Теперь это не так и каждый контентый тип может иметь своё собственное дефолтное значение.

|  |  |
| --- | --- |
| Тип заголовка | Request header |
| Forbidden header name | Да |

Синтаксис
---------
```

Accept-Charset: <кодировка>

// Множественные типы, придающие вес с quality value (en-US) синтаксисом:
Accept-Charset: utf-8, iso-8859-1;q=0.5
```

Директивы
---------

`<charset>`

Кодировка типа `utf-8` или `iso-8859-15.`

`*`

Любая кодировка не указанная нигде в заголовке; `'*'` используется как групповой символ.

`;q=` (q-factor weighting)

Любое значение помещается в порядке предпочтения, выраженного с использованием относительного значения качества, называемого *весом*.

Примеры
-------
```

Accept-Charset: iso-8859-1

Accept-Charset: utf-8, iso-8859-1;q=0.5

Accept-Charset: utf-8, iso-8859-1;q=0.5, *;q=0.1
```

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

* HTTP content negotiation
* Header with the result of the content negotiation: `Content-Type`
* Other similar headers: `TE` (en-US), `Accept-Encoding` (en-US), `Accept-Language`, `Accept`


Origin - HTTP

Origin
======

Заголовок запроса **`Origin`** показывает откуда будет производиться загрузка. Он не включает в себя какую-либо информацию о пути, содержит в себе лишь имя сервера. Заголовок отправляется как с CORS, так и с `POST` запросами. Он похож на заголовок `Referer`, но, в отличие от этого заголовка, не раскрывает весь путь.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | yes |

Синтаксис
---------
```

Origin: ""
Origin: <протокол> "://" <имя_хоста> [ ":" <порт> ]
```

`Origin` может быть пустой строкой: это полезно, например, если источником данных будет URL.

Директивы
---------

<протокол>

Используемый протокол. Обычно это HTTP протокол, или его защищённая версия HTTPS.

<имя\_хоста>

Доменное имя сервера (для виртуального хостинга) или IP.

<порт> Необязательный

Номер TCP порта, который сервер будет слушать. Если порт не задан, будет использован порт по умолчанию для указанного сервиса (например "80" для HTTP).

Примеры
-------
```

Origin: https://developer.mozilla.org
```

Спецификации
------------

| Specification |
| --- |
| The Web Origin Concept # section-7 |
| Fetch Standard # origin-header |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `Host`
* `Referer`
* Same-origin policy


Access-Control-Max-Age - HTTP

Access-Control-Max-Age
======================

Заголовок ответа сервера **`Access-Control-Max-Age`** сообщает браузеру насколько предзапрос (эта информация содержится в заголовках `Access-Control-Allow-Methods` и `Access-Control-Allow-Headers`) может быть кеширован и опущен при запросах к серверу.

|  |  |
| --- | --- |
| Тип заголовка | Заголовок ответа |
| Запрещённое имя заголовка | нет |

Синтаксис
---------
```

Access-Control-Max-Age: <delta-seconds>
```

Параметры
---------

<delta-seconds>

 Количество секунд, на которое запрос может быть кеширован.
 Максимальное значение в Firefox составляет 24 часа (86400 секунд), в Chromium 10 минут (600 секунд). Chromium также определяет значение по умолчанию 5 секунд.
 Значение **-1** отменяет кеширование, отправляя предзапрос перед каждым запросом.

Примеры
-------

Кеширование предзапроса на 600 секунд:
```

Access-Control-Max-Age: 600
```

Спецификации
------------

| Specification |
| --- |
| Fetch Standard # http-access-control-max-age |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `Access-Control-Allow-Headers`
* `Access-Control-Allow-Methods`


Accept - HTTP

Accept
======

HTTP заголовок запроса **`Accept`** указывает, какие типы контента, выраженные как MIME типы, клиент может понять. Используя согласование контента, сервер затем выбирает одно из предложений, использует его и информирует клиента о своём выборе с помощью заголовка ответа `Content-Type`. Браузеры задают адекватные значения для этого заголовка в зависимости от контекста, в котором выполняется запрос: при получении таблицы стилей CSS для запроса задаётся другое значение, чем при получении изображения, видео или скрипта.

|  |  |
| --- | --- |
| Тип заголовка | Request header |
| Запрещённое имя заголовка | нет |
| CORS-safelisted request-header |
 yes, with the additional restriction that values can't contain a
 *CORS-unsafe request header byte*: 0x00-0x1F (except 0x09 (HT)),
 `"():<>?@[\]{}`, and 0x7F (DEL).
  |

Синтаксис
---------
```

Accept: <MIME_type>/<MIME_subtype>
Accept: <MIME_type>/*
Accept: */*

// Несколько типов, дополненных синтаксисом значений качества (en-US):
Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

Директивы
---------

`<MIME_type>/<MIME_subtype>`

Один точный MIME-тип, например `text/html`.

`<MIME_type>/*`

MIME тип без какого-либо подтипа. `image/*` будет соответствовать типам `image/png`, `image/svg`, `image/gif` и любым другим типам изображений.

`*/*`

Любой MIME type

`;q=` (q-factor weighting)

Любое используемое значение помещается в порядке приоритета, заданным с использованием относительного значения качества (en-US), которое называется *весом*.

Примеры
-------
```

Accept: text/html

Accept: image/*

Accept: text/html, application/xhtml+xml, application/xml;q=0.9, */*;q=0.8
```

Спецификации
------------

| Характеристика | Название |
| --- | --- |
| RFC 7231, раздел 5.3.2: Accept | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Context |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* HTTP согласование контента
* Заголовок с результатами согласования контента: `Content-Type`
* Другие похожие заголовки: `TE` (en-US), `Accept-Encoding` (en-US), `Accept-Charset`, `Accept-Language`


Host - HTTP

Host
====

Заголовок **Host** содержит имя домена, для которого предназначен запрос и, опционально, номер порта.

Если порт не указан, то используется умолчательный порт протокола/сервиса (например «80» для HTTP, "443" для HTTPS и т.д.).

Каждый HTTP/1.1 запрос должен содержать один и только один заголовок **Host**, в ином случае ответ будет с кодом статуса `400` (Bad Request).

|  |  |
| --- | --- |
| Тип заголовка | Request header |
| Forbidden header name Неизменяемый | да |

Синтаксис
---------
```

Host: <host>:<port>
```

Обозначения
-----------

<host>

доменное имя сервера

<port> Необязательный

номер порта

Пример
------
```

Host: developer.mozilla.org
```

Спецификации
------------

| Стандарт/спецификация | Название |
| --- | --- |
| RFC 7230, раздел 5.4: Host | Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `400`


Access-Control-Allow-Methods - HTTP

Access-Control-Allow-Methods
============================

**`Access-Control-Allow-Methods`** это заголовок ответа, который определяет метод или методы доступа к ресурсам preflight request (en-US).

|  |  |
| --- | --- |
| Тип заголовка | Response header (en-US) |
| Forbidden header name | нет |

Синтаксис
---------
```

Access-Control-Allow-Methods: <method>, <method>, ...
```

Директивы
---------

<method>

Разделённый запятыми список доступных методов HTTP запросов.

Примеры
-------
```

Access-Control-Allow-Methods: POST, GET, OPTIONS
```

Спецификации
------------

| Specification |
| --- |
| Fetch Standard # http-access-control-allow-methods |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Замечания по совместимости
--------------------------

* Подстановочное значение (\*), которое упоминается в последней спецификации ещё не реализовано в браузерах:
    + Chromium: Issue 615313
    + Firefox: Firefox bug 1309358
    + Servo: Issue 13283
See also
--------

* `Access-Control-Allow-Origin`
* `Access-Control-Expose-Headers` (en-US)
* `Access-Control-Allow-Headers`
* `Access-Control-Request-Method` (en-US)


Retry-After - HTTP

Retry-After
===========

**`Retry-After`** заголовок HTTP ответа показывает, как долго клиент должен подождать перед последующим запросом. Есть три основных случая, в которых следует использовать этот заголовок:

* Когда отправлен с кодом `503` (Service Unavailable), отображая примерное время, через которое сервис будет доступен.
* Когда отправлен с кодом `429` (Too Many Requests), отображая, сколько ждать перед следующим запросом.
* Когда отправлен с кодом переадресации (например, `301` (Moved Permanently)), отображает минимальное время, которое клиент должен подождать перед переадресацией.

|  |  |
| --- | --- |
| Тип заголовка | Ответный заголовок |
| Forbidden header name | no |

Синтаксис
---------
```

Retry-After: <http-date>
Retry-After: <delay-seconds>
```

Директивы
---------

<http-date>

Дата, после которой пытаться ещё раз. За документацией к HTTP дате, обратитесь сюда: `Дата`.

<delay-seconds>

Неотрицательное число секунд, показывающее время ожидания перед новым запросом.

Примеры
-------

### Работа с запланированным временем простоя

Поддержка `Retry-After` реализована ещё не везде. Впрочем, некоторые боты, к примеру Googlebot, понимает заголовок `Retry-After`. В данном случае полезно отправлять его с кодом `503` (Service Unavailable), чтобы поисковики продолжили индексировать после простоя
```

Retry-After: Wed, 21 Oct 2015 07:28:00 GMT
Retry-After: 120
```

Спецификации
------------

| Specification | Title |
| --- | --- |
| RFC 7231, раздел 7.1.3: Retry-After | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* Google Webmaster blog: How to deal with planned site downtime
* `503` (Service Unavailable)
* `301` (Moved Permanently)


Set-Cookie - HTTP

Set-Cookie
==========

HTTP заголовок **`Set-Cookie`** используется для отправки cookies с сервера на агент пользователя.

Для детальной информации, смотрите руководство по HTTP cookies.

| Тип заголовка | Response header (en-US) |
| --- | --- |
| Forbidden header name | нет |

Синтаксис
---------
```

Set-Cookie: <cookie-name>=<cookie-value>
Set-Cookie: <cookie-name>=<cookie-value>; Expires=<date>
Set-Cookie: <cookie-name>=<cookie-value>; Max-Age=<non-zero-digit>
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>
Set-Cookie: <cookie-name>=<cookie-value>; Path=<path-value>
Set-Cookie: <cookie-name>=<cookie-value>; Secure
Set-Cookie: <cookie-name>=<cookie-value>; HttpOnly

Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Strict
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=Lax
Set-Cookie: <cookie-name>=<cookie-value>; SameSite=None
 Экспериментальная возможность

// Multiple directives are also possible, for example:
Set-Cookie: <cookie-name>=<cookie-value>; Domain=<domain-value>; Secure; HttpOnly
```

Директивы
---------

* По умолчанию - хост текущего URL документа, не включая поддомены
* В текущей спецификация начальная точка в имени хоста игнорируется (`.example.com`)
* Cookie будут отправляться также на поддомены указанного хоста
* Указывать несколько хостов недопустимо.

* По умолчанию - хост текущего URL документа, не включая поддомены
* В текущей спецификация начальная точка в имени хоста игнорируется (.example.com)
* Cookie будут отправляться также на поддомены указанного хоста
* Указывать несколько хостов недопустимо.

`<cookie-name>=<cookie-value>`

Cookie начинается с пары имя-значение:

* `<cookie-name>` может содержать любые символы US-ASCII, за исключением управляющих символов (CTLs), пробелов, или табуляций. Оно также не должно содержать разделительных символов, таких как следующие: `( ) < > @ , ; : \ " / [ ] ? = { }`.
* `<cookie-value>` может быть опционально заключено в двойные кавычки, разрешены любые символы US-ASCII за исключением CTLs, пробела, двойных кавычек, запятой, точки с запятой, и обратного слеша. **Кодирование:** Многие реализации выполняют кодирование в значениях cookies, однако этого не требуется по спецификации RFC. Однако, это помогает удовлетворить требование о разрешённых символах в <cookie-value>.
* **`__Secure-` prefix**
Non-standard
: Cookies с именем, начинающимся с `__Secure-` (подчёркивание является частью префикса ) должны быть установлены вместе с флагом secure, и должны быть с безопасной страницы (HTTPS).
* **`__Host-` prefix**
Non-standard
: Cookies с именем, начинающимся с `__Host-` должны быть установлены с флагом secure `secure`, должны быть с безопасной страницы (HTTPS), не должны иметь определённый домен (и, следовательно, не не посылаются поддоменами), а также параметр Path должен быть "/".

`Expires=<date>` Необязательный

Максимальное время жизни cookie в формате метки даты-времени HTTP. См. `Date` о деталях формата Если не определён, cookie будет иметь время жизни **сессионного cookie.** Сессия окончена, когда клиент отключается, что приводит к удалению сессионных cookie в этот момент. Однако, многие браузеры имеют возможность, называемую восстановление сессии, которая сохраняет все ваши вкладки и затем возвращает их, когда вы в следующий раз запускаете браузер. Cookies будут также присутствовать, словно вы никогда не закрывали браузер.

Когда устанавливается срок действия, время и дата устанавливаются не относительно сервера, а относительно клиента, на котором установлено cookie,

`Max-Age=<number>` Необязательный

Количество секунд, после которого cookie устаревает. Ноль или отрицательное число приводят к моментальному устареванию cookie. Старые браузеры (ie6, ie7, and ie8) не поддерживают Max-Age. Для прочих браузеров, если оба параметра (`Expires` and `Max-Age`) установлены, `Max-Age` будет иметь преимущество.

`Domain=<domain-value>` Необязательный

Хост, на который будут отправляться cookie.

 По умолчанию - хост текущего URL документа, не включая поддомены
 В текущей спецификация начальная точка в имени хоста игнорируется (.example.com)
 Cookie будут отправляться также на поддомены указанного хоста
 Указывать несколько хостов недопустимо.

`Path=<path-value>` Необязательный

Путь, который должен существовать в запрошенном URL, иначе браузер не отправит заголовок Cookie.

 Пример: `/` - cookie будет отправляться со всеми запросами
 Пример: `/docs/` - cookie будет отправляться с запросами к директории docs и её поддиректориям

`Secure` Необязательный

Cookie будет отправлен на сервер только с запросами c использованием SSL и протокола HTTPS.

Cookie не будет дополнительно шифроваться, поэтому в нем не стоит хранить конфиденциальную информацию.

**Note:** небезопасные сайты (`http:`) не могут использовать cookie с атрибутом "secure" (начиная с Chrome 52+ и Firefox 52+).

`HttpOnly` Необязательный

Запрещает JavaScript доступ к cookie

Полезно для защиты от XSS-атак.

`SameSite=<samesite-value>` Необязательный

* `Strict`: The browser sends the cookie only for same-site requests (that is, requests originating from the same site that set the cookie). If the request originated from a different URL than the current one, no cookies with the `SameSite=Strict` attribute are sent.
* `Lax`: The cookie is withheld on cross-site subrequests, such as calls to load images or frames, but is sent when a user navigates to the URL from an external site, such as by following a link
* `None`: The browser sends the cookie with both cross-site and same-site requests

Allows servers to assert that a cookie ought not to be sent along with cross-site requests, which provides some protection against cross-site request forgery attacks (CSRF).

Современные браузеры используют `SameSite=Lax`. Если необходима работа `SameSite=None` cookie должна быть установлена с атрибутом `Secure`.

Примеры
-------

### Сессионный cookie

Сессионные cookies будут удалены после отключения клиента. В них не указываются директивы `Expires` или `Max-Age`. Учитывайте, что часто в браузере включено восстановление сессии.
```

Set-Cookie: sessionid=38afes7a8; HttpOnly; Path=/
```

### Постоянный cookie

Вместо истечения срока действия, когда клиент закрыт, срок действия постоянных файлов cookie истекает в определённую дату (`Expires`) или по истечении определённого промежутка времени (`Max-Age`).
```

Set-Cookie: id=a3fWa; Expires=Wed, 21 Oct 2015 07:28:00 GMT; Secure; HttpOnly
```

### Неверные домены

Файл cookie, принадлежащий домену, который не включает исходный сервер, должен быть отклонён пользовательским. Следующий cookie будет отклонён, если он был установлен сервером, размещённым на originalcompany.com.
```

Set-Cookie: qwerty=219ffwef9w0f; Domain=somecompany.co.uk; Path=/; Expires=Wed, 30 Aug 2019 00:00:00 GMT
```

### Cookie prefixes

Cookies names with the prefixes `__Secure-` and `__Host-` can be used only if they are set with the `secure` directive from a secure (HTTPS) origin. In addition, cookies with the `__Host-` prefix must have a path of "/" (the entire host) and must not have a domain attribute. For clients that don't implement cookie prefixes, you cannot count on having these additional assurances and the cookies will always be accepted.
```

// Both accepted when from a secure origin (HTTPS)
Set-Cookie: __Secure-ID=123; Secure; Domain=example.com
Set-Cookie: __Host-ID=123; Secure; Path=/

// Rejected due to missing Secure directive
Set-Cookie: __Secure-id=1

// Rejected due to the missing Path=/ directive
Set-Cookie: __Host-id=1; Secure

// Rejected due to setting a domain
Set-Cookie: __Host-id=1; Secure; Path=/; domain=example.com
```

Specifications
--------------

| Specification | Title |
| --- | --- |
| RFC 6265, раздел 4.1: Set-Cookie | HTTP State Management Mechanism |
| draft-ietf-httpbis-rfc6265bis-02 | Cookie Prefixes, Same-Site Cookies, and Strict Secure Cookies |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Compatibility notes
-------------------

* Starting with Chrome 52 and Firefox 52, insecure sites (`http:`) can't set cookies with the "secure" directive anymore.
See also
--------

* HTTP cookies
* `Cookie` (en-US)
* `Document.cookie`


Accept-Ranges - HTTP

Accept-Ranges
=============

HTTP Заголовок ответа **`Accept-Ranges`** — это маркер, который использует сервер, чтобы уведомить клиента о поддержке "запросов по кускам". Его значение указывает единицу измерения, которая может быть использована для определения диапазона чтения.

При наличии заголовка `Accept-Ranges`, браузер может попытаться *возобновить* прерванную загрузку, а не запускать её с самого начала.

|  |  |
| --- | --- |
| Тип заголовка | Response header (en-US) |
| Forbidden header name | no |

Синтаксис
---------
```

Accept-Ranges: bytes
Accept-Ranges: none
```

Указания
--------

`none`

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

`bytes`

Единицей измерения для диапазона являются байты.

Примеры
-------
```

Accept-Ranges: bytes
```

Спецификации
------------

| Спецификация | Название |
| --- | --- |
| RFC 7233, раздел 2.3: Accept-Ranges | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `If-Range` (en-US)
* `Range`
* IANA HTTP Range Unit Registry


Expect - HTTP

Expect
======

Запрос "HTTP Expect" указывает ожидания, которые должен выполнить сервер, чтобы правильно обработать запрос.

Единственным ожиданием, определённым в спецификации, является "Expect: 100-continue", на который сервер должен ответить:

* `100` если информации, содержащейся в заголовке, достаточно, чтобы вызвать немедленный успех,
* `417` (Expectation Failed) если он не может удовлетворить ожидания; или любой другой статус 4xx..

Например, сервер может отклонить запрос, если его `Content-Length` слишком большой.

Обычные браузеры не отправляют заголовок Expect, но некоторые другие , такие как cURL, делают это по умолчанию.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Синтаксис
---------

Никаких других ожиданий, кроме «100-continue», не указано
```

Expect: 100-continue
```

Директивы
---------

100-continue

Сообщает получателям, что клиент собирается отправить (по-видимому большой) тело сообщения в этот запрос и хочет получить промежуточный ответ `100` (Continue).

Примеры
-------

### Большой текст сообщения

Клиент отправляет запрос с заголовком Expect и ожидает ответа сервера перед отправкой тела сообщения.
```

PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
```

Сервер теперь проверяет запрос и может ответить с ответом `100` (Continue), чтобы дать клиенту указание продолжить и отправить тело сообщения, или он отправит `417` (Expectation Failed), если какие-либо из ожиданий не могут быть выполнены.

Характеристики
--------------

| Спецификация | Название |
| --- | --- |
| RFC 7231, раздел 5.1.1: Expect | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `417` `Expectation Failed`
* `100` `Continue`


Content-Length - HTTP

Content-Length
==============

Заголовок **`Content-Length`** указывает размер отправленного получателю тела объекта в байтах.

|  |  |
| --- | --- |
| Тип заголовка | Заголовок сущности |
| Можно не передавать | да |

Синтаксис
---------
```

Content-Length: <длина>
```

Директивы
---------

<длина>

Байты.

Спецификация
------------

| Specification |
| --- |
| HTTP Semantics # field.content-length |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `Transfer-Encoding` (en-US)


Cache-Control - HTTP

Cache-Control
=============

Общий заголовок **`Cache-Control`** используется для задания инструкций кеширования как для запросов, так и для ответов. Инструкции кеширования однонаправленные: заданная инструкция в запросе не подразумевает, что такая же инструкция будет указана в ответе

|  |  |
| --- | --- |
| Header type | General header |
| Forbidden header name | нет |
| CORS-safelisted response-header (en-US) | да |

Синтаксис
---------

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

### Инструкции кеширования для запросов

Стандартные инструкции `Cache-Control`, которые могут задаваться клиентом для HTTP запроса.
```

Cache-Control: max-age=<seconds>
Cache-Control: max-stale[=<seconds>]
Cache-Control: min-fresh=<seconds>
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: only-if-cached
```

### Инструкции кеширования для ответов

Стандартные инструкции `Cache-Control`, которые могут задаваться сервером для HTTP ответа.
```

Cache-Control: must-revalidate
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: no-transform
Cache-Control: public
Cache-Control: private
Cache-Control: proxy-revalidate
Cache-Control: max-age=<seconds>
Cache-Control: s-maxage=<seconds>
```

### Расширенные инструкции `Cache-Control`

Расширенные инструкции `Cache-Control` не являются частью базовых стандартов, описывающих кеширование в HTTP. В таблице совместимости указаны браузеры, которые поддерживают расширенные инструкции.
```

Cache-Control: immutable
Cache-Control: stale-while-revalidate=<seconds>
Cache-Control: stale-if-error=<seconds>
```

Инструкции
----------

### Управление кешированием

`public`

Указывает, что ответ может быть закеширован в любом кеше.

`private`

Указывает, что ответ предназначен для одного пользователя и не должен помещаться в разделяемый кеш. Частный кеш может хранить ресурс.

`no-cache`

Указывает на необходимость отправить запрос на сервер для валидации ресурса перед использованием закешированных данных.

`only-if-cached`

Указывает на необходимость использования только закешированных данных. Запрос на сервер не должен посылаться.

### Управление временем жизни

`max-age=<seconds>`

Задаёт максимальное время в течение которого ресурс будет считаться актуальным. В отличие от `Expires`, данная инструкция является относительной по отношению ко времени запроса.

`s-maxage=<seconds>`

Переопределяет `max-age` или заголовок `Expires`, но применяется только для разделяемых кешей (например, прокси) и игнорируется частными кешами.

`max-stale[=<seconds>]`

Указывает, что клиент хочет получить ответ, для которого было превышено время устаревания. Дополнительно может быть указано значение в секундах, указывающее, что ответ не должен быть просрочен более чем на указанное значение.

`min-fresh=<seconds>`

Указывает, что клиент хочет получить ответ, который будет актуален как минимум указанное количество секунд.

`stale-while-revalidate=<seconds>`
Экспериментальная возможность

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

`stale-if-error=<seconds>`
Экспериментальная возможность

...

### Управление ревалидацией и перезагрузкой

`must-revalidate`

Кеш должен проверить статус устаревших ресурсов перед их использованием. Просроченные ресурсы не должны быть использованы.

`proxy-revalidate`

То же самое, что `must-revalidate`, но применимо только к разделяемым кешам (например, прокси) и игнорируется частными кешами.

`immutable`

Indicates that the response body will not change over time. The resource, if unexpired, is unchanged on the server and therefore the client should not send a conditional revalidation for it (e.g. `If-None-Match` or `If-Modified-Since`) to check for updates, even when the user explicitly refreshes the page. Clients that aren't aware of this extension must ignore them as per the HTTP specification. In Firefox, `immutable` is only honored on `https://` transactions. For more information, see also this blog post.

### Другие инструкции

`no-store`

Кеш не должен хранить никакую информацию о запросе и ответе

`no-transform`

Никакие преобразования не должны применяться к ресурсу. Заголовки `Content-Encoding`, `Content-Range`, `Content-Type` не должны изменяться прокси. Непрозрачный прокси может, например, конвертировать изображения из одного формата в другой для сохранения дискового пространства или уменьшения трафика. Инструкция `no-transform` запрещает это.

Примеры
-------

### Выключение кеширования

Для выключения кеширования возможно добавить следующий заголовок к ответу. Дополнительно см. заголовки `Expires` и `Pragma`.

```bash
Cache-Control: no-cache, no-store, must-revalidate
```

### Кеширование статического контента

Для файлов, которые не будут изменяться обычно возможно применить агрессивное кеширование, отослав ответ с заголовком ниже. Например, такой ответ может быть послан для изображений, файлов CSS и JavaScript. Дополнительно см. заголовок `Expires`.

```bash
Cache-Control: public, max-age=31536000
```

Спецификация
------------

| Specification |
| --- |
| HTTP Caching # field.cache-control |
| HTTP Immutable Responses # the-immutable-cache-control-extension |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* HTTP Caching FAQ (en-US)
* `Age` (en-US)
* `Expires`
* `Pragma`


Content-Type - HTTP

Content-Type
============

Заголовок-сущность **`Content-Type`** используется для того, чтобы определить MIME тип ресурса.

В ответах сервера заголовок `Content-Type` сообщает клиенту, какой будет тип передаваемого контента. В некоторых случаях браузеры пытаются сами определить MIME тип передаваемого контента, но их реакция может быть неадекватной. Чтобы предотвратить такие ситуации, вы можете установить в заголовке `X-Content-Type-Options` значение `nosniff`.

В запросах (таких, как `POST` или `PUT`), клиент сообщает серверу тип отправляемых данных.

|  |  |
| --- | --- |
| Тип заголовка | Entity header |
| Forbidden header name | нет |
| CORS-safelisted response-header (en-US) | да |

Синтаксис
---------
```

Content-Type: text/html; charset=utf-8
Content-Type: multipart/form-data; boundary=something
```

Директивы
---------

`media-type`

MIME тип ресурса или данных.

charset

Используемая кодировка.

boundary

Директива `boundary` обязательна для составных сущностей. Она содержит от 1 до 70 символов (не должна заканчиваться пробелом), которые без искажений пройдут через шлюзы email и служит для корректной инкапсуляции всех частей составной сущности.

Примеры
-------

### `Content-Type` в HTML формах

В `POST` запросе, сгенерированном в результате отправки HTML формы, `Content-Type` запроса определяется в атрибуте `enctype` тега `<form>`.

```html
<form action="/" method="post" enctype="multipart/form-data">
  <input type="text" name="description" value="some text" />
  <input type="file" name="myFile" />
  <button type="submit">Submit</button>
</form>
```

Запрос в этом случае может выглядеть так (менее интересные заголовки опущены):
```

POST /foo HTTP/1.1
Content-Length: 68137
Content-Type: multipart/form-data; boundary=---------------------------974767299852498929531610575

-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="description"

some text
-----------------------------974767299852498929531610575
Content-Disposition: form-data; name="myFile"; filename="foo.txt"
Content-Type: text/plain

(content of the uploaded file foo.txt)
-----------------------------974767299852498929531610575--
```

Спецификации
------------

| Спецификация | Заголовок |
| --- | --- |
| RFC 7233, раздел 4.1: Content-Type in multipart | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |
| RFC 7231, раздел 3.1.1.5: Content-Type | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `Accept` and `Accept-Charset`
* `Content-Disposition`
* `206` Partial Content
* `X-Content-Type-Options`


Pragma - HTTP

Pragma
======

Общий заголовок **`Pragma`** HTTP / 1.0 - это заголовок, зависящий от реализации, который может иметь различные эффекты в цепочке запрос-ответ. Он используется для обратной совместимости с кешами HTTP / 1.0, где заголовок `Cache-Control` HTTP / 1.1 ещё не присутствует.

**Примечание:** **`Pragma`** не указана для ответов HTTP и поэтому не является надёжной заменой общего заголовка управления кешем HTTP/1.1, хотя она ведёт себя так же, как `Cache-Control: no-cache`, если поле заголовка управления кешем опущено в запросе. Используйте `Pragma` только для обратной совместимости с клиентами HTTP / 1.0.

|  |  |
| --- | --- |
| Header type | General header, но поведение ответа не указано
 и, следовательно, зависит от реализации.
  |
| Forbidden header name | no |
| CORS-safelisted response header (en-US) | yes |

Синтаксис
---------
```

Pragma: no-cache
```

Директива
---------

no-cache

То же, что и `Cache-Control: no-cache`. Заставляет кеши отправлять запрос на исходный сервер для проверки перед выпуском кешированной копии.

Образец
-------
```

Pragma: no-cache
```

Технические требования
----------------------

| Спецификация | Название |
| --- | --- |
| RFC 7234, раздел 5.4: Pragma | Hypertext Transfer Protocol (HTTP/1.1): Caching |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Смотреть также
--------------

* `Cache-Control`
* `Expires`


X-Forwarded-For - HTTP

X-Forwarded-For
===============

Заголовок `X-Forwarded-For` (XFF) является де-факто стандартным заголовком для идентификации происхождения IP-адреса клиента, подключающегося к веб-серверу через HTTP-прокси или балансировщик нагрузки. Когда трафик перехватывается между клиентами и серверами, журналы доступа к серверу содержат только IP-адрес прокси-сервера или балансировки нагрузки. Чтобы увидеть origin IP-адрес клиента, используется заголовок запроса `X-Forwarded-For`.

Этот заголовок используется для отладки, статистики и создания зависимого от местоположения контента, и архитектурно он предоставляет секретную информацию, такую как IP-адрес клиента. Поэтому при использовании этого заголовка необходимо учитывать конфиденциальность пользователя.

Стандартизованной версией этого заголовка является HTTP `Forwarded` (en-US) заголовок.

`X-Forwarded-For` также является заголовком электронной почты, указывающим, что сообщение электронной почты было отправлено из другой учётной записи.

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Синтаксис
---------
```

X-Forwarded-For: <client>, <proxy1>, <proxy2>
```

Директивы
---------

<client>

IP адрес клиента

<proxy1>, <proxy2>

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

Примеры
-------
```

X-Forwarded-For: 2001:db8:85a3:8d3:1319:8a2e:370:7348

X-Forwarded-For: 203.0.113.195

X-Forwarded-For: 203.0.113.195, 70.41.3.18, 150.172.238.178
```

Other non-standard forms:
```

# Used for some Google services
X-ProxyUser-Ip: 203.0.113.19
```

Спецификации
------------

Не является частью любой текущей спецификации. Стандартизованная версия этого заголовка `Forwarded` (en-US).

See also
--------

* `Forwarded` (en-US)
* `X-Forwarded-Host` (en-US)
* `X-Forwarded-Proto` (en-US)
* `Via` (en-US)


Content-Disposition - HTTP

Content-Disposition
===================

В обычном HTTP-ответе заголовок **`Content-Disposition`** является индикатором того, что ожидаемый контент ответа будет отображаться в браузере, как веб-страница или часть веб-страницы, или же как вложение, которое затем может быть скачано и сохранено локально.
В случае, если тело HTTP-запроса типа `multipart/form-data`, то общий заголовок **`Content-Disposition`** используется для каждой из составных частей multipart тела для указания дополнительных сведений по полю, к которому применён заголовок. Каждая часть отделена с помощью *границы (boundary)*, определённой в заголовке `Content-Type`. `Content-Disposition,` используемый непосредственно для всего тела HTTP-запроса, ни на что не влияет.

Заголовок `Content-Disposition` определён для более широкого контекста MIME-сообщений для e-mail, поэтому для HTTP-форм и `POST`-запросов используются только несколько допустимых параметров. В контексте HTTP можно использовать только значение `form-data`, а также опциональные директивы `name` и `filename`.

|  |  |
| --- | --- |
| Тип заголовка | Заголовок ответа (en-US)
 (для тела ответа простого типа)Основной заголовок
 (для каждой части составного тела)
  |
| Запрещённое имя заголовка | нет |

Синтаксис
---------

### Как заголовок ответа с обычным телом

Первым параметром в контексте HTTP должен быть или `inline` (это значение по умолчанию, указывающее, что контент должен быть отображён внутри веб-страницы или как веб-страница) или `attachment` (указывает на скачиваемый контент; большинство браузеров отображают диалог "Сохранить как" с заранее заполненным именем файла из параметра `filename`, если он задан).
```

Content-Disposition: inline
Content-Disposition: attachment
Content-Disposition: attachment; filename="filename.jpg"
```

### Как заголовок в составном теле

Первым параметром в контексте HTTP всегда является `form-data`; дополнительные параметры регистронезависимые и могут иметь аргументы, значения которых следуют после знака `'='` и берутся в кавычки. Несколько параметров разделяются через точку с запятой (`';'`).
```

Content-Disposition: form-data
Content-Disposition: form-data; name="fieldName"
Content-Disposition: form-data; name="fieldName"; filename="filename.jpg"
```

### Директивы

`name`

 За параметром следует строка с именем HTML-поля на форме, к которому относится данная часть составного тела. При работе с несколькими файлами в том же самом поле (например, атрибуты `multiple` элемента `<input type=file>`), могут быть несколько частей с одинаковым именем.
 Если `name` имеет значение `'_charset_'`, указывающее, что данная часть не является HTML-полем, то она содержит кодировку по умолчанию для всех частей, в которых явно кодировка не указана.

`filename`

За параметром указана строка с оригинальным именем передаваемого файла. Это имя опционально и не может слепо использоваться приложением: информация о пути должна быть очищена и должно быть сделано преобразование к файловой системе сервера. Этот параметр предоставляет в основном справочную информацию. Когда используется в комбинации с `Content-Disposition: attachment`, это значение будет использовано как имя файла по умолчанию для диалога "Сохранить как".

filename\*

Оба параметра "filename" и "filename\*" отличаются только тем, что "filename\*" использует кодирование, определённое в RFC 5987. Когда присутствуют оба параметра "filename" и "filename\*" в одном поле заголовке, то преимущество имеет "filename\*" над "filename", но только в случае когда оба значения корректны.

Примеры
-------

Ответ, вызывающий диалог "Сохранить как":
```

200 OK
Content-Type: text/html; charset=utf-8
Content-Disposition: attachment; filename="cool.html"
Content-Length: 22

<HTML>Save me!</HTML>
```

Простой HTML-файл будет сохранён как обычное сохранение с диалогом "Сохранить как" вместо отображения контента файла в браузере. Большинство браузеров предложат его сохранить под именем `cool.html` (это поведение по умолчанию).

Пример HTML-формы, переданной через POST с использованием формата `multipart/form-data`, который использует заголовок `Content-Disposition`:
```

POST /test.html HTTP/1.1
Host: example.org
Content-Type: multipart/form-data;boundary="boundary"

--boundary
Content-Disposition: form-data; name="field1"

value1
--boundary
Content-Disposition: form-data; name="field2"; filename="example.txt"

value2
--boundary--
```

Спецификации
------------

| Спецификация | Название |
| --- | --- |
| RFC 7578 | Returning Values from Forms: multipart/form-data |
| RFC 6266 | Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP) |
| RFC 2183 | Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

Замечания по совместимости
--------------------------

* Firefox 5 обрабатывает `Content-Disposition заголовка` HTTP-ответа response более эффективно, если присутствуют оба параметра `filename` и `filename*`; он просматривает сначала все предоставленные имена `filename*`, даже есть вначале идут `filename`. Ранее использовалось первое найденное имя. See Firefox bug 588781.
Смотрите также
--------------

* HTML-формы
* `Content-Type` определяет границу для частей составного тела.
* Интерфейс `FormData` используется для обработки данных форм для использования в API `XMLHttpRequest`.


Authorization - HTTP

Authorization
=============

Заголовок HTTP запроса **`Authorization`** включает в себя данные пользователя для проверки подлинности пользовательского агента с сервером обычно после того, как сервер ответил со статусом `401` `Unauthorized` и заголовком `WWW-Authenticate` (en-US).

|  |  |
| --- | --- |
| Тип заголовка | Request header |
| Запрещённое имя заголовка | Нет |

Синтаксис
---------
```

Authorization: <тип> <данные пользователя>
```

Директивы
---------

<тип>

Тип авторизации. Общий тип «Базовая». Остальные типы:

* IANA registry of Authentication schemes
* Authentification for AWS servers (`AWS4-HMAC-SHA256`)

<данные пользователя>

Если используется схема авторизации «Базовая», данные пользователя формируются следующим образом:

* Логин и пароль, разделённые двоеточием (`aladdin:opensesame`).
* Результирующая строка, закодированная в base64 (`YWxhZGRpbjpvcGVuc2VzYW1l`).

**Примечание:** Кодировка Base64 не означает шифрование или хэширование! Этот метод так же небезопасен, как и отправка учётных данных в открытом виде (base64 является обратимой кодировкой). Отдавайте предпочтение использованию HTTPS в сочетании с Базовой Авторизацией.

Примеры
-------
```

Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
```

Смотрите также HTTP авторизацию для примеров конфигураций веб-серверов Apache или nginx с защитой вашего сайта паролем с Базовой HTTP авторизацией.

Спецификации
------------

| Спецификация | Заголовок |
| --- | --- |
| RFC 7235, раздел 4.2: Authorization | HTTP/1.1: Authentication |
| RFC 7617 | The 'Basic' HTTP Authentication Scheme |

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

* HTTP авторизация
* `WWW-Authenticate` (en-US)
* `Proxy-Authorization` (en-US)
* `Proxy-Authenticate` (en-US)
* `401`, `403`, `407`


Connection - HTTP

Connection
==========

Заголовок **`Connection`** определяет, остаётся ли сетевое соединение активным после завершения текущей транзакции (запроса). Если в запросе отправлено значение `keep-alive`, то соединение остаётся и не завершается, позволяя выполнять последующие запросы на тот же сервер.

**Предупреждение:** Заголовки, связанные с соединением, такие как `Connection` и `Keep-Alive` (en-US), запрещены в HTTP/2. Chrome и Firefox просто игнорируют эти заголовки в HTTP/2 ответах, однако Safari, следуя требованиям HTTP/2, вообще не будет загружать какие-либо ответы, которые содержат данные заголовки.

За исключением стандартных заголовков «hop-by-hop» (`Keep-Alive` (en-US), `Transfer-Encoding` (en-US), `TE` (en-US), `Connection`, `Trailer` (en-US), `Upgrade` (en-US), `Proxy-Authorization` (en-US) и `Proxy-Authenticate` (en-US)), любые «hop-by-hop» заголовки, используемые в сообщении, должны быть перечислены в заголовке `Connection` так, чтобы первый прокси знал, как их использовать, и не передавал дальше. Также могут быть перечислены стандартные «hop-by-hop» заголовки (часто это относится к `Keep-Alive` (en-US), но это необязательно).

|  |  |
| --- | --- |
| Тип заголовка | Общий заголовок |
| Запрещённое имя заголовка | да |

Синтаксис
---------
```

Connection: keep-alive
Connection: close
```

Указания
--------

`close`

Указывает, что клиент или сервер хотели бы закрыть соединение. Это значение по умолчанию для запросов HTTP/1.0.

любой список HTTP заголовков через запятую[Обычно только `keep-alive`]

Указывает, что клиент хотел бы сохранить соединение активным. Постоянное соединение используется по умолчанию для запросов HTTP/1.1. Список заголовков — это имена заголовка, которые удаляются первым непрозрачным прокси-сервером или промежуточным кешем: эти заголовки определяют соединение между источником и первым объектом, а не целевым узлом.

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.


If-Match - HTTP

If-Match
========

Заголовок HTTP-запроса **`If-Match`** делает запрос условным. Для методов `GET` и `HEAD` сервер отправляет запрошенный ресурс только в том случае, если он соответствует одному из перечисленных **ETags**. Для `PUT` и других небезопасных методов он будет загружать только ресурс в этом случае.

Сравнение с хранимым `ETag` использует сильный алгоритм сравнения, то есть два файла считаются одинаковыми байтами только байтом. Это ослабляется, когда префикс **`W/`** используется перед **ETag**.

Существует два распространённых варианта использования:

* Для методов `GET` и `HEAD`, используемых в сочетании с `Range`, он может гарантировать, что запрашиваемые новые диапазоны с того же ресурса, что и предыдущий. Если он не соответствует, то возвращается ответ `416` (Range Not Satisfiable).
* Для других методов и, в частности, для `PUT`, **If-Match** может использоваться для предотвращения проблемы с потерянным обновлением. Он может проверить, не изменит ли изменение ресурса, которое пользователь хочет загрузить, другое изменение, которое было выполнено с момента извлечения исходного ресурса. Если запрос не может быть выполнен, возвращается ответ `412` (Precondition Failed).

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | no |

Синтаксис
---------
```

If-Match: <etag_value>
If-Match: <etag_value>, <etag_value>, …
```

Директивы
---------

<etag\_value>

Теги объектов, однозначно представляющие запрошенные ресурсы. Они представляют собой строку символов ASCII, помещённых между двойными кавычками (например, **"675af34563dc-tr34"**) и могут быть префиксами **W/**, чтобы указать, что следует использовать слабый алгоритм сравнения.

`*`

Звёздочка представляет собой специальное значение, представляющее любой ресурс.

Примеры
-------
```

If-Match: "bfc13a64729c4290ef5b2c2730249c88ca92d82d"

If-Match: W/"67ab43", "54ed21", "7892dd"

If-Match: *
```

Спецификации
------------

| Спецификация | Название |
| --- | --- |
| RFC 7232, раздел 3.1: If-Match | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `ETag`
* `If-Unmodified-Since`
* `If-Modified-Since`
* `If-None-Match` (en-US)
* `416` `Range Not Satisfiable`
* `412` `Precondition Failed`


Range - HTTP

Range
=====

Заголовок запроса **`Range`** указывает серверу какую часть документа ему необходимо вернуть. Несколько частей документа может быть запрошено с помощью заголовка `Range` за один раз, и сервер может вернуть все эти части через многокомпонентный документ. При отправке данных отдельными частями, сервер использует код ответа `206` `Partial Content`. Если запрашиваемые диапазоны данных не верны, сервер возвращает ошибку `416` `Range Not Satisfiable`. Сервер так же может проигнорировать заголовок `Range` и вернуть документ целиком с кодом ответа `200`.

|  |  |
| --- | --- |
| Тип заголовка | Request header |
| Forbidden header name | нет |

Синтаксис
---------
```

Range: <единица>=<начало-диапазона>-
Range: <единица>=<начало-диапазона>-<конец-диапазона>
Range: <единица>=<начало-диапазона>-<конец-диапазона>, <начало-диапазона>-<конец-диапазона>
Range: <единица>=<начало-диапазона>-<конец-диапазона>, <начало-диапазона>-<конец-диапазона>, <начало-диапазона>-<конец-диапазона>
Range: <единица>=-<длина-с-конца>
```

Директивы
---------

<единица>

Единица, в которой указывается запрашиваемый диапазон. Обычно объявляется, как `bytes`.

<начало-диапазона>

Число, в указанных единицах, являющееся началом запрашиваемого диапазона.

<конец-диапазона>

Число, в указанных единицах, являющееся концом запрашиваемого диапазона. Это значение не является обязательным и, если его не определять, концом диапазона будет считаться конец документа.

<длина-с-конца>

Количество единиц документа, которые необходимо вернуть серверу, начиная с конца документа.

Примеры
-------

Запрашивание трёх диапазонов байтов из одного файла.
```

Range: bytes=200-1000, 2000-6576, 19000-
```

Запрашивание первых 500 и последних 500 байтов из файла. Запрос может быть отклонён сервером в связи с перекрывающимися диапазонами.
```

Range: bytes=0-499, -500
```

Спецификации
------------

| Спецификация | Заголовок |
| --- | --- |
| RFC 7233, раздел 3.1: Range | Hypertext Transfer Protocol (HTTP/1.1): Range Requests |

Совместимость с браузерами
--------------------------

BCD tables only load in the browser with JavaScript enabled. Enable JavaScript to view data.

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

* `If-Range` (en-US)
* `Content-Range` (en-US)
* `Content-Type`
* `206` `Partial Content`
* `416` `Range Not Satisfiable`