RTSP 2.0 | Поле заголовка запроса Authorization

RTSP 2.0 | Поле заголовка запроса Authorization

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

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

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

 

Клиент RTSP, который желает аутентифицировать себя на сервере, используя механизм аутентификации из HTTP [RFC7235 #], обычно (но не обязательно) после получения ответа 401, делает это путем включения поля заголовка запроса «Authorization» в запрос. Значение поля Authorization состоит из учетных данных, содержащих информацию об аутентификации агента пользователя для области запрашиваемого ресурса. Определение заголовка содержится в [RFC7235 #], и любые применимые схемы аутентификации HTTP появляются в других RFC, таких как Digest [RFC7616 #] и Basic [RFC7617 #]. Этот заголовок ДОЛЖЕН использоваться только в клиент-серверных запросах.

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

Когда общий кэш (см. Раздел 16 из RFC 7826) получает запрос, содержащий поле Authorization, он НЕ ДОЛЖЕН возвращать соответствующий ответ в качестве ответа на любой другой запрос, если не выполнено одно из следующих конкретных исключений:

  1. Если ответ включает в себя директиву кэша «max-age», кеш МОЖЕТ использовать этот ответ при ответе на последующий запрос. Но (если указанный максимальный возраст прошел), кеш-прокси ДОЛЖЕН сначала подтвердить его подлинность на исходном сервере, используя заголовки запроса из нового запроса, чтобы разрешить исходному серверу аутентифицировать новый запрос. (Это определенное поведение для max-age.) Если ответ включает в себя «max-age = 0», прокси-сервер ДОЛЖЕН всегда проверять его правильность перед повторным использованием.
  2. Если ответ содержит директиву управления кэшем «must-revalidate», кеш МОЖЕТ использовать этот ответ при ответе на последующий запрос. Но если ответ устарел, все кэши ДОЛЖНЫ сначала подтвердить его на исходном сервере, используя заголовки запроса из нового запроса, чтобы разрешить исходному серверу аутентифицировать новый запрос.
  3. Если ответ содержит директиву кеша «public», он МОЖЕТ быть возвращен в ответ на любой последующий запрос.

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

Authorization = "Authorization" HCOLON credentials
credentials = <Определено в RFC 7235 #>

Ссылки

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

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

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