RFC: 2068
Оригинал: Hypertext Transfer Protocol - HTTP/1.1
Другие версии: RFC 2616
Категория: Предложенный стандарт
Дата публикации:
Авторы: , , , ,
Перевод: Алексей Симонов

14.15. Content-Location

Поле заголовка объекта Content-Location может использоваться, чтобы предоставить местоположение ресурса для объекта, включенного в сообщение. В случае, где ресурсу связали множественные объекты с ним, и теми объектами фактически, имеют отдельные местоположения, которыми к ним можно было бы индивидуально обратиться, сервер должен предоставить Content-Location для определенного варианта, который возвращен. Кроме того, сервер ДОЛЖЕН предоставить Content-Location для ресурса, соответствующего объекту ответа.

Content-Location = "Content-Location" ":"
                  ( absoluteURI | relativeURI )

Если номер поля заголовка Content-Base присутствует, значение ContentLocation также определяет базовый унифицированный указатель информационного ресурса для объекта (см. раздел 14.11).

Значение Content-Location не замена для оригинала, который запрашивают URI; он — только оператор местоположения ресурса, соответствующего этому определенному объекту во время запроса.

Будущие запросы МОГУТ использовать Content-Location URI, если желание состоит в том, чтобы идентифицировать источник того определенного объекта.

Кэш не может предположить, что объект с Content-Location, отличным от URI, используемого, чтобы отыскать его, может использоваться, чтобы ответить на более поздние запросы на том Content-Location URI. Однако, ContentLocation может использоваться, чтобы дифференцироваться между множественными объектами, найденными от отдельного запрошенного ресурса, как описано в разделе 13.6.

Если Content-Location — относительный URI, URI интерпретируется относительно любого Content-Base URI, предоставленный в ответе. Если номер Content-Base предоставлен, относительный URI интерпретируется относительно Request-URI.

Страница 111 из 160

2007 - 2022 © Русские переводы RFC, IETF, ISOC.