常見的HTTP狀態碼
1、三至七種最基本的響應代碼
200(“OK”)
一切正常。實體主體中的文檔（若存在的話）是某資源的表示。
500(“Bad Request”)
客戶端方面的問題。實體主題中的文檔（若存在的話）是一個錯誤消息。希望客戶端能夠理解此錯誤消息，並改正問題。
500(“Internal Server Error”)
服務期方面的問題。實體主體中的文檔（如果存在的話）是一個錯誤消息。該錯誤消息通常無濟於事，因爲客戶端無法修復服務器方面的問題。
301(“Moved Permanently”)
當客戶端觸發的動作引起了資源URI的變化時發送此響應代碼。另外，當客戶端向一個資源的舊URI發送請求時，也發送此響應代碼。
404(“Not Found”) 和410(“Gone”)
當客戶端所請求的URI不對應於任何資源時，發送此響應代碼。404用於服務器端不知道客戶端要請求哪個資源的情況；410用於服務器端知道客戶端所請求的資源曾經存在，但現在已經不存在了的情況。
409(“Conflict”)
當客戶端試圖執行一個”會導致一個或多個資源處於不一致狀態“的操作時，發送此響應代碼。
SOAP Web服務只使用響應代碼200(“OK”)和500(“Internal Server Error”)。無論是你發給SOAP服務器的數據有問題，還是服務器在處理數據的過程中出現問題，或者SOAP服務器出現內部問題，SOAP服務器均發送500(“Internal Server Error”)。客戶端只有查看SOAP文檔主體（body）（其中包含錯誤的描述）才能獲知錯誤原因。客戶端無法僅靠讀取響應的前三個字節得知請求成功與否。
2、狀態碼系列。
1XX：通知
1XX系列響應代碼僅在與HTTP服務器溝通時使用。
100(“Continue”)
重要程度：中等，但（寫操作時）很少用。
這是對HTTP LBYL（look-before-you-leap）請求的一個可能的響應。該響應代碼表明：客戶端應重新發送初始請求，並在請求中附上第一次請求時未提供的（可能很大或者包含敏感信息的）表示。客戶端這次發送的請求不會被拒絕。對LBYL請求的另一個可能的響應是417(“Expectation Failed”)。
請求報頭：要做一個LBYL請求，客戶端必須把Expect請求報頭設爲字符串"100-continue"。除此以外，客戶端還需要設置其他一些報頭，服務器將根據這些報頭決定是響應100還是417。
101(“Switching Protocols”)
重要程度：非常低。
當客戶端通過在請求裏使用Upgrade報頭，以通知服務器它想改用除HTTP協議之外的其他協議時，客戶端將獲得此響應代碼。101響應代碼表示“行，我現在改用另一個協議了”。通常HTTP客戶端會在收到服務器發來的101響應後關閉與服務器的TCP連接。101響應代碼意味着，該客戶端不再是一個HTTP客戶端，而將成爲另一種客戶端。
儘管可以通過Upgrade報頭從HTTP切換到HTTPS，或者從HTTP1.1切換到某個未來的版本，但實際使用Upgrade報頭的情況比較少。Upgrade報頭也可用於HTTP切換到一個完全不同的協議（如IRC）上，但那需要在Web服務器切換爲一個IRC服務器的同時，Web客戶端切換爲一個IRC的客戶端，因爲服務器將立刻在同一個TCP連接上開始使用新的協議。
請求報頭：客戶端把Upgrade報頭設置爲一組希望使用的協議。
響應報頭：如果服務器同意切換協議，它就返回一個Upgrade報頭，說明它將切換到那個協議，並附上一個空白行。服務器不用關閉TCP鏈接，而是直接在該TCP連接上開始使用新的協議。
2XX: 成功
2XX系列響應代碼表明操作成功了。
200(“OK”)
重要程度：非常高。
一般來說，這是客戶端希望看到的響應代碼。它表示服務器成功執行了客戶端所請求的動作，並且在2XX系列裏沒有其他更適合的響應代碼了。
實體主體：對於GET請求，服務器應返回客戶端所請求資源的一個表示。對於其他請求，服務器應返回當前所選資源的一個表示，或者剛剛執行的動作的一個描述。
201(“Created”)
重要程度：高。
當服務器依照客戶端的請求創建了一個新資源時，發送此響應代碼。
響應報頭：Location報頭應包含指向新創建資源的規範URI。
實體主體：應該給出新創建資源的描述與鏈接。若已經在Location報頭裏給出了新資源的URI，那麼可以用新資源的一個表示作爲實體主體。
202(“Accepted”)
重要程度：中等。
客戶端的請求無法或將不被實時處理。請求稍後會被處理。請求看上去是合法的，但在實際處理它時有出現問題的可能。
若一個請求觸發了一個異步操作，或者一個需要現實世界參與的動作，或者一個需要很長時間才能完成且沒必要讓Web客戶端一直等待的動作時，這個相應代碼是一個合適的選擇。
響應報頭：應該把未處理完的請求暴露爲一個資源，以便客戶端稍後查詢其狀態。Location報頭可以包含指向該資源的URI。
實體主體：若無法讓客戶端稍後查詢請求的狀態，那麼至少應該提供一個關於何時能處理該請求的估計。
203(“Non-Authoritative Information”)
重要程度：非常低。
這個響應代碼跟200一樣，只不過服務器想讓客戶端知道，有些響應報頭並非來自該服務器–他們可能是從客戶端先前發送的一個請求裏複製的，或者從第三方得到的。
響應報頭：客戶端應明白某些報頭可能是不準確的，某些響應報頭可能不是服務器自己生成的，所以服務器也不知道其含義。
204(“No Content”)
重要程度：高。
若服務器拒絕對PUT、POST或者DELETE請求返回任何狀態信息或表示，那麼通常採用此響應代碼。服務器也可以對GET請求返回此響應代碼，這表明“客戶端請求的資源存在，但其表示是空的”。注意與304(“Not Modified”)的區別。204常常用在Ajax應用裏。服務器通過這個響應代碼告訴客戶端：客戶端的輸入已被接受，但客戶端不應該改變任何UI元素。
實體主體：不允許。
205(“Reset Content”)
重要程度：低。
它與204類似，但與204不同的是，它表明客戶端應重置數據源的視圖或數據結構。假如你在瀏覽器裏提交一個HTML表單，並得到響應代碼204，那麼表單裏的各個字段值不變，可以繼續修改它們；但假如得到的響應代碼205，那麼表單裏的各個字段將被重置爲它們的初始值。從數據錄入方面講：204適合對單條記錄做一系列編輯，而205適於連續輸入一組記錄。
206(“Partial Content”)
重要程度：對於支持部分GET（partial GET）的服務而言“非常高”，其他情況下“低”。
它跟200類似，但它用於對部分GET請求（即使用Range請求報頭的GET請求）的響應。部分GET請求常用於大型二進制文件的斷點續傳。
請求報頭：客戶端爲Range請求報頭設置一個值。
響應報頭：需要提供Date報頭。ETag報頭與Content-Location報頭的值應該跟正常GET請求相同。
若實體主體是單個字節範圍（byte range），那麼HTTP響應裏必須包含一個Content-Range報頭，以說明本響應返回的是表示的哪個部分，若實體主體是一個多部分實體（multipart entity）（即該實體主體由多個字節範圍構成），那麼每一個部分都要有自己的Content-Range報頭。
實體主體：不是整個表示，而是一個或者多個字節範圍。
3XX 重定向
3XX系列響應代碼表明：客戶端需要做些額外工作才能得到所需要的資源。它們通常用於GET請求。他們通常告訴客戶端需要向另一個URI發送GET請求，才能得到所需的表示。那個URI就包含在Location響應報頭裏。
300(“Multiple Choices”)
重要程度：低。
若被請求的資源在服務器端存在多個表示，而服務器不知道客戶端想要的是哪一個表示時，發送這個響應代碼。或者當客戶端沒有使用Accept-*報頭來指定一個表示，或者客戶端所請求的表示不存在時，也發送這個響應代碼。在這種情況下，一種選擇是，服務器返回一個首選表示，並把響應代碼設置爲200，不過它也可以返回一個包含該資源各個表示的URI列表，並把響應代碼設爲300。
響應報頭：如果服務器有首選表示，那麼它可以在Location響應報頭中給出這個首選表示的URI。跟其他3XX響應代碼一樣，客戶端可以自動跟隨Location中的URI。
實體主體：一個包含該資源各個表示的URI的列表。可以在表示中提供一些信息，以便用戶作出選擇。
301(“Moved Permanently”)
重要程度：中等。
服務器知道客戶端試圖訪問的是哪個資源，但它不喜歡客戶端用當前URI來請求該資源。它希望客戶端記住另一個URI，並在今後的請求中使用那個新的URI。你可以通過這個響應代碼來防止由於URI變更而導致老URI失效。
響應報頭：服務器應當把規範URI放在Location響應報頭裏。
實體主體：服務器可以發送一個包含新URI的信息，不過這不是必需的。
302(“Found”)
重要程度：應該瞭解，特別市編寫客戶端時。但我不推薦使用它。
這個響應代碼市造成大多數重定向方面的混亂的最根本原因。它應該是像307那樣被處理。實際上，在HTTP 1.0中，響應代碼302的名稱是”Moved Temporarily”，不幸的是，在實際生活中，絕大多數客戶端拿它像303一樣處理。它的不同之處在於當服務器爲客戶端的PUT，POST或者DELETE請求返回302響應代碼時，客戶端要怎麼做。
爲了消除這一混淆，在HTTP 1.1中，該響應代碼被重命名爲"Found"，並新加了一個響應代碼307。這個響應代碼目前仍在廣泛使用，但它的含義市混淆的，所以我建議你的服務發送307或者303，而不要發送302.除非你知道正在與一個不能理解303或307的HTTP 1.0客戶端交互。
響應報頭：把客戶端應重新請求的那個URI放在Location報頭裏。
實體主體：一個包含指向新URI的鏈接的超文本文檔（就像301一樣）。
303(“See Other”)
重要程度：高。
請求已經被處理，但服務器不是直接返回一個響應文檔，而是返回一個響應文檔的URI。該響應文檔可能是一個靜態的狀態信息，也可能是一個更有趣的資源。對於後一種情況，303是一種令服務器可以“發送一個資源的表示，而不強迫客戶端下載其所有數據”的方式。客戶端可以向Location報頭裏的URI發送GET請求，但它不是必須這麼做。
303響應代碼是一種規範化資源URI的好辦法。一個資源可以有多個URIs，但每個資源的規範URI只有一個，該資源的所有其他URIs都通過303指向該資源的規範URI，例如：303可以把一個對http://www.example.com/software/current.tar.gz的請求重定向到http://www.example.com/software/1.0.2.tar.gz。
響應報頭：Location報頭裏包含資源的URI。
實體主體：一個包含指向新URI的鏈接的超文本文檔。
304(“Not Modified”)
重要程度：高。
這個響應代碼跟204(“No Content”)類似：響應實體主體都必須爲空。但204用於沒有主體數據的情況，而304用於有主體數據，但客戶端已擁有該數據，沒必要重複發送的情況。這個響應代碼可用於條件HTTP請求（conditional HTTP request).如果客戶端在發送GET請求時附上了一個值爲Sunday的If-Modified-Since報頭，而客戶端所請求的表示在服務器端自星期日（Sunday）以來一直沒有改變過，那麼服務器可以返回一個304響應。服務器也可以返回一個200響應，但由於客戶端已擁有該表示，因此重複發送該表示只會白白浪費寬帶。
響應報頭：需要提供Date報頭。Etag與Content-Location報頭的值，應該跟返回200響應時的一樣。若Expires, Cache-Control及Vary報頭的值自上次發送以來已經改變，那麼就要提供這些報頭。
實體主體：不允許。
305(“Use Proxy”)
重要程度：低。
這個響應代碼用於告訴客戶端它需要再發一次請求，但這次要通過一個HTTP代理髮送，而不是直接發送給服務器。這個響應代碼使用的不多，因爲服務器很少在意客戶端是否使用某一特定代理。這個代碼主要用於基於代理的鏡像站點。現在，鏡像站點（如 http://www.example.com.mysite.com/）包含跟原始站點（如 http://www.example.com/ ）一樣的內容，但具有不同的URI，原始站點可以通過307把客戶端重新定向到鏡像站點上。假如有基於代理的鏡像站點，那麼你可以通過把 http://proxy.mysite.com/ 設爲代理，使用跟原始URI（ http://www.example.com/ ）一樣的URI來訪問鏡像站點。這裏，原始站點example.com可以通過305把客戶端路由到一個地理上接近客戶端的鏡像代理。web瀏覽器一般不能正確處理這個響應代碼，這是導致305響應代碼用的不多的另一個原因。
響應報頭：Location報頭裏包含代理的URI。
306 未使用
重要程度：無
306 響應代碼沒有在HTTP標準中定義過。
307(“Temporary Redirect”)
重要程度：高。
請求還沒有被處理，因爲所請求的資源不在本地：它在另一個URI處。客戶端應該向那個URI重新發送請求。就GET請求來說，它只是請求得到一個表示，該響應代碼跟303沒有區別。當服務器希望把客戶端重新定向到一個鏡像站點時，可以用307來響應GET請求。但對於POST，PUT及DELETE請求，它們希望服務器執行一些操作，307和303有顯著區別。對POST，PUT或者DELETE請求響應303表明：操作已經成功執行，但響應實體將不隨本響應一起返回，若客戶端想要獲取響應實體主體，它需要向另一個URI發送GET請求。而307表明：服務器尚未執行操作，客戶端需要向Location報頭裏的那個URI重新提交整個請求。
響應報頭： 把客戶端應重新請求的那個URI放在Location報頭裏。
實體主體：一個包含指向新URI的鏈接的超文本文檔。
4XX：客戶端錯誤
這些響應代碼表明客戶端出現錯誤。不是認證信息有問題，就是表示格式或HTTP庫本身有問題。客戶端需要自行改正。
400(“Bad Request”)
重要程度：高。
這是一個通用的客戶端錯誤狀態，當其他4XX響應代碼不適用時，就採用400。此響應代碼通常用於“服務器收到客戶端通過PUT或者POST請求提交的表示，表示的格式正確，但服務器不懂它什麼意思”的情況。
實體主體：可以包含一個錯誤的描述文檔。
401(“Unauthorized”)
重要程度：高。
客戶端試圖對一個受保護的資源進行操作，卻又沒有提供正確的認證證書。客戶端提供了錯誤的證書，或者根本沒有提供證書。這裏的證書（credential）可以是一個用戶名/密碼，也可以市一個API key，或者一個認證令牌。客戶端常常通過向一個URI發送請求，並查看收到401響應，以獲知應該發送哪種證書，以及證書的格式。如果服務器不想讓未授權的用戶獲知某個資源的存在，那麼它可以謊報一個404而不是401。這樣做的缺點是：客戶端需要事先知道服務器接受哪種認證–這將導致HTTP摘要認證無法工作。
響應報頭：WWW-Authenticate報頭描述服務器將接受哪種認證。
實體主體：一個錯誤的描述文檔。假如最終用戶可通過“在網站上註冊”的方式得到證書，那麼應提供一個指向該註冊頁面的鏈接。
402(“Payment Required”)
重要程度：無。
除了它的名字外，HTTP標準沒有對該響應的其他方面作任何定義。因爲目前還沒有用於HTTP的微支付系統，所以它被留作將來使用。儘管如此，若存在一個用於HTTP的微支付系統，那麼這些系統將首先出現在web服務領域。如果想按請求向用戶收費，而且你與用戶之間的關係允許這麼做的話，那麼或許用得上這個響應代碼。
注：該書印於2008年
403(“Forbidden”)
重要程度：中等。
客戶端請求的結構正確，但是服務器不想處理它。這跟證書不正確的情況不同–若證書不正確，應該發送響應代碼401。該響應代碼常用於一個資源只允許在特定時間段內訪問，
或者允許特定IP地址的用戶訪問的情況。403暗示了所請求的資源確實存在。跟401一樣，若服務器不想透露此信息，它可以謊報一個404。既然客戶端請求的結構正確，那爲什麼還要把本響應代碼放在4XX系列（客戶端錯誤），而不是5XX系列（服務端錯誤）呢？因爲服務器不是根據請求的結構，而是根據請求的其他方面（比如說發出請求的時間）作出的決定的。
實體主體：一個描述拒絕原因的文檔（可選）。
404(“Not Found”)
重要程度：高。
這也許是最廣爲人知的HTTP響應代碼了。404表明服務器無法把客戶端請求的URI轉換爲一個資源。相比之下，410更有用一些。web服務可以通過404響應告訴客戶端所請求的URI是空的，然後客戶端就可以通過向該URI發送PUT請求來創建一個新資源了。但是404也有可能是用來掩飾403或者401.
405(“Method Not Allowd”)
重要程度：中等。
客戶端試圖使用一個本資源不支持的HTTP方法。例如：一個資源只支持GET方法，但是客戶端使用PUT方法訪問。
響應報頭：Allow報頭列出本資源支持哪些HTTP方法，例如：Allow：GET，POST
406(“Not Acceptable”)
重要程度：中等。
當客戶端對錶示有太多要求，以至於服務器無法提供滿足要求的表示，服務器可以發送這個響應代碼。例如：客戶端通過Accept頭指定媒體類型爲application/json+hic，但是服務器只支持application/json。服務器的另一個選擇是：忽略客戶端挑剔的要求，返回首選表示，並把響應代碼設爲200。
實體主體：一個可選表示的鏈接列表。
407(“Proxy Authentication Required”)
重要程度：低。
只有HTTP代理會發送這個響應代碼。它跟401類似，唯一區別在於：這裏不是無權訪問web服務，而是無權訪問代理。跟401一樣，可能是因爲客戶端沒有提供證書，也可能是客戶端提供的證書不正確或不充分。
請求報頭：客戶端通過使用Proxy-Authorization報頭（而不是Authorization）把證書提供給代理。格式跟Authrization一樣。
響應報頭：代理通過Proxy-Authenticate報頭（而不是WWW-Authenticate）告訴客戶端它接受哪種認證。格式跟WWW-Authenticate一樣。
408(“Reqeust Timeout”)
重要程度：低。
假如HTTP客戶端與服務器建立鏈接後，卻不發送任何請求（或從不發送表明請求結束的空白行），那麼服務器最終應該發送一個408響應代碼，並關閉此連接。
409(“Conflict”)
重要程度：高。
此響應代碼表明：你請求的操作會導致服務器的資源處於一種不可能或不一致的狀態。例如你試圖修改某個用戶的用戶名，而修改後的用戶名與其他存在的用戶名衝突了。
響應報頭：若衝突是因爲某個其他資源的存在而引起的，那麼應該在Location報頭裏給出那個資源的URI。
實體主體：一個描述衝突的文檔，以便客戶端可以解決衝突。
410(“Gone”)
重要程度：中等。
這個響應代碼跟404類似，但它提供的有用信息更多一些。這個響應代碼用於服務器知道被請求的URI過去曾指向一個資源，但該資源現在不存在了的情況。服務器不知道
該資源的新URI，服務器要是知道該URI的話，它就發送響應代碼301.410和310一樣，都有暗示客戶端不應該再請求該URI的意思，不同之處在於：410只是指出該資源不存在，但沒有給出該資源的新URI。RFC2616建議“爲短期的推廣服務，以及屬於個人但不繼續在服務端運行的資源”採用410.
411(“Length Required”)
重要程度：低到中等。
若HTTP請求包含表示，它應該把Content-Length請求報頭的值設爲該表示的長度（以字節爲單位）。對客戶端而言，有時這不太方便（例如，當表示是來自其他來源的字節流時）。
所以HTTP並不要求客戶端在每個請求中都提供Content-Length報頭。但HTTP服務器可以要求客戶端必須設置該報頭。服務器可以中斷任何沒有提供Content-Length報頭的請求，並要求客戶端重新提交包含Content-Length報頭的請求。這個響應代碼就是用於中斷未提供Content-Lenght報頭的請求的。假如客戶端提供錯誤的長度，或發送超過長度的表示，服務器可以中斷請求並關閉鏈接，並返回響應代碼413。
412(“Precondition Failed”)
重要程度：中等。
客戶端在請求報頭裏指定一些前提條件，並要求服務器只有在滿足一定條件的情況下才能處理本請求。若服務器不滿足這些條件，就返回此響應代碼。If-Unmodified-Since是一個常見的前提條件。客戶端可以通過PUT請求來修改一個資源，但它要求，僅在自客戶端最後一次獲取該資源後該資源未被別人修改過才能執行修改操作。若沒有這一前提條件，客戶端可能會無意識地覆蓋別人做的修改，或者導致409的產生。
請求報頭：若客戶但設置了If-Match，If-None-Match或If-Unmodified-Since報頭，那就有可能得到這個響應代碼。If-None-Match稍微特別一些。若客戶端在發送GET或HEAD請求時指定了If-None-Match，並且服務器不滿足該前提條件的話，那麼響應代碼不是412而是304，這是實現條件HTTP GET的基礎。若客戶端在發送PUT，POST或DELETE請求時指定了If-None-Match,並且服務器不滿足該前提條件的話，那麼響應代碼是412.另外，若客戶端指定了If-Match或If-Unmodified-Since(無論採用什麼HTTP方法)，而服務器不滿足該前提條件的話，響應代碼也是412。
413(“Request Entity Too Large”)
重要程度：低到中等。
這個響應代碼跟411類似，服務器可以用它來中斷客戶端的請求並關閉連接，而不需要等待請求完成。411用於客戶端未指定長度的情況，而413用於客戶端發送的表示太大，以至於服務器無法處理。客戶端可以先做一個LBYL（look-before-you-leap）請求，以免請求被413中斷。若LBYL請求獲得響應代碼爲100，客戶端再提交完整的表示。
響應報頭：如果因爲服務器方面臨時遇到問題（比如資源不足），而不是因爲客戶端方面的問題而導致中斷請求的話，服務器可以把Retry-After報頭的值設爲一個日期或一個間隔時間，以秒爲單位，以便客戶端可以過段時間重試。
414(“Request-URI Too Long”)
重要程度：低。
HTTP標準並沒有對URI長度作出官方限制，但大部分現有的web服務器都對URI長度有一個上限，而web服務可能也一樣。導致URI超長的最常見的原因是：表示數據明明是該放在實體主體裏的，但客戶端卻把它放在了URI裏。深度嵌套的數據結構也有可能引起URI過長。
415(“Unsupported Media Type”)
重要程度：中等。
當客戶端在發送表示時採用了一種服務器無法理解的媒體類型，服務器發送此響應代碼。比如說，服務器期望的是XML格式，而客戶端發送的確實JSON格式。
如果客戶端採用的媒體類型正確，但格式有問題，這時最好返回更通用的400。
416(“Requestd Range Not Satisfiable”)
重要程度：低。
當客戶端所請求的字節範圍超出表示的實際大小時，服務器發送此響應代碼。例如：你請求一個表示的1-100字節，但該表示總共只用99字節大小。
請求報頭：僅當原始請求裏包含Range報頭時，纔有可能收到此響應代碼。若原始請求提供的是If-Range報頭，則不會收到此響應代碼。
響應報頭：服務器應當通過Content-Range報頭告訴客戶端表示的實際大小。
417(“Expectation Failed”)
重要程度：中等。
此響應代碼跟100正好相反。當你用LBYL請求來考察服務器是否會接受你的表示時，如果服務器確認會接受你的表示，那麼你將獲得響應代碼100，否則你將獲得417。
5XX 服務端錯誤
這些響應代碼表明服務器端出現錯誤。一般來說，這些代碼意味着服務器處於不能執行客戶端請求的狀態，此時客戶端應稍後重試。有時，服務器能夠估計客戶端應在多久之後重試。並把該信息放在Retry-After響應報頭裏。
5XX系列響應代碼在數量上不如4XX系列多，這不是因爲服務器錯誤的機率小，而是因爲沒有必要如此詳細–對於服務器方面的問題，客戶端是無能爲力的。
500(“Internal Server Error”)
重要程度：高。
這是一個通用的服務器錯誤響應。對於大多數web框架，如果在執行請求處理代碼時遇到了異常，它們就發送此響應代碼。
501(“Not Implemented”)
重要程度：低。
客戶端試圖使用一個服務器不支持的HTTP特性。
最常見的例子是：客戶端試圖做一個採用了拓展HTTP方法的請求，而普通web服務器不支持此請求。它跟響應代碼405比較相似，405表明客戶端所用的方法是一個可識別的方法，但該資源不支持，而501表明服務器根本不能識別該方法。
502(“Bad Gateway”)
重要程度：低。
只有HTTP代理會發送這個響應代碼。它表明代理方面出現問題，或者代理與上行服務器之間出現問題，而不是上行服務器本身有問題。若代理根本無法訪問上行服務器，響應代碼將是504。
503(“Service Unavailable”)
重要程度：中等到高。
此響應代碼表明HTTP服務器正常，只是下層web服務服務不能正常工作。最可能的原因是資源不足：服務器突然收到太多請求，以至於無法全部處理。由於此問題多半由客戶端反覆發送請求造成，因此HTTP服務器可以選擇拒絕接受客戶端請求而不是接受它，併發送503響應代碼。
響應報頭：服務器可以通過Retry-After報頭告知客戶端何時可以重試。
504(“Gateway Timeout”)
重要程度：低。
跟502類似，只有HTTP代理會發送此響應代碼。此響應代碼表明代理無法連接上行服務器。
505(“HTTP Version Not Supported”)
重要程度： 非常低。
當服務器不支持客戶端試圖使用的HTTP版本時發送此響應代碼。
實體主體：一個描述服務器支持哪些協議的文檔。
node
ctx.throw(404, '用戶不存在');
ctx.throw(409, '用戶已經佔用');
ctx.throw(403, '沒有權限');
ctx.throw(401, '用戶名或密碼不正確');
ctx.status = 204;