常見的HTTP狀態碼

本內容摘抄自《RESTful WebServices》 中文譯本附錄B '42種常見的HTTP響應代碼'。
原文做者：Leonard Ricbardson & Sam Ruby
翻譯：徐涵、李紅軍、胡偉

一、三至七種最基本的響應代碼

• 200("OK")
  一切正常。實體主體中的文檔（若存在的話）是某資源的表示。

• 400("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）（其中包含錯誤的描述）才能獲知錯誤緣由。客戶端沒法僅靠讀取響應的前三個字節得知請求成功與否。

二、狀態碼系列。

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版本時發送此響應代碼。

實體主體：一個描述服務器支持哪些協議的文檔。