Http狀態碼之 301 302重定向

301 moved permanently 被請求的資源已永久移動到新位置，並且將來任何對此資源的引用都應該使用本響應返回的若干個uri之一。如果可能，擁有鏈結編輯功能的客戶端應當自動把請求的位址修改為從伺服器反饋回來的位址。除非額外指定，否則這個響應也是可快取的。 新的永久性的uri應當在響應的location域中返回。除非這是乙個head請求，否則響應的實體中應當包含指向新的uri的超連結及簡短說明。 如果這不是乙個get或者head請求，因此瀏覽器禁止自動進行重定向，除非得到使用者的確認，因為請求的條件可能因此發生變化。 注意：對於某些使用http/1.0協議的瀏覽器，當它們傳送的post請求得到了乙個301響應的話，接下來的重定向請求將會變成get方式。

302 found 請求的資源現在臨時從不同的uri響應請求。由於這樣的重定向是臨時的，客戶端應當繼續向原有位址傳送以後的請求。只有在cache-control或expires中進行了指定的情況下，這個響應才是可快取的。 新的臨時性的uri應當在響應的location域中返回。除非這是乙個head請求，否則響應的實體中應當包含指向新的uri的超連結及簡短說明。 如果這不是乙個get或者head請求，那麼瀏覽器禁止自動進行重定向，除非得到使用者的確認，因為請求的條件可能因此發生變化。 注意：雖然rfc 1945和rfc 2068規範不允許客戶端在重定向時改變請求的方法，但是很多現存的瀏覽器將302響應視作為303響應，並且使用get方式訪問在location中規定的uri，而無視原先請求的方法。狀態碼303和307被新增了進來，用以明確伺服器期待客戶端進行何種反應。

在使用者訪問後瀏覽器都會重定向到

302 重定向和**劫持（url hijacking） 從**a 做乙個302 重定向到**b 時，主機伺服器的隱含意思是**a 隨時有可能改主意，重新顯示本身的內容或轉向其他的地方。大部分的搜尋引擎在大部分情況下，當收到302重定向時，一般只要去抓取目標**就可以了，也就是說**b。如果搜尋引擎在遇到302 轉向時，百分之百的都抓取目標**b 的話，就不用擔心**url 劫持了。問題就在於，有的時候搜尋引擎，尤其是google，並不能總是抓取目標**。比如說，有的時候a **很短，但是它做了乙個302重定向到b**，而b**是乙個很長的亂七八糟的url**，甚至還有可能包含一些問號之類的引數。很自然的，a**更加使用者友好，而b**既難看，又不使用者友好。這時google很有可能會仍然顯示**a。由於搜尋引擎排名演算法只是程式而不是人，在遇到302重定向的時候，並不能像人一樣的去準確判定哪乙個**更適當，這就造成了**url劫持的可能性。也就是說，乙個不道德的人在他自己的**a做乙個302重定向到你的**b，出於某種原因， google搜尋結果所顯示的仍然是**a，但是所用的網頁內容卻是你的**b上的內容，這種情況就叫做**url 劫持。你辛辛苦苦所寫的內容就這樣被別人偷走了。302重定向所造成的**url劫持現象，已經存在一段時間了。不過到目前為止，似乎也沒有什麼更好的解決方法。在正在進行的谷歌大爸爸資料中心轉換中，302 重定向問題也是要被解決的目標之一。從一些搜尋結果來看，**劫持現象有所改善，但是並沒有完全解決。

是說除非真是臨時重定向使用302，其他的情況最好還是使用301吧

http狀態碼 狀態碼

http狀態碼301和302詳解及區別——辛酸的探索之路 

302重定向 

http之狀態碼

1xx 表示請求已經接收，進行進一步的處理 2xx 請求已經成功的接收並處理 3xx 請求重定向，需要另外的一些處理 4xx 客戶端錯誤，請求的有語法錯誤或者請求無法實現 5xx 伺服器端錯誤 200 客服端請求成功 400 客戶端請求語法錯誤 由於語法錯誤，無法滿足該請求。401 請求沒有經過授權...

301 302跳轉與200狀態碼

關於http三種狀態碼解釋如下 200 正常狀態，未發生任何事，普通頁面瀏覽一般都是200 301 永久性轉移 permanently moved seo必用的招式，會把舊頁面的pr等資訊轉移到新頁面 302 暫時性轉移 temporarily moved 很常用的招式，也是seo最容易被判作弊的方...

http之206狀態碼

206狀態碼，在html中，加乙個a標籤，a標籤的位址是乙個檔案，就可實現該效果。你可以通過range請求頭辨認出乙個部分內容請求.該請求頭表明了客戶端需要請求資源的哪一部分 在上圖的請求中,客戶端告訴伺服器,它需要該視屏檔案中從172,032到13,325,503位元組範圍內的資料.在大多數情況下...