Поле заголовка тела сообщения «Content-Location» МОЖЕТ использоваться для предоставления местоположения ресурса для тела сообщения, заключенного в сообщении, когда это тело доступно из местоположения, отдельного от URI запрашиваемого ресурса. Сервер ДОЛЖЕН предоставить Content-Location для варианта, соответствующего телу ответного сообщения; особенно в случае, когда с ресурсом связано несколько вариантов, и эти объекты на самом деле имеют отдельные местоположения, по которым к ним можно получить индивидуальный доступ, сервер ДОЛЖЕН предоставить Content-Location для конкретного возвращаемого варианта. (раздел 18.18 из RFC 7826)
Например, если клиент RTSP выполняет запрос методом DESCRIBE для данного ресурса, например, «rtsp://a.example.com/movie/Plan9FromOuterSpace», то сервер может использовать дополнительную информацию, такую как заголовок User-Agent, чтобы определить возможности агента. Затем сервер вернет описание мультимедиа, предназначенное для этого класса агентов RTSP. Чтобы указать, какое конкретное описание получает агент, в Content-Location предоставляется идентификатор ресурса («rtsp://a.example.com/movie/Plan9FromOuterSpace/FullHD.sdp»), в то время как описание все еще является действительным ответом для универсального идентификатор ресурса, что позволяет выполнять как отладку, так и операции кеширования, как описано ниже.
Значение Content-Location не является заменой для исходного запрошенного URI; это только указание местоположения ресурса, соответствующего этому конкретному варианту на момент запроса. Будущие запросы МОГУТ указывать URI Content-Location в качестве URI запроса, если необходимо определить источник этого конкретного варианта. Это полезно, если агент RTSP хочет проверить, является ли вариант ресурса текущим с помощью условного запроса.
Кэш не может предполагать, что тело сообщения с Content-Location, отличным от URI, использованного для его получения, может использоваться для ответа на более поздние запросы по этому Content-Location URI. Тем не менее, Content-Location может использоваться для различения нескольких вариантов, извлеченных из одного запрошенного ресурса.
Если Content-Location является относительным URI, относительный URI интерпретируется относительно Request-URI.
Обратите внимание, что Content-Location может использоваться в некоторых случаях для получения базового URI для относительного URI, присутствующего в форматах описания сеанса. Это необходимо учитывать при использовании Content-Location. Самый простой способ избежать необходимости учитывать эту проблему — включать Content-Base всякий раз, когда включен Content-Location.
Также обратите внимание, что при использовании тегов мультимедиа в сочетании с Content-Location важно, чтобы разные версии имели разные MTag, даже если они предоставляются под разными URI Content-Location. Это связано с тем, что различные варианты содержимого все еще были предоставлены в ответ на один и тот же URI запроса.
Также обратите внимание, что, как и в большинстве случаев, URI, используемые в запросах DESCRIBE и SETUP, различаются: URI, предоставленный в ответе DESCRIBE Content-Location, не может напрямую использоваться в запросе SETUP. Вместо этого необходимы этапы получения URI медиаресурсов. Это обычно включает в себя объединение относительных URI описания мультимедиа, например, из атрибута a=control SDP, с base-URI для создания абсолютных URI, необходимых в запросе SETUP.
Поля заголовка тела сообщения перечислены в таблице.
Ссылки на документы
Скачать оригинальный документ на английском языке RFC 7826 — Real-Time Streaming Protocol Version 2.0
Читать полную версию документа на русском языке RFC 7826 — Потоковый протокол в реальном времени (RTSP), версия 2.0
Не забывайте про поля общих заголовков RTSP 2.0, которые могут применяться как в запросах так и в ответах.
Помните о полях заголовков запросов RTSP 2.0. Изучите методы RTSP 2.0 с которыми применяются коды состояний ответа.
