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

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

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

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

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

Поле заголовка запроса «Accept-Credentials» — это заголовок запроса, используемый для указания любому доверенному посреднику, как обрабатывать дополнительные защищенные соединения с прокси-серверами или серверами. Он НЕ ДОЛЖЕН включаться в запросы от сервера к клиенту. См. Раздел 19 из RFC 7826 для использования этого заголовка.

 

В запросе заголовок ДОЛЖЕН содержать метод (Пользователь, Прокси или Любой) для утверждения учетных данных, выбранных запрашивающей стороной. Метод НЕ ДОЛЖЕН быть изменен каким-либо прокси, если только он не является «Proxy» (Прокси), когда прокси МОЖЕТ изменить его на «user» (пользователь), чтобы взять на себя роль пользователя, одобряющего каждый последующий переход. Если метод «User» (Пользователь), заголовок содержит ноль или более учетных данных, которые принимает клиент. Заголовок может содержать нулевые учетные данные в первом запросе RTSP к серверу RTSP через прокси-сервер при использовании метода «User» (Пользователь). Это связано с тем, что клиент еще не получил никаких учетных данных для принятия. Каждое удостоверение ДОЛЖНО состоять из одного URI, идентифицирующего прокси-сервер или сервер, идентификатора алгоритма хеширования и хэша сертификата ASN.1 DER-encoded [RFC5280 #] этого агента в Base64, в соответствии с разделом 4 [RFC4648 #] и места установки битов заполнения в ноль. Все клиенты и прокси-серверы RTSP ДОЛЖНЫ реализовывать алгоритм SHA-256 [FIPS180-4] для вычисления хэша DER-кодированного сертификата. Алгоритм SHA-256 идентифицируется токеном «sha-256».

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

Пример:

Accept-Credentials:User
"rtsps://proxy2.example.com/";sha-256;exaIl9VMbQMOFGClx5rXnPJKVNI=,
"rtsps://server.example.com/";sha-256;lurbjj5khhB0NhIuOXtt4bBRH1M=

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

Accept-Credentials = "Accept-Credentials" HCOLON cred-decision
cred-decision = ("User" [LWS cred-info]) / "Proxy" / "Any" / (token [LWS 1*header-value]) ; Для будущих расширений
cred-info = cred-info-data *(COMMA cred-info-data)
cred-info-data = DQUOTE RTSP-REQ-URI DQUOTE SEMI hash-alg SEMI base64
hash-alg = "sha-256" / extension-alg
extension-alg = token

Ссылки

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

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

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