HTTP 1.1 Status Code Definitions

文章目錄

• 8.2.3 Use of the 100 (Continue) Status
• 10.1.1 100 Continue
• 10.1.2 101 Switching Protocols
• 10.2.2 201 Created

rfc 2616 http://www.rfc-editor.org/rfc/rfc2616.txt百度百科：http://baike.baidu.com/view/1790469.htm6.1 Status-Lineresponse訊息的第一行就是status-line,包含：http版本資訊，狀態代碼，以及該狀態代碼相關的文本化短語，由空格隔開：

Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

6.1.1 Status Code and Reson Phrase

3位元的狀態代碼用於響應用戶端的不同request。詳細討論見章節10狀態代碼第一位用來標識狀態代碼的分類：

- 1xx: Informational - Request received, continuing process      - 2xx: Success - The action was successfully received,        understood, and accepted      - 3xx: Redirection - Further action must be taken in order to        complete the request      - 4xx: Client Error - The request contains bad syntax or cannot        be fulfilled      - 5xx: Server Error - The server failed to fulfill an apparently        valid request

Status-Code    =            "100"  ; Section 10.1.1: Continue          | "101"  ; Section 10.1.2: Switching Protocols          | "200"  ; Section 10.2.1: OK          | "201"  ; Section 10.2.2: Created          | "202"  ; Section 10.2.3: Accepted          | "203"  ; Section 10.2.4: Non-Authoritative Information          | "204"  ; Section 10.2.5: No Content          | "205"  ; Section 10.2.6: Reset Content          | "206"  ; Section 10.2.7: Partial Content          | "300"  ; Section 10.3.1: Multiple Choices          | "301"  ; Section 10.3.2: Moved Permanently          | "302"  ; Section 10.3.3: Found          | "303"  ; Section 10.3.4: See Other          | "304"  ; Section 10.3.5: Not Modified          | "305"  ; Section 10.3.6: Use Proxy          | "307"  ; Section 10.3.8: Temporary Redirect          | "400"  ; Section 10.4.1: Bad Request          | "401"  ; Section 10.4.2: Unauthorized          | "402"  ; Section 10.4.3: Payment Required          | "403"  ; Section 10.4.4: Forbidden          | "404"  ; Section 10.4.5: Not Found          | "405"  ; Section 10.4.6: Method Not Allowed          | "406"  ; Section 10.4.7: Not AcceptableFielding, et al.            Standards Track                    [Page 40]RFC 2616                        HTTP/1.1                       June 1999          | "407"  ; Section 10.4.8: Proxy Authentication Required          | "408"  ; Section 10.4.9: Request Time-out          | "409"  ; Section 10.4.10: Conflict          | "410"  ; Section 10.4.11: Gone          | "411"  ; Section 10.4.12: Length Required          | "412"  ; Section 10.4.13: Precondition Failed          | "413"  ; Section 10.4.14: Request Entity Too Large          | "414"  ; Section 10.4.15: Request-URI Too Large          | "415"  ; Section 10.4.16: Unsupported Media Type          | "416"  ; Section 10.4.17: Requested range not satisfiable          | "417"  ; Section 10.4.18: Expectation Failed          | "500"  ; Section 10.5.1: Internal Server Error          | "501"  ; Section 10.5.2: Not Implemented          | "502"  ; Section 10.5.3: Bad Gateway          | "503"  ; Section 10.5.4: Service Unavailable          | "504"  ; Section 10.5.5: Gateway Time-out          | "505"  ; Section 10.5.6: HTTP Version not supported          | extension-code      extension-code = 3DIGIT      Reason-Phrase  = *<TEXT, excluding CR, LF>

http狀態代碼是可擴充的，也就是說我們定製的用戶端用戶端程式可以自訂一些狀態代碼。我們定義的用戶端程式應該理解5類狀態代碼鴿子的含義，一旦接受到不能理解的狀態代碼，將其等同為該類的x00狀態代碼。例如遇到未知的431，將其等同為400.此時，使用者嗲裡應該將隨同response返回的entity展現給使用者，因為這些entity可能包含人類可讀的資訊，而這些資訊將解釋這些不可理解的狀態代碼，如431.

8.2.3 Use of the 100 (Continue) Status這個狀態代碼的作用是讓用戶端判斷原始伺服器是否希望接受緊跟著要求標頭(request header)的請求體(request body)。也就是說，用戶端在發出一個包含標明Exception欄位的要求標頭之後，會根據伺服器返回的respose的狀態代碼判斷，同一個請求的額請求體是否還要發送過去。

Requirements for HTTP/1.1 clients:

--- 一個用戶端如果決定暫不發送請求體，而等待伺服器返回100的狀態代碼後再發送，就必須先發送一個包含 "100-continue"的Exceptin前序的請求過去。參見本協議14.20

---如果用戶端不決定發送請求體，就絕不要發送一個包含Exception 值為“100-continue“的請求。

因為舊http協議依然在使用，所以，http1.1對用戶端發送了“ExceptionP: 100-continue”而沒有收到417/100的狀態代碼reponse時的行為定義是模糊的。所以，如果用戶端遲遲等不到伺服器段的100狀態代碼response，也不要一直等下去，可以直接發送請求體。

Requirements for HTTP/1.1 origin servers:

---一旦收到一個包含“Exception： 100-continue”的請求，原始伺服器要不返回一個100的狀態代碼回應然後繼續從輸入資料流中讀資料，要不用一個終止狀態代碼結束。原始伺服器不要在還沒有發送100狀態代碼的響應前就開始等待請求體發過來。如果，是返回一個終止狀態代碼，伺服器的行為就多種多樣了，可能是關閉串連，可能是繼續讀並求無視掉該請求的其他部分，如果伺服器選擇返回終止狀態代碼，它的因為一定不能是執行被請求的方法。

---在用戶端沒有顯示添加“Exceptin:100-continue”前序的請求時，伺服器不應該發送100狀態代碼的響應，對不支援http1.1的用戶端，也不應該發送這個響應。但有個特例：為了和RFC 2068相容，在HTTP/1.1 PUT或者POST請求中，即使請求中沒有“Exception: 100-continue”欄位，伺服器也可能發送100狀態代碼的響應，因為這樣可以最小化用戶端未申報的對100狀態代碼的回應的等待。

---如果伺服器已經接受到了一些或者所有的請求體，就應該再發送100狀態代碼響應了。

---除非過早的斷開了串連，那麼原始伺服器在接收並處理完請求體的時候必須返回一個終止狀態的回應。

---如果伺服器正在處理一個包含請求體的請求，這個請求中並沒有加上“Excpetin : 100-continue”的前序，在伺服器讀完整個請求體之前就返回一個終止狀態代碼碼的回應，伺服器不應該關閉串連，除非等到伺服器讀完整個請求，或者除非用戶端先自己關閉串連。否則，用戶端就無法接收到可靠的響應訊息。然而，這條需求不應該被解釋成為了保護服務原理拒絕服務的攻擊，也不是為了防止垃圾的用戶端實現。

Requirements for HTTP/1.1 proxies:

---如果Proxy 伺服器收到一個包含“Exception: 100-continue”前序的請求，在不知道嚇一跳的伺服器是否相容http1.1或更高版本時，或者根本不知道下一跳伺服器的http協議版本相容性，就必須轉寄請求，並將原有的Exception頭包含進去。

---如果Proxy 伺服器能看到下一跳的伺服器的http相容性是1.0乃至更低，一定不能轉寄請求，必須Proxy 伺服器自己響應一個417的響應。---Proxy 伺服器對最近應用的下一跳的伺服器的http相容性，應該做一個緩衝記錄。---如果用戶端的http相容性是1.0或更低，Proxy 伺服器不應該轉寄100狀態代碼的響應，也不應該在這個低版本用戶端發過來的請求中插入“Exception：100-continue“前序。這條需求淩駕於（overrides）之前的一般性規則之上（見章節 10.1）10、狀態代碼定義

 下面每個狀態代碼的描述都包含它支援的request方法，還有在reponse中設定這個狀態代碼時需要的其它元資訊。有時，伺服器在不知道請求體內容的情況下就斷然拒絕接受，是不合合適也沒效率的。

10.1 Informatinal 1xx

這類狀態代碼是臨時的response，僅僅包含status-line、optional headers並被空白行結束。對於這類狀態代碼，沒有什麼header是必須出現的。因為HTTP1.0沒有定義任何該類狀態代碼，伺服器一定不可以發送該類的響應給http1.0 用戶端，除非你只是想實驗一下。

在一個普通的response之前，用戶端的預設狀態是準備好接受一個或多個該類的response，即使用戶端並沒有發送請求要獲得伺服器的此類響應。也就是說，用戶端應該隨時準備接受此類的response。有時該類的response會被使用者代理程式忽略。

Proxy 伺服器必須轉寄該類的response，除非在Proxy 伺服器和用戶端之間的串連已經被關閉了，或者除非只是Proxy 伺服器自己發起的該類請求。也就是說，Proxy 伺服器總是會將伺服器過來的該類response轉寄給用戶端。（例如，Proxy 伺服器在轉寄的請求中加上100-continue的Exception前序，這是就無需轉寄響應的該類response了）。

10.1.1 100 Continue告訴用戶端應該繼續發送同一個請求餘下的部分，或者如果請求已經發送完了，就忽略這條響應。伺服器在請求完全處理完時，應該給出一條終止的響應。詳細參看章節 8.2.310.1.2 101 Switching Protocols　伺服器已經理解了用戶端的請求，並將通過 Upgrade 訊息頭通知用戶端採用不同的協議來完成這個請求。在發送完這個響應最後的空行後，伺服器將會切換到在 Upgrade 訊息頭中定義的那些協議。

　　只有在切換新的協議更有好處的時候才應該採取類似措施。例如，切換到新的 HTTP 版本比舊版本更有優勢，或者切換到一個即時且同步的協議以傳送利用此類特性的資源。10.2 Successful 2xx這一類型的狀態代碼，代表請求已成功被伺服器接收、理解、並接受。10.2.1 200 OK請求已經成功。返回的資訊取決與請求中的method，例如：GET     一個對應與被請求的資源的entity被夾子啊響應裡發送了HEAD      響應中對應請求資源的entity-header fields被在響應中發送，而響應中並沒有message-body。POST     一個描述或者包含結果動作的entityTRACE    一個北末端的伺服器接受的請求message的entity10.2.2 201 Created請求已經處理，建立了新的資源，新資源可以被歲Location前序返回的uri(s)訪問