常見的HTTP狀态碼

本内容摘抄自《RESTful WebServices》 中文譯本附錄B '42種常見的HTTP響應代碼'。

原文作者：Leonard Ricbardson & Sam Ruby

翻譯：徐涵、李紅軍、胡偉

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

• 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）（其中包含錯誤的描述）才能獲知錯誤原因。用戶端無法僅靠讀取響應的前三個位元組得知請求成功與否。

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系列響應代碼表明操作成功了。

• 重要程度：非常高。

一般來說，這是用戶端希望看到的響應代碼。它表示伺服器成功執行了用戶端所請求的動作，并且在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的清單。可以在表示中提供一些資訊，以便使用者作出選擇。

伺服器知道用戶端試圖通路的是哪個資源，但它不喜歡用戶端用目前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報頭裡。

4XX：用戶端錯誤

這些響應代碼表明用戶端出現錯誤。不是認證資訊有問題，就是表示格式或HTTP庫本身有問題。用戶端需要自行改正。

這是一個通用的用戶端錯誤狀态，當其他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響應代碼，并關閉此連接配接。

此響應代碼表明：你請求的操作會導緻伺服器的資源處于一種不可能或不一緻的狀态。例如你試圖修改某個使用者的使用者名，而修改後的使用者名與其他存在的使用者名沖突了。

響應報頭：若沖突是因為某個其他資源的存在而引起的，那麼應該在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系列多，這不是因為伺服器錯誤的幾率小，而是因為沒有必要如此詳細--對于伺服器方面的問題，用戶端是無能為力的。

這是一個通用的伺服器錯誤響應。對于大多數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版本時發送此響應代碼。

實體主體：一個描述伺服器支援哪些協定的文檔。