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.

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

 

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

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

 

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

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

Таблица

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

 

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 #].

Таблица

 

5.3. Content Negotiation

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

Таблица

 

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

Пример:

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

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

Таблица

 

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 и ни одно из доступных представлений для ответа не имеет кодирования содержимого, которое указано в качестве приемлемого, серверу происхождения СЛЕДУЕТ отправить ответ без какого-либо кодирования содержимого.

 

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.

 

5.4. Authentication Credentials

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

Таблица

 

5.5. Request Context

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

Таблица

 

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 #]; все остальные коды состояния по умолчанию не кэшируются.

Таблица

Обратите внимание, что этот список не является исчерпывающим — он не включает коды состояния расширения, определенные в других спецификациях. Полный список кодов состояния поддерживается 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 (не изменен).

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

 

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

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

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

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

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

 

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

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

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

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

 

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

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

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

 

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.

 

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

 

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

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

Таблица

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, который может генерировать любые спецификации даты и времени, определенные форматом сообщений Интернета.

 

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, специфичный для созданного ресурса.

 

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

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

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

Например, поле заголовка ETag в ответе 201 (Создано) сообщает тег сущности представления вновь созданного ресурса, чтобы его можно было использовать в последующих условных запросах для предотвращения проблемы «потерянного обновления» [RFC7232 #].

Таблица

7.3. Authentication Challenges

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

Таблица

7.4. Response Context

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

Таблица

7.4.1. Allow

Поле заголовка «Allow» содержит список методов, объявленных как поддерживаемые целевым ресурсом. Цель этого поля — строго информировать получателя о допустимых методах запроса, связанных с ресурсом.

Allow = #method

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

Allow: GET, HEAD, PUT

Фактический набор разрешенных методов определяется исходным сервером во время каждого запроса. Сервер происхождения ДОЛЖЕН сгенерировать поле Разрешить в ответе 405 (Метод не разрешен) и МОЖЕТ сделать это в любом другом ответе. Пустое значение поля Разрешить указывает, что ресурс не допускает методов, которые могут возникнуть в ответе 405, если ресурс был временно отключен конфигурацией.

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

 

7.4.2. Server

Поле заголовка «Сервер» содержит информацию о программном обеспечении, используемом исходным сервером для обработки запроса, которое часто используется клиентами, чтобы помочь определить объем сообщаемых проблем взаимодействия, обойти или адаптировать запросы, чтобы избежать определенных ограничений сервера, и для аналитики относительно использования сервера или операционной системы. Исходный сервер МОЖЕТ генерировать поле Server в своих ответах.

Server = product *( RWS ( product / comment ) )

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

Пример:

Server: CERN/3.0 libwww/2.17

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

 

8. Соображения IANA

 

8.1. Реестр методов

«Реестр методов протокола передачи гипертекста (HTTP)» определяет пространство имен для токена метода запроса (раздел 4). Реестр методов был создан и теперь поддерживается по адресу <http://www.iana.org/assignments/http-methods>.

8.1.1. Процедура

Регистрации метода HTTP ДОЛЖНЫ включать следующие поля:

• Имя метода (см. раздел 4)
• Безопасный («да» или «нет», см. раздел 4.2.1)
• Идемпотент («да» или «нет», см. раздел 4.2.2)
• Указатель на текст спецификации

Значения, которые необходимо добавить в это пространство имен, требуют проверки IETF (см. [RFC5226 #], раздел 4.1).

 

8.1.2. Соображения по поводу новых методов

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

Так как синтаксический анализ сообщения (раздел 3.3 [RFC7230 #]) должен быть независимым от семантики метода (кроме ответов на HEAD), определения новых методов не могут изменить алгоритм синтаксического анализа или запретить присутствие тела сообщения в запросе или ответе. сообщение. Определения новых методов могут указывать, что допускается только тело сообщения нулевой длины, для чего требуется поле заголовка Content-Length со значением «0».

Новое определение метода должно указывать, является ли он безопасным (раздел 4.2.1), идемпотентом (раздел 4.2.2), кэшируемым (раздел 4.2.3), какая семантика должна быть связана с телом полезной нагрузки, если таковая имеется в запрос и какие уточнения метод делает для заголовка поля или семантики кода состояния. Если новый метод кешируется, его определение должно содержать описание того, как и при каких условиях кеш может хранить ответ и использовать его для удовлетворения последующего запроса. Новый метод должен описать, можно ли сделать его условным (Раздел 5.2) и, если да, то, как сервер отвечает, когда условие ложно. Аналогичным образом, если новый метод может иметь некоторое использование для семантики частичного ответа ([RFC7233 #]), он также должен это задокументировать.

 

8.1.3. Регистрации

«Реестр протокола передачи гипертекста (HTTP)» заполнен следующими регистрациями:

Таблица

8.2. Реестр кодов состояния

«Реестр кодов состояния протокола передачи гипертекста (HTTP)» определяет пространство имен для токена кода состояния ответа (раздел 6). Реестр кодов состояния поддерживается на

<http://www.iana.org/assignments/http-status-codes>

Этот раздел заменяет процедуру регистрации для кодов состояния HTTP, ранее определенных в разделе 7.1 [RFC2817 #].

 

8.2.1. Процедура

Регистрация ДОЛЖНА включать следующие поля:

• Код состояния (3 цифры)
• Краткое описание
• Указатель на текст спецификации

Значения, которые необходимо добавить в пространство имен кода состояния HTTP, требуют проверки IETF (см. [RFC5226 #], раздел 4.1).

8.2.2. Соображения по новым кодам статуса

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

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

Предложения о новых кодах состояния, которые еще не получили широкого распространения, должны избегать назначения конкретного номера для кода до тех пор, пока не будет достигнут четкий консенсус в отношении того, что он будет зарегистрирован; вместо этого в ранних черновиках можно использовать обозначения, такие как «4NN» или «3N0» … «3N9», чтобы указать класс предлагаемых кодов состояния без преждевременного использования числа.

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

Определение нового кода состояния должно указывать, кэшируется ли он или нет. Обратите внимание, что все коды состояния могут быть кэшированы, если ответ, в котором они появляются, имеет явную информацию о свежести; однако коды состояния, которые определены как кешируемые, могут кэшироваться без явной информации о свежести. Аналогично, определение кода состояния может накладывать ограничения на поведение кэша. См. [RFC7234 #] для получения дополнительной информации.

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

 

8.2.3. Регистрации

Реестр кодов состояния обновлен следующими регистрациями:

Таблица

 

8.3. Реестр полей заголовка

Поля заголовка HTTP регистрируются в реестре «Заголовки сообщений», расположенном по адресу

<http://www.iana.org/assignments/message-headers>, как определено в [BCP90].

8.3.1. Соображения для новых полей заголовка

Поля заголовка являются парами ключ: значение, которые могут использоваться для передачи данных о сообщении, его полезной нагрузке, целевом ресурсе или соединении (то есть управляющих данных). См. Раздел 3.2 [RFC7230 #] для общего определения синтаксиса поля заголовка в сообщениях HTTP.

Требования к именам полей заголовков определены в [BCP90].

Авторам спецификаций, определяющих новые поля, рекомендуется использовать как можно более короткое имя и не ставить префикс «X-», если только поле заголовка никогда не будет использоваться в Интернете. (На практике идиома префикса «X-» широко использовалась неправильно; она предназначалась для использования только в качестве механизма, позволяющего избежать конфликтов имен в проприетарном программном обеспечении или при обработке в интрасети, поскольку префикс гарантирует, что частные имена никогда не конфликтуют с недавно зарегистрированным Интернет-имя; см. [BCP178] для получения дополнительной информации).

Новые значения полей заголовка обычно имеют синтаксис, определенный с использованием ABNF ([RFC5234 #]), используя расширение, определенное в разделе 7 [RFC7230 #], при необходимости, и обычно ограничивается диапазоном символов US-ASCII. Поля заголовка, которым требуется больший диапазон символов, могут использовать кодировку, например, определенную в [RFC5987 #].

Начальные и конечные пробелы в необработанных значениях поля удаляются при разборе поля (Раздел 3.2.4 [RFC7230 #]). Определения полей, в которых начальные или конечные пробелы в значениях значимы, должны будут использовать синтаксис контейнера, такой как строка в кавычках (раздел 3.2.6 [RFC7230 #]).

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

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

Example-URI-Field: "http://example.com/a.html,foo",
"http://without-a-comma.example.com/"
Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005"

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

Многие поля заголовка используют формат, включающий (без учета регистра) именованные параметры (например, Content-Type, определенный в разделе 3.1.1.5). Разрешение синтаксиса как без кавычек (токен), так и с кавычками (строка в кавычках) позволяет получателям использовать существующие компоненты синтаксического анализатора. При разрешении обеих форм значение значения параметра должно быть независимым от синтаксиса, используемого для него (например, см. Примечания по обработке параметров для типов мультимедиа в разделе 3.1.1.1).

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

o Является ли поле одним значением или может ли оно быть списком (разделенным запятыми; см. раздел 3.2 [RFC7230 #]).

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

Обратите внимание, что посредники и библиотеки программного обеспечения могут объединять несколько экземпляров полей заголовка в один, несмотря на то, что определение поля не позволяет использовать синтаксис списка. Надежный формат позволяет получателям обнаруживать такие ситуации (хороший пример: «Content-Type», поскольку запятая может появляться только внутри строк в кавычках; плохой пример: «Location», так как запятая может встречаться внутри URI).

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

o Должно ли поле храниться исходными серверами, которые понимают его по запросу PUT.

o Будет ли семантика поля дополнительно уточняться контекстом, например, существующими методами запроса или кодами состояния.

o Уместно ли указывать имя поля в поле заголовка соединения (т. е. если поле заголовка должно быть скачкообразным; см. раздел 6.1 [RFC7230 #]).

o При каких условиях посредникам разрешено вставлять, удалять или изменять значение поля.

o Уместно ли указывать имя поля в поле заголовка ответа Vary (например, когда поле заголовка запроса используется алгоритмом выбора контента исходного сервера; см. Раздел 7.1.4).

o Является ли поле заголовка полезным или допустимым в трейлерах (см. Раздел 4.1 [RFC7230 #]).

o Должно ли поле заголовка сохраняться при переадресации.

o Представляет ли он какие-либо дополнительные соображения безопасности, такие как раскрытие данных, связанных с конфиденциальностью.

 

8.3.2. Регистрации

Реестр «Заголовки сообщений» обновлен следующими постоянными регистрациями:

Таблица

Контроллер изменений для вышеуказанных регистраций: «IETF (iesg@ietf.org) — Целевая группа по интернет-разработкам».

8.4. Реестр кодирования контента

«Реестр кодирования содержимого HTTP» определяет пространство имен для имен кодирования содержимого (Раздел 4.2 [RFC7230 #]). Реестр кодирования контента ведется по адресу <http://www.iana.org/assignments/http-parameters>.

8.4.1. Процедура

Регистрации кодирования контента ДОЛЖНЫ включать следующие поля:

• Имя
• Описание
• Указатель на текст спецификации

Имена кодировок контента НЕ ДОЛЖНЫ пересекаться с именами кодировок передачи (Раздел 4 [RFC7230 #]), если только преобразование кодирования не является идентичным (как в случае кодировок сжатия, определенных в Разделе 4.2 [RFC7230 #]).

Значения, добавляемые в это пространство имен, требуют проверки IETF (см. Раздел 4.1 [RFC5226 #]) и ДОЛЖНЫ соответствовать цели кодирования контента, определенной в этом разделе.

8.4.2. Регистрации

«Реестр кодирования содержимого HTTP» обновлен следующими регистрациями:

Name | Description | Reference |
+———-+—————————————-+—————+
|  |  | Section  |
| |  | |

Таблица

 

9. Вопросы безопасности

Этот раздел предназначен для информирования разработчиков, поставщиков информации и пользователей об известных проблемах безопасности, связанных с семантикой HTTP и ее использованием для передачи информации через Интернет. Соображения, связанные с синтаксисом, синтаксическим анализом и маршрутизацией сообщений, обсуждаются в разделе 9 [RFC7230 #].

Приведенный ниже список соображений не является исчерпывающим. Большинство проблем безопасности, связанных с семантикой HTTP, касаются защиты приложений на стороне сервера (код за интерфейсом HTTP), защиты обработки пользовательским агентом полезных нагрузок, полученных через HTTP, или безопасного использования Интернета в целом, а не безопасности протокола. Различные организации хранят актуальную информацию и ссылки на текущие исследования безопасности веб-приложений (например, [OWASP]).

9.1. Атаки на основе имен файлов и путей

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

Например, UNIX, Microsoft Windows и другие операционные системы используют «..» в качестве компонента пути, чтобы указать уровень каталога выше текущего, и они используют специально именованные пути или имена файлов для отправки данных на системные устройства. Подобные соглашения об именах могут существовать в других типах систем хранения. Аналогичным образом, локальные системы хранения данных имеют досадную тенденцию предпочитать удобство для пользователя над безопасностью при обработке недопустимых или неожиданных символов, перекомпоновке разложенных символов и нормализации регистра без учета регистра символов.

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

9.2. Атаки на основе команды, кода или внедрения запроса

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

Например, SQL-инъекция является распространенной атакой, в которой дополнительный язык запросов вставляется в некоторую часть полей запроса-цели или заголовка (например, Host, Referer и т. д.). Если полученные данные используются непосредственно в операторе SELECT, язык запроса может интерпретироваться как команда базы данных вместо простого строкового значения. Этот тип уязвимости реализации чрезвычайно распространен, несмотря на то, что его легко предотвратить.

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

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

9.3. Раскрытие личной информации

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

9.4. Раскрытие конфиденциальной информации в URI

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

Авторам сервисов следует избегать основанных на GET форм для представления конфиденциальных данных, поскольку эти данные будут помещены в целевой запрос. Многие существующие серверы, прокси и пользовательские агенты регистрируют или отображают целевой запрос в местах, где он может быть виден третьим лицам. Такие службы должны использовать отправку формы на основе POST.

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

9.5. Раскрытие фрагмента после перенаправления

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

9.6. Раскрытие информации о продукте

Поля заголовка User-Agent (раздел 5.5.3), Via (раздел 5.7.1 [RFC7230 #])) и Server (раздел 7.4.2) часто содержат информацию о программных системах соответствующего отправителя. Теоретически, это может помочь злоумышленнику использовать известные дыры в безопасности; на практике злоумышленники, как правило, пробуют все потенциальные дыры независимо от используемых версий программного обеспечения.

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

9.7. Отпечатки пальцев в браузере

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

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

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

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

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

 

10. Благодарности

См. Раздел 10 [RFC7230 #].

 

11. Ссылки

11.1. Нормативные ссылки

[RFC2045] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies», RFC 2045, November 1996.

[RFC2046] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types», RFC 2046, November 1996.

[RFC2119] Bradner, S., «Key words for use in RFCs to Indicate Requirement Levels», BCP 14, RFC 2119, March 1997.

[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, «Uniform Resource Identifier (URI): Generic Syntax», STD 66, RFC 3986, January 2005.

[RFC4647] Phillips, A., Ed. and M. Davis, Ed., «Matching of Language Tags», BCP 47, RFC 4647, September 2006.

[RFC5234] Crocker, D., Ed. and P. Overell, «Augmented BNF for Syntax Specifications: ABNF», STD 68, RFC 5234, January 2008.

[RFC5646] Phillips, A., Ed. and M. Davis, Ed., «Tags for Identifying Languages», BCP 47, RFC 5646, September 2009.

[RFC6365] Hoffman, P. and J. Klensin, «Terminology Used in Internationalization in the IETF», BCP 166, RFC 6365, September 2011.

[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing», RFC 7230, June 2014.

[RFC7232] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests», RFC 7232, June 2014.

[RFC7233] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Range Requests», RFC 7233, June 2014.

[RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Caching», RFC 7234, June 2014.

[RFC7235] Fielding, R., Ed. and J. Reschke, Ed., «Hypertext Transfer Protocol (HTTP/1.1): Authentication», RFC 7235, June 2014.

 

11.2. Информационные ссылки

[BCP13] Freed, N., Klensin, J., and T. Hansen, «Media Type Specifications and Registration Procedures», BCP 13, RFC 6838, January 2013.

[BCP178] Saint-Andre, P., Crocker, D., and M. Nottingham, «Deprecating the «X-» Prefix and Similar Constructs in Application Protocols», BCP 178, RFC 6648, June 2012.

[BCP90] Klyne, G., Nottingham, M., and J. Mogul, «Registration Procedures for Message Header Fields», BCP 90, RFC 3864, September 2004.

[OWASP] van der Stock, A., Ed., «A Guide to Building Secure Web Applications and Web Services», The Open Web Application Security Project (OWASP) 2.0.1, July 2005, <https://www.owasp.org/>.

[REST] Fielding, R., «Architectural Styles and the Design of Network-based Software Architectures», Doctoral Dissertation, University of California, Irvine,
September 2000, <http://roy.gbiv.com/pubs/dissertation/top.htm>.

[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, «Hypertext Transfer Protocol — HTTP/1.0», RFC 1945, May 1996.

[RFC2049] Freed, N. and N. Borenstein, «Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples», RFC 2049, November 1996.

[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2068, January 1997.

[RFC2295] Holtman, K. and A. Mutz, «Transparent Content Negotiation in HTTP», RFC 2295, March 1998.

[RFC2388] Masinter, L., «Returning Values from Forms: multipart/form-data», RFC 2388, August 1998.

[RFC2557] Palme, F., Hopmann, A., Shelness, N., and E. Stefferud, «MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)», RFC 2557, March 1999.

[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, «Hypertext Transfer Protocol — HTTP/1.1», RFC 2616, June 1999.

[RFC2774] Frystyk, H., Leach, P., and S. Lawrence, «An HTTP Extension Framework», RFC 2774, February 2000.

[RFC2817] Khare, R. and S. Lawrence, «Upgrading to TLS Within HTTP/1.1», RFC 2817, May 2000.

[RFC2978] Freed, N. and J. Postel, «IANA Charset Registration Procedures», BCP 19, RFC 2978, October 2000.

[RFC5226] Narten, T. and H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, May 2008.

[RFC5246] Dierks, T. and E. Rescorla, «The Transport Layer Security (TLS) Protocol Version 1.2», RFC 5246, August 2008.

[RFC5322] Resnick, P., «Internet Message Format», RFC 5322, October 2008.

[RFC5789] Dusseault, L. and J. Snell, «PATCH Method for HTTP», RFC 5789, March 2010.

[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, «Network Time Protocol Version 4: Protocol and Algorithms Specification», RFC 5905, June 2010.

[RFC5987] Reschke, J., «Character Set and Language Encoding for Hypertext Transfer Protocol (HTTP) Header Field Parameters», RFC 5987, August 2010.

[RFC5988] Nottingham, M., «Web Linking», RFC 5988, October 2010.

[RFC6265] Barth, A., «HTTP State Management Mechanism», RFC 6265, April 2011.

[RFC6266] Reschke, J., «Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)», RFC 6266, June 2011.

[RFC7238] Reschke, J., «The Hypertext Transfer Protocol (HTTP) Status Code 308 (Permanent Redirect)», RFC 7238, June 2014.

 

Приложение А. Различия между HTTP и MIME

HTTP / 1.1 использует многие конструкции, определенные для формата сообщений Интернета [RFC5322 #] и многоцелевых расширений почты Интернета (MIME) [RFC2045 #], чтобы разрешить передачу тела сообщения в открытом множестве представлений и с расширяемыми полями заголовка. Однако RFC 2045 ориентирован только на электронную почту; приложения HTTP имеют много характеристик, которые отличаются от электронной почты; следовательно, HTTP имеет функции, которые отличаются от MIME. Эти различия были тщательно выбраны, чтобы оптимизировать производительность по сравнению с двоичными соединениями, чтобы дать большую свободу в использовании новых типов носителей, упростить сравнение дат и признать практику некоторых ранних HTTP-серверов и клиентов.

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

A.1. MIME-Version

HTTP не является MIME-совместимым протоколом. Однако сообщения могут включать одно поле заголовка MIME-Version, чтобы указать, какая версия протокола MIME использовалась для создания сообщения. Использование поля заголовка MIME-Version указывает, что сообщение полностью соответствует протоколу MIME (как определено в [RFC2045 #]). Отправители несут ответственность за обеспечение полного соответствия (где это возможно) при экспорте HTTP-сообщений в строгие среды MIME.

А.2. Преобразование в каноническую форму

MIME требует, чтобы перед отправкой часть тела почты в Интернете была преобразована в каноническую форму, как описано в Разделе 4 [RFC2049 #]. Раздел 3.1.1.3 этого документа описывает формы, разрешенные для подтипов «текстового» типа мультимедиа при передаче по HTTP. [RFC2046 #] требует, чтобы контент с типом «текст» представлял разрывы строк как CRLF, и запрещает использование CR или LF вне последовательностей разрывов строк. HTTP позволяет CRLF, голым CR и голым LF указывать разрыв строки в текстовом содержимом.

Прокси или шлюз от HTTP до строгой среды MIME должны преобразовывать все разрывы строк в текстовых типах мультимедиа, описанных в разделе 3.1.1.3 этого документа, в каноническую форму RFC 2049 # CRLF. Однако обратите внимание, что это может быть осложнено наличием Content-Encoding и тем фактом, что HTTP позволяет использовать некоторые кодировки, которые не используют октеты 13 и 10 для представления CR и LF, соответственно.

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

А.3. Преобразование форматов даты

HTTP / 1.1 использует ограниченный набор форматов даты (Раздел 7.1.1.1), чтобы упростить процесс сравнения дат. Прокси и шлюзы из других протоколов должны гарантировать, что любое поле заголовка Date, присутствующее в сообщении, соответствует одному из форматов HTTP / 1.1, и переписать дату, если необходимо.

А.4. Конвертация контент-кодирования

MIME не содержит никакой концепции, эквивалентной полю заголовка Content-Encoding HTTP / 1.1. Поскольку это действует как модификатор типа носителя, прокси и шлюзы от HTTP до MIME-совместимых протоколов должны либо изменить значение поля заголовка Content-Type, либо декодировать представление перед пересылкой сообщения. (Некоторые экспериментальные приложения Content-Type для Интернет-почты использовали параметр типа носителя «;conversions=<content-coding>» для выполнения функции, эквивалентной Content-Encoding. Однако этот параметр не является частью стандартов MIME ).

А.5. Преобразование Content-Transfer-Encoding

HTTP не использует поле Content-Transfer-Encoding в MIME. Прокси и шлюзы от MIME-совместимых протоколов к HTTP должны удалить любое Content-Transfer-Encoding до доставки ответного сообщения клиенту HTTP.

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

А.6. MHTML и ограничения длины строки

Реализации HTTP, которые совместно используют код с реализациями MHTML [RFC2557 #], должны знать об ограничениях длины строки MIME. Поскольку HTTP не имеет этого ограничения, HTTP не сворачивает длинные строки. Сообщения MHTML, транспортируемые по HTTP, следуют всем соглашениям MHTML, включая ограничения длины строки и свертывание, канонизацию и т. д., Поскольку HTTP передает тела сообщений в качестве полезной нагрузки и, кроме типа «multipart / byteranges» (Приложение A к [RFC7233 #]) ), не интерпретирует содержимое или любые строки заголовка MIME, которые могут содержаться в нем.

 

Приложение B. Изменения по сравнению с RFC 2616

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

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

Был добавлен алгоритм для определения, связана ли полезная нагрузка с конкретным идентификатором. (Раздел 3.1.4.1)

Набор символов по умолчанию ISO-8859-1 для текстовых типов носителей был удален; по умолчанию теперь используется то, что говорит определение типа носителя. Аналогично, специальная обработка ISO-8859-1 была удалена из поля заголовка Accept-Charset. (Раздел 3.1.1.3 и Раздел 5.3.3)

Определение Content-Location было изменено, чтобы больше не влиять на базовый URI для разрешения относительных ссылок URI из-за плохой поддержки реализации и нежелательного эффекта потенциального разрыва относительных ссылок в согласованных по содержимому ресурсах. (Раздел 3.1.4.2)

В соответствии с алгоритмом синтаксического анализа, не зависящим от метода [RFC7230 #], определение GET было упрощено, поэтому запросы могут иметь тело, даже если тело не имеет значения для GET. (Раздел 4.3.1)

Серверы больше не обязаны обрабатывать все поля заголовка Content- *, и использование Content-Range было явно запрещено в запросах PUT. (Раздел 4.3.4)

Определение метода CONNECT было перенесено из [RFC2817 #] в эту спецификацию. (Раздел 4.3.6)

Методы запроса OPTIONS и TRACE были определены как безопасные. (Раздел 4.3.7 и Раздел 4.3.8)

Механизм расширения поля заголовка Expect был удален из-за широко распространенных сломанных реализаций. (Раздел 5.1.1)

Поле заголовка Max-Forwards ограничено методами OPTIONS и TRACE; ранее методы расширения могли бы также использовать его. (Раздел 5.1.2)

URI «about: blank» был предложен в качестве значения для поля заголовка Referer, если не применяется ссылающийся URI, что отличает этот случай от других случаев, когда поле Referer не было отправлено или было удалено. (Раздел 5.5.2)

Следующие коды состояния теперь кешируются (то есть они могут храниться и повторно использоваться кешем без явной информации о свежести): 204, 404, 405, 414, 501. (Раздел 6)

Описание статуса 201 (Создано) было изменено, чтобы обеспечить возможность создания более одного ресурса. (Раздел 6.3.2)

Определение 203 (неавторизованная информация) было расширено и теперь включает случаи преобразования полезной нагрузки. (Раздел 6.3.4)

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

Коды состояния 301 и 302 были изменены, чтобы пользовательские агенты могли переписать метод с POST на GET. (Разделы 6.4.2 и 6.4.3)

Описание кода состояния 303 (см. «Другое») было изменено, чтобы разрешить его кэширование, если дана явная информация о свежести, и было добавлено конкретное определение для ответа 303 на GET. (Раздел 6.4.4)

Код состояния 305 (Использовать прокси) устарел из-за проблем безопасности, связанных с внутриполосной настройкой прокси. (Раздел 6.4.5)

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

Код состояния 426 (требуется обновление) был включен из [RFC2817 #]. (Раздел 6.5.15)

Целевые требования к HTTP-дате и полю заголовка Date были уменьшены для тех систем, которые генерируют дату, а не для всех систем, отправляющих дату. (Раздел 7.1.1)

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

Разрешить было реклассифицировано как поле заголовка ответа, удалив возможность указать его в запросе PUT. Требования к содержанию Разрешить были смягчены; соответственно, клиенты не обязаны всегда доверять его стоимости. (Раздел 7.4.1)

Реестр методов был определен. (Раздел 8.1)

Реестр кодов состояния был переопределен этой спецификацией; ранее это было определено в Разделе 7.1 [RFC2817 #]. (Раздел 8.2)

Регистрация кодировок контента была изменена, чтобы требовать пересмотра IETF. (Раздел 8.4)

Поле заголовка Content-Disposition было удалено, поскольку теперь оно определено в [RFC6266 #].

Поле заголовка Content-MD5 было удалено, потому что оно было непоследовательно реализовано в отношении частичных ответов.

 

Приложение C. Импортированный ABNF

Следующие основные правила включены посредством ссылки, как определено в Приложении B.1 [RFC5234 #]: ALPHA (буквы), CR (возврат каретки), CRLF (CR LF), CTL (элементы управления), DIGIT (десятичное 0-9) , DQUOTE (двойная кавычка), HEXDIG (шестнадцатеричный 0-9 / AF / af), HTAB (горизонтальная табуляция), LF (перевод строки), OCTET (любая 8-битная последовательность данных), SP (пробел) и VCHAR ( любой видимый символ US-ASCII).

Правила ниже определены в [RFC7230 #]:

BWS = <BWS, see [RFC7230 #], Section 3.2.3>
OWS = <OWS, see [RFC7230 #], Section 3.2.3>
RWS = <RWS, see [RFC7230 #], Section 3.2.3>
URI-reference = <URI-reference, see [RFC7230 #], Section 2.7>
absolute-URI = <absolute-URI, see [RFC7230 #], Section 2.7>
comment = <comment, see [RFC7230 #], Section 3.2.6>
field-name = <comment, see [RFC7230 #], Section 3.2>
partial-URI = <partial-URI, see [RFC7230 #], Section 2.7>

quoted-string = <quoted-string, see [RFC7230 #], Section 3.2.6>
token = <token, see [RFC7230 #], Section 3.2.6>

 

Приложение D. Собранный ABNF

В приведенной ниже ABNF правила списка расширены в соответствии с разделом 1.2 [RFC7230 #].

Accept = [ ( «,» / ( media-range [ accept-params ] ) ) *( OWS «,» [OWS ( media-range [ accept-params ] ) ] ) ]
Accept-Charset = *( «,» OWS ) ( ( charset / «*» ) [ weight ] ) *( OWS «,» [ OWS ( ( charset / «*» ) [ weight ] ) ] )
Accept-Encoding = [ ( «,» / ( codings [ weight ] ) ) *( OWS «,» [ OWS ( codings [ weight ] ) ] ) ]
Accept-Language = *( «,» OWS ) ( language-range [ weight ] ) *( OWS «,» [ OWS ( language-range [ weight ] ) ] )
Allow = [ ( «,» / method ) *( OWS «,» [ OWS method ] ) ]

BWS = <BWS, see [RFC7230 #], Section 3.2.3>

Content-Encoding = *( «,» OWS ) content-coding *( OWS «,» [ OWS content-coding ] )
Content-Language = *( «,» OWS ) language-tag *( OWS «,» [ OWS language-tag ] )
Content-Location = absolute-URI / partial-URI
Content-Type = media-type

Date = HTTP-date

Expect = «100-continue»

From = mailbox

GMT = %x47.4D.54 ; GMT

HTTP-date = IMF-fixdate / obs-date

IMF-fixdate = day-name «,» SP date1 SP time-of-day SP GMT

Location = URI-reference

Max-Forwards = 1*DIGIT

OWS = <OWS, see [RFC7230 #], Section 3.2.3>

RWS = <RWS, see [RFC7230 #], Section 3.2.3>
Referer = absolute-URI / partial-URI
Retry-After = HTTP-date / delay-seconds

Server = product *( RWS ( product / comment ) )

URI-reference = <URI-reference, see [RFC7230 #], Section 2.7>
User-Agent = product *( RWS ( product / comment ) )

Vary = «*» / ( *( «,» OWS ) field-name *( OWS «,» [ OWS field-name ]) )

absolute-URI = <absolute-URI, see [RFC7230 #], Section 2.7>
accept-ext = OWS «;» OWS token [ «=» ( token / quoted-string ) ]
accept-params = weight *accept-ext
asctime-date = day-name SP date3 SP time-of-day SP year

charset = token
codings = content-coding / «identity» / «*»
comment = <comment, see [RFC7230 #], Section 3.2.6>
content-coding = token

date1 = day SP month SP year
date2 = day «-» month «-» 2DIGIT
date3 = month SP ( 2DIGIT / ( SP DIGIT ) )
day = 2DIGIT
day-name = %x4D.6F.6E ; Mon
/ %x54.75.65 ; Tue
/ %x57.65.64 ; Wed
/ %x54.68.75 ; Thu
/ %x46.72.69 ; Fri
/ %x53.61.74 ; Sat
/ %x53.75.6E ; Sun
day-name-l = %x4D.6F.6E.64.61.79 ; Monday
/ %x54.75.65.73.64.61.79 ; Tuesday
/ %x57.65.64.6E.65.73.64.61.79 ; Wednesday
/ %x54.68.75.72.73.64.61.79 ; Thursday
/ %x46.72.69.64.61.79 ; Friday
/ %x53.61.74.75.72.64.61.79 ; Saturday
/ %x53.75.6E.64.61.79 ; Sunday
delay-seconds = 1*DIGIT

field-name = <comment, see [RFC7230 #], Section 3.2>

hour = 2DIGIT

language-range = <language-range, see [RFC4647 #], Раздел 2.1>
language-tag = <Language-Tag, see [RFC5646 #], Раздел 2.1>

mailbox = <mailbox, see [RFC5322 #], Раздел 3.4>
media-range = ( «*/*» / ( type «/*» ) / ( type «/» subtype ) ) *( OWS «;» OWS parameter )

media-type = type «/» subtype *( OWS «;» OWS parameter )
method = token
minute = 2DIGIT
month = %x4A.61.6E ; Jan
/ %x46.65.62 ; Feb
/ %x4D.61.72 ; Mar
/ %x41.70.72 ; Apr
/ %x4D.61.79 ; May
/ %x4A.75.6E ; Jun
/ %x4A.75.6C ; Jul
/ %x41.75.67 ; Aug
/ %x53.65.70 ; Sep
/ %x4F.63.74 ; Oct
/ %x4E.6F.76 ; Nov
/ %x44.65.63 ; Dec

obs-date = rfc850-date / asctime-date

parameter = token «=» ( token / quoted-string )
partial-URI = <partial-URI, see [RFC7230 #], Section 2.7>
product = token [ «/» product-version ]
product-version = token
quoted-string = <quoted-string, see [RFC7230 #], Section 3.2.6>
qvalue = ( «0» [ «.» *3DIGIT ] ) / ( «1» [ «.» *3″0″ ] )

rfc850-date = day-name-l «,» SP date2 SP time-of-day SP GMT

second = 2DIGIT
subtype = token

time-of-day = hour «:» minute «:» second
token = <token, see [RFC7230 #], Section 3.2.6>
type = token

weight = OWS «;» OWS «q=» qvalue

year = 4DIGIT

Индекс

1
1xx Informational (status code class) 50
2
2xx Successful (status code class) 51
3
3xx Redirection (status code class) 54
4
4xx Client Error (status code class) 58
5
5xx Server Error (status code class) 62
1
100 Continue (status code) 50
100-continue (expect value) 34
101 Switching Protocols (status code) 50
2
200 OK (status code) 51
201 Created (status code) 52
202 Accepted (status code) 52
203 Non-Authoritative Information (status code) 52
204 No Content (status code) 53
205 Reset Content (status code) 53
3
300 Multiple Choices (status code) 55
301 Moved Permanently (status code) 56
302 Found (status code) 56
303 See Other (status code) 57
305 Use Proxy (status code) 58
306 (Unused) (status code) 58
307 Temporary Redirect (status code) 58
4
400 Bad Request (status code) 58
402 Payment Required (status code) 59
403 Forbidden (status code) 59
404 Not Found (status code) 59
405 Method Not Allowed (status code) 59
406 Not Acceptable (status code) 59
408 Request Timeout (status code) 60
409 Conflict (status code) 60

410 Gone (status code) 60
411 Length Required (status code) 61
413 Payload Too Large (status code) 61
414 URI Too Long (status code) 61
415 Unsupported Media Type (status code) 62
417 Expectation Failed (status code) 62
426 Upgrade Required (status code) 62
5
500 Internal Server Error (status code) 63
501 Not Implemented (status code) 63
502 Bad Gateway (status code) 63
503 Service Unavailable (status code) 63
504 Gateway Timeout (status code) 63
505 HTTP Version Not Supported (status code) 64
A
Accept header field 38
Accept-Charset header field 40
Accept-Encoding header field 41
Accept-Language header field 42
Allow header field 72
C
cacheable 24
compress (content coding) 11
conditional request 36
CONNECT method 30
content coding 11
content negotiation 6
Content-Encoding header field 12
Content-Language header field 13
Content-Location header field 15
Content-Transfer-Encoding header field 89
Content-Type header field 10
D
Date header field 67
deflate (content coding) 11
DELETE method 29
E
Expect header field 34
F
From header field 44

G
GET method 24
Grammar
Accept 38
Accept-Charset 40
Accept-Encoding 41
accept-ext 38
Accept-Language 42
accept-params 38
Allow 72
asctime-date 66
charset 9
codings 41
content-coding 11
Content-Encoding 12
Content-Language 13
Content-Location 15
Content-Type 10
Date 67
date1 65
day 65
day-name 65
day-name-l 65
delay-seconds 69
Expect 34
From 44
GMT 65
hour 65
HTTP-date 65
IMF-fixdate 65
language-range 42
language-tag 13
Location 68
Max-Forwards 36
media-range 38
media-type 8
method 21
minute 65
month 65
obs-date 66
parameter 8
product 46
product-version 46
qvalue 38
Referer 45
Retry-After 69
rfc850-date 66
second 65

Server 73
subtype 8
time-of-day 65
type 8
User-Agent 46
Vary 70
weight 38
year 65
gzip (content coding) 11
H
HEAD method 25
I
idempotent 23
L
Location header field 68
M
Max-Forwards header field 36
MIME-Version header field 89
O
OPTIONS method 31
P
payload 17
POST method 25
PUT method 26
R
Referer header field 45
representation 7
Retry-After header field 69
S
safe 22
selected representation 7, 71
Server header field 73
Status Codes Classes
1xx Informational 50
2xx Successful 51
3xx Redirection 54
4xx Client Error 58
5xx Server Error 62

T
TRACE method 32
U
User-Agent header field 46
V
Vary header field 70
X
x-compress (content coding) 11
x-gzip (content coding) 11

 

Адреса авторов

Roy T. Fielding (editor)
Adobe Systems Incorporated
345 Park Ave
San Jose, CA 95110
USA
EMail: fielding@gbiv.com
URI: http://roy.gbiv.com/

Julian F. Reschke (editor)
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
EMail: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/