# 第二章 協議返回狀態碼 > 作者：肖鵬 時間：2018-04-06 ## 2.1 報文信息 ### 2.1.1 報文 HTTP報文本身是由多行數據構成的字符串文本 HTTP報文大致可分為報文首部和報文主體兩塊，最初是由空行來劃分，通常，不一定需要報文主體 ### 2.1.2 請求報文及響應報文結構 請求報文結構： 1. 報文首部 1. 請求行：**包含用戶請求的方法，請求URI和HTTP版本** 2. 請求首部字段 3. 通用首部字段 4. 實體首部字段 5. 其他 2. 空行（CR + LF） 3. 報文主體 響應報文結構： 1. 報文首部 1. 狀態行：**包含表明響應結果的狀態碼，原因短語和HTTP版本** 2. 響應首部字段 3. 通用首部字段： 4. 實體首部字段 5. 其他 2. 空行（CR + LF） 3. 報文主體 首部字段：包含請求和響應的各種條件和屬性的各類首部，一般有4種首部，分別是：通用首部、請求首部、響應首部和實體首部 ### 2.1.3 報文和實體差異 > 報文（message）： 是HTTP通信中的基本單位，由8位組字節流（octet sequence，其中octet為8個比特）組成，通過HTTP通信傳輸。 > 實體（entity）： 作為請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。 > HTTP報文的主體用于傳輸請求或響應的實體主體。 > > 通常，報文主體等于實體主體，只有當傳輸中進行編碼操作時，實體主體的內容發生變化，才導致它和報文主體產生差異。** 后面會多次出現，所以我們在這里提前了解兩者差異 ** ## 2.2 請求行信息 > GET /index.html HTTP/1.1 請求方法： | 方法 | 詳細 | | ---|--- | | GET | 請求獲取服務器資源，返回報文主體 | | HEAD | 用于確認URI的有效性及資源更新的日期時間等，和GET一樣，只不過不返回主體 | | POST | 向指定資源提交數據進行處理請求（例如提交表單或者上傳件）。數據被包含在請求體中。POST請求可能會導致新的資源的建立和/或已有資源的修改。| | PUT | 從客戶端向服務器傳送的數據取代指定的文檔的內容。 | | DELETE | 請求服務器刪除指定的頁面。| | CONNECT | HTTP/1.1協議中預留給能夠將連接改為管道方式的代理服務器。要求使用隧道協議連接代理 | | OPTIONS | 允許客戶端查看服務器的性能，詢問支持的方法 | | TRACE | 回顯服務器收到的請求，主要用于測試或診斷。追蹤路勁 | 一般 DELETE，PUT直接被禁用，畢竟在HTTP/1.1中沒有驗證機制，所以為了服務器的安全，一般會禁止使用這兩種方法 ## 2.3 響應狀態碼 > HTTP狀態碼負責表示客戶端HTTP請求的返回結果、標記服務器端的處理是否正常、通知出現的錯誤等工作。當然可以自定義狀態碼 | 類別 | 信息 | 原因短語 | | ---|--- | --- | | 1XX | Informational(信息性狀態碼) | 接收的請求正在處理 | | 2XX | Success(成功狀態碼) | 請求正常處理完畢 | | 3XX | Redirection(重定向狀態碼) | 需要進行附加操作已完成請求 | | 4XX | Client Error(客戶端錯誤狀態碼) | 服務器無法處理請求 | | 5XX | Server Error(服務端錯誤狀態碼) | 服務器處理請求出錯 | ### 2.3.1 1XX 繼續 | 狀態碼 | 信息 |表示 | | ---|--- | --- | | 100 | Continue | 客戶端應當繼續發送請求 | | 101 | Switching Protocols | 服務器已經理解了客戶端的請求，并將通過Upgrade 消息頭通知客戶端采用不同的協議來完成這個請求 | | 102 | Processing | 由WebDAV（RFC 2518）擴展的狀態碼，代表處理將被繼續執行 | ### 2.3.2 2XX 成功 | 狀態碼 | 信息 |表示 | | ---|--- | --- | | 200 | OK | 從客戶端發來的請求在服務端正常處理 | | 204 | No Content | 服務端接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分，另外也不允許返回任何實體的主體 | | 206 | Partial Content | 客戶端進行了范圍請求， 而服務器成功執行了這部分請求，響應報文中包含由Content—Range 指定的范圍的實體內容 | ### 2.3.3 3XX 重定向 | 狀態碼 | 信息 |表示 | | ---|--- | --- | | 301 | Moved Permanently | 永久性重定向 | | 302 | Found | 臨時性重定向 | | 303 | See Other | 由于對應的資源存在著另一個uri，應使用GET方法定向獲取請求的資源 | | 304 | Not Modified | 客戶端發送附帶條件的請求，也就是資源找到了，但是沒有符合條件請求 | | 307 | Tempoeary Redirect | 臨時重定向，和302很相似，但是會根據游覽器不同導致出現不同問題 | > 注意：當301、302、303響應狀態碼返回時，幾乎所有的游覽器都會把POST改為GET，并刪除請求報文內的主體，之后請求會自動再次發送 > > 301、302標準是禁止將POST改為GET方法，但實際使用時都會改變 > 304的請求附加條件是指采用GET方法的請求報文中包含If-Match、If-Modified-Since、IF-None-Match、IF-Range、If-Unmodified-Since中的任一首部 ### 2.3.4 4xx 客戶端錯誤 > 4XX 的響應結果表明客戶端是發生錯誤的原因所在 | 狀態碼 | 信息 | 表示 | | ---|--- | --- | | 400 | Bad Request | 請求報文中存在語法錯誤：游覽器會像200 OK 一樣對待改狀態碼 | | 401 | Unauthorized | 發送的請求需要通過http認證(BASIC認證、DIGEST認證)的認證信息，如果前面已經請求過一次，證明認證失敗 | | 403 | Forbidden | 請求資源的訪問被服務器拒絕 | | 404 | Not Found | 服務器無法找到請求的資源 | ### 2.3.5 5xx 服務器錯誤 | 狀態碼 | 信息 | 表示 | | --- | --- | --- | | 500 | Internal Server Error | 服務器端知悉請求時發生錯誤 | | 503 | Service Unavailable | 服務器暫時處于超負載或正在進行停機維護，現在無法處理請求 | > Ps：作為前端進行ajax請求時，出現5xx錯誤，那最大的可能是服務端出現問題。 ### 2.3.6 狀態碼總結 > 1. HTTP狀態碼不可能就這么一點，所以這里我只寫了常用狀態碼，當然標準狀態碼目前是截止與600，我們也可以自定義狀態碼 > 2. 狀態碼返回信息字段可以修改，有時會出現服務器出現問題，但是依然返回200的情況，所以實際運用中需要根據實際情況來確定 ## 2.4 總結 本章我們簡單的總結了下協議響應和請求的結構，以及狀態碼，下章我們將從首部字段一個一個分析使用 >作者：肖鵬 時間：2018-04-06