RTSP 2.0 | Поле заголовка запроса Accept-Encoding

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

<Method> SP <Request-URI> SP <RTSP-Version> CRLF

Заголовки RTSP в таблице могут быть включены в запрос как request-headers (заголовки запроса), чтобы изменить специфику запроса.

Поле заголовка запроса «Accept-Encoding» аналогично полю «Accept», но оно ограничивает кодировки содержимого (см. Раздел 18.15 из RFC 7826), то есть кодировки преобразования тела сообщения, такие как сжатие gzip, которые являются приемлемыми в ответе.

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

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

Если в запросе присутствует поле Accept-Encoding, и если сервер не может отправить ответ, который является приемлемым в соответствии с заголовком Accept-Encoding, то сервер ДОЛЖЕН отправить ответ об ошибке с кодом состояния 406 (Not Acceptable).

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

Синтаксис поля заголовка запроса Accept-Encoding в RTSP 2.0

Accept-Encoding = "Accept-Encoding" HCOLON [ encoding *(COMMA encoding) ]
encoding = codings [SEMI accept-params]
codings = content-coding / "*"
content-coding = "identity" / token

Ссылки

Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0

Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0

Ссылка на синтаксис

Поделись записью