前端控制台列印，狀态碼總結

   近期實習期間接手了一個購物的電商管理系統的前端項目，在寫代碼的過程中出現錯誤，而且在控制台列印了太多次不同錯誤狀态碼，一直不停的去搜尋，查找解決辦法，今天将自己遇到的幾個常見的狀态碼，以及搜尋出來的總結一下。不對的地方希望大家多多提意見。

分享

200	請求已成功，請求所希望的響應頭或資料體将随此響應傳回。出現此狀态碼是表示正常狀态。
201	請求已經被實作，而且有一個新的資源已經依據請求的需要而建立，且其 URI 已經随Location 頭資訊傳回。假如需要的資源無法及時建立的話，應當傳回 '202 Accepted'。
300	被請求的資源有一系列可供選擇的回饋資訊，每個都有自己特定的位址和浏覽器驅動的商議資訊。使用者或浏覽器能夠自行選擇一個首選的位址進行重定向。 除非這是一個 HEAD 請求，否則該響應應當包括一個資源特性及位址的清單的實體，以便使用者或浏覽器從中選擇最合适的重定向位址。這個實體的格式由 Content-Type 定義的格式所決定。浏覽器可能根據響應的格式以及浏覽器自身能力，自動作出最合适的選擇。當然，RFC 2616規範并沒有規定這樣的自動選擇該如何進行。 如果伺服器本身已經有了首選的回饋選擇，那麼在 Location 中應當指明這個回饋的 URI；浏覽器可能會将這個 Location 值作為自動重定向的位址。此外，除非額外指定，否則這個響應也是可緩存的。
301	被請求的資源已永久移動到新位置，并且将來任何對此資源的引用都應該使用本響應傳回的若幹個 URI 之一。如果可能，擁有連結編輯功能的用戶端應當自動把請求的位址修改為從伺服器回報回來的位址。除非額外指定，否則這個響應也是可緩存的。 新的永久性的URI 應當在響應的 Location 域中傳回。除非這是一個 HEAD 請求，否則響應的實體中應當包含指向新的 URI 的超連結及簡短說明。 如果這不是一個 GET 或者 HEAD 請求，是以浏覽器禁止自動進行重定向，除非得到使用者的确認，因為請求的條件可能是以發生變化。 注意：對于某些使用 HTTP/1.0 協定的浏覽器，當它們發送的 POST 請求得到了一個301響應的話，接下來的重定向請求将會變成 GET 方式。
302	請求的資源臨時從不同的 URI響應請求。由于這樣的重定向是臨時的，用戶端應當繼續向原有位址發送以後的請求。隻有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可緩存的。 上文有提及。 如果這不是一個 GET 或者 HEAD 請求，那麼浏覽器禁止自動進行重定向，除非得到使用者的确認，因為請求的條件可能是以發生變化。 注意：雖然RFC 1945和RFC 2068規範不允許用戶端在重定向時改變請求的方法，但是很多現存的浏覽器将302響應視作為303響應，并且使用 GET 方式通路在 Location 中規定的 URI，而無視原先請求的方法。狀态碼303和307被添加了進來，用以明确伺服器期待用戶端進行何種反應。
304	如果用戶端發送了一個帶條件的 GET 請求且該請求已被允許，而文檔的内容（自上次通路以來或者根據請求的條件）并沒有改變，則伺服器應當傳回這個狀态碼。304響應禁止包含消息體，是以始終以消息頭後的第一個空行結尾。 該響應必須包含以下的頭資訊： Date，除非這個伺服器沒有時鐘。假如沒有時鐘的伺服器也遵守這些規則，那麼代理伺服器以及用戶端可以自行将 Date 字段添加到接收到的響應頭中去（正如RFC 2068中規定的一樣），緩存機制将會正常工作。 ETag 和/或 Content-Location，假如同樣的請求本應傳回200響應。 Expires, Cache-Control，和/或Vary，假如其值可能與之前相同變量的其他響應對應的值不同的話。 假如本響應請求使用了強緩存驗證，那麼本次響應不應該包含其他實體頭；否則（例如，某個帶條件的 GET 請求使用了弱緩存驗證），本次響應禁止包含其他實體頭；這避免了緩存了的實體内容和更新了的實體頭資訊之間的不一緻。 假如某個304響應指明了目前某個實體沒有緩存，那麼緩存系統必須忽視這個響應，并且重複發送不包含限制條件的請求。 假如接收到一個要求更新某個緩存條目的304響應，那麼緩存系統必須更新整個條目以反映所有在響應中被更新的字段的值。
400	1、語義有誤，目前請求無法被伺服器了解。除非進行修改，否則用戶端不應該重複送出這個請求。 2、請求參數有誤。
401	目前請求需要使用者驗證。該響應必須包含一個适用于被請求資源的 WWW-Authenticate 資訊頭用以詢問使用者資訊。用戶端可以重複送出一個包含恰當的 Authorization 頭資訊的請求。如果目前請求已經包含了 Authorization 證書，那麼401響應代表着伺服器驗證已經拒絕了那些證書。如果401響應包含了與前一個響應相同的身份驗證詢問，且浏覽器已經至少嘗試了一次驗證，那麼浏覽器應當向使用者展示響應中包含的實體資訊，因為這個實體資訊中可能包含了相關診斷資訊。參見RFC 2617。
403	伺服器已經了解請求，但是拒絕執行它。與401響應不同的是，身份驗證并不能提供任何幫助，而且這個請求也不應該被重複送出。如果這不是一個 HEAD 請求，而且伺服器希望能夠講清楚為何請求不能被執行，那麼就應該在實體内描述拒絕的原因。當然伺服器也可以傳回一個404響應，假如它不希望讓用戶端獲得任何資訊。
404	請求失敗，請求所希望得到的資源未被在伺服器上發現。沒有資訊能夠告訴使用者這個狀況到底是暫時的還是永久的。假如伺服器知道情況的話，應當使用410狀态碼來告知舊資源因為某些内部的配置機制問題，已經永久的不可用，而且沒有任何可以跳轉的位址。404這個狀态碼被廣泛應用于當伺服器不想揭示到底為何請求被拒絕或者沒有其他适合的響應可用的情況下。出現這個錯誤的最有可能的原因是伺服器端沒有這個頁面
405	請求行中指定的請求方法不能被用于請求相應的資源。該響應必須傳回一個Allow 頭資訊用以表示出目前資源能夠接受的請求方法的清單。 鑒于 PUT，DELETE 方法會對伺服器上的資源進行寫操作，因而絕大部分的網頁伺服器都不支援或者在預設配置下不允許上述請求方法，對于此類請求均會傳回405錯誤。
500	伺服器遇到了一個未曾預料的狀況，導緻了它無法完成對請求的處理。一般來說，這個問題都會在伺服器端的源代碼出現錯誤時出現。
501	伺服器不支援目前請求所需要的某個功能。當伺服器無法識别請求的方法，并且無法支援其對任何資源的請求。
502	作為網關或者代理工作的伺服器嘗試執行請求時，從上遊伺服器接收到無效的響應
503	由于臨時的伺服器維護或者過載，伺服器目前無法處理請求。這個狀況是臨時的，并且将在一段時間以後恢複。如果能夠預計延遲時間，那麼響應中可以包含一個 Retry-After 頭用以标明這個延遲時間。如果沒有給出這個 Retry-After 資訊，那麼用戶端應當以處理500響應的方式處理它。 注意：503狀态碼的存在并不意味着伺服器在過載的時候必須使用它。某些伺服器隻不過是希望拒絕用戶端的連接配接。
504	作為網關或者代理工作的伺服器嘗試執行請求時，未能及時從上遊伺服器（URI辨別出的伺服器，例如HTTP、FTP、LDAP）或者輔助伺服器（例如DNS）收到響應。 注意：某些代理伺服器在DNS查詢逾時時會傳回400或者500錯誤
505	伺服器不支援，或者拒絕支援在請求中使用的 HTTP 版本。這暗示着伺服器不能或不願使用與用戶端相同的版本。響應中應當包含一個描述了為何版本不被支援以及伺服器支援哪些協定的實體。