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

Question

Смущен / вдохновлен комментарием к моему вопросу Уважают ли поисковые системы поле заголовка HTTP «Content-Location»? , я хотел бы знать, какова точная цель Content-Location поле заголовка в HTTP есть и как его можно использовать.

Answer 1

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

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

В ответ на запрос PUT или POST,

• Если URI Content-Location отличается от запрошенного URI, то запись в кэше по указанному URI становится недействительной. (см. https://tools.ietf.org/html/rfc7234#section-4.4 и https://tools.ietf.org/html/rfc2616#section-13.10)
• Если URI Content-Location совпадает с запрошенным URI, то это указывает кэшам, что ответ на запрос PUT / POST совпадает с ответом, который будет получен ответом 200 на запрос GET в том же месте и, таким образом, может быть кэширована. (см. https://tools.ietf.org/html/rfc7231#section-3.1.4.2) Обратите внимание, что Firefox и Chrome, по-видимому, не реализуют это.

Answer 2

HTTP-заголовок Content-Location должен объявлять уникальное местоположение ресурса, который использовался для ответа на HTTP GET (например, запрос был GET /frontpage HTTP/1.1, сервер может добавить HTTP-заголовок Content-Location: <a href="http://domain.com/frontpage.english.msie-optimized">http://domain.com/frontpage.english.msie-optimized</a>, информирующий пользовательский агент, что если это конкретный ответ потребуется позже, следует использовать предоставленное местоположение, поскольку исходное местоположение может зависеть от различных вещей, которые затем должны быть объяснены через заголовок "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 достаточно различаются (часть URL "directory" / "path" отличается).

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

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

Answer 3

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

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

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

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

Answer 4

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