RFC 7231 | Протокол передачи гипертекста (HTTP/1.1): семантика и контент

Аннотация

Протокол передачи гипертекста (HTTP — Hypertext Transfer Protocol) — это протокол уровня приложений без сохранения состояния для распределенных, совместных гипертекстовых информационных систем. В этом документе определяется семантика сообщений HTTP/1.1, выраженная методами запроса, полями заголовка запроса, кодами статуса ответа и полями заголовка ответа, а также полезной нагрузкой сообщений (метаданных и основного содержимого) и механизмами согласования содержимого.

Этот документ обновил [RFC 2817 #] и сделал устаревшим [RFC 2616 #]. Скачать оригинальную версию документа на английском языке RFC 7231 PDF

Дата публикации документа

Июнь 2014 года

Оглавление

1. Введение
1.1. Соответствие и обработка ошибок
1.2. Синтаксическая нотация
2. Ресурсы
3. Представления
3.1. Метаданные представления
3.1.1. Обработка данных представления
3.1.1.1. Тип носителя
3.1.1.2. Кодировка
3.1.1.3. Канонизация и текстовые настройки по умолчанию
3.1.1.4. Составные типы
3.1.1.5. Тип содержимого
3.1.2. Кодировка для сжатия или целостности
3.1.2.1. Кодирование контента
3.1.2.2. Content-Encoding
3.1.3. Язык аудитории
3.1.3.1. Языковые теги
3.1.3.2. Content-Language
3.1.4. Удостоверение личности
3.1.4.1. Идентификация Представления
3.1.4.2. Content-Location
3.2. Данные представления
3.3. Семантика полезной нагрузки
3.4. Согласование контента
3.4.1. Упреждающие переговоры
3.4.2. Реактивные переговоры
4. Методы запроса
4.1. Обзор
4.2. Общие свойства метода
4.2.1. Безопасные методы
4.2.2. Идемпотентные методы
4.2.3. Кэшируемые методы
4.3. Определения методов
4.3.1. GET
4.3.2. HEAD
4.3.3. POST
4.3.4. PUT
4.3.5. DELETE
4.3.6. CONNECT
4.3.7. OPTIONS
4.3.8. TRACE
5. Поля заголовка запроса
5.1. Controls
5.1.1. Expect
5.1.2. Max-Forwards
5.2. Conditionals
5.3. Content Negotiation
5.3.1. Quality Values
5.3.2. Accept
5.3.3. Accept-Charset
5.3.4. Accept-Encoding
5.3.5. Accept-Language
5.4. Authentication Credentials
5.5. Request Context
5.5.1. From
5.5.2. Referer
5.5.3. User-Agent
6. Коды состояния ответа
6.1. Обзор кодов состояния
6.2. Информационные 1xx
6.2.1. 100 Продолжить
6.2.2. 101 Протокол переключения
6.3. Успешные 2xx
6.3.1. 200 ОК
6.3.2. 201 Создано
6.3.3. 202 Принято
6.3.4. 203 Неофициальная информация
6.3.5. 204 Нет содержимого
6.3.6. 205 Сбросить содержимое
6.4. Перенаправление 3xx
6.4.1. 300 Множественные варианты
6.4.2. 301 Перемещено навсегда
6.4.3. 302 Найдено
6.4.4. 303 Смотри другое
6.4.5. 305 Использовать прокси
6.4.6. 306 (не используется)
6.4.7. 307 Временное перенаправление
6.5. Ошибка клиента 4xx
6.5.1. Ошибка 400, неверный запрос
6.5.2. 402 Требуется оплата
6.5.3. 403 Запрещено
6.5.4. 404 Не Найдено
6.5.5. 405 Метод не разрешен
6.5.6. 406 Недопустимо
6.5.7. 408 Время ожидания запроса
6.5.8. 409 Конфликт
6.5.9. 410 Ушел
6.5.10. 411 Длина требуется
6.5.11. 413 Слишком большая полезная нагрузка
6.5.12. 414 URI слишком длинный
6.5.13. 415 Неподдерживаемый тип носителя
6.5.14. 417 Ожидание не удалось
6.5.15. 426 Требуется обновление
6.6. Ошибка сервера 5xx
6.6.1. 500 Внутренняя ошибка сервера
6.6.2. 501 Не реализовано
6.6.3. 502 Неверный шлюз
6.6.4. 503 Сервис недоступен
6.6.5. 504 Время ответа сервера истекло
6.6.6. 505 Версия HTTP не поддерживается
7. Поля заголовка ответа
7.1. Control Data
7.1.1. Origination Date
7.1.1.1. Форматы Даты / Времени
7.1.1.2. Date
7.1.2. Location
7.1.3. Retry-After
7.1.4. Vary
7.2. Validator Header Fields
7.3. Authentication Challenges
7.4. Response Context
7.4.1. Allow
7.4.2. Server
8. Соображения IANA
8.1. Реестр методов
8.1.1. Процедура
8.1.2. Соображения по поводу новых методов
8.1.3. Регистрации
8.2. Реестр кодов состояния
8.2.1. Процедура
8.2.2. Соображения по новым кодам статуса
8.2.3. Регистрации
8.3. Реестр полей заголовка
8.3.1. Соображения для новых полей заголовка
8.3.2. Регистрации
8.4. Реестр кодирования контента
8.4.1. Процедура
8.4.2. Регистрации
9. Вопросы безопасности
9.1. Атаки на основе имен файлов и путей
9.2. Атаки на основе команды, кода или внедрения запроса
9.3. Раскрытие личной информации
9.4. Раскрытие конфиденциальной информации в URI
9.5. Раскрытие фрагмента после перенаправления
9.6. Раскрытие информации о продукте
9.7. Отпечатки пальцев в браузере
10. Благодарности
11. Ссылки
11.1. Нормативные ссылки
11.2. Информационные ссылки
Приложение А. Различия между HTTP и MIME
A.1. MIME-Version
А.2. Преобразование в каноническую форму
А.3. Преобразование форматов даты
А.4. Конвертация контент-кодирования
А.5. Преобразование Content-Transfer-Encoding
А.6. MHTML и ограничения длины строки
Приложение B. Изменения по сравнению с RFC 2616
Приложение C. Импортированный ABNF
Приложение D. Собранный ABNF
Индекс
Адреса авторов

1. Введение

Каждое сообщение протокола передачи гипертекста (HTTP) является либо запросом, либо ответом. Сервер прослушивает соединение для запроса, анализирует каждое полученное сообщение, интерпретирует семантику сообщения относительно идентифицированной цели запроса и отвечает на этот запрос одним или несколькими ответными сообщениями. Клиент создает сообщения запроса, чтобы сообщить конкретные намерения, анализирует полученные ответы, чтобы увидеть, были ли выполнены намерения, и определяет, как интерпретировать результаты. Этот документ определяет семантику запросов и ответов HTTP / 1.1 в терминах архитектуры, определенной в [RFC7230 #].

HTTP обеспечивает единый интерфейс для взаимодействия с ресурсом (раздел 2), независимо от его типа, характера или реализации, посредством манипулирования и передачи представлений (раздел 3).

Семантика HTTP включает намерения, определенные каждым методом запроса (раздел 4), расширения этой семантики, которые могут быть описаны в полях заголовка запроса (раздел 5), значение кодов состояния, указывающих машиночитаемый ответ (раздел 6), и значение других управляющих данных и метаданных ресурса, которые могут быть указаны в полях заголовка ответа (раздел 7).

Этот документ также определяет метаданные представления, которые описывают, как полезная нагрузка должна интерпретироваться получателем, поля заголовка запроса, которые могут влиять на выбор контента, и различные алгоритмы выбора, которые в совокупности называются «согласованием контента» (раздел 3.4).

1.1. Соответствие и обработка ошибок

Ключевые слова «ОБЯЗАН — MUST», «НЕ ОБЯЗАН — MUST NOT», «ТРЕБУЕТСЯ — REQUIRED», «ДОЛЖЕН — SHALL», «НЕ ДОЛЖЕН — SHALL NOT», «СЛЕДУЕТ — SHOULD», «НЕ СЛЕДУЕТ — SHOULD NOT», «РЕКОМЕНДУЕТСЯ — RECOMMENDED», «НЕ РЕКОМЕНДУЕТСЯ — NOT RECOMMENDED», «ВОЗМОЖЕН — MAY» и «ДОПОЛНИТЕЛЬНО — OPTIONAL» в этом документе интерпретироваться как описано в [RFC2119 #] [RFC8174 #].

Критерии соответствия и соображения, касающиеся обработки ошибок, определены в разделе 2.5 [RFC7230 #].

1.2. Синтаксическая нотация

В этой спецификации используется нотация расширенной формы Бэкуса-Наура (ABNF) в [RFC5234 #] с расширением списка, определенным в разделе 7 [RFC7230 #], который позволяет компактно определять списки, разделенные запятыми, используя оператор решётки «#» (аналогично как оператор звёздочки ‘*’ указывает на повторение). Приложение C описывает правила, импортированные из других документов. В приложении D показана собранная грамматика, в которой все операторы списка расширены до стандартной записи ABNF.

В этой спецификации используются термины «символ» (character), «схема кодирования символов» (character encoding scheme), «кодировка» (charset) и «элемент протокола» (protocol element), как они определены в [RFC6365 #].

2. Ресурсы

Цель HTTP-запроса называется «ресурсом» (resource). HTTP не ограничивает природу ресурса; он просто определяет интерфейс, который может использоваться для взаимодействия с ресурсами. Каждый ресурс идентифицируется унифицированным идентификатором ресурса (URI), как описано в разделе 2.7 [RFC7230 #].

Когда клиент создает сообщение запроса HTTP / 1.1, он отправляет целевой URI в одной из различных форм, как определено в (Раздел 5.3 [RFC7230 #]). Когда запрос получен, сервер восстанавливает эффективный URI запроса для целевого ресурса (раздел 5.5 [RFC7230 #]).

Одна из целей разработки HTTP состоит в том, чтобы отделить идентификацию ресурса от семантики запроса, что стало возможным благодаря передаче семантики запроса в методе запроса (раздел 4) и нескольких полей заголовка, изменяющих запрос (раздел 5). Если существует конфликт между семантикой метода и любой семантикой, подразумеваемой самим URI, как описано в Разделе 4.2.1, семантика метода имеет приоритет.

3. Представления

Учитывая, что ресурсом может быть все что угодно, и что унифицированный интерфейс, предоставляемый HTTP, подобен окну, через которое можно наблюдать и воздействовать на это только посредством передачи сообщений некоторому независимому субъекту на другой стороне, абстракция необходима для представления («занять место») текущего или желаемого состояния этой вещи в наших сообщениях. Эта абстракция называется представлением [REST].

Для целей HTTP «представление» (representation) — это информация, которая предназначена для отражения прошлого, текущего или желаемого состояния данного ресурса в формате, который может быть легко передан через протокол и который состоит из набора представления метаданных и потенциально неограниченного потока данных представления.

Исходный сервер может быть снабжен или способен генерировать несколько представлений, каждое из которых предназначено для отражения текущего состояния целевого ресурса. В таких случаях некоторый алгоритм используется сервером происхождения для выбора одного из этих представлений, как наиболее применимых к данному запросу, обычно на основе согласования контента. Это «выбранное представление» (selected representation) используется для предоставления данных и метаданных для оценки условных запросов [RFC7232 #] и построения полезной нагрузки для 200 (ОК) и 304 (Не изменено) ответов на GET (Раздел 4.3.1).

3.1. Метаданные представления

Поля заголовка представления предоставляют метаданные о представлении. Когда сообщение включает в себя тело полезной нагрузки, поля заголовка представления описывают, как интерпретировать данные представления, заключенные в теле полезной нагрузки. В ответ на запрос HEAD поля заголовка представления описывают данные представления, которые были бы включены в тело полезной нагрузки, если бы тот же запрос был GET.

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

Имя поля заголовкаОпределено в …
Content-TypeРаздел 3.1.1.5
Content-EncodingРаздел 3.1.2.2
Content-LanguageРаздел 3.1.3.2
Content-LocationРаздел 3.1.4.2

3.1.1. Обработка данных представления

3.1.1.1. Тип носителя

HTTP использует типы мультимедиа в Интернете [RFC2046 #] в полях заголовка «Content-Type» (раздел 3.1.1.5) и «Accept» (раздел 5.3.2), чтобы обеспечить открытую и расширяемую типизацию данных и согласование типов. Типы носителей определяют как формат данных, так и различные модели обработки: как обрабатывать эти данные в соответствии с каждым контекстом, в котором они получены.

media-type = type "/" subtype *( OWS ";" OWS parameter )
type = token
subtype = token

Тип/подтип МОГУТ сопровождаться параметрами в виде пар «имя=значение«.

parameter = token "=" ( token / quoted-string )

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

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

text/html;charset=utf-8
text/html;charset=UTF-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"

Типы интернет-медиа должны быть зарегистрированы в IANA в соответствии с процедурами, определенными в [BCP13].

Примечание. В отличие от некоторых аналогичных конструкций в других полях заголовка, параметры типа мультимедиа не допускают пробелов (даже «плохих» пробелов) вокруг символа равенства «=».

3.1.1.2. Кодировка

HTTP использует имена кодировок для указания или согласования схемы кодирования символов текстового представления [RFC6365 #]. Кодировка идентифицируется нечувствительным к регистру токеном.

charset = token

Имена кодировок должны быть зарегистрированы в реестре «Наборов символов» IANA (<http://www.iana.org/assignments/character-sets>) в соответствии с процедурами, определенными в [RFC2978 #].

3.1.1.3. Канонизация и текстовые настройки по умолчанию

Типы мультимедиа в Интернете регистрируются в канонической форме для обеспечения возможности взаимодействия между системами с различными собственными форматами кодирования. Представления, выбранные или переданные по протоколу HTTP, должны быть в канонической форме по многим из тех же причин, которые описаны в Многоцелевых расширениях почты Интернета (MIME — Multipurpose Internet Mail Extensions) [RFC2045 #]. Однако характеристики производительности развертываний электронной почты (то есть хранения и пересылки сообщений одноранговым узлам) значительно отличаются от общих для HTTP и Web (информационных служб на основе сервера). Более того, ограничения MIME для совместимости со старыми протоколами пересылки почты не применяются к HTTP (см. Приложение A).

Каноническая форма MIME требует, чтобы медиа-подтипы типа «text» использовали CRLF в качестве разрыва текстовой строки. HTTP позволяет передавать текстовые медиа с одним простым CR или LF, представляющим разрыв строки, когда такие разрывы строк согласованы для всего представления. Отправитель HTTP МОЖЕТ сгенерировать, и получатель ДОЛЖЕН иметь возможность анализировать разрывы строк в текстовом мультимедиа, которые состоят из CRLF, пустого CR или пустого LF. Кроме того, текстовые носители в HTTP не ограничиваются кодировками, которые используют октеты 13 и 10 для CR и LF соответственно. Эта гибкость в отношении разрывов строк применяется только к тексту в представлении, которому назначен тип носителя «text»; он не применяется к «multipart» типам или элементам HTTP вне тела полезной нагрузки (например, поля заголовка).

Если представление кодируется с помощью контент-кодирования, базовые данные должны быть в форме, определенной выше, перед кодированием.

3.1.1.4. Составные типы

MIME предусматривает несколько «multipart» типов — инкапсуляцию одного или нескольких представлений в одном теле сообщения. Все составные типы имеют общий синтаксис, как определено в разделе 5.1.1 [RFC2046 #], и включают граничный параметр как часть значения типа носителя. Тело сообщения само является элементом протокола; отправитель ДОЛЖЕН генерировать только CRLF для представления разрывов строк между частями тела.

При формировании сообщения HTTP не используется составная граница в качестве индикатора длины тела сообщения, хотя она может использоваться реализациями, которые генерируют или обрабатывают полезную нагрузку. Например, тип «multipart/form-data» часто используется для переноса данных формы в запросе, как описано в [RFC2388 #], а тип «multipart/byteranges» определяется этой спецификацией для использования в некоторых 206-ых ответах (частичных Содержание) [RFC7233 #].

3.1.1.5. Тип содержимого

Поле заголовка «Content-Type» указывает тип мультимедиа связанного представления: либо представление, заключенное в полезную нагрузку сообщения, либо выбранное представление, как определено семантикой сообщения. Указанный тип мультимедиа определяет как формат данных, так и то, как эти данные предназначены для обработки получателем в рамках семантики принятого сообщения после декодирования любых кодировок контента, указанных в Content-Encoding.

Content-Type = media-type

Типы носителей определены в разделе 3.1.1.1. Пример поля

Content-Type: text/html; charset=ISO-8859-4

Отправителю, который генерирует сообщение, содержащее тело полезной нагрузки, СЛЕДУЕТ генерировать поле заголовка Content-Type в этом сообщении, если только предполагаемый тип мультимедиа вложенного представления неизвестен отправителю. Если поле заголовка Content-Type отсутствует, получатель МОЖЕТ либо принять тип носителя «application/octet-stream» ([RFC2046 #], Раздел 4.5.1), либо проверить данные, чтобы определить его тип.

На практике владельцы ресурсов не всегда правильно настраивают свой исходный сервер для предоставления правильного Content-Type для данного представления, в результате чего некоторые клиенты проверяют содержимое полезной нагрузки и переопределяют указанный тип. Клиенты, которые так поступают, рискуют сделать неверные выводы, что может создать дополнительные риски для безопасности (например, «повышение привилегий» (privilege escalation)). Кроме того, невозможно определить намерение отправителя, изучив формат данных: многие форматы данных соответствуют нескольким типам мультимедиа, которые отличаются только семантикой обработки. Разработчикам рекомендуется предоставлять средства отключения такого «прослушивания контента» (content sniffing), когда он используется.

3.1.2. Кодировка для сжатия или целостности

3.1.2.1. Кодирование контента

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

content-coding = token

Все значения кодирования содержимого нечувствительны к регистру и должны быть зарегистрированы в «Реестре кодирования содержимого HTTP», как определено в разделе 8.4. Они используются в полях заголовка «Accept-Encoding» (раздел 5.3.4) и «Content-Encoding» (раздел 3.1.2.2).

Следующие значения кодирования содержимого определяются этой спецификацией:

compress (and x-compress): см. раздел 4.2.1 [RFC7230 #].

deflate: см. раздел 4.2.2 [RFC7230 #].

gzip (and x-gzip): См. Раздел 4.2.3 [RFC7230 #].

3.1.2.2. Content-Encoding

Поле заголовка «Content-Encoding» указывает, какие кодировки контента были применены к представлению, помимо тех, которые присущи типу медиа, и, таким образом, какие механизмы декодирования должны быть применены для получения данных в типе медиа, на который ссылается Content-Type поле заголовка. Content-Encoding в основном используется для сжатия данных представления без потери идентичности его основного типа носителя.

Content-Encoding = 1#content-coding

Примером его использования является

Content-Encoding: gzip

Если к представлению было применено одно или несколько кодировок, отправитель, применивший кодировки, ДОЛЖЕН создать поле заголовка «Content-Encoding», в котором перечислены кодировки содержимого в том порядке, в котором они были применены. Дополнительная информация о параметрах кодирования может быть предоставлена ​​другими полями заголовка, не определенными в этой спецификации.

В отличие от «Transfer-Encoding» (раздел 3.3.1 [RFC7230 #]), кодировки, перечисленные в «Content-Encoding», являются характеристикой представления; представление определяется в терминах закодированной формы, а все остальные метаданные о представлении относятся к кодированной форме, если иное не указано в определении метаданных. Как правило, представление декодируется только непосредственно перед рендерингом или аналогичным использованием.

Если тип мультимедиа включает в себя внутреннюю кодировку, такую ​​как формат данных, который всегда сжат, то эта кодировка не будет переустанавливаться в «Content-Encoding», даже если это тот же алгоритм, что и в одной из кодировок контента. Такое кодирование контента будет отображаться только в том случае, если по какой-то странной причине его применяют во второй раз для формирования представления. Аналогично, сервер-источник может выбрать публикацию одних и тех же данных в виде нескольких представлений, которые отличаются только тем, определена ли кодировка как часть «Content-Type» или «Content-Encoding», поскольку некоторые пользовательские агенты будут вести себя по-разному при обработке каждого ответа (например, откройте диалоговое окно «Сохранить как …» вместо автоматической распаковки и рендеринга содержимого).

Исходный сервер МОЖЕТ ответить кодом состояния 415 (неподдерживаемый тип носителя), если представление в сообщении запроса имеет неприемлемую кодировку контента.

3.1.3. Язык аудитории

3.1.3.1. Языковые теги

Языковой тег, как определено в [RFC5646 #], идентифицирует естественный язык, на котором говорят, пишут или иным образом передают люди для передачи информации другим людям. Компьютерные языки явно исключены.

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

language-tag = <Language-Tag, смотри [RFC5646 #], раздел 2.1>

Языковой тег — это последовательность из одного или нескольких нечувствительных к регистру подтегов, каждый из которых разделен дефисом («-»,% x2D). В большинстве случаев языковой тег состоит из основного языкового подтэга, который идентифицирует широкое семейство родственных языков (например, «en» = английский), за которым необязательно следует серия вложенных тегов, которые уточняют или сужают диапазон этого языка (например, «en-CA» = разновидность английского языка, как в Канаде). Пробелы запрещены внутри языкового тега. Примеры тегов включают в себя:

fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN

Смотри [RFC5646 #] для получения дополнительной информации.

3.1.3.2. Content-Language

Поле заголовка «Content-Language» описывает естественный язык (языки) целевой аудитории для представления. Обратите внимание, что это может быть не эквивалентно всем языкам, используемым в представлении.

Content-Language = 1#language-tag

Языковые теги определены в разделе 3.1.3.1. Основная цель Content-Language — позволить пользователю идентифицировать и дифференцировать представления в соответствии с предпочтительным языком пользователя. Таким образом, если контент предназначен только для датско-грамотной аудитории, соответствующее поле

Content-Language: da

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

Несколько языков МОГУТ быть перечислены для контента, который предназначен для нескольких аудиторий. Например, исполнение «Договора Вайтанги», представленное одновременно в оригинальной и маорийской версиях, потребовало бы

Content-Language: mi, en

Однако то, что в представлении присутствует несколько языков, не означает, что оно предназначено для нескольких языковых аудиторий. В качестве примера можно привести языковой учебник для начинающих, например «Первый урок латыни», который явно предназначен для англо-грамотной аудитории. В этом случае Content-Language будет правильно включать только «en».

Content-Language МОЖЕТ применяться к любому типу медиа — он не ограничивается текстовыми документами.

3.1.4. Удостоверение личности

3.1.4.1. Идентификация Представления

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

Для сообщения запроса:

  • Если запрос имеет поле заголовка Content-Location, то отправитель утверждает, что полезная нагрузка является представлением ресурса, идентифицируемого значением поля Content-Location. Однако такое утверждение не может быть доверенным, если оно не может быть проверено другими средствами (не определенными в данной спецификации). Информация все еще может быть полезна для ссылок истории изменений.
  • В противном случае полезная нагрузка не идентифицируется.

Для ответного сообщения применяются следующие правила по порядку, пока не будет найдено совпадение:

  1. Если метод запроса — GET или HEAD, а код состояния ответа — 200 (ОК), 204 (Нет содержимого), 206 (Частичное содержимое) или 304 (Не изменено), полезная нагрузка представляет собой представление ресурса, идентифицируемого URI действующего запроса (Раздел 5.5 [RFC7230 #]).
  2. Если метод запроса — GET или HEAD, а код состояния ответа — 203 (неавторизованная информация), полезная нагрузка представляет собой потенциально измененное или расширенное представление целевого ресурса, предоставляемое посредником.
  3. Если ответ имеет поле заголовка Content-Location и его значение поля является ссылкой на тот же URI, что и эффективный URI запроса, полезная нагрузка представляет собой представление ресурса, идентифицированного эффективным URI запроса.
  4. Если ответ имеет поле заголовка Content-Location и его значение поля является ссылкой на URI, отличный от действующего URI запроса, то отправитель утверждает, что полезная нагрузка является представлением ресурса, идентифицированного полем Content-Location -значение. Однако такое утверждение не может быть доверенным, если оно не может быть проверено другими средствами (не определенными в данной спецификации).
  5. В противном случае полезная нагрузка не идентифицируется.
3.1.4.2. Content-Location

Поле заголовка «Content-Location» ссылается на URI, который можно использовать в качестве идентификатора для конкретного ресурса, соответствующего представлению в полезной нагрузке этого сообщения. Другими словами, если кто-то должен выполнить запрос GET для этого URI во время генерации этого сообщения, тогда ответ 200 (ОК) будет содержать то же представление, которое заключено в полезную нагрузку в этом сообщении.

Content-Location = absolute-URI / partial-URI

Значение Content-Location не является заменой действующего URI запроса (раздел 5.5 [RFC7230 #]). Это метаданные представления. Он имеет тот же синтаксис и семантику, что и поле заголовка с тем же именем, определенное для частей тела MIME в Разделе 4 [RFC2557 #]. Однако его появление в сообщении HTTP имеет некоторые особые последствия для получателей HTTP.

Если Content-Location включен в ответное сообщение 2xx (Успешно) и его значение ссылается (после преобразования в абсолютную форму) на URI, который совпадает с действующим URI запроса, то получатель МОЖЕТ считать полезную нагрузку текущим представлением. этого ресурса во время, указанное в дате создания сообщения. Для запроса GET (раздел 4.3.1) или HEAD (раздел 4.3.2) это совпадает с семантикой по умолчанию, когда сервер не предоставляет Content-Location. Для запроса на изменение состояния, такого как PUT (раздел 4.3.4) или POST (раздел 4.3.3), это означает, что ответ сервера содержит новое представление этого ресурса, тем самым отличая его от представлений, которые могут сообщать только о действии ( например, «Это сработало!»). Это позволяет авторским приложениям обновлять свои локальные копии без необходимости последующего запроса GET.

Если Content-Location включен в ответное сообщение 2xx (Успешно) и его значение поля относится к URI, который отличается от действующего URI запроса, тогда сервер происхождения утверждает, что URI является идентификатором для другого ресурса, соответствующего вложенному представление. Такой заявке можно доверять только в том случае, если оба идентификатора совместно используют одного и того же владельца ресурса, который не может быть программно определен через HTTP.

  • Для ответа на запрос GET или HEAD это указывает на то, что эффективный URI запроса относится к ресурсу, который подлежит согласованию контента, а значение поля Content-Location является более конкретным идентификатором для выбранного представления.
  • Для ответа 201 (Создано) на метод изменения состояния значение поля Content-Location, которое идентично значению поля Location, указывает, что эта полезная нагрузка является текущим представлением вновь созданного ресурса.
  • В противном случае такое расположение содержимого указывает, что эта полезная нагрузка является отчетом о состоянии запрошенного действия и что этот же отчет доступен (для будущего доступа с GET) по данному URI. Например, транзакция покупки, выполненная с помощью запроса POST, может включать документ квитанции в качестве полезной нагрузки ответа 200 (ОК); значение поля Content-Location предоставляет идентификатор для получения копии той же квитанции в будущем.

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

Исходный сервер, который получает поле Content-Location в сообщении запроса, ДОЛЖЕН обрабатывать информацию как временный контекст запроса, а не как метаданные, которые дословно сохраняются как часть представления. Исходный сервер МОЖЕТ использовать этот контекст для руководства при обработке запроса или для сохранения его для других целей, таких как ссылки на источники или метаданные управления версиями. Однако сервер происхождения НЕ ДОЛЖЕН использовать такую ​​контекстную информацию для изменения семантики запроса.

Например, если клиент отправляет запрос PUT на согласованный ресурс, а исходный сервер принимает этот PUT (без перенаправления), то ожидается, что новое состояние этого ресурса будет соответствовать одному представлению, предоставленному в этом PUT; Content-Location не может использоваться как форма обратного идентификатора выбора контента для обновления только одного из согласованных представлений. Если бы пользовательский агент хотел использовать последнюю семантику, он бы применил PUT непосредственно к URI Content-Location.

3.2. Данные представления

Данные представления, связанные с сообщением HTTP, либо предоставляются в качестве тела полезной нагрузки сообщения, либо на них ссылаются семантика сообщения и действующий URI запроса. Данные представления имеют формат и кодировку, определенные полями заголовка метаданных представления.

Тип данных представления данных определяется через поля заголовка Content-Type и Content-Encoding. Они определяют двухслойную упорядоченную модель кодирования:

representation-data := Content-Encoding( Content-Type( bits ) )

3.3. Семантика полезной нагрузки

Некоторые HTTP-сообщения передают полное или частичное представление как сообщение «полезная нагрузка». В некоторых случаях полезная нагрузка может содержать только поля заголовка ассоциированного представления (например, ответы на HEAD) или только некоторую часть (и) данных представления (например, код состояния 206 (частичное содержимое)).

Назначение полезной нагрузки в запросе определяется семантикой метода. Например, представление в полезной нагрузке запроса PUT (раздел 4.3.4) представляет желаемое состояние целевого ресурса, если запрос успешно применяется, тогда как представление в полезной нагрузке запроса POST (раздел 4.3.3) представляет информация для обработки целевым ресурсом.

В ответе назначение полезной нагрузки определяется как методом запроса, так и кодом состояния ответа. Например, полезная нагрузка ответа 200 (OK) на GET (раздел 4.3.1) представляет текущее состояние целевого ресурса, наблюдаемое во время даты создания сообщения (раздел 7.1.1.2), тогда как полезная нагрузка один и тот же код состояния в ответе на POST может представлять либо результат обработки, либо новое состояние целевого ресурса после применения обработки. Ответные сообщения с кодом состояния ошибки обычно содержат полезную нагрузку, которая представляет состояние ошибки, так что она описывает состояние ошибки и какие дальнейшие шаги предлагаются для ее устранения.

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

Имя поля заголовкаОпределено в  …
Content-LengthРаздел 3.3.2 RFC 7230
Content-RangeРаздел 4.2 RFC 7233 #
TrailerРаздел 4.4 RFC 7230
Transfer-EncodingРаздел 3.3.1 RFC 7230

3.4. Согласование контента

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

Эта спецификация определяет два шаблона согласования контента, которые можно сделать видимыми в протоколе: «упреждающий», где сервер выбирает представление на основе заявленных предпочтений агента пользователя, и «реактивный» согласование, где сервер предоставляет список представлений для пользовательский агент на выбор. Другие шаблоны согласования содержимого включают в себя «условное содержимое», где представление состоит из множества частей, которые выборочно отображаются на основе параметров пользовательского агента, «активное содержимое», где представление содержит сценарий, который выполняет дополнительные (более конкретные) запросы на основе характеристики агента пользователя и «Согласование прозрачного контента» ([RFC2295 #]), где выбор контента выполняется посредником. Эти шаблоны не являются взаимоисключающими, и у каждого есть компромиссы в применимости и практичности.

Обратите внимание, что во всех случаях HTTP не знает о семантике ресурса. Непротиворечивость, с которой сервер происхождения отвечает на запросы, с течением времени и в течение различных измерений согласования контента, и, таким образом, «одинаковость» наблюдаемых представлений ресурса во времени, полностью определяется тем, какой объект или алгоритм выбирает или генерирует эти ответы. HTTP не обращает внимания на человека за кулисами.

3.4.1. Упреждающие переговоры

Когда предпочтения согласования контента отправляются пользовательским агентом в запросе, чтобы побудить алгоритм, расположенный на сервере, выбрать предпочтительное представление, это называется проактивным согласованием (например, согласование, управляемое сервером). Выбор основывается на доступных представлениях ответа (измерениях, в которых он может варьироваться, таких как язык, кодирование содержимого и т. Д.) По сравнению с различной информацией, представленной в запросе, включая как явные поля согласования в разделе 5.3, так и неявные характеристики, такие как сетевой адрес клиента или части поля User-Agent.

Упреждающее согласование выгодно, когда алгоритм выбора из доступных представлений трудно описать пользовательскому агенту, или когда сервер желает отправить свое «наилучшее предположение» пользовательскому агенту вместе с первым ответом (в надежде избежать раунда задержка отключения последующего запроса, если «наилучшее предположение» достаточно для пользователя). Чтобы улучшить предположение сервера, пользовательский агент МОЖЕТ отправить поля заголовка запроса, которые описывают его предпочтения.

Упреждающие переговоры имеют серьезные недостатки:

  • Для сервера невозможно точно определить, что может быть «лучшим» для любого данного пользователя, поскольку для этого потребуется полное знание как возможностей пользовательского агента, так и предполагаемого использования для ответа (например, хочет ли пользователь просмотреть его на экране или распечатать на бумаге?);
  • Предоставление агентом пользователя описания своих возможностей в каждом запросе может быть как очень неэффективным (учитывая, что только небольшой процент ответов имеет несколько представлений), так и потенциальным риском для конфиденциальности пользователя;
  • Усложняет реализацию исходного сервера и алгоритмов генерации ответов на запрос; а также,
  • Ограничивает возможность повторного использования ответов для общего кэширования.

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

Поле заголовка Vary (раздел 7.1.4) часто отправляется в ответе при условии проактивного согласования, чтобы указать, какие части информации запроса были использованы в алгоритме выбора.

3.4.2. Реактивные переговоры

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

Обратите внимание, что вышеизложенное относится к представлениям ответа, в общем, не к представлениям ресурса. Альтернативные представления считаются только представлениями целевого ресурса, если ответ, в котором предоставляются эти альтернативы, имеет семантику представления целевого ресурса (например, ответ 200 (ОК) на запрос GET) или имеет семантику предоставление ссылок на альтернативные представления для целевого ресурса (например, ответ 300 (множественный выбор) на запрос GET).

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

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

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

4. Методы запроса

4.1. Обзор

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

Семантика метода запроса может быть дополнительно специализирована семантикой некоторых полей заголовка, когда они присутствуют в запросе (раздел 5), если эта дополнительная семантика не конфликтует с методом. Например, клиент может отправить поля заголовка условного запроса (раздел 5.2), чтобы сделать запрошенное действие условным для текущего состояния целевого ресурса ([RFC7232 #]).

method = token

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

В отличие от распределенных объектов, стандартизированные методы запросов в HTTP не зависят от ресурсов, поскольку унифицированные интерфейсы обеспечивают лучшую видимость и повторное использование в сетевых системах [REST]. После определения стандартизированный метод должен иметь одинаковую семантику при применении к любому ресурсу, хотя каждый ресурс сам определяет, реализована ли эта семантика или разрешена.

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

МетодОписаниеРаздел
GETПередать текущее представление целевого ресурса. (Transfer a current representation of the target resource.)4.3.1
HEADТо же, что и GET, но только перенос строки состояния и раздела заголовка. (Same as GET, but only transfer the status line and header section.)4.3.2
POSTВыполните специфичную для ресурса обработку полезной нагрузки запроса. (Perform resource-specific processing on the request payload.)4.3.3
PUTЗамените все текущие представления целевого ресурса полезной нагрузкой запроса. (Replace all current representations of the target resource with the request payload.)4.3.4
DELETEУдалить все текущие представления целевого ресурса. (Remove all current representations of the target resource.)4.3.5
CONNECTУстановите туннель к серверу, указанному целевым ресурсом. (Establish a tunnel to the server identified by the target resource.)4.3.6
OPTIONSОпишите параметры связи для целевого ресурса. (Describe the communication options for the target resource.)4.3.7
TRACEВыполните проверку обратной связи по пути к целевому ресурсу. (Perform a message loop-back test along the path to the target resource.)4.3.8

Таблица

Все серверы общего назначения ДОЛЖНЫ поддерживать методы GET и HEAD. Все остальные методы НЕОБЯЗАТЕЛЬНЫ.

Дополнительные методы, выходящие за рамки данной спецификации, были стандартизированы для использования в HTTP. Все такие методы должны быть зарегистрированы в «Реестре методов протокола передачи гипертекста (HTTP)», который ведется IANA, как определено в разделе 8.1.

Набор методов, разрешенных целевым ресурсом, может быть указан в поле Разрешить заголовок (Раздел 7.4.1). Однако набор разрешенных методов может изменяться динамически. Когда получен метод запроса, который не распознан или не реализован сервером происхождения, сервер происхождения ДОЛЖЕН ответить кодом состояния 501 (Не реализовано). Когда получен метод запроса, который известен исходному серверу, но не разрешен для целевого ресурса, исходный сервер ДОЛЖЕН ответить кодом состояния 405 (метод не разрешен).

4.2. Общие свойства метода

4.2.1. Безопасные методы

Методы запроса считаются «safe» (безопасными), если их определенная семантика по существу доступна только для чтения; т.е. клиент не запрашивает и не ожидает какого-либо изменения состояния на исходном сервере в результате применения безопасного метода к целевому ресурсу. Кроме того, разумное использование безопасного метода не должно причинять вреда, потери имущества или необычного бремени на исходном сервере.

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

Из методов запроса, определенных в этой спецификации, методы GET, HEAD, OPTIONS и TRACE определены как безопасные.

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

Пользовательский агент ДОЛЖЕН различать безопасные и небезопасные методы при представлении потенциальных действий пользователю, так что пользователь может быть осведомлен о небезопасном действии до того, как оно будет запрошено.

Когда ресурс создается таким образом, что параметры в действующем URI запроса влияют на выбор действия, владелец ресурса несет ответственность за то, чтобы это действие соответствовало семантике метода запроса. Например, в программном обеспечении для редактирования контента в Интернете обычно используются действия в параметрах запроса, например «page?do=delete«. Если целью такого ресурса является выполнение небезопасного действия, то владелец ресурса ДОЛЖЕН отключить или запретить это действие, когда к нему обращаются с использованием безопасного метода запроса. Невыполнение этого требования приведет к нежелательным побочным эффектам, когда автоматизированные процессы выполняют GET для каждой ссылки на URI для обслуживания ссылок, предварительной выборки, построения поискового индекса и т. д.

4.2.2. Идемпотентные методы

Метод запроса считается «idempotent» (идемпотентным), если предполагаемое воздействие на сервер нескольких идентичных запросов с помощью этого метода такое же, как и эффект для одного такого запроса. Из методов запроса, определенных в этой спецификации, PUT, DELETE и безопасные методы запроса являются идемпотентными.

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

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

4.2.3. Кэшируемые методы

Методы запроса могут быть определены как «cacheable» (кэшируемые), чтобы указать, что ответы на них разрешено хранить для последующего повторного использования; конкретные требования см. в [RFC7234 #]. Как правило, безопасные методы, которые не зависят от текущего или авторитетного ответа, определяются как кешируемые; эта спецификация определяет GET, HEAD и POST как кешируемые, хотя подавляющее большинство реализаций кеша поддерживают только GET и HEAD.

4.3. Определения методов

4.3.1. GET

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

Соблазнительно думать об идентификаторах ресурсов как об именах путей удаленной файловой системы, а об представлениях — как о копии содержимого таких файлов. Фактически, это то, сколько ресурсов реализовано (см. Раздел 9.1 для соответствующих соображений безопасности). Однако на практике таких ограничений нет. Интерфейс HTTP для ресурса также может быть реализован в виде дерева объектов контента, программного представления различных записей базы данных или шлюза в другие информационные системы. Даже когда механизм сопоставления URI привязан к файловой системе, сервер происхождения может быть настроен на выполнение файлов с запросом в качестве входных данных и отправку выходных данных в виде представления, а не для прямой передачи файлов. В любом случае, только исходный сервер должен знать, как каждый из его идентификаторов ресурса соответствует реализации и как каждой реализации удается выбрать и отправить текущее представление целевого ресурса в ответ на GET.

Клиент может изменить семантику GET, чтобы он был «запросом диапазона», запрашивая передачу только некоторой части (частей) выбранного представления, отправляя поле заголовка Range в запросе ([RFC7233 #]).

Полезная нагрузка в сообщении запроса GET не имеет определенной семантики; отправка тела полезной нагрузки по запросу GET может привести к тому, что некоторые существующие реализации отклонят запрос.

Ответ на запрос GET кэшируется; кеш МОЖЕТ использовать его для удовлетворения последующих запросов GET и HEAD, если иное не указано в поле заголовка Cache-Control (раздел 5.2 [RFC7234 #]).

4.3.2. HEAD

Метод HEAD идентичен GET, за исключением того, что сервер НЕ ДОЛЖЕН отправлять тело сообщения в ответе (то есть ответ заканчивается в конце раздела заголовка). Сервер ДОЛЖЕН послать те же поля заголовка в ответ на запрос HEAD, что и отправил бы, если бы запрос был GET, за исключением того, что поля заголовка полезной нагрузки (раздел 3.3) МОГУТ быть опущены. Этот метод может использоваться для получения метаданных о выбранном представлении без передачи данных представления и часто используется для проверки гипертекстовых ссылок на достоверность, доступность и недавнюю модификацию.

Полезная нагрузка в сообщении запроса HEAD не имеет определенной семантики; отправка тела полезной нагрузки по запросу HEAD может привести к тому, что некоторые существующие реализации отклонят запрос.

Ответ на запрос HEAD кэшируется; кеш МОЖЕТ использовать его для удовлетворения последующих запросов HEAD, если иное не указано в поле заголовка Cache-Control (раздел 5.2 [RFC7234 #]). Ответ HEAD также может влиять на ранее кэшированные ответы на GET; см. раздел 4.3.5 [RFC7234 #].

4.3.3. POST

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

  • Предоставление блока данных, такого как поля, введенные в форму HTML, для процесса обработки данных;
  • размещение сообщения на доске объявлений, в группе новостей, списке рассылки, блоге или подобной группе статей;
  • Создание нового ресурса, который еще не идентифицирован исходным сервером; а также
  • Добавление данных к существующему представлению (ям) ресурса.

Исходный сервер указывает семантику ответа, выбирая соответствующий код состояния в зависимости от результата обработки запроса POST; почти все коды состояния, определенные в этой спецификации, могут быть получены в ответе на POST (исключая 206 (частичное содержимое), 304 (не изменено) и 416 (диапазон не удовлетворяется)).

Если один или несколько ресурсов были созданы на исходном сервере в результате успешной обработки запроса POST, исходный сервер ДОЛЖЕН отправить ответ 201 (Создан), содержащий поле заголовка Location, которое предоставляет идентификатор для созданного первичного ресурса (Раздел 7.1 .2) и представление, которое описывает состояние запроса при обращении к новому ресурсу (-ам).

Ответы на запросы POST кешируются только в том случае, если они содержат явную информацию о свежести (см. Раздел 4.2.1 [RFC7234 #]). Однако POST-кеширование широко не применяется. В случаях, когда исходный сервер желает, чтобы клиент мог кэшировать результат POST таким образом, который может быть повторно использован более поздним GET, исходный сервер МОЖЕТ отправить ответ 200 (ОК), содержащий результат и Content-Location поле заголовка, которое имеет то же значение, что и эффективный URI запроса POST (раздел 3.1.4.2).

Если результат обработки POST будет эквивалентен представлению существующего ресурса, сервер-источник МОЖЕТ перенаправить пользовательский агент на этот ресурс, отправив ответ 303 (см. Другие) с идентификатором существующего ресурса в поле Location. Это дает преимущества предоставления пользовательскому агенту идентификатора ресурса и передачи представления с помощью метода, более поддающегося совместному кэшированию, хотя за счет дополнительного запроса, если пользовательский агент еще не имеет кэшированное представление.

4.3.4. PUT

Метод PUT запрашивает, чтобы состояние целевого ресурса было создано или заменено на состояние, определенное представлением, заключенным в полезную нагрузку сообщения запроса. Успешное PUT данного представления предполагает, что последующее GET для того же целевого ресурса приведет к отправке эквивалентного представления в ответе 200 (ОК). Однако нет гарантии, что такое изменение состояния будет наблюдаемым, поскольку другие целевые ресурсы могут обрабатываться другими пользовательскими агентами параллельно или могут подвергаться динамической обработке исходным сервером до получения любого последующего GET. Успешный ответ подразумевает только то, что намерение агента пользователя было достигнуто во время его обработки сервером происхождения.

Если целевой ресурс не имеет текущего представления, и PUT успешно создает его, то сервер происхождения ДОЛЖЕН проинформировать пользовательский агент, отправив ответ 201 (Создано). Если целевой ресурс действительно имеет текущее представление, и это представление успешно изменено в соответствии с состоянием вложенного представления, то сервер происхождения ДОЛЖЕН отправить ответ 200 (ОК) или 204 (без содержимого), чтобы указать успешное завершение запрос.

Исходный сервер ДОЛЖЕН игнорировать нераспознанные поля заголовка, полученные в запросе PUT (то есть не сохранять их как часть состояния ресурса).

Исходный сервер ДОЛЖЕН проверить, что представление PUT соответствует любым ограничениям, которые имеет сервер для целевого ресурса, который не может или не будет изменен PUT. Это особенно важно, когда исходный сервер использует внутреннюю информацию о конфигурации, связанную с URI, чтобы установить значения для метаданных представления в ответах GET. Когда представление PUT несовместимо с целевым ресурсом, исходный сервер ДОЛЖЕН либо сделать их согласованными, преобразовав представление или изменив конфигурацию ресурса, либо ответить соответствующим сообщением об ошибке, содержащим достаточную информацию, чтобы объяснить, почему представление не подходит. Предлагаются коды состояния 409 (конфликт) или 415 (неподдерживаемый тип носителя), причем последний характерен для ограничений на значения типа содержимого.

Например, если целевой ресурс всегда настроен на использование Content-Type типа «text / html», а представление, представляющее собой PUT, имеет Content-Type типа «image / jpeg», исходный сервер должен выполнить одно из следующих действий:

  • а. перенастроить целевой ресурс для отражения нового типа носителя;
  • б. преобразовать представление PUT в формат, соответствующий формату ресурса, перед сохранением его в качестве нового состояния ресурса; или же,
  • в. отклоните запрос с ответом 415 (неподдерживаемый тип носителя), указывающим, что целевой ресурс ограничен «text / html», возможно, включающим ссылку на другой ресурс, который был бы подходящей целью для нового представления.

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

Исходный сервер НЕ ДОЛЖЕН отправлять поле заголовка валидатора (Раздел 7.2), такое как поле ETag или Last-Modified, в успешном ответе на PUT, если только данные представления запроса не были сохранены без какого-либо преобразования, примененного к телу (т. Е. Ресурса новые данные представления идентичны данным представления, полученным в запросе PUT), а значение поля валидатора отражает новое представление. Это требование позволяет агенту пользователя знать, когда тело представления, которое он имеет в памяти, остается текущим в результате PUT, таким образом, не нуждается в повторном извлечении с исходного сервера, и что новый валидатор (ы) получен в ответе. может использоваться для будущих условных запросов с целью предотвращения случайных перезаписей (раздел 5.2).

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

Правильная интерпретация запроса PUT предполагает, что пользовательский агент знает, какой целевой ресурс требуется. Служба, которая выбирает правильный URI от имени клиента, после получения запроса на изменение состояния ДОЛЖНА быть реализована с использованием метода POST, а не PUT. Если исходный сервер не будет вносить запрошенное изменение состояния PUT в целевой ресурс и вместо этого желает применить его к другому ресурсу, например, когда ресурс был перемещен в другой URI, то исходный сервер ДОЛЖЕН отправить соответствующий 3xx (Перенаправление) ответ; Затем пользовательский агент МОЖЕТ принять собственное решение относительно того, следует ли перенаправить запрос.

Запрос PUT, примененный к целевому ресурсу, может иметь побочные эффекты для других ресурсов. Например, статья может иметь URI для идентификации «текущей версии» (ресурса), который отделен от URI, идентифицирующих каждую конкретную версию (различные ресурсы, которые в какой-то момент находились в том же состоянии, что и ресурс текущей версии). Следовательно, успешный запрос PUT для URI «текущей версии» может создать ресурс новой версии в дополнение к изменению состояния целевого ресурса, а также может привести к добавлению ссылок между связанными ресурсами.

Сервер происхождения, который разрешает PUT для данного целевого ресурса, ДОЛЖЕН послать ответ 400 (неверный запрос) на запрос PUT, который содержит поле заголовка Content-Range (раздел 4.2 [RFC7233 #]), поскольку полезная нагрузка, вероятно, будет частичным содержимым это было по ошибке PUT как полное представление. Частичные обновления содержимого возможны путем нацеливания на отдельно идентифицированный ресурс с состоянием, которое перекрывает часть более крупного ресурса, или с использованием другого метода, который был специально определен для частичных обновлений (например, метод PATCH, определенный в [RFC5789 #]).

Ответы на метод PUT не кешируются. Если успешный запрос PUT проходит через кэш, который имеет один или несколько сохраненных ответов для эффективного URI запроса, эти сохраненные ответы будут признаны недействительными (см. Раздел 4.4 [RFC7234 #]).

4.3.5. DELETE

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

Если целевой ресурс имеет одно или несколько текущих представлений, они могут или не могут быть уничтожены исходным сервером, а связанное хранилище может или не может быть восстановлено, полностью в зависимости от природы ресурса и его реализации исходным сервером ( которые выходят за рамки данной спецификации). Аналогично, другие аспекты реализации ресурса, возможно, должны быть деактивированы или архивированы в результате УДАЛЕНИЯ, такие как соединения с базой данных или шлюзом. В общем, предполагается, что исходный сервер разрешит УДАЛИТЬ только для ресурсов, для которых у него есть предписанный механизм для выполнения удаления.

Относительно небольшое количество ресурсов позволяет метод DELETE — его основное использование для удаленных сред разработки, где у пользователя есть некоторое направление относительно его эффекта. Например, ресурс, который был ранее создан с использованием запроса PUT или идентифицирован в поле заголовка Location после ответа 201 (Создано) на запрос POST, может позволить соответствующему запросу DELETE отменить эти действия. Точно так же пользовательские реализации пользовательских агентов, которые реализуют функцию разработки, например клиенты управления версиями, использующие HTTP для удаленных операций, могут использовать DELETE, исходя из предположения, что пространство URI сервера было создано для соответствия хранилищу версий.

Если метод DELETE успешно применен, исходный сервер ДОЛЖЕН отправить код состояния 202 (Принят), если действие, скорее всего, выполнится успешно, но еще не было выполнено, и код состояния 204 (Нет содержимого), если действие было выполнено и больше не требуется. необходимо предоставить информацию или код состояния 200 (ОК), если действие было выполнено, и ответное сообщение включает в себя представление, описывающее состояние.

Полезная нагрузка в сообщении запроса DELETE не имеет определенной семантики; отправка тела полезной нагрузки по запросу DELETE может привести к тому, что некоторые существующие реализации отклонят запрос.

Ответы на метод DELETE не кэшируются. Если запрос DELETE проходит через кэш, который имеет один или несколько сохраненных ответов для эффективного URI запроса, эти сохраненные ответы будут признаны недействительными (см. Раздел 4.4 [RFC7234 #]).

4.3.6. CONNECT

Метод CONNECT запрашивает, чтобы получатель установил туннель к исходному серверу назначения, идентифицированному целью-запросом, и, в случае успеха, после этого ограничил свое поведение слепой пересылкой пакетов в обоих направлениях, пока туннель не будет закрыт. Туннели обычно используются для создания сквозного виртуального соединения через один или несколько прокси-серверов, которые затем могут быть защищены с помощью TLS (Transport Layer Security, [RFC5246 #]).

CONNECT предназначен только для использования в запросах к прокси. Исходный сервер, который получает запрос CONNECT для себя, МОЖЕТ ответить кодом статуса 2xx (Успешно), чтобы указать, что соединение установлено. Однако большинство исходных серверов не поддерживают CONNECT.

Клиент, отправляющий запрос CONNECT, ДОЛЖЕН отправить полномочную форму запроса-цели (раздел 5.3 [RFC7230 #]); то есть цель запроса состоит только из имени хоста и номера порта назначения туннеля, разделенных двоеточием. Например,

CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80

Прокси-получатель может установить туннель, либо напрямую подключившись к цели-запросу, либо, если он настроен на использование другого прокси-сервера, перенаправив запрос CONNECT на следующий входящий прокси-сервер. Любой ответ 2xx (Успешный) указывает, что отправитель (и все входящие прокси) переключится в туннельный режим сразу после пустой строки, которая завершает раздел заголовка успешного ответа; данные, полученные после этой пустой строки, поступают с сервера, идентифицированного объектом-запросом. Любой ответ, отличный от успешного ответа, указывает, что туннель еще не сформирован и что соединение остается управляемым HTTP.

Туннель закрывается, когда туннельный посредник обнаруживает, что одна из сторон закрыла свое соединение: посредник ДОЛЖЕН попытаться отправить все оставшиеся данные, которые пришли с закрытой стороны, на другую сторону, закрыть оба соединения, а затем отбросить все оставшиеся данные, оставленные недоставленными.

Прокси-аутентификация может использоваться для установления полномочий на создание туннеля. Например,

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

Существуют значительные риски при установке туннеля к произвольным серверам, особенно когда местом назначения является хорошо известный или зарезервированный порт TCP, который не предназначен для веб-трафика. Например, CONNECT для цели запроса «example.com:25» предполагает, что прокси-сервер подключается к зарезервированному порту для трафика SMTP; если позволено, это может обмануть прокси в пересылке спама. Прокси, поддерживающие CONNECT, ДОЛЖНЫ ограничивать его использование ограниченным набором известных портов или настраиваемым белым списком целевых объектов безопасного запроса.

Сервер НЕ ДОЛЖЕН отправлять поля заголовка Transfer-Encoding или Content-Length в ответе 2xx (успешно) на CONNECT. Клиент ДОЛЖЕН игнорировать любые поля заголовка Content-Length или Transfer-Encoding, полученные в успешном ответе на CONNECT.

Полезная нагрузка в сообщении запроса CONNECT не имеет определенной семантики; отправка тела полезной нагрузки по запросу CONNECT может привести к тому, что некоторые существующие реализации отклонят запрос.

Ответы на метод CONNECT не кэшируются.

4.3.7. OPTIONS

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

Запрос OPTIONS со звездочкой («*») в качестве цели запроса (раздел 5.3 [RFC7230 #]) применяется к серверу в целом, а не к конкретному ресурсу. Поскольку параметры связи сервера обычно зависят от ресурса, запрос «*» полезен только как метод «ping» или «no-op»; он не делает ничего, кроме того, что позволяет клиенту проверить возможности сервера. Например, это можно использовать для проверки прокси на соответствие HTTP / 1.1 (или его отсутствие).

Если цель запроса не является звездочкой, запрос OPTIONS применяется к параметрам, которые доступны при взаимодействии с целевым ресурсом.

Сервер, генерирующий успешный ответ на OPTIONS, ДОЛЖЕН послать любые поля заголовка, которые могут указывать дополнительные функции, реализованные сервером и применимые к целевому ресурсу (например, Allow), включая потенциальные расширения, не определенные в этой спецификации. Полезная нагрузка ответа, если таковая имеется, может также описывать параметры связи в машинном или машиночитаемом представлении. Стандартный формат для такого представления не определен этой спецификацией, но может быть определен будущими расширениями HTTP. Сервер ДОЛЖЕН генерировать поле Content-Length со значением «0», если в ответе не должно быть отправлено тело полезной нагрузки.

Клиент МОЖЕТ отправить поле заголовка Max-Forwards в запросе OPTIONS, чтобы указать конкретного получателя в цепочке запросов (см. Раздел 5.1.2). Прокси НЕ ДОЛЖЕН генерировать поле заголовка Max-Forwards при пересылке запроса, если только этот запрос не был получен с полем Max-Forwards.

Клиент, который генерирует запрос OPTIONS, содержащий тело полезной нагрузки, ДОЛЖЕН отправить действительное поле заголовка Content-Type, описывающее тип носителя представления. Хотя эта спецификация не определяет какого-либо использования для такой полезной нагрузки, будущие расширения HTTP могут использовать тело OPTIONS для выполнения более подробных запросов о целевом ресурсе.

Ответы на метод OPTIONS не кэшируются.

4.3.8. TRACE

Метод TRACE запрашивает удаленную обратную петлю сообщения запроса на уровне приложения. Конечный получатель запроса ДОЛЖЕН отражать полученное сообщение, исключая некоторые поля, описанные ниже, обратно клиенту как тело сообщения ответа 200 (ОК) с типом содержимого «message / http» (раздел 8.3.1 из [RFC7230 #]). Конечный получатель — это либо исходный сервер, либо первый сервер, получивший в запросе значение Max-Forwards, равное нулю (0) (раздел 5.1.2).

Клиент НЕ ДОЛЖЕН генерировать поля заголовка в запросе TRACE, содержащие конфиденциальные данные, которые могут быть раскрыты ответом. Например, было бы глупо, чтобы пользовательский агент отправлял сохраненные пользовательские учетные данные [RFC7235 #] или куки [RFC6265 #] в запросе TRACE. Конечный получатель запроса ДОЛЖЕН исключить любые поля заголовка запроса, которые могут содержать конфиденциальные данные, когда этот получатель создает тело ответа.

TRACE позволяет клиенту видеть, что получено на другом конце цепочки запросов, и использовать эти данные для тестирования или диагностической информации. Значение поля заголовка Via (раздел 5.7.1 [RFC7230 #]) представляет особый интерес, поскольку оно действует как трассировка цепочки запросов. Использование поля заголовка Max-Forwards позволяет клиенту ограничивать длину цепочки запросов, что полезно для проверки цепочки прокси-серверов, пересылающих сообщения в бесконечном цикле.

Клиент НЕ ДОЛЖЕН отправлять тело сообщения в запросе TRACE.

Ответы на метод TRACE не кэшируются.

5. Поля заголовка запроса

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

5.1. Controls

Элементы управления являются полями заголовка запроса, которые управляют конкретной обработкой запроса.

Имя поля заголовкаОпределено в  …
Cache-ControlРаздел 5.2 RFC 7234 #
ExpectРаздел 5.1.1
HostРаздел 5.4 RFC 7230
Max-ForwardsРаздел 5.1.2
PragmaРаздел 5.4 RFC 7234 #
RangeРаздел 3.1 RFC 7233 #
TEРаздел 4.3 RFC 7230

Таблица

5.1.1. Expect

Поле заголовка «Expect» в запросе указывает определенный набор поведений (ожиданий), которые должны поддерживаться сервером для правильной обработки этого запроса. Единственное такое ожидание, определенное в этой спецификации, это 100-продолжение.

Expect = "100-continue"

Значение поля Expect не зависит от регистра.

Сервер, который получает значение поля Expect, отличное от 100-continue, МОЖЕТ ответить кодом состояния 417 (Expectation Failed), чтобы указать, что неожиданное ожидание не может быть удовлетворено.

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

Например, запрос, который начинается с

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

позволяет исходному серверу немедленно ответить сообщением об ошибке, например 401 (неавторизовано) или 405 (метод не разрешен), прежде чем клиент начнет заполнять каналы ненужной передачей данных.

Требования к клиентам:

  • Клиент НЕ ДОЛЖЕН генерировать ожидание 100-продолжений в запросе, который не включает в себя тело сообщения.
  • Клиент, который будет ожидать ответа 100 (продолжение) перед отправкой тела сообщения запроса, ДОЛЖЕН отправить поле заголовка Expect, содержащее ожидание 100-продолжения.
  • Клиент, который отправляет ожидание 100-продолжений, не обязан ждать какого-то определенного промежутка времени; такой клиент МОЖЕТ приступить к отправке тела сообщения, даже если он еще не получил ответ. Кроме того, поскольку 100 (продолжение) ответов не могут быть отправлены через посредника HTTP / 1.0, такому клиенту НЕ СЛЕДУЕТ ждать в течение неопределенного периода времени перед отправкой тела сообщения.
  • Клиент, который получает код состояния 417 (ожидание не выполнен) в ответ на запрос, содержащий ожидание 100, ДОЛЖЕН повторить этот запрос без ожидания 100, поскольку ответ 417 просто указывает на то, что цепочка ответов не поддерживает ожидания ( например, он проходит через сервер HTTP / 1.0).

Требования к серверам:

  • Сервер, который получает ожидание 100-продолжений в запросе HTTP / 1.0, ДОЛЖЕН игнорировать это ожидание.
  • Сервер МОЖЕТ пропустить отправку ответа 100 (Продолжить), если он уже получил часть или все тело сообщения для соответствующего запроса, или если кадрирование указывает на отсутствие тела сообщения.
  • Сервер, который отправляет ответ 100 (Продолжить), ДОЛЖЕН, в конечном итоге, отправить окончательный код состояния, как только тело сообщения будет получено и обработано, если соединение преждевременно не закрыто.
  • Сервер, который отправляет окончательный код состояния перед прочтением всего тела сообщения, ДОЛЖЕН указать в этом ответе, намерен ли он закрыть соединение или продолжить чтение и отбрасывание сообщения запроса (см. раздел 6.6 [RFC7230 #]).

Исходный сервер ДОЛЖЕН, после получения строки запроса HTTP / 1.1 (или более поздней) и полного раздела заголовка, который содержит ожидание 100-продолжения и указывает, что тело сообщения запроса будет следовать, либо отправит немедленный ответ с окончательным кодом состояния, если этот статус можно определить, изучив только поля строки запроса и заголовка, или отправьте немедленный ответ 100 (Продолжить), чтобы побудить клиента отправить тело сообщения запроса. Исходный сервер НЕ ДОЛЖЕН ждать тела сообщения перед отправкой ответа 100 (Продолжить).

Прокси-сервер ДОЛЖЕН, после получения строки запроса HTTP / 1.1 (или более поздней) и полного раздела заголовка, который содержит ожидание 100-продолжения и указывает, что тело запроса будет следовать, либо отправьте немедленный ответ с окончательным кодом состояния, если этот статус можно определить, изучив только поля строки запроса и заголовка, или начать пересылку запроса на исходный сервер, отправив соответствующий раздел строки запроса и заголовка на следующий входящий сервер. Если прокси-сервер полагает (из конфигурации или из прошлого взаимодействия), что следующий входящий сервер поддерживает только HTTP / 1.0, прокси-сервер МОЖЕТ сгенерировать немедленный ответ 100 (Продолжить), чтобы побудить клиента начать отправку тела сообщения.

Примечание. Поле заголовка Expect было добавлено после первоначальной публикации HTTP / 1.1 [RFC2068 #] как средство запроса промежуточного ответа 100 (продолжение) и общий механизм указания расширений, которые необходимо понять. Однако механизм расширения не использовался клиентами, и многие серверы не выполняли обязательные для понимания требования, что делает механизм расширения бесполезным. В этой спецификации удален механизм расширения для упрощения определения и обработки 100-continue.

5.1.2. Max-Forwards

Поле заголовка «Max-Forwards» предоставляет механизм с методами запроса TRACE (раздел 4.3.8) и OPTIONS (раздел 4.3.7) для ограничения количества раз, когда запрос перенаправляется прокси-серверами. Это может быть полезно, когда клиент пытается отследить запрос, который, по-видимому, не выполняется или зацикливается в средней цепи.

Max-Forwards = 1*DIGIT

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

Каждый посредник, который получает запрос TRACE или OPTIONS, содержащий поле заголовка Max-Forwards, ДОЛЖЕН проверять и обновлять свое значение до пересылки запроса. Если полученное значение равно нулю (0), посредник НЕ ДОЛЖЕН пересылать запрос; вместо этого посредник ДОЛЖЕН ответить как конечный получатель. Если полученное значение Max-Forwards больше нуля, посредник ДОЛЖЕН сгенерировать обновленное поле Max-Forwards в перенаправленном сообщении со значением поля, которое является меньшим из a) полученного значения, уменьшенного на единицу (1) или b) максимальное поддерживаемое значение получателя для Max-Forwards.

Получатель МОЖЕТ игнорировать поле заголовка Max-Forwards, полученное с помощью любых других методов запроса.

5.2. Conditionals

Поля заголовка условного запроса HTTP [RFC7232 #] позволяют клиенту поместить предварительное условие в состояние целевого ресурса, так что действие, соответствующее семантике метода, не будет применено, если предварительное условие оценивается как ложное. Каждое предварительное условие, определенное в данной спецификации, состоит из сравнения набора валидаторов, полученных из предыдущих представлений целевого ресурса, с текущим состоянием валидаторов для выбранного представления (раздел 7.2). Следовательно, эти предварительные условия оценивают, изменилось ли состояние целевого ресурса с момента данного состояния, известного клиенту. Эффект такой оценки зависит от семантики метода и выбора условия, как определено в Разделе 5 [RFC7232 #].

Имя поля заголовкаОпределено в  …
If-MatchРаздел 3.1 RFC 7232 #
If-None-MatchРаздел 3.2 RFC 7232 #
If-Modified-SinceРаздел 3.3 RFC 7232 #
If-Unmodified-SinceРаздел 3.4 RFC 7232 #
If-RangeРаздел 3.2 RFC 7233 #

Таблица

5.3. Content Negotiation

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

Имя поля заголовкаОпределено в  …
AcceptРаздел 5.3.2
Accept-CharsetРаздел 5.3.3
Accept-EncodingРаздел 5.3.4
Accept-LanguageРаздел 5.3.5

Таблица

5.3.1. Quality Values

Многие из полей заголовка запроса для упреждающего согласования используют общий параметр с именем «q» (без учета регистра), чтобы назначить относительный «вес» предпочтению для этого ассоциированного вида контента. Этот вес называется «значением качества» (или «qvalue»), потому что одно и то же имя параметра часто используется в конфигурациях сервера, чтобы назначить вес относительному качеству различных представлений, которые могут быть выбраны для ресурса.

Вес нормализован к действительному числу в диапазоне от 0 до 1, где 0,001 является наименее предпочтительным, а 1 является наиболее предпочтительным; значение 0 означает «не приемлемо». Если параметр «q» отсутствует, вес по умолчанию равен 1.

weight = OWS ";" OWS "q=" qvalue
qvalue = ( "0" [ "." 0*3DIGIT ] ) / ( "1" [ "." 0*3("0") ] )

Отправитель qvalue НЕ ДОЛЖЕН генерировать более трех цифр после десятичной точки. Пользовательская конфигурация этих значений должна быть ограничена таким же образом.

5.3.2. Accept

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

Accept = #( media-range [ accept-params ] )
media-range = ( "*/*"
/ ( type "/" "*" )
/ ( type "/" subtype )
) *( OWS ";" OWS parameter )
accept-params = weight *( accept-ext )
accept-ext = OWS ";" OWS token [ "=" ( token / quoted-string ) ]

Символ звездочки «*» используется для группировки типов мультимедиа по диапазонам, где «* / *» обозначает все типы мультимедиа, а «тип / *» обозначает все подтипы этого типа. Диапазон медиа может включать в себя параметры типа медиа, которые применимы к этому диапазону.

За каждым диапазоном медиа может следовать ноль или более применимых параметров типа медиа (например, кодировка), необязательный параметр «q» для указания относительного веса (раздел 5.3.1), а затем ноль или более параметров расширения. Параметр «q» необходим, если присутствуют какие-либо расширения (accept-ext), поскольку он действует как разделитель между двумя наборами параметров.

Примечание. Использование имени параметра «q» для отделения параметров типа носителя от параметров расширения «Принять» связано с исторической практикой. Хотя это предотвращает использование любого параметра типа носителя с именем «q» с диапазоном носителей, такое событие считается маловероятным, учитывая отсутствие каких-либо параметров «q» в реестре типов носителей IANA и редкое использование любого типа носителя. параметры в Accept. Будущим типам мультимедиа не рекомендуется регистрировать любой параметр с именем «q».

Пример:

Accept: audio/*; q=0.2, audio/basic

интерпретируется как «Я предпочитаю аудио / базовый, но присылайте мне любой тип аудио, если он является лучшим из доступных после 80% снижения качества».

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

Более сложный пример

Accept: text/plain; q=0.5, text/html,
text/x-dvi; q=0.8, text/x-c

В устной форме это будет интерпретировано как «text / html и text / xc — одинаково предпочтительные типы носителей, но если они не существуют, отправьте представление text / x-dvi, а если его не существует, отправьте текст / простое представление «.

Диапазоны носителей могут быть переопределены более конкретными диапазонами носителей или определенными типами носителей. Если к данному типу применяется более одного диапазона носителей, приоритет имеет наиболее конкретная ссылка. Например,

Accept: text/*, text/plain, text/plain;format=flowed, */*

имеют следующий приоритет:

  1. text/plain;format=flowed
  2. text/plain
  3. text/*
  4. */*

Коэффициент качества типа носителя, связанный с данным типом, определяется путем нахождения диапазона носителей с наивысшим приоритетом, который соответствует типу. Например,

Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1,
text/html;level=2;q=0.4, */*;q=0.5

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

Тип носителя (Media Type)Значение качества (Quality Value)
text/html;level=11
text/html0.7
text/plain0.3
image/jpeg0.5
text/html;level=20.4
text/html;level=30.7

Таблица

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

5.3.3. Accept-Charset

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

Accept-Charset = 1#( ( charset / "*" ) [ weight ] )

Имена кодировок определены в разделе 3.1.1.2. Пользовательский агент МОЖЕТ связать значение качества с каждой кодировкой, чтобы указать относительное предпочтение пользователя для этой кодировки, как определено в Разделе 5.3.1. Примером является

Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

Специальное значение «*», если оно присутствует в поле «Accept-Charset», соответствует каждой кодировке, которая не упоминается в других местах в поле «Accept-Charset». Если в поле Accept-Charset нет «*», то любые наборы символов, явно не упомянутые в этом поле, считаются «неприемлемыми» для клиента.

Запрос без какого-либо поля заголовка Accept-Charset подразумевает, что пользовательский агент примет любую кодировку в ответ. Большинство пользовательских агентов общего назначения не отправляют Accept-Charset, если это специально не настроено для этого, поскольку подробный список поддерживаемых наборов символов облегчает серверу идентификацию личности по характеристикам запроса пользовательского агента (раздел 9.7).

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

5.3.4. Accept-Encoding

Поле заголовка «Accept-Encoding» может использоваться пользовательскими агентами для указания того, какие кодировки содержимого ответа (раздел 3.1.2.1) приемлемы в ответе. Токен «идентичность» используется в качестве синонима «без кодирования» для связи, когда кодирование не является предпочтительным.

Accept-Encoding = #( codings [ weight ] )
codings = content-coding / "identity" / "*"

Каждому значению кодирования МОЖЕТ быть присвоено соответствующее значение качества, представляющее предпочтение для этого кодирования, как определено в разделе 5.3.1. Символ звездочки «*» в поле Accept-Encoding соответствует любому доступному кодированию содержимого, явно не указанному в поле заголовка.

Например,

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0

Запрос без поля заголовка Accept-Encoding подразумевает, что пользовательский агент не имеет предпочтений относительно кодировок контента. Хотя это позволяет серверу использовать любое кодирование содержимого в ответе, это не означает, что пользовательский агент сможет правильно обрабатывать все кодировки.

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

  1. Если в запросе нет поля Accept-Encoding, любое кодирование контента считается приемлемым для пользовательского агента.
  2. Если представление не имеет кодирования содержимого, то оно является приемлемым по умолчанию, если только оно не исключено специально в поле Accept-Encoding с указанием либо «identity; q = 0», либо «*; q = 0» без более конкретной записи для « идентичность».
  3. Если кодирование контента представления является одним из кодировок контента, перечисленных в поле Accept-Encoding, то оно допустимо, если оно не сопровождается значением q, равным 0. (Как определено в разделе 5.3.1, значение q равно 0 означает «не приемлемо».)
  4. Если допустимы множественные кодировки контента, то предпочтительным является приемлемое кодирование контента с наибольшим ненулевым qvalue.

Поле заголовка Accept-Encoding с комбинированным значением поля, которое является пустым, подразумевает, что пользовательский агент не хочет никакого кодирования содержимого в ответ. Если в заголовке присутствует поле заголовка Accept-Encoding и ни одно из доступных представлений для ответа не имеет кодирования содержимого, которое указано в качестве приемлемого, серверу происхождения СЛЕДУЕТ отправить ответ без какого-либо кодирования содержимого.

Примечание. Большинство приложений HTTP / 1.0 не распознают и не подчиняются значениям q, связанным с кодировками содержимого. Это означает, что qvalues может не работать и не разрешается с x-gzip или x-compress.

5.3.5. Accept-Language

Поле заголовка «Accept-Language» может использоваться пользовательскими агентами для указания набора естественных языков, которые являются предпочтительными в ответе. Языковые теги определены в разделе 3.1.3.1.

Accept-Language = 1#( language-range [ weight ] )
language-range = <language-range, see [RFC4647 #], Section 2.1>

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

Accept-Language: da, en-gb;q=0.8, en;q=0.7

будет означать: «Я предпочитаю датский, но приму британский английский и другие типы английского».

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

Обратите внимание, что некоторые получатели рассматривают порядок, в котором языковые теги перечислены в качестве указания на нисходящий приоритет, особенно для тегов, которым назначены одинаковые значения качества (никакое значение не совпадает с q = 1). Однако на это поведение нельзя положиться. Для обеспечения согласованности и максимизации функциональной совместимости многие пользовательские агенты присваивают каждому языковому тегу уникальное значение качества, а также перечисляют их в порядке уменьшения качества. Дополнительное обсуждение списков приоритетов языка можно найти в Разделе 2.3 [RFC4647 #].

Для сопоставления в разделе 3 [RFC4647 #] определены несколько схем сопоставления. Реализации могут предложить наиболее подходящую схему соответствия для своих требований. Схема «Базовая фильтрация» ([RFC4647 #], раздел 3.3.1) идентична схеме сопоставления, которая была ранее определена для HTTP в разделе 14.4 [RFC2616 #].

Это может противоречить ожиданиям конфиденциальности пользователя при отправке поля заголовка Accept-Language с полными лингвистическими предпочтениями пользователя в каждом запросе (раздел 9.7).

Поскольку разборчивость в значительной степени зависит от отдельного пользователя, пользовательские агенты должны позволять пользователю контролировать языковые предпочтения (либо путем настройки самого пользовательского агента, либо путем установки по умолчанию управляемой пользователем настройки системы). Пользовательский агент, который не предоставляет такого контроля пользователю, НЕ ДОЛЖЕН отправлять поле заголовка Accept-Language.

Примечание. Пользовательские агенты должны предоставлять рекомендации пользователям при настройке предпочтений, поскольку пользователи редко знакомы с деталями соответствия языков, как описано выше. Например, пользователи могут предположить, что при выборе «en-gb» им будет предоставлен любой документ на английском языке, если британский английский недоступен. Пользовательский агент может предложить, в таком случае, добавить «en» в список для лучшего соответствия поведения.

5.4. Authentication Credentials

Два поля заголовка используются для переноса учетных данных аутентификации, как определено в [RFC7235 #]. Обратите внимание, что различные пользовательские механизмы для аутентификации пользователя используют поле заголовка Cookie для этой цели, как определено в [RFC6265 #].

Имя поля заголовкаОпределено в …
AuthorizationРаздел 4.2 RFC 7235 #
Proxy-AuthorizationРаздел 4.4 RFC 7235 #

Таблица

5.5. Request Context

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

Имя поля заголовкаОпределено в …
FromРаздел 5.5.1
RefererРаздел 5.5.2
User-AgentРаздел 5.5.3

Таблица

5.5.1. From

Поле заголовка «От» содержит адрес электронной почты в Интернете для пользователя-пользователя, который управляет запрашивающим пользовательским агентом. Адрес должен быть машинно-используемым, как определено в «почтовом ящике» в разделе 3.4 [RFC5322 #]:

From = mailbox
mailbox = <mailbox, see [RFC5322 #], Раздел 3.4>

Примером является:

From: webmaster@example.org

Поле заголовка From редко отправляется не роботизированными пользовательскими агентами. Пользовательский агент НЕ ДОЛЖЕН отправлять поле заголовка From без явной настройки пользователем, поскольку это может противоречить интересам пользователя в отношении конфиденциальности или политике безопасности их сайта.

Пользовательский агент-робот ДОЛЖЕН отправить действительное поле заголовка From, чтобы можно было связаться с лицом, ответственным за запуск робота, в случае возникновения проблем на серверах, например, если робот отправляет чрезмерные, нежелательные или недействительные запросы.

Серверу НЕ СЛЕДУЕТ использовать поле заголовка From для контроля доступа или аутентификации, так как большинство получателей будут считать, что значение поля является публичной информацией.

5.5.2. Referer

Поле заголовка «Referer» [sic] позволяет агенту пользователя указать ссылку на URI для ресурса, из которого был получен целевой URI (т. Е. «Referrer», хотя имя поля написано с ошибкой). Пользовательский агент НЕ ДОЛЖЕН включать фрагменты и компоненты userinfo ссылки URI [RFC3986 #], если таковые имеются, при генерации значения поля Referer.

Referer = absolute-URI / partial-URI

Поле заголовка Referer позволяет серверам создавать обратные ссылки на другие ресурсы для простой аналитики, ведения журналов, оптимизированного кэширования и т. Д. Оно также позволяет находить устаревшие или опечатки для технического обслуживания. Некоторые серверы используют поле заголовка Referer как средство запрета ссылок с других сайтов (так называемые «глубокие ссылки») или ограничения подделки межсайтовых запросов (CSRF), но не все запросы содержат его.

Пример:

Referer: http://www.example.org/hypertext/Overview.html

Если целевой URI был получен из источника, который не имеет своего собственного URI (например, ввод с клавиатуры пользователя или запись в закладках / избранных пользователя), пользовательский агент ДОЛЖЕН либо исключить поле Referer, либо отправить его с значение «about: blank».

Поле Referer может раскрыть информацию о контексте запроса или истории просмотра пользователя, что является проблемой конфиденциальности, если идентификатор ссылающегося ресурса раскрывает личную информацию (например, имя учетной записи) или ресурс, который должен быть конфиденциальным ( например, за брандмауэром или внутри защищенной службы). Большинство пользовательских агентов общего назначения не отправляют поле заголовка Referer, когда ссылающийся ресурс является локальным URI «файл» или «данные». Пользовательский агент НЕ ДОЛЖЕН отправлять поле заголовка Referer в незащищенном HTTP-запросе, если ссылающаяся страница была получена по безопасному протоколу. См. Раздел 9.4 для дополнительных соображений безопасности.

Известно, что некоторые посредники без разбора удаляют поля заголовков Referer из исходящих запросов. Это имеет неприятный побочный эффект — мешает защите от CSRF-атак, которые могут быть гораздо более вредными для их пользователей. Посредники и расширения пользовательских агентов, которые хотят ограничить раскрытие информации в Referer, должны ограничивать свои изменения конкретными изменениями, такими как замена внутренних доменных имен псевдонимами или усечение компонентов запроса и / или пути. Посреднику НЕ СЛЕДУЕТ изменять или удалять поле заголовка Referer, если значение поля использует ту же схему и хост, что и цель запроса.

5.5.3. User-Agent

Поле заголовка «Пользователь-агент» содержит информацию о пользовательском агенте, инициирующем запрос, который часто используется серверами, чтобы помочь определить объем сообщаемых проблем взаимодействия, обойти или адаптировать ответы, чтобы избежать определенных ограничений пользовательского агента, и для аналитики. относительно использования браузера или операционной системы. Пользовательский агент ДОЛЖЕН отправлять поле User-Agent в каждом запросе, если специально не настроено не делать этого.

User-Agent = product *( RWS ( product / comment ) )

Значение поля User-Agent состоит из одного или нескольких идентификаторов продукта, за которыми следуют ноль или более комментариев (Раздел 3.2 [RFC7230 #]), которые вместе идентифицируют программное обеспечение агента пользователя и его важные подпродукты. По соглашению идентификаторы продукта перечислены в порядке убывания их значимости для идентификации программного обеспечения агента пользователя. Каждый идентификатор продукта состоит из имени и необязательной версии.

product = token ["/" product-version]
product-version = token

Отправителю СЛЕДУЕТ ограничить сгенерированные идентификаторы продукта тем, что необходимо для идентификации продукта; отправитель НЕ ДОЛЖЕН генерировать рекламную или другую несущественную информацию в рамках идентификатора продукта. Отправителю НЕ СЛЕДУЕТ генерировать информацию о версии продукта, которая не является идентификатором версии (т. Е. Последовательные версии одного и того же названия продукта должны отличаться только в части продукта-версии идентификатора продукта).

Пример:

User-Agent: CERN-LineMode/2.15 libwww/2.17b3

Пользовательский агент НЕ ДОЛЖЕН генерировать поле User-Agent, содержащее ненужные мелкие детали, и СЛЕДУЕТ ограничивать добавление субпродуктов третьими лицами. Слишком длинные и подробные значения полей User-Agent увеличивают задержку запросов и риск того, что пользователь будет идентифицирован против их пожеланий («дактилоскопия»).

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

6. Коды состояния ответа

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

Коды состояния HTTP расширяемы. HTTP-клиенты не обязаны понимать значение всех зарегистрированных кодов состояния, хотя такое понимание, очевидно, желательно. Однако клиент ДОЛЖЕН понимать класс любого кода состояния, как указано первой цифрой, и обрабатывать нераспознанный код состояния как эквивалентный коду состояния x00 этого класса, за исключением того, что получатель НЕ ДОЛЖЕН кэшировать ответ с помощью нераспознанный код состояния.

Например, если клиент получил нераспознанный код состояния 471, клиент может предположить, что с его запросом что-то не так, и обработать ответ так, как если бы он получил код состояния 400 (неправильный запрос). Ответное сообщение обычно будет содержать представление, объясняющее статус.

Первая цифра кода состояния определяет класс ответа. Последние две цифры не имеют никакой роли категоризации. Для первой цифры есть пять значений:

  • 1xx (информационный): запрос получен, процесс продолжается
  • 2xx (успешно): запрос был успешно получен, понят и принят
  • 3xx (перенаправление): для выполнения запроса необходимо предпринять дальнейшие действия
  • 4xx (ошибка клиента): запрос содержит неверный синтаксис или не может быть выполнен
  • 5xx (ошибка сервера): серверу не удалось выполнить явно допустимый запрос

6.1. Обзор кодов состояния

Коды состояния, перечисленные ниже, определены в этой спецификации, Раздел 4 [RFC7232 #], Раздел 4 [RFC7233 #] и Раздел 3 [RFC7235 #]. Приведенные здесь фразы-причины являются лишь рекомендациями — их можно заменить локальными эквивалентами, не влияя на протокол.

Ответы с кодами состояния, которые по умолчанию определены как кешируемые (например, 200, 203, 204, 206, 300, 301, 404, 405, 410, 414 и 501 в этой спецификации), могут повторно использоваться кешем с эвристическим истечением, если только иное указывается в определении метода или в явном контроле кэша [RFC7234 #]; все остальные коды состояния по умолчанию не кэшируются.

Код (Code)Фраза причины (Reason-Phrase)Определено в …
100ContinueРаздел 6.2.1
101Switching ProtocolsРаздел 6.2.2
200OKРаздел 6.3.1
201CreatedРаздел 6.3.2
202AcceptedРаздел 6.3.3
203Non-Authoritative InformationРаздел 6.3.4
204No ContentРаздел 6.3.5
205Reset ContentРаздел 6.3.6
206Partial ContentРаздел 4.1 из RFC 7233 #
300Multiple ChoicesРаздел 6.4.1
301Moved PermanentlyРаздел 6.4.2
302FoundРаздел 6.4.3
303See OtherРаздел 6.4.4
304Not ModifiedРаздел 4.1 из RFC 7232 #
305Use ProxyРаздел 6.4.5
307Temporary RedirectРаздел 6.4.7
400Bad RequestРаздел 6.5.1
401UnauthorizedРаздел 3.1 из RFC 7235 #
402Payment RequiredРаздел 6.5.2
403ForbiddenРаздел 6.5.3
404Not FoundРаздел 6.5.4
405Method Not AllowedРаздел 6.5.5
406Not AcceptableРаздел 6.5.6
407Proxy Authentication RequiredРаздел 3.2 из RFC 7235 #
408Request TimeoutРаздел 6.5.7
409ConflictРаздел 6.5.8
410GoneРаздел 6.5.9
411Length RequiredРаздел 6.5.10
412Precondition FailedРаздел 4.2 из RFC 7232 #
413Payload Too LargeРаздел 6.5.11
414URI Too LongРаздел 6.5.12
415Unsupported Media TypeРаздел 6.5.13
416Range Not SatisfiableРаздел 4.4 из RFC 7233 #
417Expectation FailedРаздел 6.5.14
426Upgrade RequiredРаздел 6.5.15
500Internal Server ErrorРаздел 6.6.1
501Not ImplementedРаздел 6.6.2
502Bad GatewayРаздел 6.6.3
503Service UnavailableРаздел 6.6.4
504Gateway TimeoutРаздел 6.6.5
505HTTP Version Not SupportedРаздел 6.6.6

Таблица

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

6.2. Информационные 1xx

Класс кода состояния 1xx (информационный) указывает промежуточный ответ для сообщения о состоянии соединения или выполнения запроса до завершения запрошенного действия и отправки окончательного ответа. Ответы 1xx завершаются первой пустой строкой после строки состояния (пустой строкой, обозначающей конец раздела заголовка). Поскольку HTTP / 1.0 не определял никаких кодов состояния 1xx, сервер НЕ ДОЛЖЕН отправлять ответ 1xx клиенту HTTP / 1.0.

Клиент ДОЛЖЕН иметь возможность анализировать один или несколько ответов 1xx, полученных до окончательного ответа, даже если клиент не ожидает их получения. Пользовательский агент МОЖЕТ игнорировать неожиданные ответы 1xx.

Прокси-сервер ДОЛЖЕН пересылать ответы 1xx, если только прокси-сервер сам не запросил генерацию ответа 1xx. Например, если прокси-сервер добавляет поле «Expect: 100-continue» при пересылке запроса, ему не нужно пересылать соответствующий ответ 100 (Continue).

6.2.1. 100 — Continue (Продолжать)

Код состояния 100 (Продолжить) указывает, что начальная часть запроса была получена и еще не была отклонена сервером. Сервер намеревается отправить окончательный ответ после того, как запрос будет полностью получен и обработан.

Когда запрос содержит поле заголовка Expect, которое включает ожидание продолжения 100, ответ 100 указывает, что сервер желает получить тело полезной нагрузки запроса, как описано в разделе 5.1.1. Клиент должен продолжить отправку запроса и отменить ответ 100.

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

6.2.2. 101 — Switching Protocols (Протокол переключения)

Код состояния 101 (Switching Protocols) указывает, что сервер понимает и готов выполнить запрос клиента через поле заголовка Upgrade (раздел 6.7 [RFC7230 #]) для изменения протокола приложения, используемого в этом соединении. Сервер ДОЛЖЕН генерировать поле заголовка Upgrade в ответе, которое указывает, какой протокол (ы) будет переключен сразу после пустой строки, которая завершает ответ 101.

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

6.3. Успешные 2xx

Класс статуса 2xx (Успешно) указывает, что запрос клиента был успешно получен, понят и принят.

6.3.1. 200 — ОК (Хорошо)

Код состояния 200 (ОК) указывает, что запрос выполнен успешно. Полезная нагрузка, отправленная в ответе 200, зависит от метода запроса. Для методов, определенных в этой спецификации, предполагаемое значение полезной нагрузки может быть суммировано как:

  • GET — представление целевого ресурса;
  • HEAD то же представление, что и GET, но без данных представления;
  • POST представление статуса или результатов, полученных от действия;
  • PUT, DELETE представление статуса действия;
  • OPTIONS — представление параметров связи;
  • TRACE — представление сообщения запроса, полученного конечным сервером.

Помимо ответов на CONNECT, ответ 200 всегда имеет полезную нагрузку, хотя исходный сервер МОЖЕТ генерировать тело полезной нагрузки нулевой длины. Если полезная нагрузка не требуется, исходный сервер должен вместо этого отправить 204 (без содержимого). Для CONNECT полезная нагрузка не допускается, поскольку успешным результатом является туннель, который начинается сразу после раздела заголовка ответа 200.

Ответ 200 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.3.2. 201 — Created (Создано)

Код состояния 201 (Создан) указывает, что запрос был выполнен и привел к созданию одного или нескольких новых ресурсов. Основной ресурс, созданный запросом, идентифицируется либо полем заголовка Location в ответе, либо, если поле Location не получено, эффективным URI запроса.

Полезная нагрузка 201 ответа обычно описывает и ссылается на созданный ресурс (ы). См. Раздел 7.2 для обсуждения значения и назначения полей заголовка валидатора, таких как ETag и Last-Modified, в ответе 201.

6.3.3. 202 — Accepted (Принято)

Код состояния 202 (Принят) указывает, что запрос был принят для обработки, но обработка не была завершена. Запрос может или не может в конечном итоге быть обработан, так как он может быть отклонен, когда обработка действительно имеет место. В HTTP нет средства для повторной отправки кода состояния из асинхронной операции.

Ответ 202 намеренно не является обязательным. Его цель — позволить серверу принять запрос для какого-либо другого процесса (возможно, пакетно-ориентированного процесса, который выполняется только один раз в день), не требуя, чтобы соединение пользовательского агента с сервером сохранялось до завершения процесса. Представление, отправленное с этим ответом, должно описать текущее состояние запроса и указать (или встроить) монитор состояния, который может предоставить пользователю оценку того, когда запрос будет выполнен.

6.3.4. 203 — Non-Authoritative Information (Неофициальная информация)

Код состояния 203 (неавторизованная информация) указывает, что запрос был успешным, но вложенная полезная нагрузка была изменена по сравнению с ответом исходного сервера 200 (OK) с помощью преобразовывающего прокси-сервера (раздел 5.7.2 [RFC7230 #]). Этот код состояния позволяет прокси-серверу уведомлять получателей о применении преобразования, поскольку эти знания могут повлиять на последующие решения относительно содержимого. Например, будущие запросы проверки кэша для контента могут быть применимы только по одному и тому же пути запроса (через те же прокси-серверы).

Ответ 203 аналогичен коду предупреждения 214 «Преобразование применено» (раздел 5.5 [RFC7234 #]), который имеет преимущество в том, что он применим к ответам с любым кодом состояния.

Ответ 203 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.3.5. 204 — No Content (Нет содержимого)

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

Например, если код состояния 204 получен в ответ на запрос PUT, и ответ содержит поле заголовка ETag, тогда PUT прошел успешно, а значение поля ETag содержит тег объекта для нового представления этого целевого ресурса.

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

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

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

Ответ 204 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.3.6. 205 — Reset Content (Сбросить содержимое)

Код состояния 205 (Reset Content) указывает, что сервер выполнил запрос, и желает, чтобы пользовательский агент сбросил «представление документа», из-за которого был отправлен запрос, в исходное состояние, полученное с сервера-источника.

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

Поскольку код состояния 205 подразумевает, что дополнительный контент не будет предоставлен, сервер НЕ ДОЛЖЕН генерировать полезную нагрузку в ответе 205. Другими словами, сервер ДОЛЖЕН выполнить одно из следующих действий для ответа 205: a) указать тело нулевой длины для ответа, включив поле заголовка Content-Length со значением 0; b) указать полезную нагрузку нулевой длины для ответа путем включения поля заголовка Transfer-Encoding со значением chunked и тела сообщения, состоящего из одного фрагмента нулевой длины; или c) закрыть соединение сразу после отправки пустой строки, завершающей раздел заголовка.

6.4. Перенаправление 3xx

Класс кода состояния 3xx (Redirection) указывает, что пользовательский агент должен предпринять дальнейшие действия для выполнения запроса. Если предусмотрено поле заголовка Location (раздел 7.1.2), пользовательский агент МОЖЕТ автоматически перенаправить свой запрос на URI, на который ссылается значение поля Location, даже если конкретный код состояния не понят. Автоматическое перенаправление необходимо выполнять с осторожностью для методов, которые, как известно, не являются безопасными, как определено в разделе 4.2.1, поскольку пользователь может не захотеть перенаправлять небезопасный запрос.

Существует несколько типов перенаправлений:

  1. Перенаправления, которые указывают, что ресурс может быть доступен по другому URI, как предусмотрено в поле «Местоположение», как, например, в кодах состояния 301 (Постоянно перемещено), 302 (найдено) и 307 (Временное перенаправление).
  2. Перенаправление, которое предлагает выбор подходящих ресурсов, каждый из которых способен представлять исходную цель запроса, как в коде состояния 300 (множественный выбор).
  3. Перенаправление на другой ресурс, указанный в поле «Местоположение», который может представлять косвенный ответ на запрос, как в коде состояния 303 (см. «Другое»).
  4. Перенаправление на ранее кэшированный результат, как в коде состояния 304 (не изменен).

Примечание. В HTTP / 1.0 коды статуса 301 (постоянно перемещены) и 302 (найдено) были определены для первого типа перенаправления ([RFC1945 #], раздел 9.3). Ранние пользовательские агенты разделяют, будет ли метод, примененный к цели перенаправления, таким же, как исходный запрос, или будет переписан как GET. Хотя HTTP первоначально определял прежнюю семантику для 301 и 302 (чтобы соответствовать своей первоначальной реализации в CERN) и определял 303 (см. Раздел Другое) для соответствия последней семантике, преобладающая практика постепенно сходилась и к последней семантике для 301 и 302. Первая версия HTTP / 1.1 добавила 307 (временное перенаправление), чтобы указать прежнюю семантику без влияния расходящейся практики. Более 10 лет спустя большинство пользовательских агентов все еще переписывают методы для 301 и 302; следовательно, эта спецификация делает это поведение соответствующим, когда исходный запрос является POST.

Клиент ДОЛЖЕН обнаруживать циклические перенаправления и вмешиваться в них (то есть «бесконечные» циклы перенаправления).

Примечание. В более ранней версии этой спецификации рекомендовалось не более пяти перенаправлений ([RFC2068 #], раздел 10.3). Разработчики контента должны знать, что некоторые клиенты могут применять такое фиксированное ограничение.

6.4.1. 300 — Multiple Choices (Множественные варианты)

Код состояния 300 (множественный выбор) указывает, что целевой ресурс имеет более одного представления, каждое со своим более конкретным идентификатором, и предоставляется информация об альтернативах, чтобы пользователь (или пользовательский агент) мог выбрать предпочтительное представление посредством перенаправить его запрос на один или несколько из этих идентификаторов. Другими словами, сервер желает, чтобы пользовательский агент участвовал в реактивных переговорах, чтобы выбрать наиболее подходящее представление (я) для своих нужд (раздел 3.4).

Если у сервера есть предпочтительный выбор, серверу СЛЕДУЕТ генерировать поле заголовка Location, содержащее ссылку URI предпочтительного выбора. Пользовательский агент МОЖЕТ использовать значение поля Location для автоматического перенаправления.

Для методов запроса, отличных от HEAD, сервер ДОЛЖЕН генерировать полезную нагрузку в ответе 300, содержащем список метаданных представления и ссылки (я) URI, из которых пользователь или пользовательский агент может выбрать наиболее предпочтительный. Пользовательский агент МОЖЕТ сделать выбор из этого списка автоматически, если он понимает предоставленный тип носителя. Конкретный формат для автоматического выбора не определен этой спецификацией, потому что HTTP пытается оставаться ортогональным к определению его полезных нагрузок. На практике представление предоставляется в некотором легко анализируемом формате, который считается приемлемым для пользовательского агента, как определено общим дизайном или согласованием контента, или в некотором общепринятом гипертекстовом формате.

Ответ 300 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

Примечание. Исходное предложение для кода состояния 300 определило поле заголовка URI как обеспечивающее список альтернативных представлений, так что оно могло бы использоваться для ответов 200, 300 и 406 и передаваться в ответах на метод HEAD. Однако отсутствие развертывания и разногласия по поводу синтаксиса привели к тому, что и URI, и Alternates (последующее предложение) были исключены из этой спецификации. Можно связать список, используя набор полей заголовка Link [RFC5988 #], каждое из которых имеет отношение «альтернативный», хотя развертывание — это проблема «курицы и яйца».

6.4.2. 301 — Moved Permanently (Перемещено навсегда)

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

Серверу СЛЕДУЕТ генерировать поле заголовка Location в ответе, содержащее предпочтительную ссылку URI для нового постоянного URI. Пользовательский агент МОЖЕТ использовать значение поля Location для автоматического перенаправления. Полезная нагрузка сервера обычно содержит короткую гипертекстовую заметку с гиперссылкой на новый URI.

Примечание. По историческим причинам пользовательский агент МОЖЕТ изменить метод запроса с POST на GET для последующего запроса. Если это поведение нежелательно, вместо него можно использовать код состояния 307 (временное перенаправление).

Ответ 301 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.4.3. 302 — Found (Найдено)

Код состояния 302 (Найдено) указывает, что целевой ресурс временно находится под другим URI. Поскольку перенаправление может иногда изменяться, клиент должен продолжать использовать эффективный URI запроса для будущих запросов.

Сервер ДОЛЖЕН генерировать поле заголовка Location в ответе, содержащее ссылку на URI для другого URI. Пользовательский агент МОЖЕТ использовать значение поля Location для автоматического перенаправления. Полезная нагрузка сервера обычно содержит короткую гипертекстовую заметку с гиперссылкой на различные URI.

Примечание. По историческим причинам пользовательский агент МОЖЕТ изменить метод запроса с POST на GET для последующего запроса. Если это поведение нежелательно, вместо него можно использовать код состояния 307 (временное перенаправление).

6.4.4. 303 — See Other (См. Другое)

Код состояния 303 (см. «Другое») указывает, что сервер перенаправляет пользовательский агент на другой ресурс, как указано URI в поле заголовка Location, который предназначен для предоставления косвенного ответа на исходный запрос. Пользовательский агент может выполнить запрос поиска, направленный на этот URI (запрос GET или HEAD, если используется HTTP), который также может быть перенаправлен, и представить конечный результат в качестве ответа на исходный запрос. Обратите внимание, что новый URI в поле заголовка Location не считается эквивалентным действующему URI запроса.

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

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

За исключением ответов на запрос HEAD, представление ответа 303 должно содержать короткую гипертекстовую заметку с гиперссылкой на ту же ссылку URI, которая указана в поле заголовка Location.

6.4.5. 305 — Use Proxy (Использовать прокси)

Код состояния 305 (Использовать прокси) был определен в предыдущей версии этой спецификации и в настоящее время не рекомендуется (Приложение Б).

6.4.6. 306 (Unused — не используется)

Код состояния 306 был определен в предыдущей версии этой спецификации, больше не используется, и код зарезервирован.

6.4.7. 307 — Temporary Redirect (Временное перенаправление)

Код состояния 307 (временное перенаправление) указывает на то, что целевой ресурс временно находится под другим URI, и пользовательский агент НЕ ДОЛЖЕН изменять метод запроса, если он выполняет автоматическое перенаправление на этот URI. Поскольку перенаправление со временем может измениться, клиент должен продолжать использовать исходный эффективный URI запроса для будущих запросов.

Сервер ДОЛЖЕН генерировать поле заголовка Location в ответе, содержащее ссылку на URI для другого URI. Пользовательский агент МОЖЕТ использовать значение поля Location для автоматического перенаправления. Полезная нагрузка сервера обычно содержит короткую гипертекстовую заметку с гиперссылкой на различные URI.

Примечание. Этот код состояния аналогичен 302 (найдено), за исключением того, что он не позволяет изменить метод запроса с POST на GET. Эта спецификация не определяет эквивалент для 301 (Постоянно перемещено) (однако [RFC7238 #] определяет код состояния 308 (Постоянное перенаправление) для этой цели).

6.5. Ошибка клиента 4xx

Класс кода состояния 4xx (Ошибка клиента) указывает, что клиент, похоже, допустил ошибку. За исключением случаев ответа на запрос HEAD, сервер ДОЛЖЕН послать представление, содержащее объяснение ситуации с ошибкой, и является ли это временным или постоянным условием. Эти коды состояния применимы к любому методу запроса. Пользовательские агенты ДОЛЖНЫ отображать любое включенное представление пользователю.

6.5.1. 400 — Bad Request (Неверный запрос)

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

6.5.2. 402 — Payment Required (Требуется оплата)

Код состояния 402 (требуется оплата) зарезервирован для использования в будущем.

6.5.3. 403 — Forbidden (Запрещено)

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

Если в запросе были предоставлены учетные данные для проверки подлинности, сервер считает их недостаточными для предоставления доступа. Клиент НЕ ДОЛЖЕН автоматически повторять запрос с теми же учетными данными. Клиент МОЖЕТ повторить запрос с новыми или другими учетными данными. Однако запрос может быть запрещен по причинам, не связанным с учетными данными.

Исходный сервер, который хочет «скрыть» текущее существование запрещенного целевого ресурса, МОЖЕТ вместо этого ответить кодом состояния 404 (Не найдено).

6.5.4. 404 — Not Found (Не Найдено)

Код состояния 404 (не найден) указывает на то, что исходный сервер не нашел текущее представление для целевого ресурса или не хочет раскрывать его. Код состояния 404 не указывает, является ли это отсутствие представления временным или постоянным; код состояния 410 (пропал) предпочтительнее, чем 404, если исходный сервер знает, предположительно, через некоторые настраиваемые средства, что условие, вероятно, будет постоянным.

Ответ 404 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.5.5. 405 — Method Not Allowed (Метод не разрешен)

Код состояния 405 (метод не разрешен) указывает, что метод, полученный в строке запроса, известен исходному серверу, но не поддерживается целевым ресурсом. Сервер происхождения ДОЛЖЕН сгенерировать поле заголовка Allow в ответе 405, содержащем список поддерживаемых в настоящее время методов целевого ресурса.

Ответ 405 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.5.6. 406 — Not Acceptable (Недопустимо)

Код состояния 406 (не приемлемо) указывает, что целевой ресурс не имеет текущего представления, которое было бы приемлемо для пользовательского агента, в соответствии с полями заголовка проактивного согласования, полученными в запросе (раздел 5.3), и сервер не желает предоставить представление по умолчанию.

Серверу СЛЕДУЕТ генерировать полезную нагрузку, содержащую список доступных характеристик представления и соответствующие идентификаторы ресурса, из которых пользователь или пользовательский агент может выбрать наиболее подходящую. Пользовательский агент МОЖЕТ автоматически выбрать наиболее подходящий вариант из этого списка. Однако эта спецификация не определяет какого-либо стандарта для такого автоматического выбора, как описано в разделе 6.4.1.

6.5.7. 408 — Request Timeout (Время ожидания запроса)

Код состояния 408 (время ожидания запроса) указывает, что сервер не получил полное сообщение запроса в течение времени, которое он был готов ждать. Сервер ДОЛЖЕН отправить в ответ опцию «закрыть» (Раздел 6.1 [RFC7230 #]), поскольку 408 подразумевает, что сервер решил закрыть соединение, а не продолжать ожидание. Если у клиента есть невыполненный запрос в пути, клиент МОЖЕТ повторить этот запрос на новом соединении.

6.5.8. 409 — Conflict (Конфликт)

Код состояния 409 (Конфликт) указывает, что запрос не может быть выполнен из-за конфликта с текущим состоянием целевого ресурса. Этот код используется в ситуациях, когда пользователь может разрешить конфликт и повторно отправить запрос. Сервер ДОЛЖЕН генерировать полезную нагрузку, которая включает в себя достаточно информации, чтобы пользователь мог распознать источник конфликта.

Конфликты чаще всего возникают в ответ на запрос PUT. Например, если использовалось управление версиями, а представление, представляющее собой PUT, включало изменения в ресурсе, которые конфликтуют с ресурсами, созданными в результате более раннего (стороннего) запроса, исходный сервер может использовать ответ 409, чтобы указать, что он не может завершить запрос. В этом случае представление ответа, вероятно, будет содержать информацию, полезную для объединения различий, основанных на истории изменений.

6.5.9. 410 — Gone (Ушел)

Код состояния 410 (пропал) указывает, что доступ к целевому ресурсу больше не доступен на исходном сервере и что это условие, вероятно, будет постоянным. Если исходный сервер не знает или не имеет возможности определить, является ли условие постоянным, вместо этого следует использовать код состояния 404 (не найден).

Ответ 410 в первую очередь предназначен для содействия задаче веб-обслуживания, уведомляя получателя о том, что ресурс намеренно недоступен и что владельцы серверов желают удалить удаленные ссылки на этот ресурс. Такое мероприятие является обычным для ограниченных по времени рекламных услуг и для ресурсов, принадлежащих лицам, которые больше не связаны с сайтом сервера происхождения. Нет необходимости отмечать все постоянно недоступные ресурсы как «пропавшие» или сохранять отметку в течение любого промежутка времени — это оставлено на усмотрение владельца сервера.

Ответ 410 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.5.10. 411 — Length Required (Длина требуется)

Код состояния 411 (длина обязательна) указывает, что сервер отказывается принимать запрос без определенной длины содержимого (раздел 3.3.2 [RFC7230 #]). Клиент МОЖЕТ повторить запрос, если он добавляет допустимое поле заголовка Content-Length, содержащее длину тела сообщения в сообщении запроса.

6.5.11. 413  — Payload Too Large (Слишком большая полезная нагрузка)

Код состояния 413 (Слишком большая полезная нагрузка) указывает, что сервер отказывается обрабатывать запрос, поскольку полезная нагрузка запроса больше, чем сервер желает или может обработать. Сервер МОЖЕТ закрыть соединение, чтобы клиент не мог продолжить запрос.

Если условие является временным, сервер ДОЛЖЕН сгенерировать поле заголовка Retry-After, чтобы указать, что оно является временным и по истечении которого клиент МОЖЕТ повторить попытку.

6.5.12. 414 — URI Too Long (URI слишком длинный)

Код состояния 414 (URI Too Long) указывает, что сервер отказывает в обслуживании запроса, поскольку цель запроса (раздел 5.3 [RFC7230 #]) длиннее, чем сервер хочет интерпретировать. Это редкое условие может возникнуть только тогда, когда клиент неправильно преобразовал запрос POST в запрос GET с длинной информацией о запросе, когда клиент спустился в «черную дыру» перенаправления (например, префикс перенаправленного URI, который указывает на сам суффикс) или когда сервер подвергается атаке со стороны клиента, пытающегося использовать потенциальные дыры в безопасности.

Ответ 414 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.5.13. 415 — Unsupported Media Type (Неподдерживаемый тип носителя)

Код состояния 415 (неподдерживаемый тип носителя) указывает, что исходный сервер отказывается обслуживать запрос, поскольку полезная нагрузка находится в формате, не поддерживаемом этим методом на целевом ресурсе. Проблема с форматированием может быть связана с указанным в запросе Content-Type или Content-Encoding или из-за прямой проверки данных.

6.5.14. 417 — Expectation Failed (Ожидание не удалось)

Код состояния 417 (Expectation Failed) указывает, что ожидание, указанное в поле заголовка Expect запроса (раздел 5.1.1), не может быть удовлетворено хотя бы одним из входящих серверов.

6.5.15. 426 — Upgrade Required (Требуется обновление)

Код состояния 426 (требуется обновление) указывает, что сервер отказывается выполнять запрос с использованием текущего протокола, но может захотеть сделать это после того, как клиент обновит другой протокол. Сервер ДОЛЖЕН отправить поле заголовка обновления в ответе 426, чтобы указать требуемый протокол (ы) (раздел 6.7 [RFC7230 #]).

Пример:

HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

Этот сервис требует использования протокола HTTP / 3.0.

6.6. Ошибка сервера 5xx

Класс кода состояния 5xx (Ошибка сервера) указывает, что сервер знает, что он допустил ошибку или не может выполнить запрошенный метод. За исключением случаев ответа на запрос HEAD, сервер ДОЛЖЕН послать представление, содержащее объяснение ситуации с ошибкой, и является ли это временным или постоянным условием. Пользовательский агент ДОЛЖЕН отображать любое включенное представление пользователю. Эти коды ответов применимы к любому методу запроса.

6.6.1. 500 — Internal Server Error (Внутренняя ошибка сервера)

Код состояния 500 (Внутренняя ошибка сервера) указывает, что сервер обнаружил непредвиденное состояние, которое не позволило ему выполнить запрос.

6.6.2. 501 — Not Implemented (Не реализовано)

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

Ответ 501 кэшируется по умолчанию; то есть, если иное не указано в определении метода или явных элементах управления кэшем (см. Раздел 4.2.2 [RFC7234 #]).

6.6.3. 502 — Bad Gateway (Неверный шлюз)

Код состояния 502 (Bad Gateway) указывает на то, что сервер, выступая в качестве шлюза или прокси-сервера, получил неверный ответ от входящего сервера, к которому он обращался при попытке выполнить запрос.

6.6.4. 503 — Service Unavailable (Сервис недоступен)

Код состояния 503 (служба недоступна) указывает, что в настоящее время сервер не может обработать запрос из-за временной перегрузки или планового обслуживания, которое, вероятно, будет устранено после некоторой задержки. Сервер МОЖЕТ отправить поле заголовка Retry-After (раздел 7.1.3), чтобы предложить клиенту соответствующее время ожидания, прежде чем повторять запрос.

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

6.6.5. 504 — Gateway Timeout (Время ответа сервера истекло)

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

6.6.6. 505 — HTTP Version Not Supported (Версия HTTP не поддерживается)

Код состояния 505 (версия HTTP не поддерживается) указывает, что сервер не поддерживает или отказывается поддерживать основную версию HTTP, которая использовалась в сообщении запроса. Сервер указывает, что он не может или не хочет выполнить запрос, используя ту же основную версию, что и клиент, как описано в Разделе 2.6 [RFC7230 #], за исключением этого сообщения об ошибке. Серверу СЛЕДУЕТ генерировать представление для ответа 505, которое описывает, почему эта версия не поддерживается и какие другие протоколы поддерживаются этим сервером.

7. Поля заголовка ответа

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

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

7.1. Control Data

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

Имя поля заголовкаОпределено в …
AgeРаздел 5.1 из RFC 7234 #
Cache-ControlРаздел 5.2 из RFC 7234 #
ExpiresРаздел 5.3 из RFC 7234 #
DateРаздел 7.1.1.2
LocationРаздел 7.1.2
Retry-AfterРаздел 7.1.3
VaryРаздел 7.1.4
WarningРаздел 5.5 из RFC 7234 #

Таблица

7.1.1. Origination Date

7.1.1.1. Форматы Даты/Времени

До 1995 года серверы использовали три разных формата для передачи меток времени. Для совместимости со старыми реализациями все три определены здесь. Предпочтительным форматом является подмножество фиксированной длины и одной зоны спецификации даты и времени, используемой форматом сообщений Интернета [RFC5322 #].

HTTP-date = IMF-fixdate / obs-date

Примером предпочтительного формата является

Sun, 06 Nov 1994 08:49:37 GMT ; IMF-fixdate

Примеры двух устаревших форматов:

Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
Sun Nov 6 08:49:37 1994 ; ANSI C’s asctime() format

Получатель, который анализирует значение метки времени в поле заголовка HTTP, ДОЛЖЕН принять все три формата даты HTTP. Когда отправитель генерирует поле заголовка, которое содержит одну или несколько меток времени, определенных как HTTP-дата, отправитель ДОЛЖЕН генерировать эти метки времени в формате IMF-fixdate.

Значение HTTP-даты представляет время как экземпляр всемирного координированного времени (UTC). Первые два формата обозначают UTC трехбуквенным сокращением для среднего времени по Гринвичу, «GMT», предшественника названия UTC; значения в формате asctime предполагаются в формате UTC. Отправитель, который генерирует значения HTTP-даты из локальных часов, должен использовать NTP ([RFC5905 #]) или какой-либо подобный протокол для синхронизации своих часов с UTC.

Предпочитаемый формат:

IMF-fixdate = day-name "," SP date1 SP time-of-day SP GMT
; fixed length/zone/capitalization subset of the format
; смотри Раздел 3.3 of [RFC5322 #]

day-name = %x4D.6F.6E ; "Mon", case-sensitive
/ %x54.75.65 ; "Tue", case-sensitive
/ %x57.65.64 ; "Wed", case-sensitive
/ %x54.68.75 ; "Thu", case-sensitive
/ %x46.72.69 ; "Fri", case-sensitive
/ %x53.61.74 ; "Sat", case-sensitive
/ %x53.75.6E ; "Sun", case-sensitive

date1 = day SP month SP year
; e.g., 02 Jun 1982

day = 2DIGIT
month = %x4A.61.6E ; "Jan", case-sensitive
/ %x46.65.62 ; "Feb", case-sensitive
/ %x4D.61.72 ; "Mar", case-sensitive
/ %x41.70.72 ; "Apr", case-sensitive
/ %x4D.61.79 ; "May", case-sensitive
/ %x4A.75.6E ; "Jun", case-sensitive
/ %x4A.75.6C ; "Jul", case-sensitive
/ %x41.75.67 ; "Aug", case-sensitive
/ %x53.65.70 ; "Sep", case-sensitive
/ %x4F.63.74 ; "Oct", case-sensitive
/ %x4E.6F.76 ; "Nov", case-sensitive
/ %x44.65.63 ; "Dec", case-sensitive
year = 4DIGIT

GMT = %x47.4D.54 ; "GMT", case-sensitive

time-of-day = hour ":" minute ":" second
; 00:00:00 - 23:59:60 (leap second)

hour = 2DIGIT
minute = 2DIGIT
second = 2DIGIT

Устаревшие форматы:

obs-date = rfc850-date / asctime-date

rfc850-date = day-name-l "," SP date2 SP time-of-day SP GMT
date2 = day "-" month "-" 2DIGIT
; e.g., 02-Jun-82

day-name-l = %x4D.6F.6E.64.61.79 ; "Monday", case-sensitive
/ %x54.75.65.73.64.61.79 ; "Tuesday", case-sensitive
/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday", case-sensitive
/ %x54.68.75.72.73.64.61.79 ; "Thursday", case-sensitive
/ %x46.72.69.64.61.79 ; "Friday", case-sensitive
/ %x53.61.74.75.72.64.61.79 ; "Saturday", case-sensitive
/ %x53.75.6E.64.61.79 ; "Sunday", case-sensitive

asctime-date = day-name SP date3 SP time-of-day SP year
date3 = month SP ( 2DIGIT / ( SP 1DIGIT ))
; e.g., Jun 2

HTTP-дата чувствительна к регистру. Отправитель НЕ ДОЛЖЕН генерировать дополнительные пробелы в HTTP-дате помимо тех, которые специально включены в грамматику как SP. Семантика день-имя, день, месяц, год и время дня такие же, как определенные для конструкций формата сообщений Интернета с соответствующим именем ([RFC5322 #], раздел 3.3).

Получатели значения метки времени в формате даты rfc850, в котором используется год из двух цифр, ДОЛЖНЫ интерпретировать метку времени, которая, как представляется, будет более 50 лет в будущем, как представляющую самый последний год в прошлом, который имел те же последние две цифры.

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

Примечание. Требования HTTP для формата отметки даты / времени применяются только к их использованию в потоке протокола. Реализации не обязаны использовать эти форматы для представления пользователя, регистрации запросов и т. д.

7.1.1.2. Date (Поле заголовка)

Поле заголовка «Дата» представляет дату и время, когда сообщение было отправлено, и имеет ту же семантику, что и поле «Дата происхождения» (дата-дата), определенное в разделе 3.6.1 [RFC5322 #]. Значением поля является HTTP-дата, как определено в разделе 7.1.1.1.

Date = HTTP-date

Примером является

Date: Tue, 15 Nov 1994 08:12:31 GMT

Когда поле заголовка Date генерируется, отправителю СЛЕДУЕТ генерировать значение его поля как наилучшее доступное приближение даты и времени генерации сообщения. Теоретически, дата должна представлять момент непосредственно перед созданием полезной нагрузки. На практике, дата может быть сгенерирована в любое время во время создания сообщения.

Исходный сервер НЕ ДОЛЖЕН отправлять поле заголовка Date, если у него нет часов, способных обеспечить разумное приближение текущего экземпляра в универсальном координированном времени. Исходный сервер МОЖЕТ отправить поле заголовка Date, если ответ находится в классе кодов состояния 1xx (информационный) или 5xx (ошибка сервера). Сервер происхождения ДОЛЖЕН отправить поле заголовка Date во всех других случаях.

Получатель с часами, который получает ответное сообщение без поля заголовка даты, ДОЛЖЕН записать время, когда оно было получено, и добавить соответствующее поле заголовка даты в раздел заголовка сообщения, если оно кэшируется или пересылается вниз по течению.

Пользовательский агент МОЖЕТ отправлять поле заголовка Date в запросе, хотя обычно не делает этого, если не считается, что он передает полезную информацию на сервер. Например, пользовательские приложения HTTP могут передавать Date, если ожидается, что сервер настроит свою интерпретацию запроса пользователя на основе различий между пользовательским агентом и серверными часами.

7.1.2. Location

Поле заголовка «Location» используется в некоторых ответах для ссылки на конкретный ресурс по отношению к ответу. Тип отношения определяется комбинацией метода запроса и семантики кода состояния.

Location = URI-reference

Значение поля состоит из одной URI-ссылки. Когда он имеет форму относительной ссылки ([RFC3986 #], раздел 4.2), окончательное значение вычисляется путем сопоставления его с URI действующего запроса ([RFC3986 #], раздел 5).

Для 201 (Создано) ответов значение Location относится к первичному ресурсу, созданному запросом. Для ответов 3xx (перенаправление) значение Location относится к предпочтительному целевому ресурсу для автоматического перенаправления запроса.

Если значение Location, указанное в ответе 3xx (Redirection), не имеет компонента фрагмента, пользовательский агент ДОЛЖЕН обработать перенаправление, как если бы значение наследовало компонент фрагмента ссылки URI, использованной для генерации цели запроса (то есть перенаправление наследует оригинальный фрагмент ссылки, если есть).

Например, запрос GET, сгенерированный для ссылки URI «http://www.example.org/~tim«, может привести к ответу 303 (см. «Другое»), содержащему поле заголовка:

Location: /People.html#tim

что предполагает, что пользовательский агент перенаправляет на «http://www.example.org/People.html#tim»

Аналогично, запрос GET, сгенерированный для ссылки URI «http://www.example.org/index.html#larry«, может привести к ответу 301 (перемещено навсегда), содержащему поле заголовка:

Location: http://www.example.net/index.html

что предполагает, что пользовательский агент перенаправляет на «http://www.example.net/index.html#larry«, сохраняя исходный идентификатор фрагмента.

Существуют обстоятельства, при которых идентификатор фрагмента в значении Location не подходит. Например, поле заголовка Location в ответе 201 (Создано) должно предоставлять URI, специфичный для созданного ресурса.

Примечание. Некоторые получатели пытаются восстановить данные из полей Location, которые не являются допустимыми ссылками URI. Эта спецификация не предписывает и не определяет такую обработку, но допускает ее ради надежности.

Примечание. Поле заголовка Content-Location (раздел 3.1.4.2) отличается от Location тем, что Content-Location относится к наиболее конкретному ресурсу, соответствующему вложенному представлению. Поэтому ответ может содержать поля заголовка Location и Content-Location.

7.1.3. Retry-After

Серверы отправляют поле заголовка «Retry-After», чтобы указать, как долго пользовательский агент должен ждать перед выполнением последующего запроса. При отправке с ответом 503 (служба недоступна) Retry-After указывает, как долго ожидается, что служба будет недоступна для клиента. При отправке с любым ответом 3xx (перенаправление) Retry-After указывает минимальное время, в течение которого пользовательский агент должен ждать перед отправкой перенаправленного запроса.

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

Retry-After = HTTP-date / delay-seconds

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

delay-seconds = 1*DIGIT

Два примера его использования

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

В последнем примере задержка составляет 2 минуты.

7.1.4. Vary

Поле заголовка Vary в ответе описывает, какие части сообщения запроса, кроме метода, поля заголовка узла и цели запроса, могут влиять на процесс исходного сервера для выбора и представления этого ответа. Значение состоит из одной звездочки («*») или списка имен полей заголовка (без учета регистра).

Vary = "*" / 1#field-name

Значение поля Vary, равное «*», указывает на то, что что-либо в запросе может играть роль в выборе представления ответа, возможно, включая элементы вне синтаксиса сообщения (например, сетевой адрес клиента). Получатель не сможет определить, подходит ли этот ответ для более позднего запроса, без пересылки запроса на исходный сервер. Прокси НЕ ДОЛЖЕН генерировать поле Vary со значением «*».

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

Например, ответ, который содержит

Vary: accept-encoding, accept-language

указывает, что исходный сервер мог использовать поля запроса Accept-Encoding и Accept-Language (или их отсутствие) в качестве определяющих факторов при выборе содержимого для этого ответа.

Исходный сервер может отправить Vary со списком полей для двух целей:

  1. Информировать получателей кэша о том, что они НЕ ДОЛЖНЫ использовать этот ответ для удовлетворения более позднего запроса, если только у более позднего запроса нет тех же значений для перечисленных полей, что и у исходного запроса (Раздел 4.1 [RFC7234 #]). Другими словами, Vary расширяет ключ кеша, необходимый для сопоставления нового запроса с сохраненной записью кеша.
  2. Информировать получателей пользовательского агента о том, что этот ответ подлежит согласованию контента (раздел 5.3) и что в последующем запросе может быть отправлено другое представление, если в перечисленных полях заголовка указаны дополнительные параметры (упреждающее согласование).

Исходному серверу СЛЕДУЕТ отправлять поле заголовка Vary, когда его алгоритм выбора представления изменяется на основе аспектов сообщения запроса, отличных от метода и цели запроса, если только отклонение не может быть пересечено или исходный сервер был специально настроен для предотвращения прозрачности кэша , Например, нет необходимости отправлять имя поля авторизации в Vary, потому что повторное использование между пользователями ограничено определением поля (раздел 4.2 в [RFC7235 #]). Аналогично, исходный сервер может использовать директивы Cache-Control (раздел 5.2 [RFC7234 #]) для замены Vary, если он считает, что разница менее значительна, чем затраты производительности Vary на кэширование.

7.2. Validator Header Fields

Поля заголовка валидатора передают метаданные о выбранном представлении (