Content-Encoding - HTTP

Content-Encoding
================

**`Content-Encoding`** - это сущность заголовка, используемая для сжатия медиа-типа. При наличии её значение определяет кодировку, применённую к сущности **`body`**. Это позволяет клиенту информацию как декодировать **`body`**, чтобы получить медиа-тип ссылающийся на заголовок **`Content-Type`**

Рекомендация - сжимать данные насколько это возможно и следовательно использовать это поле, но некоторые типы данных, такие как изображения в формате jpeg, уже сжаты. Иногда, использование дополнительного сжатия не уменьшает размер пакета и даже может сделать загрузку дольше.

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

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

Content-Encoding: gzip
Content-Encoding: compress
Content-Encoding: deflate
Content-Encoding: identity
Content-Encoding: br

// Multiple, in the order in which they were applied
Content-Encoding: gzip, identity
Content-Encoding: deflate, gzip
```

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

`gzip`

A format using the Lempel-Ziv coding (LZ77), with a 32-bit CRC. This is the original format of the UNIX *gzip* program. The HTTP/1.1 standard also recommends that the servers supporting this content-encoding should recognize `x-gzip` as an alias, for compatibility purposes.

`compress`

A format using the Lempel-Ziv-Welch (LZW) algorithm. The value name was taken from the UNIX *compress* program, which implemented this algorithm. Like the compress program, which has disappeared from most UNIX distributions, this content-encoding is not used by many browsers today, partly because of a patent issue (it expired in 2003).

`deflate`

Using the zlib structure (defined in RFC 1950) with the *deflate* compression algorithm (defined in RFC 1951).

`identity`

Indicates the identity function (i.e., no compression or modification). This token, except if explicitly specified, is always deemed acceptable.

`br`

A format using the Brotli algorithm.

Examples
--------

### Compressing with gzip

On the client side, you can advertise a list of compression schemes that will be sent along in an HTTP request. The `Accept-Encoding` (en-US) header is used for negotiating content encoding.
```

Accept-Encoding: gzip, deflate
```

The server responds with the scheme used, indicated by the `Content-Encoding` response header.
```

Content-Encoding: gzip
```

Note that the server is not obligated to use any compression method. Compression highly depends on server settings and used server modules.

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

| Specification | Title |
| --- | --- |
| RFC 7932: Brotli Compressed Data Format | Brotli Compressed Data Format |
| RFC 7231, раздел 3.1.2.2: Content-Encoding | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |
| RFC 2616, раздел 14.11: Content-Encoding | Content-Encoding |

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

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

See also
--------

* `Accept-Encoding` (en-US)
* `Transfer-Encoding` (en-US)


Last-Modified - HTTP

Last-Modified
=============

Заголовок **`Last-Modified`** в ответе HTTP содержит дату и время, в которую, по мнению удалённого сервера, запрашиваемый ресурс был изменён. Он используется в качестве средства проверки для определения того, остался ли ресурс неизменным. Этот заголовок менее надёжный, чем `ETag`, и используется как резервный механизм. Условный запрос, содержащий заголовок `If-Modified-Since` или `If-Unmodified-Since` позволяет серверу использовать для сравнения эту дату.

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

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

Last-Modified: <имя-дня>, <номер-дня> <имя-месяца> <год> <час>:<минута>:<секунда> GMT
```

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

<имя-дня>

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

<номер-дня>

Номер дня из двух цифр, например "04" или "23".

<имя-месяца>

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

<год>

Номер года из четырёх цифр, например "1990" или "2016".

<час>

Номер часа из двух цифр, например "09" или "23".

<минута>

Номер минуты из двух цифр, например "04" или "59".

<секунда>

Номер секунды из двух цифр, например "04" или "59".

`GMT`

Greenwich Mean Time. HTTP даты всегда представлены GMT, и никогда — в локальном поясе.

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

Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT
```

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

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

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

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

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

* `If-Modified-Since`
* `If-Unmodified-Since`
* `Etag`


If-Unmodified-Since - HTTP

If-Unmodified-Since
===================

HTTP-заголовок запроса **`If-Unmodified-Since`** делает запрос условным: сервер отправит обратно запрошенный ресурс или примет его в случае `POST` или другого небезопасного метода, только если он не был последним изменён после указанной даты. Если запрос был изменён после указанной даты, то ответ будет `412` (Precondition Failed) ошибка.

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

* В сочетании с другими небезопасными методами, такими как `POST`, он может использоваться для реализации optimistic concurrency control, например, сделанного некоторыми вики-версиями: выпуски отклоняются, если сохранённый документ был изменён с момента восстановления оригинала.

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

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

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

If-Unmodified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

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

<day-name>

One of "Mon", "Tue", "Wed", "Thu", "Fri", "Sat", or "Sun" (case-sensitive).

<day>

2 digit day number, e.g. "04" or "23".

<month>

One of "Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" (case sensitive).

<year>

4 digit year number, e.g. "1990" or "2016".

<hour>

2 digit hour number, e.g. "09" or "23".

<minute>

2 digit minute number, e.g. "04" or "59".

<second>

2 digit second number, e.g. "04" or "59".

`GMT`

Greenwich Mean Time. HTTP dates are always expressed in GMT, never in local time.

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

If-Unmodified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

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

| Спецификация | Заголовок |
| --- | --- |
| RFC 7232, раздел 3.4: If-Unmodified-Since | Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests |

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

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

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

* `Last-Modified`
* `If-Modified-Since`
* `If-Match`
* `If-None-Match` (en-US)
* `If-Range` (en-US)
* `412` `Precondition Failed`


Accept-Language - HTTP

Accept-Language
===============

HTTP-заголовок Запрос **`Accept-Language`** сообщает серверу, какие языки клиент понимает и какая локаль предпочтительнее (имеются в виду естественные языки, такие как английский, а не языки программирования). Используя механизм обсуждения содержимого (content negotiation), сервер выбирает один из предложенных вариантов, использует его и информирует клиента о своём выборе при помощи заголовка ответа `Content-Language`. Браузеры устанавливают соответствующие значения для данного заголовка, исходя из языка пользовательского интерфейса, и, даже если у пользователя есть возможность изменить значение заголовка **`Accept-Language`**, это происходит редко (и не одобряется, так как ведёт.к идентификации).
Данный заголовок является подсказкой для сервера, когда он не имеет другого способа определить язык, (например, явно указанный язык в URL'е, который пользователь явно выбрал). Рекомендуется никогда не переопределять на стороне сервера явный выбор пользователем языка. Содержимое заголовка `Accept-Language` часто не может быть переопределено пользователем (например, в путешествии, когда пользователь пользуется услугами интернет-кафе); также пользователь может захотеть посмотреть содержимое сайта на языке отличном от языка интерфейса.

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

|  |  |
| --- | --- |
| Header type | Request header |
| Forbidden header name | нет |
| CORS-safelisted request-header | да |

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

Accept-Language: <language>
Accept-Language: <locale>
Accept-Language: *

// Multiple types, weighted with the quality value (en-US) syntax:
Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5
```

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

`<language>`

Тег языка (иногда называют идентификатором локали, "locale identifier"). Состоит из 2-3 буквенного основного языкового тега, представляющего язык, и опционально за ним могут следовать дополнительные под-теги, разделённые `'-'`. Наиболее распространённой дополнительной информацией являются указания на страну или регион (например, `'en-US'` или `'fr-CA'`) или тип алфавита, который следует использовать (например, `'sr-Latn'`). Другие варианты, такие как тип орфографии (`'de-DE-1996'`) обычно не используются в контексте данного заголовка.

`*`

Любой язык; `'*'` обозначает любое значение.

`;q=` (q-factor weighting)

Любое из значений, размещённых в порядке предпочтения, выраженном позицией quality value (en-US), которое называют *весами*.

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

Accept-Language: *

Accept-Language: de

Accept-Language: de-CH

Accept-Language: en-US,en;q=0.5

Accept-Language: fr-CH, fr;q=0.9, en;q=0.8, de;q=0.7, *;q=0.5

Accept-Language: ru-RU, ru;q=0.9, en-US;q=0.8, en;q=0.7, fr;q=0.6
```

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

| Спецификация | Название |
| --- | --- |
| RFC 7231, раздел 5.3.5: Accept-Language | 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 negotiation
* Header with the result of the content negotiation: `Content-Language`
* Other similar headers: `TE` (en-US), `Accept-Encoding` (en-US), `Accept-Charset`, `Accept`


DNT - HTTP

DNT
===

The **`DNT`** (**D**o **N**ot **T**rack - Не отслеживать) заголовок указывает разрешает ли пользователь отслеживать себя. Он позволяет пользователю указать предпочитают они приватность персонифицированному контенту, подготавливаемому с использованием отслеживания.

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

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

DNT: 0
DNT: 1
```

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

0

Пользователь разрешает отслеживание на целевом сайте.

1

Пользователь предпочитает не отслеживаться на целевом сайте.

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

### Чтение статуса Do Not Track из JavaScript

DNT предпочтение пользователя может быть считано из JavaScript используя свойство `Navigator.doNotTrack` :

```js
navigator.doNotTrack; // "0" or "1"
```

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

#### No specification found

No specification data found for `http.headers.DNT`.
Check for problems with this page or contribute a missing `spec_url` to mdn/browser-compat-data. Also make sure the specification is included in w3c/browser-specs.

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

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

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

* `Navigator.doNotTrack`
* `Tk` (en-US) header
* Do Not Track on Wikipedia
* What Does the "Track" in "Do Not Track" Mean? – EFF
* donottrack.us
* DNT browser settings help:
    + Firefox
    + Chrome


X-Content-Type-Options - HTTP

X-Content-Type-Options
======================

HTTP-заголовок ответа **`X-Content-Type-Options`** является маркером, используемым сервером для указания того, что типы MIME, объявленные в заголовках `Content-Type`, должны соблюдаться и не изменяться. Это позволяет отказаться от перехвата MIME, или, другими словами, это способ сказать, что веб-мастера знали, что они делают.

Этот HTTP-заголовок был введён Microsoft в IE 8 как способ для веб-мастеров блокировать происходящий перехват содержимого и может преобразовывать неисполняемые типы MIME в исполняемые типы MIME. С тех пор другие браузеры внедрили его, даже если их алгоритмы обработки MIME были менее агрессивными.

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

**Примечание:** Примечание: `nosniff` применяется только к типам "`script`" и "`style`". Также применение `nosniff` к изображениям оказалось несовместимым с существующими веб-сайтами.

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

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

X-Content-Type-Options: nosniff
```

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

`nosniff`

Блокирует запрос, если запрошенный тип:

* "`style`" и его MIME не "`text/css`", или
* "`script`" и его MIME не JavaScript MIME-тип.

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

| Specification |
| --- |
| Fetch Standard # x-content-type-options-header |

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

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

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

* `Content-Type`
* Первоначальное определение X-Content-Type-Options от Microsoft®.
* Инструмент Обсерватория Mozilla проверяющий конфигурацию (включая этот заголовок) веб-сайтов на безопасность.
* Смягчение MIME путаницы в Firefox
* Блокировка чтения из разных источников (Cross-Origin Read Blocking)
* Google Docs CORB explainer


If-Modified-Since - HTTP

If-Modified-Since
=================

Заголовок HTTP запроса **`If-Modified-Since`** делает запрос условным: сервер отправит обратно запрошенный ресурс с статусом `200`, только если он был изменён после указанной даты. Если запрос не был изменён после указанной даты, ответ будет `304` без какого-либо тела; заголовок `Last-Modified` при этом будет содержать дату последней модификации. В отличие от `If-Unmodified-Since`, `If-Modified-Since` может использоваться только с `GET` или `HEAD`.

При использовании в сочетании с `If-None-Match` (en-US) заголовок `If-Modified-Since` игнорируется, кроме тех случаев, когда сервер не поддерживает If-None-Match.

Наиболее распространённым вариантом использования является обновление кешированного объекта, не связанного с `ETag`.

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

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

If-Modified-Since: <day-name>, <day> <month> <year> <hour>:<minute>:<second> GMT
```

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

<day-name>

День недели ("Mon", "Tue", "Wed", "Thu", "Fri", "Sat" или "Sun") с учётом регистра.

<day>

День (2 цифры), например, "04" или "23".

<month>

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

<year>

Год (4 цифры), например, "1990" или "2016".

<hour>

Час (2 цифры), например, "09" или "23".

<minute>

Минута (2 цифры), например, "04" или "59".

<second>

Секунда (2 цифры), например, "04" or "59".

`GMT`

Среднее время по Гринвичу (Greenwich Mean Time). HTTP даты всегда представлены как GMT время и никогда как локальное.

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

If-Modified-Since: Wed, 21 Oct 2015 07:28:00 GMT
```

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

| Спецификация | Название |
| --- | --- |
| RFC 7232, раздел 3.3: If-Modified-Since | 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-Match`
* `If-None-Match` (en-US)
* `304` `Not Modified`


User-Agent - HTTP

User-Agent
==========

Заголовок запроса **User-Agent** - это строка с характеристиками, по которым сервера и сетевые узлы могут определить тип приложения, операционную систему, производителя и/или версию пользовательского агента.

>
> **Обратите внимание:** Показывать ту или иную страницу в зависимости от характеристик пользовательского агента — дурная практика. Почему не стоит так делать, читайте в статье «Определение браузера по пользовательскому агенту (en-US)».
>
>
>

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

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

User-Agent: <product> / <product-version> <comment>
```

Общий формат для веб-браузеров:
```

User-Agent: Mozilla/5.0 (<system-information>) <platform> (<platform-details>) <extensions>
```

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

<product>

Идентификатор продукта — его название или кодовое имя.

<product-version>

Версия продукта

<comment>

Может быть пустым или содержать дополнительную информацию. Например, информацию о продукте.

Строка UA в Firefox
-------------------

Подробные сведения о *user agent* строках в Firefox и других браузерах, основанных на движке Gecko, вы найдёте в справочнике (en-US).

Строка UA в Firefox разбита на 4 части и одну общую метку для всех:
```

Mozilla/5.0 (platform; rv:geckoversion) Gecko/geckotrail Firefox/firefoxversion
```

1. `Mozilla/5.0` — общая метка, которая сообщает, что браузер совместим с Mozilla. По историческим причинам сегодня такую метку отправляет почти каждый браузер.
2. ***platform*** указывает платформу, на которой работает браузер (Windows, Mac, Linux, Android и т.д.), а так же, мобильный ли это телефон. В телефонах на Firefox OS (en-US) указывается только `Mobile`, поскольку Firefox OS построена на веб-технологиях. Обратите внимание, ***platform*** может содержать несколько значений, разделённых `;`. Подробная информация и примеры ниже.
3. **rv:*geckoversion*** указывает релизную версию Gecko (например, "*17.0*"). В последних браузерах ***geckoversion*** совпадает с ***firefoxversion***.
4. ***Gecko/geckotrail*** указывает, что браузер основан на Gecko (на компьютерах ***geckotrail*** — всегда строка `20100101`).
5. ***Firefox/firefoxversion*** обозначает, что браузером является Firefox, и указывает его версию (например, "*17.0*").
### Примеры
```

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0
Mozilla/5.0 (Macintosh; Intel Mac OS X x.y; rv:42.0) Gecko/20100101 Firefox/42.0
```

Строка UA в Chrome
------------------

Строка *user agent* в Chrome и браузерах, основанных на движке Chromium/Blink, аналогична строке Firefox. Для совместимости добавлены строки `KHTML, like Gecko` и `Safari`.

### Примеры
```

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.103 Safari/537.36
```

Строка UA в Opera
-----------------

Браузер Opera также основан на движке Blink, поэтому его строка *user agent* совпадает со строкой Chrome, только в конце добавляется `"OPR/<version>"`.

### Примеры
```

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 OPR/38.0.2220.41
```

В старых версиях Opera, на базе движка Presto, строки выглядят так:
```

Opera/9.80 (Macintosh; Intel Mac OS X; U; en) Presto/2.2.15 Version/10.00
Opera/9.60 (Windows NT 6.0; U; en) Presto/2.1.1
```

Строка UA в Microsoft Edge
--------------------------

Браузер Microsoft Edge также основан на движке Blink, поэтому его строка *user agent* совпадает со строкой Chrome, только в конце добавляется `"Edg/<version>"`.

### Примеры
```

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/91.0.4472.124 Safari/537.36 Edg/91.0.864.59
```

Строка UA в Safari
------------------

В этом примере строка *user agent* представлена в мобильной версии Safari и содержит слово `"Mobile"`.

### Примеры
```

Mozilla/5.0 (iPhone; CPU iPhone OS 13_5_1 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.1.1 Mobile/15E148 Safari/604.1
```

Строка UA в Internet Explorer
-----------------------------

### Примеры
```

Mozilla/5.0 (compatible; MSIE 9.0; Windows Phone OS 7.5; Trident/5.0; IEMobile/9.0)
```

Строка UA поискового робота
---------------------------

### Примеры
```

Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)
```

```
Mozilla/5.0 (compatible; YandexAccessibilityBot/3.0; +http://yandex.com/bots)
```

Строка UA у библиотек и net-tools
---------------------------------

### Примеры
```

curl/7.64.1
```

```
PostmanRuntime/7.26.5
```

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

| Specification |
| --- |
| HTTP Semantics # field.user-agent |

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

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

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

* User-Agent detection, history and checklist
* Firefox user agent string reference (en-US)
* Browser detection using the user agent (en-US)


Access-Control-Allow-Origin - HTTP

Access-Control-Allow-Origin
===========================

Заголовок ответа **`Access-Control-Allow-Origin`** показывает, может ли ответ сервера быть доступен коду, отправляющему запрос с данного источника origin.

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

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

Access-Control-Allow-Origin: *
Access-Control-Allow-Origin: <origin>
Access-Control-Allow-Origin: null
```

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

`*`

Для запросов *без учётных данных*. Значение "`*`" может быть использован как шаблон; значение указывает браузеру разрешить запросы из любых источников. Попытка использовать шаблон с учётными данными приведёт к ошибке (en-US).

`<origin>`

Указывает источник. Может быть указан только один источник.

`null`

Определяет в качестве источника "null".

**Примечание:** Не используйте `null`: "Может показаться, что вернуть `Access-Control-Allow-Origin: "null"` безопасно, но сериализация Источника любого ресурса, использующего неиерархическую схему (такие как `data:` или `file:`), и изолированные документы, определяются как "null". Многие пользовательские агенты предоставляют таким документам доступ к ответу с заголовком `Access-Control-Allow-Origin: "null"`, и любой источник может создать враждебный документ с Источником "null". Поэтому использования заголовка ACAO со значением "null" следует избегать."

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

Ответ, который указывает браузеру разрешить доступ к ресурсу из любого источника:
```

Access-Control-Allow-Origin: *
```

Ответ, который указывает браузеру разрешить доступ к ресурсу только из источника `https://developer.mozilla.org`:
```

Access-Control-Allow-Origin: https://developer.mozilla.org
```

Чтобы ограничить `Access-Control-Allow-Origin` разрешённым набором значений, необходимо реализовать логику на стороне сервера для проверки значения заголовка `Origin` запроса, сравнить его с разрешённым списком источников, а затем, если значение `Origin` присутствует в списке, задать значение `Access-Control-Allow-Origin`, равное значению `Origin`.

### CORS и кеширование

Если сервер послал ответ со значением `Access-Control-Allow-Origin`, которое содержит явное указание источника (а не шаблонное значение "`*`"), тогда ответ также должен включать в себя заголовок `Vary` со значением `Origin` — чтобы указать браузеру, что ответы с сервера могут отличаться в зависимости от заголовка запроса `Origin`.
```

Access-Control-Allow-Origin: https://developer.mozilla.org
Vary: Origin
```

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

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

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

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

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

* `Origin`
* `Vary`
* Cross-Origin Resource Sharing (CORS)
* `Cross-Origin-Resource-Policy` (en-US)


Content-Language - HTTP

Content-Language
================

HTTP-заголовок **`Content-Language`** используется для описания языков контента доступных для аудитории, позволяя таким образом пользователю выбрать язык в соответствии со своими предпочтениями.

Например, если установлен заголовок "`Content-Language: de-DE`", это говорит о том, что документ предназначен для носителей немецкого языка (однако это не означает, что документ написан на немецком языке). Это может быть документ на английском языке в рамках языкового курса для носителей немецкого языка).

Если заголовок `Content-Language` не указан, по умолчанию предполагается, что содержимое предназначено для всех языковых аудиторий. Также допустимо использование в заголовке нескольких языковых тегов. Заголовок `Content-Language` может применяться не только к текстовым документам но и другим типам контента.

|  |  |
| --- | --- |
| Header type | Entity header |
| Forbidden header name | no |
| CORS-safelisted response-header (en-US) | yes |
| CORS-safelisted request-header | yes |

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

Content-Language: de-DE
Content-Language: en-US
Content-Language: de-DE, en-CA
```

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

`language-tag`

Несколько языковых тегов разделяются запятыми. Каждый языковой тег представляет собой последовательность из одного или нескольких подтегов без учёта регистра, разделённых символом дефиса ("`-`", `%x2D`).

В большинстве случаев языковой тег состоит из подтега основного языка, который идентифицирует широкое семейство родственных языков (например, "`en`" = English), за которым дополнительно следует ряд подтегов, уточняющих или сужающих диапазон этого языка (например, "`en-CA`" = вариант диалекта английского языка, использующегося в Канаде).

**Примечание:** Языковые теги формально описаны в RFC 5646, который в свою очередь опирается на стандарт ISO 639 (точнее на ISO 639-1 code list) в части перечня используемых language codes.

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

### Указание использованного языка документа

Глобальный атрибут `lang` используется на HTML-элементах для указания языка всего HTML документа или его частей.

```html
<html lang="de"></html>
```

**Не** используйте этот мета элемент как здесь для констатирования языка документа:

```html
<!-- /!\ Это плохая практика -->
<meta http-equiv="content-language" content="de" />
```

### Указание целевой аудитории для ресурса

`Content-Language` заголовок используется для определения целевой аудитории страницы и может указывать на более чем 1 язык.
```

Content-Language: de, en
```

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

| Спецификация | Заголовок |
| --- | --- |
| RFC 7231, раздел 3.1.3.2: Content-Language | 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-Language`
* HTTP headers, meta elements and language information


Причина: отсутствует заголовок CORS «Access-Control-Allow-Origin» - HTTP

Причина: отсутствует заголовок CORS «Access-Control-Allow-Origin»
=================================================================

Причина
-------
```

Причина: отсутствует заголовок CORS «Access-Control-Allow-Origin»
```

Почему это произошло?
---------------------

В ответе на CORS-запрос отсутствует заголовок `Access-Control-Allow-Origin`, используемый для проверки, может ли ресурс быть доступен для контента на текущем домене.

Если у вас есть доступ к серверу, то добавьте домен запрашивающего сайта в список разрешённых доменов, добавив его в значение заголовка `Access-Control-Allow-Origin`.

Например, для предоставления сайту `https://amazing.site` доступа к ресурсам с использованием CORS, заголовок должен выглядеть так:
```

Access-Control-Allow-Origin: https://amazing.site
```

Также вы можете разрешить доступ любому сайту, используя подстановку `*`. Используйте этот способ только для публичных API. В закрытых API `*` не должна использоваться, вместо этого должен быть установлен определённый домен или домены. При этом подстановка работает только для запросов с атрибутом `crossorigin` со значением `anonymous`.
```

Access-Control-Allow-Origin: *
```

**Предупреждение:** **Внимание:** Использование \* для доступа к закрытым API — плохая идея по очевидным причинам.

Чтобы разрешить любому сайту делать CORS-запросы *без* использования подстановки `*` (например, для включения авторизационных данных), ваш сервер должен считывать значение заголовка `Origin` из запроса и использовать это значение, чтобы задать `Access-Control-Allow-Origin`, а также выставить заголовок `Vary: Origin`, чтобы обозначить динамическую установку заголовка в зависимости от источника.

Конкретная директива для установки заголовков зависит от вашего сервера. Так в Apache нужно добавить следующую строку в конфигурацию сервера (в соответствующих разделах `<Directory>`, `<Location>`, `<Files>` или `<VirtualHost>`). Конфигурация обычно находится в файле с расширением `.conf` (стандартные названия: `httpd.conf`, `apache.conf`), либо в файле `.htaccess`.
```

Header set Access-Control-Allow-Origin 'origin-list'
```

В Nginx для установки этого заголовка используется команда:
```

add_header 'Access-Control-Allow-Origin' 'origin-list'
```

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

* Ошибки CORS (en-US)
* Глоссарий: CORS
* Введение в CORS


Причина: CORS заголовок 'Access-Control-Allow-Origin' не соответствует 'xyz' - HTTP

Причина: CORS заголовок 'Access-Control-Allow-Origin' не соответствует 'xyz'
============================================================================

Reason
------
```

Причина: CORS заголовок 'Access-Control-Allow-Origin' не соответствует 'xyz'
```

Что пошло не так?
-----------------

Проще говоря, источник делает запрос который не совпадает ни с одним из источников разрешённых заголовком - `Access-Control-Allow-Origin`.

Эта ошибка также может произойти, если ответ содержит более одного заголовка `Access-Control-Allow-Origin`.

Если сервис, к которому ваш код обращается с помощью CORS запроса находится под вашим контролем, убедитесь что он настроен для включения в себя вашего источника в заголовке `Access-Control-Allow-Origin` и что в ответах от сервера присутствует только один такой заголовок. Заголовок принимает список источников, поэтому указать новый источник совсем не сложно.

К примеру, в Apache, вы можете добавить следующую строку в конфигурацию веб-сервера (в пределах одной из секций - `<Directory>`, `<Location>`, `<Files>` или `<VirtualHost>`). Обычно конфигурация находиться в файле `.conf` (наиболее частые имена для него - `httpd.conf` и `apache.conf`) или в файле `.htaccess`.
```

Header set Access-Control-Allow-Origin 'origin-list'
```

В Nginx, для установки такого заголовка можно воспользоваться следующей командой:
```

add_header 'Access-Control-Allow-Origin' 'origin-list'
```

See also
--------

* CORS errors (en-US)
* Glossary: CORS
* CORS introduction
* Enable CORS: I want to add CORS support to my server


Ошибка: CORS disabled - HTTP

Ошибка: CORS disabled
=====================

Ошибка
------
```

Ошибка: CORS disabled
```

Что случилось?
--------------

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

В браузере Firefox, настройка которая отключает CORS - `content.cors.disable`. Устанавливая данное значение в `true` вы отключаете CORS, поэтому каждый раз при использовании CORS запрос будет отклонён с ошибкой.

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

* CORS errors (en-US)
* Глоссарий: CORS
* CORS introduction


Причина: Не удалось выполнить запрос CORS - HTTP

Причина: Не удалось выполнить запрос CORS
=========================================

Причина
-------
```

Причина: Не удалось выполнить запрос CORS
```

Что произошло?
--------------

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

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

* Ошибки CORS (en-US)
* Глоссарий: CORS
* Введение в CORS


HEAD - HTTP

HEAD
====

**HTTP-метод `HEAD`** запрашивает заголовки, идентичные тем, что возвращаются, если указанный ресурс будет запрошен с помощью HTTP-метода `GET`. Такой запрос может быть выполнен перед загрузкой большого ресурса, например, для экономии пропускной способности.

Ответ на метод `HEAD` не должен содержать тело. Если это не так, то его следует игнорировать. Но даже в этом случае заголовки сущности, описывающие содержимое тела, например `Content-Length`, должны быть включены в ответ. Они не относятся к телу ответа на запрос `HEAD`, которое должно быть пустым, они относятся к телу ответа, полученный на аналогичный запрос с помощью метода `GET`.

Если результат запроса `HEAD` показывает, что кешированный после запроса `GET` ресурс устарел, то кеш становится недействительным, даже если запрос `GET` не был сделан.

|  |  |
| --- | --- |
| Запрос имеет тело | Нет |
| Успешный ответ имеет тело | Нет |
| Безопасный | Да |
| Идемпотентный | Да |
| Кешируемый | Да |
| Допускается в HTML-формах | Нет |

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

HEAD /index.html
```

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

| Specification |
| --- |
| HTTP Semantics # HEAD |

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

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

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

* `GET`


OPTIONS - HTTP

OPTIONS
=======

**HTTP-метод** `OPTIONS` используется для описания параметров соединения с целевым ресурсом. Клиент может указать особый URL для обработки метода OPTIONS, или \* (звёздочку) чтобы указать весь сервер целиком.

|  |  |
| --- | --- |
| Запрос имеет тело | Нет |
| Успешный ответ имеет тело | Да |
| Безопасный | Да |
| Идемпотентный | Да |
| Кешируемый | Нет |
| Допускается в HTML-формах | Нет |

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

OPTIONS /index.html HTTP/1.1
OPTIONS * HTTP/1.1
```

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

### Определение разрешённых сервером методов запроса

Для того, чтобы узнать какие методы запросов поддерживаются сервером, можно воспользоваться curl направить OPTIONS запрос:
```

curl -X OPTIONS http://example.org -i
```

Ответ на запрос содержит `Allow` (en-US) заголовок с поддерживаемыми методами:
```

HTTP/1.1 200 OK
Allow: OPTIONS, GET, HEAD, POST
Cache-Control: max-age=604800
Date: Thu, 13 Oct 2016 11:45:00 GMT
Expires: Thu, 20 Oct 2016 11:45:00 GMT
Server: EOS (lax004/2813)
x-ec-custom-error: 1
Content-Length: 0
```

### Предзапросы по технологии CORS

По технологии CORS (en-US), с помощью метода `OPTIONS` направляется предварительный запрос, поэтому сервер может ответить приемлемо ли отправлять запросы этим методом. `Access-Control-Request-Method` (en-US) заголовок уведомляет сервер в составе предварительного запроса о том что, запрос `OPTIONS` будет отправляться на сервер вместе с `POST` запросом. `Access-Control-Request-Headers` (en-US) заголовок уведомляет сервер о том, что при отправке фактического запроса, он будет отправлен с помощью пользовательских заголовков `X-PINGOTHER` и `Content-Type`. В этом случае сервер имеет возможность определять возможно ли принять запрос с такими параметрами.
```

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type
```

Ответ сервера содержит параметр `Access-Control-Allow-Methods` и сообщает, что `POST`, `GET`, и `OPTIONS` методы являются приемлемыми для данного ресурса. Этот заголовок похож на заголовок `Allow` (en-US) , но используется строго в контексте CORS.
```

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain
```

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

| Спецификация | Заголовок |
| --- | --- |
| RFC 7231, раздел 4.3.7: OPTIONS | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

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

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

* `Allow` (en-US) заголовок
* CORS (en-US)


GET - HTTP

GET
===

**HTTP-метод `GET`** запрашивает представление указанного ресурса. `GET`-запросы должны только получать данные.

|  |  |
| --- | --- |
| Запрос имеет тело | Нет |
| Успешный ответ имеет тело | Да |
| Безопасный | Да |
| Идемпотентный | Да |
| Кешируемый | Да |
| Допускается в HTML-формах | Да |

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

GET /index.html
```

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

| Спецификация | Заголовок |
| --- | --- |
| RFC 7231, раздел 4.3.1: GET | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

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

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

* HTTP Заголовки
* `Range`
* POST


POST - HTTP

POST
====

**HTTP-метод `POST`** предназначен для отправки данных на сервер. Тип тела запроса указывается в заголовке `Content-Type`.

Разница между `PUT` и `POST` состоит в том, что `PUT` является идемпотентным: повторное его применение даёт тот же результат, что и при первом применении (то есть у метода нет *побочных эффектов*), тогда как повторный вызов одного и того же метода `POST` может иметь такие эффекты, как например, оформление одного и того же заказа несколько раз.

Запрос `POST` обычно отправляется через форму HTML и приводит к изменению на сервере. element or the formenctype attribute of the <input> or <button> elements:">В этом случае тип содержимого выбирается путём размещения соответствующей строки в атрибуте `enctype` элемента `<form>` или `formenctype` атрибута элементов `<input>` или `<button>`:

* `application/x-www-form-urlencoded`: значения кодируются в кортежах с ключом, разделённых символом `'&'`, с `'='` между ключом и значением. Не буквенно-цифровые символы - percent encoded: это причина, по которой этот тип не подходит для использования с двоичными данными (вместо этого используйте `multipart/form-data`)
* `multipart/form-data`: каждое значение посылается как блок данных ("body part"), с заданными пользовательским клиентом разделителем ("boundary"), разделяющим каждую часть. Эти ключи даются в заголовки `Content-Disposition` каждой части
* `text/plain`

Когда запрос `POST` отправляется с помощью метода, отличного от HTML-формы, — например, через `XMLHttpRequest` — тело может принимать любой тип. Как описано в спецификации HTTP 1.1, `POST` предназначен для обеспечения единообразного метода для покрытия следующих функций:

* Аннотация существующих ресурсов
* Публикация сообщения на доске объявлений, в новостной группе, в списке рассылки или в аналогичной группе статей;
* Добавление нового пользователя посредством модальности регистрации;
* Предоставление блока данных, например, результата отправки формы, процессу обработки данных;
* Расширение базы данных с помощью операции добавления.

|  |  |
| --- | --- |
| Запрос имеет тело | Да |
| Успешный ответ имеет тело | Да |
| Безопасный | Нет |
| Идемпотентный | Нет |
| Кешируемый | Только если включена информация о свежести сообщения |
| Допускается в HTML-формах | Да |

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

POST /index.html
```

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

Простая форма запроса, используя стандартный `application/x-www-form-urlencoded` content type:

```http
POST / HTTP/1.1
Host: foo.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 13

say=Hi&to=Mom
```

Форма запроса, используя `multipart/form-data` content type:

```http
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--
```

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

| Specification |
| --- |
| HTTP Semantics # POST |

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

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

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

* `Content-Type`
* `Content-Disposition`
* GET


CONNECT - HTTP

CONNECT
=======

**HTTP `CONNECT` method** запускает двустороннюю связь с запрошенным ресурсом. Метод можно использовать для открытия туннеля.

К примеру, метод CONNECT может использоваться для доступа к сайту, который использует SSL (en-US) (HTTPS). Клиент запрашивает HTTP-прокси-сервер для туннелирования TCP-соединения с желаемым назначением. Затем сервер переходит к подключению от имени клиента. После того, как соединение установлено сервером, прокси-сервер продолжает проксировать поток TCP к клиенту и от него.

`CONNECT` is a hop-by-hop method.

|  |  |
| --- | --- |
| Запрос имеет тело | Нет |
| Успешный ответ имеет тело | Да |
| Безопасный | Нет |
| Идемпотентный | Нет |
| Кешируемый | Нет |
| Допускается в HTML формах | Нет |

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

CONNECT www.example.com:443 HTTP/1.1
```

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

Некоторые прокси сервера могут запросить авторизацию для создания туннеля. Смотрите также `Proxy-Authorization` (en-US).

```http
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
```

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

| Specification |
| --- |
| HTTP Semantics # CONNECT |

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

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

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

* Proxy server
* `Proxy-Authorization` (en-US)


PUT - HTTP

PUT
===

**Метод запроса HTTP PUT** создаёт новый ресурс или заменяет представление целевого ресурса данными, представленными в теле запроса.
Разница между `PUT` и `POST` в том, что `PUT` является идемпотентным, т.е. единичный и множественные вызовы этого метода, с идентичным набором данных, будут иметь тот же результат выполнения (без сторонних эффектов), в случае с `POST`, множественный вызов с идентичным набором данных может повлечь за собой сторонние эффекты.

|  |  |
| --- | --- |
| Запрос имеет тело | Да |
| Успешный ответ имеет тело | Нет |
| Безопасный | Нет |
| Идемпотентный | Да |
| Кешируемый | Нет |
| Допускается в HTML-формах | Нет |

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

PUT /new.html HTTP/1.1
```

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

### Запрос
```

PUT /new.html HTTP/1.1
Host: example.com
Content-type: text/html
Content-length: 16

<p>Новый файл</p>
```

### Ответ

Если целевой ресурс не содержит отправляемой сущности и `PUT` запрос создаёт её, то сервер должен проинформировать клиентское приложение о создании, отправив в ответ `201` (`Created`).
```

HTTP/1.1 201 Created
Content-Location: /new.html
```

Если целевой ресурс содержит отправляемую сущность и сущность была успешно мутирована (обновлена), в соответствии с прилагаемыми в теле запроса данными, то сервер должен отправить или `200` (`OK`), или `204` (`No Content`) для информирования об успешном завершении запроса.
```

HTTP/1.1 204 No Content
Content-Location: /existing.html
```

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

| Спецификация | Заголовок |
| --- | --- |
| RFC 7231, раздел 4.3.4: PUT | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

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

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

* `201`
* `204`


DELETE - HTTP

DELETE
======

**Метод запроса HTTP DELETE** удаляет указанный ресурс.

|  |  |
| --- | --- |
| Запрос имеет тело | Может |
| Успешный ответ имеет тело | Может |
| Безопасный | Нет |
| Идемпотентный | Да |
| Кешируемый | Нет |
|
 Допускается в
 HTML-формах | Нет |

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

DELETE /file.html HTTP/1.1
```

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

### Запрос
```

DELETE /file.html HTTP/1.1
```

### Ответ

Если метод `DELETE` успешно выполняется, то возможны следующие коды состояния ответа:

* `202` (`Accepted`) код состояния, если удаление будет успешным, но ещё не выполнено.
* `204` (`No Content`) код ответа, если удаление было выполнено, но тело ответа отсутствует.
* `200` (`OK`) код ответа, если удаление было выполнено, и ответ содержит код и объект описывающий состояние.
```

HTTP/1.1 200 OK
Date: Wed, 21 Oct 2015 07:28:00 GMT

<html>
  <body>
    <h1>File deleted.</h1>
  </body>
</html>
```

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

| Спецификация | Заголовок |
| --- | --- |
| RFC 7231, раздел 4.3.5: DELETE | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

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

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

* HTTP status: `200`, `202`, `204`


TRACE - HTTP

TRACE
=====

**HTTP Метод `TRACE`** выполняет проверку обратной связи по пути к целевому ресурсу, предоставляя полезный механизм отладки.

Конечный получатель запроса должен отразить полученное сообщение, исключая некоторые поля описанные ниже, назад клиенту как тело сообщения с ответом 200 (`OK`) с заголовком `Content-Type` `message/http`. Конечный получатель это либо исходный сервер, либо первый сервер получивший значение `Max-Forwards` (en-US) в запросе.

|  |  |
| --- | --- |
| Запрос имеет тело | Нет |
| Успешный ответ имеет тело | Нет |
| Безопасный | Нет |
| Идемпотентный | Да |
| Кешируемый | Нет |
| Допускается в HTML-формах | Нет |

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

TRACE /index.html
```

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

| Specification |
| --- |
| HTTP Semantics # TRACE |

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

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

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

* HTTP methods


PATCH - HTTP

PATCH
=====

**Метод запроса HTTP `PATCH`** частично изменяет ресурс.

В какой-то степени `PATCH` можно назвать аналогом действия «обновить» из CRUD (en-US) (однако не следует путать HTTP и CRUD (en-US) — это две разные вещи).

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

`PATCH` может как быть идемпотентным, так и не быть, в отличие от `PUT`, который всегда идемпотентен. Операция считается идемпотентной, если её многократное выполнение приводит к тому же результату, что и однократное. Например, если автоинкрементное поле является важной частью ресурса, то `PUT` перезапишет его (т.к. он перезаписывает всё), но `PATCH` может и не перезаписать.

`PATCH` (как и `POST`) *может* иметь побочные эффекты.

Чтобы обозначить, что сервер поддерживает `PATCH`, можно добавить этот метод в список заголовков ответа `Allow` (en-US) или `Access-Control-Allow-Methods` (для CORS).

Другим (неявным) индикатором, что метод `PATCH` разрешён, является наличие заголовка `Accept-Patch`, который описывает, какой формат изменения документа принимает сервер.

|  |  |
| --- | --- |
| Запрос имеет тело | Да |
| Успешный ответ имеет тело | Может |
| Безопасный | Нет |
| Идемпотентный | Нет |
| Кешируемый | Только если включена информация о дате последнего изменения |
| Допускается в HTML-формах | Нет |

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

PATCH /file.txt HTTP/1.1
```

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

### Запрос

```http
PATCH /file.txt HTTP/1.1
Host: www.example.com
Content-Type: application/example
If-Match: "e0023aa4e"
Content-Length: 100

[описание изменений]
```

### Ответ

Успешный ответ указывается с помощью любого кода ответа серии 2xx.

В следующем примере используется код ответа `204`, поскольку ответ не содержит тела сообщения. Если требуется передать тело, то используется код `200`.
```

HTTP/1.1 204 No Content
Content-Location: /file.txt
ETag: "e0023aa4f"
```

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

| Specification |
| --- |
| RFC 5789  |

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

* `204`
* `Allow` (en-US), `Access-Control-Allow-Methods`
* `Accept-Patch` – указывает изменяемые типы документов принимаемые сервером.


Идентификация ресурсов в Вебе - HTTP

Идентификация ресурсов в Вебе
=============================

"Объект" (или "цель") HTTP-запроса называется "ресурс", чья природа может быть разной: фото, документ, или что-либо ещё. Каждый ресурс идентифицируется с помощью унифицированного идентификатора ресурса (URI (en-US)) используемого повсюду в HTTP для идентификации ресурсов.

Обычно чтобы описать конкретный ресурс (его имя) и его местоположение в Вебе, используется всего один URL (Uniform Resource Locator - Унифицированный локатор ресурса, вид URI, его ещё называют *веб-адресом*). Можно добавить, что иногда с помощью специального заголовка `Alt-Svc` (en-US) в ответе на запрос можно попросить клиента перезапросить ресурс с другой локации.

URLы и URNы
-----------

### URL

Самый популярный тип URI - это Uniform Resource Locator (URL), который также называют *веб-адресом*.
```

https://developer.mozilla.org
https://developer.mozilla.org/ru/docs/Learn
https://developer.mozilla.org/ru/search?q=URL
```

Любой из этих URL-ов может быть набран в адресной строке браузера чтобы сказать ему загрузить соответствующую страницу (ресурс).

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

http://www.example.com:80/path/to/myfile.html?key1=value1&key2=value2#SomewhereInTheDocument
```

### URN

Uniform Resource Name (URN) - это URI, который идентифицирует ресурс по имени в конкретном пространстве имён.
```

urn:isbn:9780141036144
urn:ietf:rfc:7230
```

Эти два URN-а соответствуют:

* книга "1984" Джорджа Оруэлла,
* IETF спецификация 7230, Hypertext Transfer Protocol (HTTP/1.1): Синтаксис и маршрутизация сообщений.
Синтаксис Унифицированных Идентификаторов Ресурсов (URI)
--------------------------------------------------------

### Схема или протокол

![Protocol](/ru/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-protocol@x2.png)

`http://` это пример протокола (схемы). Тут описывается какой протокол браузер должен использовать. Обычно это HTTP протокол или его безопасная версия - HTTPS. Интернет требует один из этих двух, но браузеры также знают как работать с некоторыми другими, например `mailto:` (чтобы открыть почтовый клиент) или `ftp:` для работы с передачей файлов. Популярные схемы:

| Схема | Описание |
| --- | --- |
| data | Data URIs |
| file | Доступ к файлам на локальном компьютере |
| ftp | File Transfer Protocol (протокол передачи файлов) |
| http/https | Hyper text transfer protocol (Secure) |
| mailto | Адрес электронной почты |
| ssh | Протокол Secure shell для работы с серверами |
| tel | Телефон |
| urn | Uniform Resource Names |
| view-source | Исходный код ресурса |
| ws/wss | (Зашифрованные) соединения WebSocket |

### Владелец (имя хоста)

![Domaine Name](/ru/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-domain@x2.png)

`www.example.com` - это доменное имя, идентификатор ответственного за это пространство имён. Идентифицирует, какой именно Веб-сервер получает запрос. Альтернативно, можно просто использовать IP address, но поскольку это не так удобно, то этот способ используется не часто.

### Порт

![Port](/ru/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-port@x2.png)

`:80` - это порт сервера. Он идентифицирует технические "ворота", которые нужны для доступа к ресурсу на сервере. Обычно порт не указывается, т.к. существуют общепринятые нормы о стандартных портах для HTTP (80 для HTTP и 443 для HTTPS). В других случаях обязательно нужно указывать.

### Путь

![Path to the file](/ru/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-path@x2.png)

`/path/to/myfile.html` - это путь к ресурсу на Веб-сервере. Изначально путь типа этого указывал на физическое место файла на сервере, но сейчас всё чаще это псевдоним или описание некоторого абстрактного ресурса.

### Строка запроса (query string)

![Parameters](/ru/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-parameters@x2.png)

`?key1=value1&key2=value2` - это дополнительные параметры, предоставляемые Веб-серверу. Это список пар "ключ=значение", разделённых символом `&` . Веб-сервер может использовать эти параметры как дополнительные инструкции, что именно сделать с ресурсом перед отправкой его пользователю. Каждый Веб-сервер имеет свои правила насчёт параметров, и единственный надёжный способ узнать как конкретный Веб-сервер обрабатывает эти параметры - это спросить того, кто контролирует Веб-сервер.

### Фрагмент

![Anchor](/ru/docs/Web/HTTP/Basics_of_HTTP/Identifying_resources_on_the_Web/mdn-url-anchor@x2.png)

`#SomewhereInTheDocument` - это "якорь" на другую часть ресурса. Якорь представляет собой что-то вроде "закладки" внутри ресурса, давая браузеру указание показать содержимое с определённого места. В HTML-документе, к примеру, браузер будет скроллить к точке где якорь определён, а на аудио/видео-документе браузер попытается перейти на время, указанное в якоре. Важно что часть, начинающаяся с # - никогда не пересылается серверу в запросе.

Примечания по использованию
---------------------------

Когда используются URLы в HTML содержимом, вам стоит использовать только несколько из этих схем. Когда идёт обращение к субресурсам (файлам, которые являются частью большого документа) — вам стоит использовать лишь HTTP и HTTPS. Браузеры сейчас перестают использовать FTP для загрузки ресурсов, из соображений безопасности.

FTP до сих пор доступен на верхнем уровне (т.е. когда ссылка указывается в адресной строке или в ссылке), но некоторые браузеры могут делегировать загрузку FTP ресурсов другим приложениям.

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

https://developer.mozilla.org/ru/docs/Learn
tel:+1-816-555-1212
git@github.com:mdn/browser-compat-data.git
ftp://example.org/resource.txt
urn:isbn:9780141036144
mailto:help@supercyberhelpdesk.info
```

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

| Спецификация | Название |
| --- | --- |
| RFC 7230, раздел 2.7: Uniform Resource Identifiers | Hypertext Transfer Protocol (HTTP/1.1): Синтаксис и маршрутизация сообщений |

Читайте также
-------------

* Что такое URL?
* Список URI-схем IANA


MIME types - HTTP

MIME types
==========

**Медиа тип** (так же известный как **Multipurpose Internet Mail Extensions** или **MIME тип)** является стандартом, который описывает природу и формат документа, файла или набора байтов. Он определён и стандартизирован в спецификации RFC 6838 .

Организация Internet Assigned Numbers Authority (IANA) является ответственной за все официально признанные MIME типы, и вы можете найти самый последний и полный лист MIME типов на их странице Медиа Типов.

**Предупреждение:** **Важно:** Для принятия решения о том, как обрабатывать URL, браузеры используют MIME типы, *а не расширения файлов*, так что серверам необходимо отправлять правильные MIME типы в `Content-Type` заголовке ответа. При неточном задавании этого заголовка, браузеры с большой вероятностью будут неправильно интерпретировать и обрабатывать содержание файлов, из-за чего сайт будет работать неверно.

Структура MIME типа
-------------------

Простейший MIME тип состоит из *типа* и *подтипа* — двух строк разделённых наклонной чертой (`/`), без использования пробелов.
```

тип/подтип
```

**Тип** представляет общую категорию, в которой находится тип данных, например `video` или `text`. **Подтип** же строго отождествляется с отдельным типом данных, представляемых данным MIME типом. Например, для MIME типа `text`, подтипы могут быть `plain` (простой текст), `html` (HTML source code) или `calendar` (для iCalendar `.ics`).

Необязательный **параметр** может быть добавлен для указания дополнительных деталей
```

тип/подтип;параметр=значение
```

Например, для MIME типов категории `text`, необязательный параметр `charset` может быть задан для уточнения кодировки, используемой в документе. Для объявления, что пересылаемый файл имеет кодировку UTF-8, необходимо использовать MIME тип `text/plain;charset=UTF-8`. При не указании параметра `charset`, его значение автоматически будет задано, как ASCII (`US-ASCII`), если в настройках браузера не будет определено иначе.

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

### Типы

Все типы можно разделить на два класса: **дискретные** и **многокомпонентные.** Дискретные типы представляют одиночные файлы, например, одиночный текстовый, музыкальный или видео файл. Многокомпонентные типы представляют документы, составленные из нескольких частей, каждая из которых может иметь свой отдельный MIME тип, или они могут заключать в себе несколько отдельных файлов, передаваемых в одном сообщении. Например, многокомпонентные MIME типы используются для передачи нескольких изображений в одном email.

#### Дискретные типы

В настоящее время на IANA зарегистрированы следующие дискретные типы:

`application` Список IANA

Любой вид бинарных данных, явно не попадающих ни в одну другую группу типов. Данные, которые будут выполняться или как-либо интерпретироваться, или данные для выполнения, которых необходимо отдельное приложение. Для указания базового типа бинарных данных (данных без определённого типа) используют тип `application/octet-stream`. Другие распространённые примеры включают `application/pdf`, `application/pkcs8` и `application/zip`.

`audio` Список IANA

Аудио или музыкальные данные. Примеры: `audio/mpeg`, `audio/vorbis`.

`example`

Тип, зарезервированный для написания примеров, отображающих использование MIME типов. Этот тип никогда не должен использоваться вне примеров кода или документации. `example` может так же использоваться, как подтип.

`font` Список IANA

Данные шрифтов. Распространённые примеры включают `font/woff`, `font/ttf` и `font/otf`.

`image` Список IANA

Изображения или графические данные, включая векторную и растровую графику, а так же анимированные версии форматов неподвижных изображений, таких как GIF (en-US) или APNG. Распространённые примеры включают `image/jpeg`, `image/png`, и `image/svg+xml`.

`model` Список IANA

Данные моделей для 3D объектов или сцен. Примеры: `model/3mf` и `model/vml`.

`text` Список IANA

Любые текстовые данные, так или иначе доступные для чтения человеку, а так же исходный код или текстовые данные для программ. Примеры: `text/plain`, `text/csv` и `text/html`.

`video` Список IANA

Видео данные или файлы. Например, MP4 фильмы (`video/mp4`).

Любые текстовые документы без определённого подтипа стоит отправлять, как `text/plain` тип. Аналогичным образом, `application/octet-stream` тип подойдёт бинарным документам при неопределённом или неизвестном подтипе.

#### Многокомпонентные типы

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

За исключением `multipart/form-data` типа, используемого в `POST` методе HTML форм, и `multipart/byteranges` типа, используемом в ответе `206` `Partial Content` для отправки части документа, HTTP никаким особым образом не обрабатывает многокомпонентные типы, и просто отправляет данные в браузер (который, с большой вероятностью, предложит сохранить переданный файл, тоже не зная как его обработать).

Существуют два многокомпонентных типа:

`message` Список IANA

Сообщение, включающее в себя другие сообщения. Этот тип может использоваться, например, для представления сообщения, которое включают в себя другое переадресованное сообщение, как часть данных, или для отправки больших сообщений по частям, как если бы каждое сообщение отправлялось отдельно. Примеры включают `message/rfc822` (для переадресованных или цитируемых сообщений) и `message/partial` для автоматического разделения одного большого сообщения на несколько небольших и их последующей сборки на стороне получателя.

`multipart` Список IANA

Данные составленные из нескольких компонентов, каждый из которых может иметь отдельный MIME тип. Примеры включают `multipart/form-data` (для данных созданных с помощью `FormData` API) и `multipart/byteranges` (определённого в RFC 7233: 5.4.1 и используемого в ответах HTTP `206` "Partial Content", когда запрашиваемые данные возвращаются по частям в нескольких сообщениях, как например, при использовании заголовка `Range`).

Важные для Web-разработчиков MIME типы
--------------------------------------

### application/octet-stream

Этот тип является базовым для бинарных данных. В связи с тем, что он подразумевает *неопределённые бинарные* данные, браузеры, как правило, не будут пытаться его обработать каком-либо образом, а вызовут для него диалоговое окно «Сохранить Как», как если бы заголовок ответа `Content-Disposition` имел значение `attachment`.

### text/plain

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

**Примечание:** `text/plain` не означает "любой вид текстовых данных". Если браузер ожидает получения какого-то конкретного типа текстовых данных, то с большой вероятностью он не будет считать `text/plain` подходящим типом. Например, при загрузке `text/plain` документа через `<link>` элемент, браузер не будет его признавать правильным CSS файлом и использовать для применения стилей. Только `text/css` тип должен использоваться для загрузки CSS документов.

### text/css

CSS документы, используемые для стилизации web-страниц **должны** отправляться, как `text/css` тип. Большинство браузеров не смогут распознавать CSS документы, загруженные с отличным от `text/css` MIME типом.

### text/html

Все HTML данные должны пересылаться с данным типом. Альтернативные MIME типы для XHTML (например, `application/xhtml+xml`) почти не используются в настоящее время.

**Примечание:** Используйте `application/xml` или `application/xhtml+xml`, когда вам необходим строгий синтаксический анализ документов, разделы `<![CDATA[…]]>` или элементы, не принадлежащие к пространствам имён HTML/SVG/MathML.

### text/javascript

Согласно HTML спецификации: при пересылке JavaScript файлов, всегда должен использоваться MIME тип `text/javascript`.

По исторически сложившимся причинам, MIME Sniffing Standard (стандарт, определяющий, как браузеры должны интерпретировать медиа типы и выяснять, как обрабатывать данные при неправильно заданных медиа типах) позволяет серверам отправлять JavaScript документы, используя один из нижеперечисленных типов:

* `application/javascript`
* `application/ecmascript`
* `application/x-ecmascript`
Non-standard
* `application/x-javascript`
Non-standard
* `text/javascript`
* `text/ecmascript`
* `text/javascript1.0`
Non-standard
* `text/javascript1.1`
Non-standard
* `text/javascript1.2`
Non-standard
* `text/javascript1.3`
Non-standard
* `text/javascript1.4`
Non-standard
* `text/javascript1.5`
Non-standard
* `text/jscript`
Non-standard
* `text/livescript`
Non-standard
* `text/x-ecmascript`
Non-standard
* `text/x-javascript`
Non-standard

**Примечание:** Несмотря на то, что некоторые user agent могут поддерживать какие-то из вышеперечисленных типов, вы всегда должны использовать `text/javascript`. Это единственный MIME тип, который гарантированно будет работать в настоящее время и в будущем.

Иногда вы можете заметить использование `text/javascript` MIME типа в связке с параметром `charset`, для уточнения кодировки, в которой был написан файл. Такое определение MIME типа является неправильным, и в большинстве случаев браузеры не станут загружать скрипт, передаваемый с таким типом.

### Типы изображений

Файлы, MIME типом которых является `image`, содержат в себе данные изображений. Подтип определяет, какой конкретный формат изображения представлен в данных.

Лишь несколько типов изображений (en-US) достаточно распространены, чтобы безопасно использоваться на веб-страницах.

### Аудио и видео типы

Так же как в случае с изображениями, стандарт HTML не обязывает браузеры поддерживать какие-либо определённые форматы и кодеки для `<audio>` и `<video>` элементов, так что при их выборе, важно брать в расчёт целевую аудиторию и диапазон браузеров (а так же версии этих браузеров), которые она может использовать.

Наше руководство по медиа форматам (en-US) предоставляет список общепринятых типов, включая информацию об особых случаях при их использовании, их недостатках, совместимости, а так же других деталях.

Руководства по аудио (en-US) и видео (en-US) кодекам перечисляют часто поддерживаемые браузерами кодеки, предоставляя детали по их совместимости и техническую информацию, например как много аудио каналов они поддерживают, какой тип сжатия используют, и так далее. Руководство по используемым в WebRTC кодекам развивает эту тему ещё дальше, конкретно описывая кодеки, поддерживаемые популярными браузерами, так чтобы вы могли выбрать кодеки, которые имеют наилучшую поддержку в диапазоне браузеров по вашему выбору.

Что касается MIME типов для аудио и видео файлов, то чаще всего они указывают на формат контейнера (тип файла). Необязательный параметр `codecs` может быть добавлен к MIME типу для более точного указания, какой кодек и параметры использовались для пересылаемого файла.

Ниже перечислены наиболее часто используемые на веб-страницах MIME типы. Обратите внимание, что это не полный перечень всех доступных типов. Более полный список поддерживаемых форматов может быть найден в руководстве по медиа форматам (en-US).

| MIME тип | Аудио или видео тип |
| --- | --- |
| `audio/wave` `audio/wav` `audio/x-wav` `audio/x-pn-wav` | Аудио файл WAVE формата. С PCM аудио кодеком (WAVE кодек "1"), считающимся наиболее поддерживаемым, а так же другими, имеющими ограниченную поддержку. |
| `audio/webm` | Аудио файл формата WebM. С Vorbis и Opus официально поддерживаемыми WebM спецификацией аудио кодеками. |
| `video/webm` | Видео файл, с возможной аудио дорожкой, формата WebM. С VP8 и VP9, как наиболее распространёнными видео кодеками; Vorbis и Opus, как наиболее распространёнными аудио кодеками. |
| `audio/ogg` | Аудио файл формата OGG. С Vorbis, как наиболее распространённым аудио кодеком. Хотя на данный момент имеется поддержка и Opus кодека. |
| `video/ogg` | Видео файл, с возможной аудио дорожкой, в формате OGG. Где Theora – наиболее часто встречающийся видео кодек и Vorbis - наиболее часто встречающийся аудио кодек. Хотя использование кодека Opus становится всё более распространённым. |
| `application/ogg` | Аудио или видео формата OGG. Где Theora – наиболее часто встречающийся видео кодек и Vorbis - наиболее часто встречающийся аудио кодек. |

### multipart/form-data

`multipart/form-data` тип может быть использован при отправке значений из заполненной HTML Формы на сервер.

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

Content-Type: multipart/form-data; boundary=aBoundaryString
(other headers associated with the multipart document as a whole)

--aBoundaryString
Content-Disposition: form-data; name="myFile"; filename="img.jpg"
Content-Type: image/jpeg

(data)
--aBoundaryString
Content-Disposition: form-data; name="myField"

(data)
--aBoundaryString
(more subparts)
--aBoundaryString--
```

Следующая форма `<form>`:

```html
<form
 action="http://localhost:8000/"
 method="post"
 enctype="multipart/form-data">
  <label>Name: <input name="myTextField" value="Test" /></label>
  <label><input type="checkbox" name="myCheckBox" /> Check</label>
  <label
 >Upload file: <input type="file" name="myFile" value="test.txt"
 /></label>
  <button>Send the file</button>
</form>
```

отправит сообщение:
```

POST / HTTP/1.1
Host: localhost:8000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:50.0) Gecko/20100101 Firefox/50.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Upgrade-Insecure-Requests: 1
Content-Type: multipart/form-data; boundary=---------------------------8721656041911415653955004498
Content-Length: 465

-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myTextField"

Test
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myCheckBox"

on
-----------------------------8721656041911415653955004498
Content-Disposition: form-data; name="myFile"; filename="test.txt"
Content-Type: text/plain

Simple file.
-----------------------------8721656041911415653955004498--
```

### multipart/byteranges

`multipart/byteranges` MIME тип используется для отправки данных в браузер по частям.

При отправке кода состояния `206` `Partial Content`, этот MIME тип будет означать, что документ состоит из нескольких частей, по одной для каждого отдельно запрашиваемого диапазона. Аналогично с остальными многокомпонентными типами, заголовок `Content-Type` используется для объявления границы `boundary`, разделяющей документ на отдельные компоненты. Каждый компонент имеет заголовок `Content-Type`, описывающий тип сегмента данных, и `Content-Range` (en-US), описывающий его диапазон.
```

HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: multipart/byteranges; boundary=3d6b6a416f9b5
Content-Length: 385

--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 100-200/1270

eta http-equiv="Content-type" content="text/html; charset=utf-8" />
    <meta name="vieport" content
--3d6b6a416f9b5
Content-Type: text/html
Content-Range: bytes 300-400/1270

-color: #f0f0f2;
        margin: 0;
        padding: 0;
        font-family: "Open Sans", "Helvetica
--3d6b6a416f9b5--
```

**Важность задания правильного** **MIME** **типа**
--------------------------------------------------

Большинство серверов отправляет ресурсы неопределённого типа, как `application/octet-stream` MIME тип. Большинство же браузеров, в целях безопасности, не позволяет их никак обрабатывать, вынуждая пользователя сохранять их на жёсткий диск, для дальнейшего использования.

Несколько советов по правильной настройке MIME типов на серверах:

* RAR-сжатые файлы. В этом случае самым правильным вариантом было бы задать тип изначального ресурса; но это не всегда выполнимо, так как .RAR файлы могут хранить в себе несколько типов данных. Тогда, настройте сервер на отправку `application/x-rar-compressed` MIME типа вместе с RAR ресурсами.
* Аудио и видео. Только ресурсы с правильно заданными MIME типами могут производиться в `<video>` и `<audio>` элементах. Убедитесь, что вы используете правильные типы для аудио и видео данных (en-US).
* Запатентованные типы файлов. Избегайте использования `application/octet-stream` при их отправке, так как большинство браузеров не позволит определять способы обработки (например, "Открыть в Word") для этого базового MIME типа. Используйте специальные типы, например `application/vnd.mspowerpoint`, чтобы позволить пользователям открывать загруженный ресурс в программе по их выбору.
MIME sniffing
-------------

В отсутствии заданного MIME типа, или в определённых случаях, когда браузеры полагают, что MIME тип задан неправильно, они могут выполнять *MIME sniffing* — попытку угадать правильный MIME тип, анализируя характеристики ресурса.

Каждый браузер выполняет MIME sniffing по-своему и при разных условиях (например, Safari будет смотреть на расширение файла, если переданный MIME тип является неподходящим для документа). В этих случаях могут присутствовать опасения по поводу безопасности, так как некоторые MIME типы представляют исполняемые файлы. Сервера имеют возможность предотвращать MIME sniffing, отправляя `X-Content-Type-Options` заголовок ответа.

Другие методы сообщения о типе ресурса
--------------------------------------

MIME типы не являются единственным способом сообщения типа документа:

* Суффиксы в названиях файлов могут указывать на тип документа, главным образом на Microsoft Windows. Но не все операционные системы могут считать их имеющими смысл (например, Linux или MacOS). А так же нет никакой гарантии, что они будут указывать на правильный тип.
* Магические числа. Синтаксисы различных форматов позволяют узнавать их тип, через анализ их структуры байтов. Например, GIF файлы начинаются с `47 49 46 38 39` шестнадцатеричного значения (`GIF89`), а PNG файлы с `89 50 4E 47` (`.PNG`). Опять же, не все типы документов имеют магические числа, так что этот подход так же не надёжен на 100%.
Смотрите также
--------------

* Медиа технологии в web (en-US)
* Руководство по медиа типам и форматам в web (en-US)
* Настраивание MIME типов на стороне сервера (en-US)


Data URL - HTTP

Data URL
========

**Data URL**, URL имеющий приставку `data:`, делает возможным встраивание файлов небольшого размера прямо в документ.

**Примечание:** современные браузеры обрабатывают Data URL, как неявный уникальный origin, и не заимствуют значение origin из объекта настроек ответственного за навигацию.

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

Data URL состоит из четырёх сегментов: приставки (`data:`), MIME типа, описывающего тип данных, дополнительного ключевого слова `base64` для нетекстовых данных и самой строки данных:
```

data:[<тип данных>][;base64],<данные>
```

`тип данных` описывается строкой в формате MIME типа, например `'image/jpeg'` для JPEG файла изображения. При не указывании типа данных, браузер автоматически будет интерпретировать строку данных, как `text/plain;charset=US-ASCII`

Если данные представляют собой какую-либо текстовую информацию, вы можете просто вставить эту текстовую строку в Data URL (используя соответствующие для типа данных сущности и знаки экранирования). В ином случае вам будет необходимо использовать ключевое слово `base64` перед вставкой base64-кодированных бинарных данных. Дополнительную информацию о MIME типах вы сможете найти здесь и здесь (en-US).

Несколько примеров:

`data:,Hello%2C%20World!`

Простые text/plain данные

`data:text/plain;base64,SGVsbG8sIFdvcmxkIQ%3D%3D`

base64-кодированная версия примера выше

`data:text/html,%3Ch1%3EHello%2C%20World!%3C%2Fh1%3E`

HTML строка вида: `<h1>Hello, World!</h1>`

`data:text/html,<script>alert('hi');</script>`

HTML строка, вызывающая JavaScript alert функцию. Заметьте необходимость закрывающего <script> тега.

Кодирование данных в формат base64
----------------------------------

Base64 относится к группе транспортных кодировок, и позволяет представлять бинарные данные в виде ASCII строк, переводя их в radix-64 представление. Состоя только из ASCII символов, base64 строки являются допустимыми для использования в URL, по этой причине они могут быть использованы и в Data URL.

### Кодирование в Javascript

Web API имеет встроенные методы для кодирования и декодирования формата base64: Base64 кодирование и декодирование.

### Кодирование на Unix системах

На Linux и Mac OS X системах, кодирование файлов или строк в формат Base64 может быть выполнено через программу `base64` в командной строке (или, в качестве альтернативы, программу `uuencode` с `-m` аргументом).

```bash
echo -n hello|base64
# выводит в консоль: aGVsbG8=

echo -n hello>a.txt
base64 a.txt
# выводит в консоль: aGVsbG8=

base64 a.txt>b.txt
# записывает в файл b.txt: aGVsbG8=
```

### Кодирование на Microsoft Windows

Кодирование на Windows может быть выполнено через powershell или какую-либо другую предназначенную для этого программу. Так же кодирование может быть выполнено и через программу `base64` (смотрите секцию Кодирование на Unix системах), при условии активированной технологии WSL.
```

[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes("hello"))
# выводит в консоль: aGVsbG8=

bash -c "echo -n hello`|base64"
# выводит в консоль: aGVsbG8=
# обратный апостроф (`) используется здесь для экранирования символа вертикальной черты (|)
```

Распространённые проблемы
-------------------------

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

Для примера рассмотрим Data URL вида:
```

data:text/html,lots of text...<p><a name%3D"bottom">bottom</a>?arg=val
```

результатом декодирования которого будет HTML строка:
```

lots of text...<p><a name="bottom">bottom</a>?arg=val
```

Синтаксис

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

Форматирование внутри документа

Встраивание Data URL по сути является встраиванием файла внутрь файла, и длина его строки может быть намного шире, чем ширина заключающего его документа. Так же, несмотря на то, что использование пробелов считается обычной практикой при форматировании данных, есть вероятность, что у вас возникнут проблемы при их base64 кодировании.

Ограничения длины

Хотя Firefox поддерживает Data URL практически неограниченных размеров, каждый отдельный браузер имеет свои ограничения на их длину. Например, Opera 11 ограничивает допустимую длину URL до 65535 символов, что означает ограничение сегмента данных в Data URL до 65529 символов (длина в 65529 символов взята из условия использования только только `data:` сегмента, без определения MIME типа данных).

Нехватка возможности обработки ошибок

Опечатки в определении MIME типа или написания ключевого слова `'base64'` будут проигнорированы без каких-либо уведомлений об ошибках.

Отсутствие поддержки строки параметров

В связи с неопределённостью типа сегмента данных в Data URL, строка параметров (характерные для страницы параметры, представляющиеся в виде `<url>?parameter-data`), добавленная к сегменту данных будет рассматриваться, как часть этих данных.

Проблемы с безопасностью

Несколько проблем с безопасностью (например: фишинг) связаны с Data URL и переходом по ним из корневого контекста документа. Чтобы избавиться от этих проблем, переход по URI, начинающихся со схемы `data://`, из корневого контекста документа перестал быть возможен в Firefox, начиная с версии 59 (и начиная с версии 58 в Nightly/Beta вариантах браузера). Надеемся, что остальные браузеры так же последуют этому примеру. Для дополнительной информации смотрите Blocking Top-Level Navigations to data URLs for Firefox 58.

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

| Спецификация | Заголовок |
| --- | --- |
| RFC 2397 | The "data" URL scheme |

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

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

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

* Base64 кодирование и декодирование
* `atob()` (en-US)
* `btoa()`
* CSS `url()` (en-US)
* URI (en-US)


Неполный список типов MIME - HTTP

Неполный список типов MIME
==========================

Здесь представлен исчерпывающий список типов MIME, соотнесённых с типами документов и отсортированных по расширению.Два ключевых типа MIME, использующихся в качестве типов по умолчанию:
* `text/plain` является типом по умолчанию для текстовых файлов. Текстовый файл должен быть читаемым человеком и не должен содержать в себе бинарную информацию.
* `application/octet-stream` является типом по умолчанию для всех остальных случаев. Нужно использовать этот тип, если тип файла неизвестен. Браузеры уделяют дополнительное внимание при работе с данным типом файлов для предотвращения вредоносного поведения.

IANA является официальным регистром типов MIME и поддерживает их официальный список. В данной таблице представлен список типов, наиболее важных для Web:

| Расширение | Тип документа | Тип MIME |
| --- | --- | --- |
| `.aac` | AAC audio | `audio/aac` |
| `.abw` | AbiWord document | `application/x-abiword` |
| `.arc` | Archive document (multiple files embedded) | `application/x-freearc` |
| `.avi` | AVI: Audio Video Interleave | `video/x-msvideo` |
| `.azw` | Amazon Kindle eBook format | `application/vnd.amazon.ebook` |
| `.bin` | Any kind of binary data | `application/octet-stream` |
| `.bmp` | Windows OS/2 Bitmap Graphics | `image/bmp` |
| `.bz` | BZip archive | `application/x-bzip` |
| `.bz2` | BZip2 archive | `application/x-bzip2` |
| `.csh` | C-Shell script | `application/x-csh` |
| `.css` | Cascading Style Sheets (CSS) | `text/css` |
| `.csv` | Comma-separated values (CSV) | `text/csv` |
| `.doc` | Microsoft Word | `application/msword` |
| `.docx` | Microsoft Word (OpenXML) | `application/vnd.openxmlformats-officedocument.wordprocessingml.document` |
| `.eot` | MS Embedded OpenType fonts | `application/vnd.ms-fontobject` |
| `.epub` | Electronic publication (EPUB) | `application/epub+zip` |
| `.gz` | GZip Compressed Archive | `application/gzip` |
| `.gif` | Graphics Interchange Format (GIF) | `image/gif` |
| `.htm .html` | HyperText Markup Language (HTML) | `text/html` |
| `.ico` | Icon format | `image/vnd.microsoft.icon` |
| `.ics` | iCalendar format | `text/calendar` |
| `.jar` | Java Archive (JAR) | `application/java-archive` |
| `.jpeg` `.jpg` | JPEG images | `image/jpeg` |
| `.js` | JavaScript | `text/javascript` |
| `.json` | JSON format | `application/json` |
| `.jsonld` | JSON-LD format | `application/ld+json` |
| `.mid` `.midi` | Musical Instrument Digital Interface (MIDI) | `audio/midi` `audio/x-midi` |
| `.mjs` | JavaScript module | `text/javascript` |
| `.mp3` | MP3 audio | `audio/mpeg` |
| `.mpeg` | MPEG Video | `video/mpeg` |
| `.mpkg` | Apple Installer Package | `application/vnd.apple.installer+xml` |
| `.odp` | OpenDocument presentation document | `application/vnd.oasis.opendocument.presentation` |
| `.ods` | OpenDocument spreadsheet document | `application/vnd.oasis.opendocument.spreadsheet` |
| `.odt` | OpenDocument text document | `application/vnd.oasis.opendocument.text` |
| `.oga` | OGG audio | `audio/ogg` |
| `.ogv` | OGG video | `video/ogg` |
| `.ogx` | OGG | `application/ogg` |
| `.opus` | Opus audio | `audio/opus` |
| `.otf` | OpenType font | `font/otf` |
| `.png` | Portable Network Graphics | `image/png` |
| `.pdf` | Adobe Portable Document Format (PDF) | `application/pdf` |
| `.php` | Hypertext Preprocessor (**Personal Home Page**) | `application/php` |
| `.ppt` | Microsoft PowerPoint | `application/vnd.ms-powerpoint` |
| `.pptx` | Microsoft PowerPoint (OpenXML) | `application/vnd.openxmlformats-officedocument.presentationml.presentation` |
| `.rar` | RAR archive | `application/vnd.rar` |
| `.rtf` | Rich Text Format (RTF) | `application/rtf` |
| `.sh` | Bourne shell script | `application/x-sh` |
| `.svg` | Scalable Vector Graphics (SVG) | `image/svg+xml` |
| `.swf` | Small web format (SWF) or Adobe Flash document | `application/x-shockwave-flash` |
| `.tar` | Tape Archive (TAR) | `application/x-tar` |
| `.tif .tiff` | Tagged Image File Format (TIFF) | `image/tiff` |
| `.ts` | MPEG transport stream | `video/mp2t` |
| `.ttf` | TrueType Font | `font/ttf` |
| `.txt` | Text, (generally ASCII or ISO 8859-*n*) | `text/plain` |
| `.vsd` | Microsoft Visio | `application/vnd.visio` |
| `.wav` | Waveform Audio Format | `audio/wav` |
| `.weba` | WEBM audio | `audio/webm` |
| `.webm` | WEBM video | `video/webm` |
| `.webp` | WEBP image | `image/webp` |
| `.woff` | Web Open Font Format (WOFF) | `font/woff` |
| `.woff2` | Web Open Font Format (WOFF) | `font/woff2` |
| `.xhtml` | XHTML | `application/xhtml+xml` |
| `.xls` | Microsoft Excel | `application/vnd.ms-excel` |
| `.xlsx` | Microsoft Excel (OpenXML) | `application/vnd.openxmlformats-officedocument.spreadsheetml.sheet` |
| `.xml` | `XML` | `application/xml` if *not* readable from casual users (RFC 3023, section 3) `text/xml` if readable from casual users (RFC 3023, section 3) |
| `.xul` | XUL | `application/vnd.mozilla.xul+xml` |
| `.zip` | ZIP archive | `application/zip` |
| `.3gp` | 3GPP audio/video container | `video/3gpp` `audio/3gpp` if it doesn't contain video |
| `.3g2` | 3GPP2 audio/video container | `video/3gpp2` `audio/3gpp2` if it doesn't contain video |
| `.7z` | 7-zip archive | `application/x-7z-compressed` |


411 Length Required - HTTP

411 Length Required
===================

Код ответа на ошибку **`411 Length Required`** указывает, что сервер отказывается принять запрос без определённого `Content-Length`.

Обратите внимание, что по спецификации при отправке данных в ряд фрагментов **Content-Length** опущен, и в начале каждого фрагмента вам нужно добавить длину текущего фрагмента в шестнадцатеричном формате. Подробнее смотрите `Transfer-Encoding` (en-US).

Статус
------
```

411 Length Required
```

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

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

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

* `Content-Length`
* `Transfer-Encoding` (en-US)


409 Conflict - HTTP

409 Conflict
============

HTTP **`409 Conflict`** код состояния ответа указывает на конфликт запроса с текущим состоянием сервера.

Конфликты чаще всего возникают в ответ на `PUT` запрос. Например, вы можете получить ответ 409 при загрузке файла, который старше, чем тот, который уже существует на сервере, что приводит к конфликту управления версиями.

Статус
------
```

409 Conflict
```

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

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

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

* `PUT`


415 Unsupported Media Type - HTTP

415 Unsupported Media Type
==========================

Код ответа на ошибку клиента HTTP **415 Unsupported Media Type** указывает, что сервер отказывается принять запрос, потому что формат содержимого не поддерживается сервером.

Проблема формата может быть связана с указанным запросом `Content-Type` или `Content-Encoding` или в результате непосредственного контроля данных.

Status
------
```

415 Unsupported Media Type
```

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

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

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

* `Content-Type`
* `Content-Encoding`
* `Accept`


401 Unauthorized - HTTP

401 Unauthorized
================

Код ответа на статус ошибки HTTP **`401 Unauthorized`** клиента указывает, что запрос не был применён, поскольку ему не хватает действительных учётных данных для целевого ресурса.

Этот статус отправляется с `WWW-Authenticate` (en-US), который содержит информацию о правильности авторизации.

Этот статус похож на `403`, но в этом случае возможна аутентификация.

Статус
------
```

401 Unauthorized
```

Пример ответа
-------------
```

HTTP/1.1 401 Unauthorized
Date: Wed, 21 Oct 2015 07:28:00 GMT
WWW-Authenticate: Basic realm="Access to staging site"
```

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

| Спецификация | Название |
| --- | --- |
| RFC 7235, раздел 3.1: 401 Unauthorized | HTTP/1.1: Authentication |

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

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

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

* HTTP authentication
* `WWW-Authenticate` (en-US)
* `Authorization`
* `Proxy-Authorization` (en-US)
* `Proxy-Authenticate` (en-US)
* `403`, `407`


200 OK - HTTP

200 OK
======

Код ответа об успешном статусе "*The HTTP* **200 OK**" указывает, что запрос выполнен успешно. Ответ 200 может кешироваться по умолчанию.

Значение успеха зависит от метода \*HTTP-\*запроса:

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

Успешный результат `PUT` или `DELETE` часто не **200 OK**, `204` **No Content** ( или `201` **Created**, когда ресурс загружается в первый раз).

Статус
------
```

200 OK
```

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

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

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

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

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

* HTTP request methods


428 Precondition Required - HTTP

428 Precondition Required
=========================

Код статуса HTTP **428 Precondition Required** означает, что сервер требует, чтобы запрос был условным (соответствовал неким предварительно заданным условиям).

Как правило, это означает, что требуемый заголовок предварительного условия, например `If-Match` отсутствует .

Если заголовок предусловия **не соответствует** состоянию на стороне сервера, ответ должен быть `412` `Precondition Failed`.

Статус
------
```

428 Precondition Required
```

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

| Спецификации | Название |
| --- | --- |
| RFC 6585, раздел 3: 428 Precondition Required | Расширенные коды статуса HTTP |

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

* Условные запросы HTTP
* `If-Match`
* `412`


302 Found - HTTP

302 Found
=========

HTTP код перенаправления **`302 Found`** означает, что запрошенный ресурс был временно перемещён по адресу, указанному в заголовке `Location` (en-US). Получив такой ответ браузер перенаправляется на новую страницу, но поисковые системы не обновляют свои ссылки на ресурс (в жаргоне SEO говорят, что вес ссылки (link-juice) не меняется и не отправляется на новый URL-адрес).

Несмотря на требование спецификации не изменять при перенаправлении метод и тело запроса, не все программные клиенты выполняют его, и с некоторыми из них можно столкнуться до сих пор. Поэтому рекомендуется установить код `302` только как ответ для методов `GET` или `HEAD`. Для остальных случаев лучше использовать код `307 Temporary Redirect`, поскольку в этом случае изменение метода явно запрещено.

В тех случаях, когда вы хотите, чтобы используемый метод был изменён на `GET`, используйте код `303 See Other`. Это полезно, если вы хотите дать ответ на метод `PUT`, который не является загруженным ресурсом, но является подтверждающим сообщением (например, «Вы успешно загрузили XYZ»).

Статус
------
```

302 Found
```

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

### Запрос клиента
```

GET / HTTP/1.1
Host: www.example.org
```

### Ответ сервера
```

HTTP/1.1 302 Found
Location: http://www.example.org/index.asp
```

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

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

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

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

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

* `307 Temporary Redirect`, эквивалент рассматриваемого кода ответа, но явно запрещающий изменение метода запроса.
* `303 See Other`, временное перенаправление, которое изменяет метод запроса на `GET`.
* `301 Moved Permanently`, постоянное перенаправление.


405 Method Not Allowed - HTTP

405 Method Not Allowed
======================

Код состояния протокола HTTP **`405 Method Not Allowed`**, указывает, что метод запроса известен серверу, но был отключён и не может быть использован. Два обязательных метода `GET` и `HEAD` никогда не должны быть отключены и не должны возвращать этот код ошибки.

Сервер ОБЯЗАН сгенерировать поле заголовка **`Allow`** в ответе с кодом 405, которое содержит список текущих доступных методов ресурса.

Статус
------
```

405 Method Not Allowed
```

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

| Спецификация | Титул |
| --- | --- |
| RFC 7231, раздел 6.5.5: 405 Method Not Allowed | Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content |

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

* `Allow` (en-US)
* 405 Method Not Allowed


503 Service Unavailable - HTTP

503 Service Unavailable
=======================

HTTP **`503 Service Unavailable`** код состояния сервера, указывающий на то, что сервер не готов обработать данный запрос.

Часто причиной этого оказывается закрытие сервера для технических работ или его перегрузка. Обратите внимание, что вместе с этим ответом следует отправить удобную для пользователя страницу, объясняющую проблему. Данный код должен использоваться для временных состояний, а HTTP-заголовок `Retry-After` должен, по возможности, содержать предполагаемое время возвращения в работу.

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

Статус
------
```

503 Service Unavailable
```

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

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

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

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

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

* `Retry-After`


204 No Content - HTTP

204 No Content
==============

"The HTTP **`204 No Content"`** код ответа статуса успеха указывает, что запрос имеет успех, но что клиенту не нужно уходить со своей текущей страницы. По умолчанию ответ **204** кешируется. В такой ответ включён `ETag`.

Общим вариантом использования является возвращение **204** в результате запроса `PUT`, обновления ресурса, без изменения текущего содержимого страницы, отображаемой пользователю. Если ресурс создан, вместо него возвращается `201` **Created**. Если страница должна быть изменена на вновь обновлённую страницу, вместо неё следует использовать `200`.

Статус
------
```

204 No Content
```

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

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

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

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

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

* Хотя этот статус код предназначен для описания ответа без тела, серверы могут ошибочно включать данные, следующие за заголовками. Протокол позволяет идентификаторам браузера изменять способ обработки таких ответов (обсуждение этого текста спецификации можно найти здесь). Это наблюдается в постоянных соединениях, где невалидное тело запроса может содержать отдельный ответ на последующий запрос.
 Apple Safari отклоняет любые такие данные. Google Chrome и Microsoft Edge отбрасывают до 4 невалидных байт, предшествующих правильному ответу.
Смотрите также
--------------

* HTTP request methods


400 Bad Request - HTTP

400 Bad Request
===============

Код состояния ответа "HTTP **400 Bad Request**" указывает, что сервер не смог понять запрос из-за недействительного синтаксиса. Клиент не должен повторять этот запрос без изменений.

Статус
------
```

400 Bad Request
```

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

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

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

* 400 Bad Request


431 Request Header Fields Too Large - HTTP

431 Request Header Fields Too Large
===================================

HTTP **`431 Request Header Fields Too Large`** Код состояния ответа указывает, что сервер не желает обрабатывать запрос, потому что его поля заголовка слишком велики. Запрос может быть повторно представлен после уменьшения размера полей заголовка запроса.

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

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

Статус
------
```

431 Request Header Fields Too Large
```

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

| Спецификация | Название |
| --- | --- |
| RFC 6585, раздел 5: 431 Request Header Fields Too Large | Additional HTTP Status Codes |

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

* Request header


307 Temporary Redirect - HTTP

307 Temporary Redirect
======================

HTTP код перенаправления `307 Temporary Redirect` означает, что запрошенный ресурс был временно перемещён в URL-адрес, указанный в заголовке `Location` (en-US).

Метод и тело исходного запроса повторно используются для выполнения перенаправленного запроса. Если вы хотите, чтобы используемый метод был изменён на `GET`, используйте `303 See Other`. Это полезно, если вы хотите дать ответ на метод `PUT`, который не является загруженным ресурсом, а является подтверждающим сообщением (например, «Вы успешно загрузили XYZ»).

Единственное различие между `307` и `302` состоит в том, что `307` гарантирует, что метод и тело не будут изменены при выполнении перенаправленного запроса. В случае с кодом `302` некоторые старые клиенты неправильно меняли метод на `GET`, из-за чего поведение запросов с методом отличным от `GET` и ответа с кодом `302` непредсказуемо, тогда как поведение в случае ответа с кодом `307` предсказуемо. Для запросов `GET` поведение идентично.

Статус
------
```

307 Temporary Redirect
```

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

### Запрос клиента
```

DELETE /cars/oldest HTTP/1.1
Host: www.example.org
```

### Ответ сервера
```

HTTP/1.1 307 Temporary Redirect
Location: http://www.example.org/cars/id/123456
```

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

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

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

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

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

* `302 Found`, эквивалентен этому коду ответа, но может изменить метод запроса, если он отличается от `GET`.
* `303 See Other`, временное перенаправление, которое изменяет метод на `GET`.
* `301 Moved Permanently`, постоянное перенаправление
* 307 Temporary Redirect


418 I'm a teapot - HTTP

418 I'm a teapot
================

HTTP код ошибки **`418 I'm a teapot`** сообщает о том, что сервер не может приготовить кофе, потому что он чайник. Эта ошибка ссылается на Hyper Text Coffee Pot Control Protocol (гипертекстовый протокол кофейников) который был первоапрельской шуткой в 1998 году.

Статус
------
```

418 I'm a teapot
```

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

| Specification | Title |
| --- | --- |
| RFC 2324, раздел 2.3.2: 418 I'm a teapot | Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0): Semantics and Content |

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

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