您的當前位置： 首頁(yè) > 網(wǎng)站建設
發(fā)布時(shí)間：2026-05-05 00:46:07 瀏覽：8344 次
訪(fǎng)問(wèn)網(wǎng)站所反應的狀態(tài)重定信號叫做HTTP狀態(tài)碼，是向類(lèi)以三個(gè)數字為主的，我們看不到只是態(tài)碼瀏覽器可以檢測到這樣的信號。也就是介紹用以表示網(wǎng)頁(yè)服務(wù)器HTTP響應狀態(tài)的3位數的數字代碼，http狀態(tài)碼是狀態(tài)重定由RFC2616規范定義的，并得到了RFC 2518、向類(lèi)RFC 2817、態(tài)碼RFC 2295、介紹RFC 2774、狀態(tài)重定RFC 4918等規范擴(⊙_⊙)展。向類(lèi)h??ttp狀態(tài)碼的態(tài)碼第一個(gè)數字代表了相應的一??種狀態(tài)，通常??共有五種狀態(tài)形式。介紹
大寶把百度百科對HTTP狀態(tài)碼當中3開(kāi)頭的狀態(tài)重┐(′?｀)┌定重定向類(lèi)的狀態(tài)碼(???)的介紹分享給朋友們：
3開(kāi)頭的http狀態(tài)碼
代表需要客戶(hù)端采取進(jìn)一步的操作才能完成請求。通常，向類(lèi)這些狀態(tài)碼用來(lái)重定向，態(tài)碼后續的請求地址（重定向目標）在本次響應的(′ω｀) Loc??ation 域中指明。當且僅當后續的請求所使用的方法??是 GET 或者 HEAD 時(shí)，用戶(hù)瀏覽器才可以在沒(méi)有用戶(hù)介入的情況下自動(dòng)提交所需要的后續請求?？蛻?hù)端應當自動(dòng)監測無(wú)限循環(huán)重定向（例如：A->A，或者A->B->C->A），因為這會(huì )導致服務(wù)器和客戶(hù)端大量不必要的資源消耗。按照 HTTP/1.0 版規范的建議，瀏覽器不應自動(dòng)訪(fǎng)問(wèn)超過(guò)5次的重定向。
300 multiple="multiple" Choices
被請求的資源有一系列可供選擇的回饋信息，每個(gè)都(′?ω?`)有自己特定的地址和瀏覽器驅動(dòng)的商議信息。用戶(hù)或瀏覽器能( ?° ?? ?°)夠自行選擇一個(gè)首選的地址進(jìn)行重定向。 除非這是??一個(gè) HEAD 請求???，否則該響應應當包括一個(gè)資??源特性及地址的列表的實(shí)體，以便用戶(hù)或瀏覽器從中選擇最合適的重定向地址。這個(gè)實(shí)體的格式由 Content-Type 定義的格式所決定(′?｀)。瀏覽器可??能根據響應的格式以及瀏?覽器自身(shen)能力，自動(dòng)作出最合適的選擇??。當然，RFC 2616規范并沒(méi)有規定這樣的自動(dòng)選擇該如何進(jìn)行。如果服務(wù)器本身已經(jīng)有了首選的回饋選擇，那么在 Location 中應當指明這個(gè)回饋的 URI；瀏覽器可能會(huì )將(′▽?zhuān)?這個(gè) Location 值作為自動(dòng)重??定向的地址。此(′_｀)外，除非額外指定，否則這個(gè)響應也是可緩存的。
301 Moved Permanently
被請求的資源已永久移動(dòng)到新位置，(′▽?zhuān)?并且將來(lái)任何對此資源的引用都應該使用本響應返回的若干個(gè) URI 之一。如果可能，擁有鏈接編輯功能的客戶(hù)端應當(dang)自動(dòng)把請求的地址修改為從服務(wù)器反饋回來(lái)的地址。除非額外指定(???)，否則這個(gè)響應也是可緩存的。新的永久性的URI 應當在響應的 Location 域中返回。除非這是(shi)一??個(gè) HEAD 請求，否則響應的實(shí)體中(??-)?應當包含ˉ\_(ツ)_/ˉ指向新的 URI 的超鏈接及簡(jiǎn)ヾ(?■_■)ノ短說(shuō)明。如果這不是一個(gè) GET 或者 HEAD 請求??，因此瀏覽器禁止自動(dòng)進(jìn)行重定向，??除非得到用戶(hù)的(◎_◎;)確認，( ?° ?? ?°)因為請求的條件可能因此發(fā)生變化。注意：對于某些使用 HTTP/1.0 協(xié)議的瀏覽器，當它們發(fā)送的 POST 請求得到了一個(gè)301響應的話(huà)，接下來(lái)的重定向請求將會(huì )變成 GET 方式。
302 Move?? temporarily
請求的資源臨時(shí)從不同的 URI響應請求。由于這樣的重定向是臨時(shí)的，客戶(hù)端應當繼續向原有地址發(fā)送以后的請求。只有在(╥_╥)Cache-Control或Expires中進(jìn)行了指定的(′ω｀*)情況下，這個(gè)響(xiang)應才是可緩存的。上文(′ω｀)有提及。如果這不是一個(gè) GET 或者 HEAD 請求，那么瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶(hù)的確認，因為請求的條件可能因此發(fā)生變化。注意：雖然RFC 1945和RFC 2068規范不允許客戶(hù)端在重定向時(shí)改變請求的方法，但是很多現存的瀏覽器將302響應視作為303響應，并且使用 GET 方式訪(fǎng)問(wèn)在 Location 中規定的 URI??，而無(wú)視原先請求的方法。狀態(tài)碼303和307被添加了進(jìn)來(lái)，用以明確服務(wù)器期待客戶(hù)端進(jìn)行何種反應。
303 See Other
對應當前請求的響應可以在另一個(gè) URI 上被找到，而且客戶(hù)端應當采用 GE(╬?益?)T 的方式訪(fǎng)問(wèn)那個(gè)資源。這個(gè)方法的存在主要是為了??允許由腳本激活的POST請求輸出重定向到一個(gè)新的資源。這個(gè)新的 URI 不是原始資源的替代引用。同時(shí)，303響應禁止被緩存。當然，第二個(gè)請求（重定( ?ヮ?)向）可能被緩存。注意：許多 HTTP/1.1 版以前的瀏覽器不能正確理解303狀態(tài)。如果需要考慮與這些瀏覽器之間的互(⊙_⊙)動(dòng)，302狀態(tài)碼應該可以勝任，因為大多數的瀏覽器處理302響應時(shí)的方式恰恰就是上述規范要求客戶(hù)端處理303響應(′ω｀)時(shí)應當做的。
304 Not Modified
如果客戶(hù)端發(fā)送了一個(gè)帶??條件的 GET 請求且該請求已被允許，而文檔的內容（自上次訪(fǎng)問(wèn)以來(lái)或(???)者根據請求??的條件）并沒(méi)有改變，則服務(wù)器應當返回這個(gè)狀態(tài)碼(′；ω；`)。304ヽ(′ー｀)ノ響應禁止包含消息體，因此始終以消息頭后的第一個(gè)空行結尾。該響應必須包含以下的頭信息：D(′?｀*)ate，除非這個(gè)服務(wù)器沒(méi)有時(shí)鐘。假如沒(méi)有時(shí)鐘的服務(wù)器也遵守這些規則，那么代理服務(wù)器以及客戶(hù)端可以自行將 Da(T_T)te 字段添加到接收到的響應頭中去（正如(⊙_⊙)RFC(???) 2068中(zhong)規定的一樣），緩存機制將會(huì )正常工作。ETag 和/或 Content-Location，假如同樣的請求本應返回200響應。Expires, Cache-Control，和/或V(′?ω?`)ary，假如其值可能??與之前相同變量的其他響應對應的值不同的話(huà)。假如本響應請求使用了強緩( ???)存驗??證，那么本次響應不應該包含其他實(shí)體頭；否則（例如，某個(gè)帶條件的 GET 請求使用了(le)弱緩存驗證），本次響應禁止包含其他實(shí)體頭；這避?????免了緩存了的實(shí)體內容??和更新了的實(shí)體頭信息之間的不一致。假如某個(gè)304響應指明了當前某個(gè)實(shí)體沒(méi)有緩存，那么緩存系統必須忽視這個(gè)響應，并且重復發(fā)(fa)送不包含限制條件的請求。假如接收到一個(gè)要求更新某個(gè)緩存條目的304響應，那么緩存系統必須更新整個(gè)條目以反映所(suo)有在響應中被更新的字段的值。
305 Use Proxy
被請求的資源必須通過(guò)指定的代(dai)理才能被訪(fǎng)問(wèn)。Location 域中將給出指定的代理所在的 URI 信息，接收者需要重復發(fā)送一個(gè)單獨的(′?｀)請求，通(′ω｀)過(guò)這個(gè)代理才能訪(fǎng)問(wèn)相應資源。只有原始服務(wù)器才能建立305響應。注意：RFC 2068中沒(méi)有明確305響應是為了重定向一個(gè)單獨的請求??，而且只能被原始服務(wù)器建立。忽視這ヾ(′?｀)?些限制可能導致嚴重的安全后果。
306 Switch Proxy
在最新版的規范中(╯‵□′)╯，306狀態(tài)碼已經(jīng)不再被使用。
307 Temporary Redirect
請求的資源臨時(shí)從不同的URI 響應請求。新的臨時(shí)性的URI 應當在響應的 Location 域中返回。除非這是一個(gè)HEAD 請求，否則響應的實(shí)體中應當包含指向新的URI 的超鏈接及簡(jiǎn)短說(shuō)明。因為部分瀏覽器不能識別307響應，因此需要添加上述必要信息以便用戶(hù)能夠理解并向新的 URI 發(fā)出訪(fǎng)問(wèn)請求。??如果這不是一個(gè)GET 或者 HEAD 請求，那么瀏覽器禁止自動(dòng)進(jìn)行重定向，除非得到用戶(hù)的確認，因為請求的條件可能??因此發(fā)生變化。
接下來(lái)的博文會(huì )接著(zhù)分析關(guān)于4開(kāi)頭的客戶(hù)端出現錯誤所反應出的狀態(tài)碼介紹分享，敬請期待。
