本文為《三萬長文50+趣圖帶你領悟web程式設計的內功心法》第三個章節。
3、HTTP/1.1報文詳解
在RFC2616中心詳細的描述了HTTP/1.1[1]的報文，感興趣的朋友也可以前往閱讀。
HTTP是基於TCP的，HTTP作為應用層協議，會在TCP/IP協議棧往下傳遞的時候，不斷封裝資料幀，如下圖：
上面HTTP正文即是以我們HTTP報文格式來組織的。下面我們看看具體的HTTP報文的格式。
3.1、HTTP報文組成部分
HTTP請求和響應都使用如下通用的格式：
-
start-line：起始行，起始行可以為以下兩者之一：-
Request-Line：請求行，如：-
GET /hello-world2.html HTTP/1.1
-
-
Status-Line：狀態行，如：-
HTTP/1.1 200 OK
-
-
-
*(message-header CRLF)：0個或者多個訊息頭； -
CRLF：一個空行； -
[message-body]：可選的訊息體；
可以分別把請求報文和響應報文分開來描述：
請求報文
響應報文
可以發現，請求報文和響應報文格式就起始行不一樣。
下面我們逐個來介紹。
為了儘可能保證內容的準確性，下面報文各種欄位說明部分內容，大部分整理自RFC2616和MDN web docs：
以上資料內容有衝突的，以RFC2616的為準。
3.2、請求行
請求行格式：
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
3.2.1、Method
方法是區分大訊息的，以下是常用的方法：
| 方法 | 說明 |
|---|---|
| OPTIONS | 列出可以對伺服器資源執行哪些方法 |
| GET | 獲取資源 |
| HEAD | 獲取資源的首部，與GET類似，但是不會響應訊息體 |
| POST | 向伺服器提交資料 |
| PUT | 將請求主體部分儲存在伺服器上 |
| DELETE | 刪除資源 |
| TRACE | 對可能經過代理伺服器傳送到伺服器上的報文進行追蹤 |
| CONNECT | 建立連線隧道 |
| extension-method | 擴充套件方法 |
另外，伺服器還可以實現一些自己的請求方法，這些附加的方法是對HTTP規範的擴充套件，因此也成為擴充套件方法。
extension-method = token
請求可能的返回結果：
-
405：表示請求的方法不被允許，這個時候伺服器響應頭會響應當前資源允許的方法，如：
-
Allow: GET, HEAD, PUT
-
-
501：代表原伺服器的該方法未能被識別或者未實現；
下面逐個方法介紹下：
GET
GET方法意味著可以檢索 Request-URI標識的任何資訊。
如果Request-URI涉及到建立資料，則應該將新建的資料作為響應實體返回。
如果請求訊息包含 If-Modified-Since，If-Unmodified-Since，If-Match，If-None_match或If-Range標頭欄位，則此時的Get為條件GET。通過使用快取標頭，可以儘可能避免不必要的網路傳輸。
如果請求標頭包含Range，則GET方法變為部分GET。
HEAD
HEAD方法與GET方法很類似，但是HEAD方法在在響應中只返回首部，不會反悔訊息體。
這就允許客戶端再不用獲取實際資源的情況下，對資源首部進行檢查。如：
- 檢查資源是否有更新：如果獲取到的 Content-Length、Content-MD5、ETag、Last-Modified與之前獲取到的值不同，那麼快取應該被視為過期；
- 檢視響應狀態碼，檢視資源是否存在；
- 獲取首部更多資訊，判斷資源情況。
POST
POST方法起初是用來向伺服器傳輸資料的，通常用來提交HTML的表單到伺服器。
PUT
PUT方法用於向伺服器寫入資源，如果Request-URI對應的資源已經存在的話，就進行更新。
注意：
POST用於向伺服器傳送資料，PUT用於向伺服器上的資源中儲存資料。
DELETE
請求伺服器刪除URL所指示的資源，但是客戶端無法保證刪除操作一定會被執行，除非在響應式伺服器打算刪除資源或者將其移動到無法訪問的位置。可能的響應：
- 如果響應包含描述狀態的實體，則響應200（確定）；
- 如果尚未執行刪除操作，則響應202（接受）；
- 如果已執行該操作，並且響應不包含任何實體，則響應204（無內容）。
此方法的響應不可快取。
TRACE
一個請求從客戶端到服務端，中間可能會經歷各種代理、閘道器等程式，每個中間節點都可能修改原始HTTP請求。為此，通過TRACE，服務端會在接收到請求後反饋一個TRACE響應，並且在響應主體中攜帶它收到的原始請求報文。客戶端拿到TRACE響應，就可以進行測試和診斷了。其中Via標頭欄位特別有用，它用於充當請求鏈的跟蹤。
可以使用Max-Forwards標頭欄位限制請求鏈的長度，這對於測試無限迴圈中轉發訊息的代理很有用。
如果請求有效，則響應應該在實體正文中包含整個請求訊息，其 Content-Type為"message/http"。對此方法的響應絕對不能快取。
TRACE允跨站點跟蹤問題，並且可能使黑客可以選擇竊取您的cookie資訊。基於安全的考慮，一般的伺服器會關掉TRACE：
TraceEnable off這樣執行TRACE會導致客戶端收到一個405不允許使用方法的狀態碼。
CONNECT
CONNECT 方法可以開啟一個客戶端與所請求資源之間的雙向溝通的通道。它可以用來建立隧道（tunnel）。
例如，CONNECT 可以用來訪問採用了 SSL (HTTPS) 協議的站點。客戶端要求代理伺服器將 TCP 連線作為通往目的主機隧道。之後該伺服器會代替客戶端與目的主機建立連線。連線建立好之後，代理伺服器會面向客戶端傳送或接收 TCP 訊息流。[3]
OPTIONS
通過該方法，可以請求伺服器獲取Request-URI對應支援的各種通訊選項的資訊。最常見的如：詢問伺服器當前URI支援哪些請求方法。
此方法響應不能快取。
方法的安全性與冪等性
所謂安全性，就是無論方法執行多少次，伺服器上的資料都不會被改變。
安全方法：GET、HEAD；
不安全方法：POST、PUT、DELETE操作則會改動資料。
所謂冪等，就是多次執行一個方法，結果都是相同的。
冪等方法：GET、HEAD、PUT、DELETE；
非冪等方法：POST。
3.2.2、Request-URI
URI，Uniform Resource Identifier，請求的統一資源識別符號。
3.2.2.1、URI與URL什麼關係？
我們經常會用到這兩個概念，但是他們是什麼意思呢？
URI，Uniform Resource Identifier，統一資源識別符號，能夠唯一的標識網上的一個資源，比如，我的網站IT宅的Logo：
https://www.itzhai.com/resources/images/itzhai_logo_home_page.jpg
只要在世界的任何一個有網路的地方，發起請求，就可以拿到這個圖片，這個URI具有唯一性。那什麼是URL呢？
URI有兩種形式：URL和URN。
URL
URL，Uniform Resource Locator，統一資源定位符，描述了一臺特定伺服器上某個資源的特定位置。例如上面的連結就是一個統一資源定位符：
scheme方案：指定方位資源所使用的協議型別，如HTTPS；主機與埠：英特網地址，即域名，這裡預設為80埠；路徑：其餘部分指定web伺服器上的某個資源。
幾乎所有的 URI都是URL。
一個完整的URL格式如下：
使用者名稱和密碼：有寫伺服器要求輸入使用者名稱和密碼才允許使用者訪問資料，如FTP；?query 查詢字串：可以通過查詢字串進行查詢來縮小所請求資源型別的範圍；fragment片段：指向HTML文件中特定的圖片或者小節。
URN
URL，Uniform Resource Name，統一資源名，作為特定內容的唯一名稱，與資源所在位置無關。也就是說，我可以給一份文件定義一個URN，不管你把這個文件放到哪裡，有多少個URL，但是都只有唯一個URN。舉個例子，因特網標準文件 RFC 3986不管存在哪個伺服器上，都可以用唯一的URN來命名：
urn:ietf:rfc:3986
URN處於試驗階段，暫未大範圍使用。
再通俗易懂點來說：URN就相當於身份證，通過特定的規則，制定了一串唯一的字串作為你的身份證，但是沒有規定身份證一定要放在哪裡，只是作為你的個人唯一憑證。URL相當於是快遞單上的地址，根據地址，快遞員一定可以把快遞送到唯一的一個目的地。
3.2.3、HTTP-Version
指定了當前請求用到的HTTP協議版本。
3.3、訊息頭[4]
通過傳遞訊息頭(首部)，伺服器和客戶端可以把自己的資訊或者是請求響應相關資訊進行傳遞。
可以把首部分為：通用首部，請求首部，響應首部，實體首部，擴充套件首部。下面就來詳細介紹下。
3.3.1、通用首部
有些首部，不管是請求還是響應都會出現他們的身影，我們把他們歸類為通用首部。常見通用首部如下表格所示：
| 首部 | 說明 |
|---|---|
| Cache-Control | 通過指定指令來實現快取機制 |
| Connection | Connection 頭（header） 決定當前的事務完成後，是否會關閉網路連線。如果該值是“keep-alive”，網路連線就是持久的，不會關閉，使得對同一個伺服器的請求可以繼續在該連線上完成： Connection: keep-alive Connection: close |
| Data | 提供報文建立的時間 |
| MIME-Version | 提供傳送端使用的MIME版本 |
| Trailer | 允許傳送方在分塊傳送的訊息後面新增額外的元資訊，這些元資訊可能是隨著訊息主體的傳送動態生成的，比如訊息的完整性校驗，訊息的數字簽名，或者訊息經過處理之後的最終狀態等。 |
| Transfer-Encoding | 告知接收端報文的編碼方式 |
| Upgrade | 允許客戶端指定它支援並且希望使用的通訊協議，如果伺服器認為適合，則切換協議，伺服器必須使用101(交換協議)中的Upgrade標頭欄位響應，以知識正在交換的協議。 |
| Via | 顯示報文經過的中間節點，用來追蹤訊息轉發情況，防止迴圈請求，以及識別在請求或響應傳遞鏈中訊息傳送者對於協議的支援能力 |
| Warning | 包含報文當前狀態可能存在的問題。在響應中可以出現多個 Warning 首部。一般來說， Warning 首部可以應用於任何型別的報文。然而一部分警告碼（warn-code）是為快取代理伺服器定製的，並且只可以應用在響應報文中。 |
3.3.2、請求首部
客戶端通過傳遞請求頭欄位，將有關請求以及有關客戶端本身的其他資訊傳遞給伺服器，這些欄位充當請求修飾符，其語義等同於程式語言方法呼叫中的引數。
常見的請求頭如下：
Accept首部
| 首部 | 說明 |
|---|---|
| Accept | 表明客戶端能夠接受的媒體型別 |
| Accept-Charset | 表明客戶端能夠接受的字符集 |
| Accept-Encoding | 表明客戶端能夠接受的編碼方式 |
| Accept-Language | Section 14.4 |
| TE | 表明客戶端能夠接受的擴充套件傳輸編碼 |
條件請求首部
| 首部 | 說明 |
|---|---|
| Expect | 指示客戶端要求特定的伺服器行為 目前規範中只規定了 "100-continue" 這一個期望條件：通知接收方客戶端要傳送一個體積可能很大的訊息體，期望收到狀態碼為100 (Continue) 的臨時回覆 |
| If-Match | 請求首部 If-Match 的使用表示這是一個條件請求。在請求方法為 GET 和 HEAD 的情況下，伺服器僅在請求的資源滿足此首部列出的 ETag值時才會返回資源。而對於 PUT 或其他非安全方法來說，只有在滿足條件的情況下才可以將資源上傳。 |
| If-Modified-Since | If-Modified-Since 是一個條件式請求首部，伺服器只在所請求的資源在給定的日期時間之後對內容進行過修改的情況下才會將資源返回，狀態碼為 200 。如果請求的資源從那時起未經修改，那麼返回一個不帶有訊息主體的 304 響應，而在 Last-Modified 首部中會帶有上次修改時間。 不同於 If-Unmodified-Since, If-Modified-Since 只可以用在GET 或 HEAD 請求中。 |
| If-None-Match | 對於 GET 和 HEAD 請求方法來說，當且僅當伺服器上沒有任何資源的 ETag 屬性值與這個首部中列出的相匹配的時候，伺服器端會才返回所請求的資源，響應碼為 200。對於其他方法來說，當且僅當最終確認沒有已存在的資源的 ETag 屬性值與這個首部中所列出的相匹配的時候，才會對請求進行相應的處理。 |
| If-Range | If-Range HTTP 請求頭欄位用來使得 Range 頭欄位在一定條件下起作用：當欄位值中的條件得到滿足時，Range 頭欄位才會起作用，同時伺服器回覆206 部分內容狀態碼，以及Range 頭欄位請求的相應部分；如果欄位值中的條件沒有得到滿足，伺服器將會返回 200 OK 狀態碼，並返回完整的請求資源。 |
| If-Unmodified-Since | HTTP協議中的 If-Unmodified-Since 訊息頭用於請求之中，使得當前請求成為條件式請求：只有當資源在指定的時間之後沒有進行過修改的情況下，伺服器才會返回請求的資源，或是接受 POST 或其他 non-safe 方法的請求。如果所請求的資源在指定的時間之後發生了修改，那麼會返回 412 (Precondition Failed) 錯誤。 |
| Range | The Range 是一個請求首部，告知伺服器返回檔案的哪一部分。在一個 Range 首部中，可以一次性請求多個部分，伺服器會以 multipart 檔案的形式將其返回。如果伺服器返回的是範圍響應，需要使用 206 Partial Content 狀態碼。假如所請求的範圍不合法，那麼伺服器會返回 416 Range Not Satisfiable 狀態碼，表示客戶端錯誤。伺服器允許忽略 Range 首部，從而返回整個檔案，狀態碼用 200 。 |
安全請求首部
| 首部 | 說明 |
|---|---|
| Authorization | HTTP協議中的 Authorization 請求訊息頭含有伺服器用於驗證使用者代理身份的憑證，通常會在伺服器返回401 Unauthorized 狀態碼以及WWW-Authenticate 訊息頭之後在後續請求中傳送此訊息頭。 |
| Cookie | Cookie 是一個請求首部，其中含有先前由伺服器通過 Set-Cookie 首部投放並儲存到客戶端的 HTTP cookies。 |
| Cookie2 | 這個已經被廢棄的 Cookie2 請求首部曾經被用來告知瀏覽器該使用者代理支援“新型” cookies，但是現代的使用者代理一般使用 Cookie 來替代 Cookie2。 |
代理請求首部
| 首部 | 說明 |
|---|---|
| Max-Forwards | 在通往源端伺服器的路徑上，將請求轉發給其他代理或者閘道器的最大次數，與TRACE方法類似。 |
| Proxy-Authorization | Proxy-Authorization 是一個請求首部，其中包含了使用者代理提供給代理伺服器的用於身份驗證的憑證。這個首部通常是在伺服器返回了 407 Proxy Authentication Required 響應狀態碼及 Proxy-Authenticate 首部後傳送的。 |
| Proxy-Connection | 同Connection，不過這個首部是在與代理建立連線時使用。 |
3.3.3、響應首部
| 首部 | 說明 |
|---|---|
| Age | Age 訊息頭裡包含物件在快取代理中存貯的時長，以秒為單位。Age的值通常接近於0。表示此物件剛剛從原始伺服器獲取不久；其他的值則是表示代理伺服器當前的系統時間與此應答中的通用頭 Date 的值之差。 |
| Retry-After | 在HTTP協議中，響應首部 Retry-After 表示使用者代理需要等待多長時間之後才能繼續傳送請求。這個首部主要應用於以下兩種場景：- 當與 503 響應一起傳送的時候，表示服務下線的預期時長；- 當與重定向響應一起傳送的時候，比如 301 (Moved Permanently，永久遷移)，表示使用者代理在傳送重定向請求之前需要等待的最短時間。 |
| Server | Server 首部包含了處理請求的源頭伺服器所用到的軟體相關資訊。避免描述的過於詳細，因為這有可能洩露伺服器內部實現細節，或者被攻擊者找到已知安全漏洞。 |
| Title | 對於HTML文件來說，就是HTML文案定的源端給出的標題。 該首部定義與原始的 HTTP/1.0草案，並未列入RFC2616。 |
| Warning | Warning 是一個通用報文首部，包含報文當前狀態可能存在的問題。在響應中可以出現多個 Warning 首部。一般來說， Warning 首部可以應用於任何型別的報文。然而一部分警告碼（warn-code）是為快取代理伺服器定製的，並且只可以應用在響應報文中。格式： Warning: <warn-code> <warn-agent> <warn-text> [<warn-date>] |
協商首部
如果資源有多種表示方法，伺服器可以通過協商首部來傳遞可協商資源有關的資訊。
| 首部 | 說明 |
|---|---|
| Accept-Range | 伺服器使用 HTTP 響應頭 **Accept-Ranges** 標識自身支援範圍請求(partial requests)。欄位的具體值用於定義範圍請求的單位。當瀏覽器發現 Accept-Ranges頭時，可以嘗試繼續中斷了的下載，而不是重新開始。 |
| Vary | Vary 是一個HTTP響應頭部資訊，它決定了對於未來的一個請求頭，應該用一個快取的回覆(response)還是向源伺服器請求一個新的回覆。例如，移動端和桌面端響應內容是不同的，為了防止移動端誤用了桌面端的快取，可以這樣指定Vary： Vary: User-Agent |
安全響應首部
| 首部 | 描述 |
|---|---|
| Proxy-Authenticate | 指定了獲取 proxy server （代理伺服器）上的資源訪問許可權而採用的身份驗證方式。代理伺服器對請求進行驗證，以便它進一步傳遞請求。Proxy-Authenticate 首部需要與 407 Proxy Authentication Required 響應一起傳送。 |
| Set-Cookie | 響應首部 Set-Cookie 被用來由伺服器端向客戶端傳送 cookie。 |
| Set-Cookie2 | 已廢棄使用。它被伺服器用來向客戶端傳送 cookie 資料，但是已經在協議中被標記為不贊成使用了。請使用 Set-Cookie 將其代替。 |
| WWW-Authenticate | 定義了使用何種驗證方式去獲取對資源的連線。WWW-Authenticate header通常會和一個 401 Unauthorized 的響應一同被髮送。 |
3.3.4、實體首部
用來描述HTTP報文中實體相關資訊的首部，我們成為實體首部。
| 首部 | 描述 |
|---|---|
| Allow | Allow 首部欄位用於列舉資源所支援的 HTTP 方法的集合。 |
| Location | Location 首部指定的是需要將頁面重新定向至的地址。一般在響應碼為3xx的響應中才會有意義：- 303 (See Also) 始終引致請求使用 GET 方法，而，而 307 (Temporary Redirect) 和 308 (Permanent Redirect) 則不轉變初始請求中的所使用的方法；- 301 (Permanent Redirect) 和 302 (Found) 在大多數情況下不會轉變初始請求中的方法，不過一些比較早的使用者代理可能會引發方法的變更；除了重定向響應之外， 狀態碼為 201 (Created) 的訊息也會帶有Location首部。它指向的是新建立的資源的地址。 |
內容首部
| 首部 | 描述 |
|---|---|
| Content-Encoding | Content-Encoding 是一個實體訊息首部，用於對特定媒體型別的資料進行壓縮。 |
| Content-Languate | Content-Language 用來說明訪問者希望採用的語言或語言組合，這樣的話使用者就可以根據自己偏好的語言來定製不同的內容。 |
| Content-Length | 指明傳送給接收方的訊息主體的大小，即用十進位制數字表示的八位元組的數目。 |
| Content-Location | 指定的是要返回的資料的地址選項。最主要的用途是用來指定要訪問的資源經過內容協商後的結果的URL。 |
| Content-MD5 | 訊息主題的MD5校驗和 |
| Content-Range | 描述一個資料片段在整個檔案中的位置 |
| Content-Type | 指示資源的MIME型別 media type |
實體快取首部
實體快取首部提供與被快取實體有關的資訊，如什麼時候或者如何快取，快取是否有效等，通過快取首部可以估計快取何時失效。
| 首部 | 描述 |
|---|---|
| ETag | 資源的特定版本的識別符號。這可以讓快取更高效，並節省頻寬，因為如果內容沒有改變，Web伺服器不需要傳送完整的響應。 如果給定URL中的資源更改，則一定要生成新的Etag值。 |
| Expires | 該首部包含日期/時間， 即在此時候之後，響應過期。 無效的日期，比如 0, 代表著過去的日期，即該資源已經過期。 |
| Last-Modified | 含源頭伺服器認定的資源做出修改的日期及時間。 它通常被用作一個驗證器來判斷接收到的或者儲存的資源是否彼此一致。 由於精確度比 ETag 要低，所以這是一個備用機制。包含有 If-Modified-Since 或 If-Unmodified-Since 首部的條件請求會使用這個欄位。 |
3.4、訊息體
3.4.1、請求訊息體
並不是所有的請求都需要body，如：GET，HEAD，DELETE，OPTIONS通產不需要body。
請求body可以分為兩類：
- Single-resource bodies，由單個檔案組成。該型別 body 由兩個 header 定義：
Content-Type和Content-Length； - Multiple-resource bodies，由多部分body組成，每一部分包含不同的資訊位。通常是和 HTML Forms 連繫在一起。
3.4.2、響應訊息體
並不是所有的響應都有body，如 201 或 204狀態碼的響應一般不會有body。
響應body可以分為三類：
- Single-resource bodies，由已知長度的單個檔案組成。該型別 body 由兩個 header 定義：
Content-Type和Content-Length； - Single-resource bodies，由未知長度的單個檔案組成，通過將
Transfer-Encoding設定為chunked來使用 chunks 編碼； - Multiple-resource bodies，由多部分 body 組成，每部分包含不同的資訊段。但這是比較少見的。
3.5、狀態行
響應訊息的第一行是狀態行，由協議版本，數字狀態程式碼及其關聯的文字短語組成，每個元素由SP字元分隔。 除最後的CRLF序列外，不允許CR或LF。
狀態行格式：
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
3.5.1、Status-Code狀態碼和Reason-Phrase狀態描述
狀態碼是3位數的整數結果程式碼。
狀態碼的第一位數字定義響應的類別。 後兩位數字沒有任何分類作用。可以分為5個類別：
- 1xx：資訊狀態碼，收到請求，繼續進行；
- 2xx：請求成功接收；
- 3xx：重定向，必須採取進一步措施才能完成請求；
- 4xx：客戶端錯誤，請求包含錯誤語法，或者不能被完成；
- 5xx：伺服器錯誤，伺服器無法完成看似有效的請求；
RFC中定義的狀態碼很多，這裡我們列出最常見的一些狀態碼：
| 狀態碼 | 描述 | 詳細說明 |
|---|---|---|
| 101 | Switching Protocol | 該程式碼是響應客戶端的 Upgrade 標頭髮送的，並且指示伺服器也正在切換的協議。 |
| 200 | OK | 請求成功。 |
| 204 | No Content | 伺服器成功處理了請求，但不需要返回任何實體內容，並且希望返回更新了的元資訊。 用這個狀態碼區分成功狀態下又返回內容和沒返回內容的響應。 |
| 206 | Partial Content | 伺服器已經成功處理了部分 GET 請求。通過HTTP的分塊下載，獲取資源的部分時返回。該請求必須包含 Range 頭資訊來指示客戶端希望得到的內容範圍，並且可能包含 If-Range 來作為請求條件。 206狀態碼通常會攜帶 Content-Range，用於表示報文裡面body資料的具體範圍。 |
| 301 | Moved Permanently | 永久重定向，將來任何對此資源的引用都應該使用本響應返回的若干個 URI 之一。 |
| 302 | Found | 臨時重定向，客戶端下次應當繼續向原有地址傳送以後的請求。只有在Cache-Control或Expires中進行了指定的情況下，這個響應才是可快取的。 |
| 304 | Not Modified | 如果客戶端傳送了一個帶條件的 GET 請求且該請求已被允許，而文件的內容（自上次訪問以來或者根據請求的條件）並沒有改變，則伺服器應當返回這個狀態碼。304 響應禁止包含訊息體，因此始終以訊息頭後的第一個空行結尾。 |
| 400 | Bad Request | 語義有誤，當前請求無法被伺服器理解。除非進行修改，否則客戶端不應該重複提交這個請求。 |
| 401 | Unauthorized | 當前請求需要使用者驗證。該響應必須包含一個適用於被請求資源的 WWW-Authenticate 資訊頭用以詢問使用者資訊。客戶端可以重複提交一個包含恰當的 Authorization 頭資訊的請求。 |
| 403 | Forbidden | 伺服器已經理解請求，但是拒絕執行它。如果這不是一個 HEAD 請求，而且伺服器希望能夠講清楚為何請求不能被執行，那麼就應該在實體內描述拒絕的原因。當然伺服器也可以返回一個 404 響應，假如它不希望讓客戶端獲得任何資訊。 |
| 404 | Not Found | 請求失敗，請求所希望得到的資源未被在伺服器上發現。 究竟是不是真的資源不存在呢？還得看程式是怎麼寫的。 |
| 405 | Method Not Allowed | 請求行中指定的請求方法不能被用於請求相應的資源。該響應必須返回一個Allow 頭資訊用以表示出當前資源能夠接受的請求方法的列表。 |
| 408 | Request Timeout | 請求超時。客戶端沒有在伺服器預備等待的時間內完成一個請求的傳送。客戶端可以隨時再次提交這一請求而無需進行任何更改。 |
| 409 | Conflict | 由於和被請求的資源的當前狀態之間存在衝突，請求無法完成。 |
| 413 | Payload Too Large | 請求提交的實體資料大小超過了伺服器願意或者能夠處理的範圍。此種情況下，伺服器可以關閉連線以免客戶端繼續傳送此請求。如果這個狀況是臨時的，伺服器應當返回一個 Retry-After 的響應頭，以告知客戶端可以在多少時間以後重新嘗試。 |
| 429 | Too Many Requests | 使用者在給定的時間內傳送了太多請求（“限制請求速率”）。 |
| 431 | Request Header Fields Too Large | 請求頭欄位太大（ Request Header Fields Too Large） |
| 500 | Internal Server Error | 伺服器遇到了不知道如何處理的情況。通常用來捕獲伺服器異常，統一返回500，避免輸出詳細錯誤堆疊給別人利用。 |
| 501 | Not Implemented | 此請求方法不被伺服器支援且無法被處理。只有GET和HEAD是要求伺服器支援的，它們必定不會返回此錯誤程式碼。 |
| 502 | Bad Gateway | 此錯誤響應表明伺服器作為閘道器需要得到一個處理這個請求的響應，但是得到一個錯誤的響應。 |
| 503 | Service Unavailable | 伺服器沒有準備好處理請求。 常見原因是伺服器因維護或過載而停機。 |
| 504 | Gateway Timeout | 當伺服器作為閘道器，不能及時得到響應時返回此錯誤程式碼。 |
更多狀態碼說明：
上面我們把HTTP報文介紹了一遍，HTTP作為一個協議，只是規定了大家要遵循這樣的約定，但是具體實現的時候，還是要看應用程式的相容程度。我們在寫程式的時候，也不要跟協議對著幹，這會讓對接的同事無法理解的。
你都知道以下狀態碼的含義了嗎？
200 204 206 301 302 304 401 403 405 500 501 502 503 504
本文首次發表於: HTTP/1.1報文詳解 以及公眾號 Java架構雜談，未經許可，不得轉載。
本文為arthinking基於相關技術資料和官方文件撰寫而成，確保內容的準確性，如果你發現了有何錯漏之處，煩請高抬貴手幫忙指正，萬分感激。
如果您覺得讀完本文有所收穫的話，可以關注我的賬號，或者點贊吧，碼字不易，您的支援就是我寫作的最大動力，再次感謝！
為了把相關係列文章收集起來，方便後續查閱，這裡我建立了一個Github倉庫，把釋出的文章按照分類收集起來了，感興趣的朋友可以Star跟進：
關注我的部落格IT宅(itzhai.com)或者公眾號Java架構雜談，及時獲取最新的文章。我將持續更新後端相關技術，涉及JVM、Java基礎、架構設計、網路程式設計、資料結構、資料庫、演算法、併發程式設計、分散式系統等相關內容。
References
- 謝希仁. 計算機網路(第6版). 電子工業出版社.
- TCP/IP詳解 卷1：協議（原書第2版）. 機械工業出版社.
- UNIX網路程式設計 卷1：套接字聯網API. 人民郵電出版社
- HTTP權威指南. 人民郵電出版社
- HTTP/2基礎教程. 人民郵電出版社
- 劉超. 趣談網路協議. 極客時間
- 羅劍鋒. 透視HTTP協議. 即可時間
本文同步發表於我的部落格IT宅(itzhai.com)和公眾號(Java架構雜談)
作者：arthinking | 公眾號：Java架構雜談
部落格連結：https://www.itzhai.com/articles/detailed-explanation-of-http-1-1-messages.html
版權宣告： 版權歸作者所有，未經許可不得轉載，侵權必究！聯絡作者請加公眾號。
Hypertext Transfer Protocol -- HTTP/1.1 2616. Retrieved from https://tools.ietf.org/html/rfc2616 ↩︎ ↩︎
HTTP. MDN web docs. Retrieved from https://developer.mozilla.org/zh-CN/docs/Web/HTTP ↩︎
CONNECT. Retrieved from https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Methods/CONNECT ↩︎
HTTP Headers. Retrieved from https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Headers ↩︎
List of HTTP status codes. Retrieved from https://en.wikipedia.org/wiki/List_of_HTTP_status_codes ↩︎
https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status. Retrieved from https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Status ↩︎