HTTP頭字段「Content-Location」的用途是什麼？

Question

困惑/受我的問題Do search engines respect the HTTP header field 「Content-Location」?的評論啓發，我想知道Content-Location header field in HTTP的確切用途是什麼以及如何使用它。

Answer 1

作爲對GET請求的響應，當請求的資源具有多個表示可用時，可以使用HTTP中的Content-Location。多種語言。返回資源的選擇取決於原始GET請求中的Accept頭。

通常，Content-Location標頭中指定的位置與原始請求URI中指定的位置不同。

響應於PUT或POST請求，

• 如果內容位置URI比請求的URI不同，則在所指示的URI高速緩存條目被無效。 （請參閱https://tools.ietf.org/html/rfc7234#section-4.4和https://tools.ietf.org/html/rfc2616#section-13.10）
• 如果Content-Location URI與所請求的URI相同，則表示要緩存對PUT/POST請求的響應與將由200接收的響應相同響應同一位置的GET請求，並因此可以被緩存。 （請參閱https://tools.ietf.org/html/rfc7231#section-3.1.4.2）請注意，Firefox和Chrome似乎沒有執行此操作。

Answer 2

Section 14.14 of RFC 2616狀態：

的內容位置實體頭字段時，可以使用的是 實體是從獨立的可訪問的位置，以提供用於封閉該消息中的實體的 資源位置所請求的資源 的URI ...

這在AtomPub (RFC 5023, Section 9.2)使用：

如果創建請求中包含一個Atom Entry文檔，從該服務器 後續響應包含字符換字符匹配Location頭一個Content-Location頭 ，則 客戶端被授權解釋響應實體作爲 新創建的條目的完整表示。如果沒有匹配的Content-Location標頭，客戶端肯定不會假設返回的 實體是創建的資源的完整表示。

Answer 3

如果您有興趣，請查看RFC2557：http://www.faqs.org/rfcs/rfc2557.html以獲取更深入的解釋。我目前正在爲這個課程寫這篇文章。這有點舊，但仍然相關。

Answer 4

內容 - 位置HTTP標頭應該聲明用於HTTP GET響應的資源的唯一位置（例如請求是GET /frontpage HTTP/1.1，服務器可能會添加HTTP標頭Content-Location: http://domain.com/frontpage.english.msie-optimized通知用戶代理，如果此特定響應是之後需要使用提供的位置，因爲原始位置可能取決於各種事情，應通過「Vary」標題解釋）。

但是請注意，HTTP內容 - 位置標頭是在現實世界中使用的問題，因爲不同的瀏覽器（用戶代理）不同的處理： http://mail.python.org/pipermail/web-sig/2004-October/000985.html

這是因爲2616款14.14它說「的價值Content-Location也定義了實體的基本URI「。簡而言之，一個合適的用戶代理將使用Content-Location頭部計算獲取文檔的BASE URL，如果獲取的文檔沒有定義BASE URL和實際獲取的URL並且Content-Location不同，則可能導致使用不同的相對URL （URL的「目錄」/「路徑」部分不同）。此外，我還沒有看到使用HTTP Content-Location的任何優勢（我曾希望這可以用於提示永久性書籤位置，以防萬一當前查看的URL變得不穩定，例如domain.com/新聞/最新，但似乎並非如此）。

我目前的建議是忘記HTTP的內容位置，但您可以將其用於MIME電子郵件。