URL縮短器301重定向理解

我們正在使用PHP中的URL縮短器項目。我們使用301 HTTP重定向，並自然地跟蹤我們的鏈接訪問。但有一些奇怪的：URL縮短器301重定向理解

在我們縮短一個URL並通過瀏覽器瀏覽它之後，只有第一次訪問被跟蹤，並且似乎沒有其他請求發送到我們的服務器，並且它直接轉到目標URL （我認爲這是一次嘗試後的瀏覽器緩存）。但是：

嘗試使用類似服務時，如bitly，它有不同的待遇。一些在相同的瀏覽器上被跟蹤的訪問跟蹤（實際上不止一個，我不明白爲什麼，我沒有看到任何邏輯），同時他們也使用301重定向。在瀏覽器窗口的左下方有時會寫入「等待bit.ly ...」，有時不會，實際上是隨機的）。

這裏是否包含任何技巧？這種不同的待遇發生了什麼

來源

2012-11-02 Aliweb

閱讀HTTP specification。一個301響應告訴請求的資源已permanantly移動到被重定向到新的URL，瀏覽器，不應該再使用原來的網址：

10.3.2 301永久移動

請求資源已被分配一個新的永久URI，並且任何將來對該資源的引用都應該使用返回的URI中的一個。在可能的情況下，具有鏈接編輯功能的客戶端應自動將對Request-URI的引用重新鏈接到服務器返回的新引用的一個或多個。除非另有說明，否則這個響應是可緩存的。

新的永久URI應該由響應中的位置字段給出。除非請求方法是HEAD，否則響應的實體應該包含一個簡短的超文本註釋，其中包含一個到新的URI的超文本鏈接到
。

如果接收響應的301個狀態代碼到其他
比GET或HEAD的請求，用戶代理不必自動重定向
請求，除非它可以由用戶來確認，因爲這可能
變化請求發出的條件。

對您嘗試一下，嘗試使用302，303，或者307代替。

10.3.3 302實測值

請求的資源下不同的URI臨時駐留。
由於重定向有時可能會發生變化，因此客戶端應該繼續使用請求URI以用於將來的請求。該響應
僅在由緩存控制或過期報頭
字段指示時纔可緩存。

臨時URI應該由
響應中的Location字段給出。除非請求方法是HEAD，否則響應的實體應該包含一個簡短的超文本註釋，其中包含一個到新的URI的超文本鏈接到
。

如果接收響應302個狀態代碼到其他
比GET或HEAD的請求，用戶代理不必自動重定向
請求，除非它可以由用戶來確認，因爲這可能
變化請求發出的條件。
Note: RFC 1945 and RFC 2068 specify that the client is not allowed 
    to change the method on the redirected request. However, most 
    existing user agent implementations treat 302 as if it were a 303 
    response, performing a GET on the Location field-value regardless 
    of the original request method. The status codes 303 and 307 have 
    been added for servers that wish to make unambiguously clear which 
    kind of reaction is expected of the client. 

。

10.3.4 303查看其它

於所述請求的響應可以根據不同的URI被發現和應該使用該資源一GET方法來提取。此方法
主要用於允許POST激活的腳本輸出到
將用戶代理重定向到選定的資源。新的URI不是原始請求資源的替代引用。響應不得被緩存，但對第二個
（重定向）請求的響應可能是可緩存的。

不同的URI應該由
響應中的位置字段給出。除非請求方法是HEAD，否則響應的實體應該包含一個簡短的超文本註釋，其中包含一個到新的URI的超文本鏈接到
。
Note: Many pre-HTTP/1.1 user agents do not understand the 303 
    status. When interoperability with such clients is a concern, the 
    302 status code may be used instead, since most user agents react 
    to a 302 response as described here for 303. 

。

10.3.8 307臨時重定向

請求的資源下不同的URI臨時駐留。
因爲重定向可能偶爾被修改，所以客戶端應該繼續使用Request-URI作爲將來的請求。該響應
僅在由緩存控制或過期報頭
字段指示時纔可緩存。

臨時URI應該由
響應中的Location字段給出。除非請求方法是HEAD，所述
響應應該包含一個超鏈接的短的超文本註釋到
新URI（或多個）的實體，因爲許多預HTTP/1.1用戶代理不
明白307個狀態。因此，筆記應該包含用戶在新的URI上重複原始請求所需的信息。

如果接收響應307個狀態代碼到其他
比GET或HEAD的請求，用戶代理不必自動重定向
請求，除非它可以由用戶來確認，因爲這可能
變化請求發出的條件。

來源

2012-11-02 22:05:18

好吧，我在我的問題中說，也有點使用301重定向。但有時類似的請求被髮送到它的服務器並被跟蹤。那這個呢？ – Aliweb

我知道什麼是301重定向。我不明白造成治療不端的原因...... – Aliweb

你的'301'頭部和'301'頭部有什麼不同？ –

只是記下我的意見..

高速緩存控制頭也起到這個作用。如果您檢查捲曲或螢火蟲持續跟蹤，您可以在位置之前看到緩存控制標頭。如果用戶在90秒後點擊鏈接，則會將其配置爲與之聯繫。

來源

2015-09-15 01:16:52

URL縮短器301重定向理解

回答

相關問題