搜索引擎是否尊重HTTP標題字段「Content-Location」？

我想知道搜索引擎是否尊重HTTP header field Content-Location。搜索引擎是否尊重HTTP標題字段「Content-Location」？

這可能是有用的，例如，當你要刪除的會話ID參數超出URL的：

GET /foo/bar?sid=HTTP/1.1 
Host: example.com 
… 

HTTP/1.1 200 OK 
Content-Location: http://example.com/foo/bar 
…

澄清：
我不想重定向請求，因爲刪除會話ID會導致完全不同的請求，因此可能也會有不同的響應。我只想說明所附迴應也可在其「主要網址」下找到。

也許我的例子不是我的問題意圖的好表現。所以請看What is the purpose of the HTTP header field 「Content-Location」?。

來源

2009-01-13 Gumbo

這不就是爲了擴展Content-Location的用途麼？這個規範使得它聽起來應該比查詢字符串有更大的區別。 – 2009-01-13 10:33:37

刪除查詢只是一個例子。但可能是我誤解了Content-Location的目的，而不是提供請求資源的真實位置。 – Gumbo 2009-01-13 12:13:41

我認爲這是確切的目的，但我認爲這個想法更像 URI：http://foo.com/listOfStuff/indexOfResult（基本上，標識集合的特定成員） Content-Location：http：// foo.com/path/to/individualItem（基本上，資源直接URI）我認爲你的想法很好，壽。 – 2009-01-13 16:26:43

我覺得Google剛剛公佈了我的問題的答案：the canonical link relation for declaring the canonical URL。

Maile Ohye從谷歌中寫道：

MickeyC說...
你應該使用的Content-Location頭代替，按：
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
「14.14內容位置」

@MikeyC：是的，從理論的角度來看，這是有道理的，我們當然認爲它。然而，有幾點讓我們選擇：

我們的數據顯示「Content-Location」標頭在很多網站上配置不正確。有時候，網站管理員會提供長而醜陋的網址，甚至不會重複 - 這可能是無意的。他們可能不知道他們的網絡服務器甚至發送Content-Location標頭。

聯繫網站所有者清理整個網絡中的內容定位問題將非常耗時。我們意識到，如果我們從一塊乾淨的平板開始，我們可以更快地提供功能。隨着微軟和雅虎！爲了支持這種格式，網站管理員只需要學習一種語法。

通常，網站管理員很難配置他們的Web服務器標題，但可以更容易地更改他們的HTML。 rel =「canonical」看起來像一個友好的屬性。

http://googlewebmastercentral.blogspot.com/2009/02/specify-your-canonical.html?showComment=1234714860000#c8376597054104610625

來源

2009-02-13 19:04:53 Gumbo