recursal/MDN huggingface dataset:
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
==============

Заголовок **`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
======

Заголовок запроса **`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
======================

Заголовок ответа сервера **`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`** указывает, какие типы контента, выраженные как 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
====

Заголовок **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
============================

**`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
===========

**`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)
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" указывает ожидания, которые должен выполнить сервер, чтобы правильно обработать запрос.

Единственным ожиданием, определённым в спецификации, является "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
==============

Заголовок **`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)
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
======

Общий заголовок **`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
===============

Заголовок `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)