Какова цель поля заголовка HTTP "Content-Location"?

Ответ 1

Содержимое-местоположение в HTTP может использоваться, когда запрашиваемый ресурс имеет несколько представлений, например, нескольких языков. Выбор возвращаемого ресурса будет зависеть от заголовков Accept в исходном запросе GET.

Обычно местоположение, указанное в заголовке Content-Location, отличается от местоположения, указанного в исходном URI запроса.

Я не считаю, что Content_Location имеет какое-либо определенное поведение в ответ на запрос PUT или POST.

Ответ 2

Контент-местоположение HTTP-заголовок должен объявлять уникальное местоположение ресурса, который использовался для ответа на HTTP GET (например, запрос был GET /frontpage HTTP/1.1, сервер может добавлять HTTP-заголовок Content-Location: http://domain.com/frontpage.english.msie-optimized, информируя пользовательский агент, что если это конкретный ответ требуется позже, необходимо указать предоставленное местоположение, потому что исходное местоположение может зависеть от разных вещей, которое затем должно быть объяснено с помощью заголовка "Vary" ).

Однако обратите внимание, что заголовок HTTP Content-Location проблематичен в реальном мире, поскольку разные браузеры (пользовательские агенты) обрабатывают его по-разному: http://mail.python.org/pipermail/web-sig/2004-October/000985.html

Это из-за раздела 14.14 RFC 2616, в котором говорится, что "Значение Content-Location также определяет базовый URI для объекта". Короче говоря, подходящий пользовательский агент будет вычислять BASE-URL для выбранного документа, используя заголовок Content-Location, который может привести к использованию разных относительных URL-адресов, если выбранный документ не определяет URL-адрес BASE и реальные выбранные URL-адреса и Content-Location, (часть "directory" / "path" URL-адреса отличается).

Кроме того, я еще не вижу никакого преимущества для использования HTTP-контента-местоположения (я как-то надеялся, что это можно использовать для подсказки о постоянном местоположении закладки, если в данный момент просматриваемый URL был неустойчивым, например domain.com/news/последнее, но это, похоже, не так).

Мой текущий совет забывает о Content-Location для HTTP, но вы можете использовать его для электронной почты MIME.

Ответ 3

Раздел 14.14 RFC 2616 гласит:

Поле заголовка объекта Content-Location МОЖЕТ использоваться для предоставления расположение ресурсов для объекта, заключенного в сообщении, когда это объект доступен из местоположения, отдельно от запрашиваемого ресурс URI...

Это используется в AtomPub (RFC 5023, раздел 9.2):

Если запрос на создание содержал документ ввода Atom, и последующий ответ с сервера содержит заголовок Content-Location, который соответствует символу заголовка местоположения для символа, затем клиент имеет право интерпретировать объект ответа как полное представление вновь созданной записи. Без соответствия Заголовок Content-Location, клиент НЕ ДОЛЖЕН принимать возвращенные entity является полным представлением созданного Ресурса.

Ответ 4

ознакомьтесь с RFC2557 по адресу http://www.faqs.org/rfcs/rfc2557.html для более глубокого объяснения, если вы заинтересованы. В настоящее время я пишу об этом для класса. Это немного устарело, но по-прежнему актуально.