該狀態碼不被HTTP/1.0的應用程序直接使用，只是做為3xx類型回應的缺省解釋。存在多個可用的被請求資源。

 

除非是HEAD請求，否則回應的實體中必須包括這些資源的字符列表及位置信息，由用戶或用戶代理來決定哪個是最適合的。

 

如果服務器有首選，它應將對應的URL信息存放在位置域(Location field)處，用戶代理會根據此域的值來實現自動的重定向。

 

301 Moved Permanently

 

請求到的資源都會分配一個永久的URL，這樣就可以在將來通過該URL來訪問此資源。有編輯鏈接功能的客戶端會盡可能地根據服務器端傳回的新鏈接而自動更新請求URI。 新的URL必須由回應中的位置域指定。除非是HEAD請求，否則回應的實體主體 (Entity-Body)必須包括對新URL超鏈接的簡要描述。

 

如果用POST方法發出請求，而接收到301回應狀態碼。在這種情況下，除非用戶確認，否則用戶代理不必自動重定向請求，因為這將導致改變已發出請求的環境。

 

注意：當在接收到301狀態碼后而自動重定向POST請求時，一些現存的用戶代理會錯誤地將其改為GET請求。

 

302 Moved Temporarily

 

請求到的資源在一個不同的URL處臨時保存。因為重定向有時會被更改，客戶端應繼續用請求URI來發出以后的請求。新的URL必須由回應中的位置域指定。除非是HEAD請求，否則回應的實體主體 (Entity-Body)必須包括對新URL超鏈接的簡要描述。

 

如果用POST方法發出請求，而接收到302回應狀態碼。在這種情況下，除非用戶確認，否則用戶代理不必自動重定向請求，因為這將導致改變已發出請求的環境。

 

注意：當在接收到302狀態碼后而自動重定向POST請求時，一些現存的用戶代理會錯誤地將其改為GET請求。

 

304 Not Modified

 

如果客戶端成功執行了條件GET請求，而對應文件自If-Modified-Since域所指定的日期以來就沒有更新過，服務器應當回應此狀態碼，而不是將實體主體發送給客戶端。回應標題域中只應包括一些相關信息，比如緩存管理器、與實體最近更新(entity\'s Last-Modified)日期無關的修改。相關標題域的例子有：日期、服務器、過期時間。每當304回應中給出的域值發生變化，緩存都應當對緩存的實體進行更新。

 

以上就是小編關于服務器的重定向的解析。