四、重定向（3字頭）

 

這類狀態(tài)碼代表需要客戶端采取進(jìn)一步的操作才能完成請(qǐng)求。通常，這些狀態(tài)碼用來重定向，后續(xù)的請(qǐng)求地址（重定向目標(biāo)）在本次響應(yīng)的 Location 域中指明。

 

當(dāng)且僅當(dāng)后續(xù)的請(qǐng)求所使用的方法是 GET 或者 HEAD 時(shí)，用戶瀏覽器才可以在沒有用戶介入的情況下自動(dòng)提交所需要的后續(xù)請(qǐng)求。客戶端應(yīng)當(dāng)自動(dòng)監(jiān)測(cè)無限循環(huán)重定向（例如：A->A，或者A->B->C->A），因?yàn)檫@會(huì)導(dǎo)致服務(wù)器和客戶端大量不必要的資源消耗。按照 HTTP/1.0 版規(guī)范的建議，瀏覽器不應(yīng)自動(dòng)訪問超過5次的重定向。

 

300 Multiple Choices

 

被請(qǐng)求的資源有一系列可供選擇的回饋信息，每個(gè)都有自己特定的地址和瀏覽器驅(qū)動(dòng)的商議信息。用戶或?yàn)g覽器能夠自行選擇一個(gè)首選的地址進(jìn)行重定向。

 

除非這是一個(gè) HEAD 請(qǐng)求，否則該響應(yīng)應(yīng)當(dāng)包括一個(gè)資源特性及地址的列表的實(shí)體，以便用戶或?yàn)g覽器從中選擇最合適的重定向地址。這個(gè)實(shí)體的格式由 Content-Type 定義的格式所決定。瀏覽器可能根據(jù)響應(yīng)的格式以及瀏覽器自身能力，自動(dòng)作出最合適的選擇。當(dāng)然，RFC 2616規(guī)范并沒有規(guī)定這樣的自動(dòng)選擇該如何進(jìn)行。

 

如果服務(wù)器本身已經(jīng)有了首選的回饋選擇，那么在 Location 中應(yīng)當(dāng)指明這個(gè)回饋的 URI；瀏覽器可能會(huì)將這個(gè) Location 值作為自動(dòng)重定向的地址。此外，除非額外指定，否則這個(gè)響應(yīng)也是可緩存的。

 

301 Moved Permanently

 

被請(qǐng)求的資源已永久移動(dòng)到新位置，并且將來任何對(duì)此資源的引用都應(yīng)該使用本響應(yīng)返回的若干個(gè) URI 之一。如果可能，擁有鏈接編輯功能的客戶端應(yīng)當(dāng)自動(dòng)把請(qǐng)求的地址修改為從服務(wù)器反饋回來的地址。除非額外指定，否則這個(gè)響應(yīng)也是可緩存的。

 

新的永久性的URI 應(yīng)當(dāng)在響應(yīng)的 Location 域中返回。除非這是一個(gè) HEAD 請(qǐng)求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的 URI 的超鏈接及簡(jiǎn)短說明。

 

如果這不是一個(gè) GET 或者 HEAD 請(qǐng)求，因此瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶的確認(rèn)，因?yàn)檎?qǐng)求的條件可能因此發(fā)生變化。

 

注意：對(duì)于某些使用 HTTP/1.0 協(xié)議的瀏覽器，當(dāng)它們發(fā)送的 POST 請(qǐng)求得到了一個(gè)301響應(yīng)的話，接下來的重定向請(qǐng)求將會(huì)變成 GET 方式。

 

302 Found

 

請(qǐng)求的資源現(xiàn)在臨時(shí)從不同的 URI 響應(yīng)請(qǐng)求。由于這樣的重定向是臨時(shí)的，客戶端應(yīng)當(dāng)繼續(xù)向原有地址發(fā)送以后的請(qǐng)求。只有在Cache-Control或Expires中進(jìn)行了指定的情況下，這個(gè)響應(yīng)才是可緩存的。

 

新的臨時(shí)性的URI 應(yīng)當(dāng)在響應(yīng)的 Location 域中返回。除非這是一個(gè) HEAD 請(qǐng)求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的 URI 的超鏈接及簡(jiǎn)短說明。

 

如果這不是一個(gè) GET 或者 HEAD 請(qǐng)求，那么瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶的確認(rèn)，因?yàn)檎?qǐng)求的條件可能因此發(fā)生變化。

 

注意：雖然RFC 1945和RFC 2068規(guī)范不允許客戶端在重定向時(shí)改變請(qǐng)求的方法，但是很多現(xiàn)存的瀏覽器將302響應(yīng)視作為303響應(yīng)，并且使用 GET 方式訪問在 Location 中規(guī)定的 URI，而無視原先請(qǐng)求的方法。狀態(tài)碼303和307被添加了進(jìn)來，用以明確服務(wù)器期待客戶端進(jìn)行何種反應(yīng)。

 

303 See Other

 

對(duì)應(yīng)當(dāng)前請(qǐng)求的響應(yīng)可以在另一個(gè) URI 上被找到，而且客戶端應(yīng)當(dāng)采用 GET 的方式訪問那個(gè)資源。這個(gè)方法的存在主要是為了允許由腳本激活的POST請(qǐng)求輸出重定向到一個(gè)新的資源。這個(gè)新的 URI 不是原始資源的替代引用。同時(shí)，303響應(yīng)禁止被緩存。當(dāng)然，第二個(gè)請(qǐng)求（重定向）可能被緩存。

 

新的URI 應(yīng)當(dāng)在響應(yīng)的 Location 域中返回。除非這是一個(gè) HEAD 請(qǐng)求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的 URI 的超鏈接及簡(jiǎn)短說明。

 

注意：許多 HTTP/1.1 版以前的瀏覽器不能正確理解303狀態(tài)。如果需要考慮與這些瀏覽器之間的互動(dòng)，302狀態(tài)碼應(yīng)該可以勝任，因?yàn)榇蠖鄶?shù)的瀏覽器處理302響應(yīng)時(shí)的方式恰恰就是上述規(guī)范要求客戶端處理303響應(yīng)時(shí)應(yīng)當(dāng)做的。

 

304 Not Modified

 

如果客戶端發(fā)送了一個(gè)帶條件的 GET 請(qǐng)求且該請(qǐng)求已被允許，而文檔的內(nèi)容（自上次訪問以來或者根據(jù)請(qǐng)求的條件）并沒有改變，則服務(wù)器應(yīng)當(dāng)返回這個(gè)狀態(tài)碼。304響應(yīng)禁止包含消息體，因此始終以消息頭后的第一個(gè)空行結(jié)尾。

 

該響應(yīng)必須包含以下的頭信息：

 

Date，除非這個(gè)服務(wù)器沒有時(shí)鐘。假如沒有時(shí)鐘的服務(wù)器也遵守這些規(guī)則，那么代理服務(wù)器以及客戶端可以自行將 Date 字段添加到接收到的響應(yīng)頭中去（正如RFC 2068中規(guī)定的一樣），緩存機(jī)制將會(huì)正常工作。

 

ETag 和/或 Content-Location，假如同樣的請(qǐng)求本應(yīng)返回200響應(yīng)。

 

Expires, Cache-Control，和/或Vary，假如其值可能與之前相同變量的其他響應(yīng)對(duì)應(yīng)的值不同的話。

 

假如本響應(yīng)請(qǐng)求使用了強(qiáng)緩存驗(yàn)證，那么本次響應(yīng)不應(yīng)該包含其他實(shí)體頭；否則（例如，某個(gè)帶條件的 GET 請(qǐng)求使用了弱緩存驗(yàn)證），本次響應(yīng)禁止包含其他實(shí)體頭；這避免了緩存了的實(shí)體內(nèi)容和更新了的實(shí)體頭信息之間的不一致。

 

假如某個(gè)304響應(yīng)指明了當(dāng)前某個(gè)實(shí)體沒有緩存，那么緩存系統(tǒng)必須忽視這個(gè)響應(yīng)，并且重復(fù)發(fā)送不包含限制條件的請(qǐng)求。

 

假如接收到一個(gè)要求更新某個(gè)緩存條目的304響應(yīng)，那么緩存系統(tǒng)必須更新整個(gè)條目以反映所有在響應(yīng)中被更新的字段的值。

 

305 Use Proxy

 

被請(qǐng)求的資源必須通過指定的代理才能被訪問。Location 域中將給出指定的代理所在的 URI 信息，接收者需要重復(fù)發(fā)送一個(gè)單獨(dú)的請(qǐng)求，通過這個(gè)代理才能訪問相應(yīng)資源。只有原始服務(wù)器才能建立305響應(yīng)。

 

注意：RFC 2068中沒有明確305響應(yīng)是為了重定向一個(gè)單獨(dú)的請(qǐng)求，而且只能被原始服務(wù)器建立。忽視這些限制可能導(dǎo)致嚴(yán)重的安全后果。

 

306 Switch Proxy

 

在最新版的規(guī)范中，306狀態(tài)碼已經(jīng)不再被使用。

 

307 Temporary Redirect

 

請(qǐng)求的資源現(xiàn)在臨時(shí)從不同的URI 響應(yīng)請(qǐng)求。由于這樣的重定向是臨時(shí)的，客戶端應(yīng)當(dāng)繼續(xù)向原有地址發(fā)送以后的請(qǐng)求。只有在Cache-Control或Expires中進(jìn)行了指定的情況下，這個(gè)響應(yīng)才是可緩存的。

 

新的臨時(shí)性的URI 應(yīng)當(dāng)在響應(yīng)的 Location 域中返回。除非這是一個(gè)HEAD 請(qǐng)求，否則響應(yīng)的實(shí)體中應(yīng)當(dāng)包含指向新的URI 的超鏈接及簡(jiǎn)短說明。因?yàn)椴糠譃g覽器不能識(shí)別307響應(yīng)，因此需要添加上述必要信息以便用戶能夠理解并向新的 URI 發(fā)出訪問請(qǐng)求。

 

如果這不是一個(gè)GET 或者 HEAD 請(qǐng)求，那么瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶的確認(rèn)，因?yàn)檎?qǐng)求的條件可能因此發(fā)生變化。