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

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

Причина: отсутствует заголовок 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'
============================================================================

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

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

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

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

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

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

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

* CORS errors (en-US)
* Глоссарий: CORS
* CORS introduction
Причина: Не удалось выполнить запрос CORS
=========================================

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

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

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

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

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

* Ошибки CORS (en-US)
* Глоссарий: CORS
* Введение в CORS
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` используется для описания параметров соединения с целевым ресурсом. Клиент может указать особый 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`** запрашивает представление указанного ресурса. `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
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** создаёт новый ресурс или заменяет представление целевого ресурса данными, представленными в теле запроса.
Разница между `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** удаляет указанный ресурс.

|  |  |
| --- | --- |
| Запрос имеет тело | Может |
| Успешный ответ имеет тело | Может |
| Безопасный | Нет |
| Идемпотентный | Да |
| Кешируемый | Нет |
| 
 Допускается в
 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`** выполняет проверку обратной связи по пути к целевому ресурсу, предоставляя полезный механизм отладки.

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

В какой-то степени `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` – указывает изменяемые типы документов принимаемые сервером.
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`** код состояния ответа указывает на конфликт запроса с текущим состоянием сервера.

Конфликты чаще всего возникают в ответ на `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** указывает, что сервер отказывается принять запрос, потому что формат содержимого не поддерживается сервером.

Проблема формата может быть связана с указанным запросом `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`** клиента указывает, что запрос не был применён, поскольку ему не хватает действительных учётных данных для целевого ресурса.

Этот статус отправляется с `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`