前面介紹了URL是用於定位服務器上的資源。但是定位到資源後，通過什麼樣的方式、規定來讓客戶端和服務端進行交流呢？這就是本篇要介紹的HTTP報文。
1 報文流
HTTP 報文是在 HTTP 應用程序之間發送的數據塊。這些數據塊以一些文本形式的元信息（meta-information）開頭。這些報文在客戶端、服務器和代理之間流動。術語“流入”、“流出”、“上游”及“下游”都是用來描述報文方向的。一個示例如下圖所示：
1.1 報文向下流動
HTTP 報文會像河水一樣流動。不管是請求報文還是響應報文，所有報文都會向下遊（downstream）流動。所有報文的發送者都在接收者的上游（upstream）。如下圖所示中，對請求報文來說，代理 1 位於代理 3 的上游，但對響應報文來說，它就位於代理 3 的下游 1。
2 報文組成部分
一條HTTP報文一般由如下部分組成：對報文進行描述的起始行（start line）、包含屬性的首部（header）塊，以及可選的、包含數據的主體（body）部分。示例如圖：
如上圖所示，start line和header一般都有ASCII碼組成，每行都由CRLF標識作爲結束終止，但是有些程序也會用單個換行符作爲結束標誌。body部分另外兩個組成部分不太一樣，除了可以包含文本外，還可以包含一些二進制數據。
2.1 報文的語法
HTTP報文分爲兩類：請求報文和響應報文。兩類報文的格式如下：
請求報文
<method> <request-URL> <version>
<headers>
<entity-body>
請求報文：
<version> <status> <reason-phrase>
<headers>
<entity-body>
每個部分簡要介紹如下：
- 方法（method）：客戶端希望對服務器進行的操作動作，如：GET, POST
- 請求URL（request-URL）：“、命名了所請求資源，或者 URL 路徑組件的完整 URL。
- 版本（version）：報文所使用的HTTP版本，格式：HTTP/<major>.<minor>
- 狀態碼（status-code）：描述請求過程中所發生的情況。
- 原因短語（reason-phase）：用用戶對前面狀態碼的簡短描述，主要用於給用戶看的。
- 首部（header）：可以有零個或多個首部，每個首部都包含一個名字，後面跟着一個冒號（:），然後是一個可選的空格，接着是一個值，最後是一個 CRLF。
- 實體部分（entity-body）：實體的主體部分包含一個由任意數據組成的數據塊。
2.2 起始行
所有的 HTTP 報文都以一個起始行作爲開始。分爲請求行和嚮應行。
- 請求行：包含了一個方法和一個請求URL，還有HTTP版本。這些字段都有空格分開
- 響應行：包含了響應報文使用的HTTP版本，數字狀態，以及描述狀態碼的原因短語。
2.2.1 方法
請求的起始行以方法作爲開始，方法用來告知服務器需要做什麼，HTTP規範中定義了常用的方法如下：
| 方 法 | 描 述 | 是否包含主體 |
|---|---|---|
| GET | 從服務器獲取一份文檔 | 否 |
| HEAD | 只從服務器獲取文檔的首部 | 否 |
| POST | 向服務器發送需要處理的數據 | 是 |
| PUT | 將請求的主體部分存儲在服務器上 | 是 |
| TRACE | 對可能經過代理服務器傳送到服務器上去的報文進行追蹤 | 否 |
| OPTIONS | 決定可以在服務器上執行哪些方法 | 否 |
| DELETE | 從服務器上刪除一份文檔 | 否 |
除了這些方法外，我們還可以自定義一些擴展方法。
2.2.2 狀態碼
方法是用來告訴服務器做什麼事情的，狀態碼則用來告訴客戶端，發生了什麼事情。狀態碼位於響應行中，如：HTTP/1.0 200 OK中，200即爲狀態碼。HTTP中狀態碼分類如下：
| 整體範圍 | 已定義範圍 | 分 類 |
|---|---|---|
| 100～199 | 100～101 | 信息提示 |
| 200～299 | 200～206 | 成功 |
| 300～399 | 300～305 | 重定向 |
| 400～499 | 400～415 | 客戶端錯誤 |
| 500～599 | 500～505 | 服務器錯誤 |
常見狀態碼如下：
| 狀 態 碼 | 原因短語 | 含 義 |
|---|---|---|
| 200 | OK | 成功。請求的所有數據都在響應主體中 |
| 401 | Unauthorized（未授權） | 需要輸入用戶名和密碼 |
| 404 | Not Found（未找到） | 服務器無法找到所請求URL對應的資源 |
2.2.3 原因短語
原因短語是響應起始行中的最後一個組件。它爲狀態碼提供了文本形式的解釋。比如，在行 HTTP/1.0 200 OK 中，OK 就是原因短語。
2.2.4 版本號
版本號會以 HTTP/x.y 的形式出現在請求和響應報文的起始行中。版本號說明了應用程序支持的最高 HTTP 版本。
有個注意的地方，版本號不會被當作小數來處理。版本中的每個數字（比如 HTTP/1.0 中的 1 和 0）都會被當作一個單獨的數字來處理。比如，HTTP/2.22 就比 HTTP/2.3 的版本要高，因爲 22 比 3 大。
2.3 首部
前面介紹了請求和響應的第一行數據——起始行，接下來介紹首部。
HTTP 首部字段向請求和響應報文中添加了一些附加信息。本質上來說，它們只是一些鍵值對的列表。首部一般分爲以下幾類：通用首部、請求首部、響應首部、實體首部、擴展首部。
每個 HTTP 首部都有一種簡單的語法：名字後面跟着冒號（ ：），然後跟上可選的空格，再跟上字段值，最後是一個 CRLF。
常見首部示例如下：
| 首部實例 | 描 述 |
|---|---|
| Date:Tue,3Oct 1997 02:16:03 GMT | 服務器產生響應的日期 |
| Content-length:15040 | 實體的主體部分包含了15 040字節的數據 |
| Content-type:image/gif | 實體的主體部分是一個GIF圖片 |
| Accept: image/gif, image/jpeg, text/html | 客戶端可以接收GIF圖片和JPEG圖片以及HTML |
首部一個鍵可以對應多個值，如果出現此種情況，爲了提高可讀性，多出來的行每行前面至少要有一個空格或製表符，如：
HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
Version 1.0
2.4 實體部分(body)
HTTP 報文的第三部分是可選的實體主體部分。實體的主體是 HTTP 報文的負荷。就是 HTTP 要傳輸的內容。
HTTP 報文可以承載很多類型的數字數據：圖片、視頻、HTML 文檔、軟件應用程序、信用卡事務、電子郵件等。
3 方法
上面我們也提到過方法，現在對方法進行一個詳細的說明。
HTTP1.1要求，每臺服務器必須要實現GET和HEAD方法，其他方法可以選擇實現，也可以選擇不實現。同時HEAD和GET也被稱爲安全方法，因爲這兩個方法不會對請求的資源產生任何動作。
3.1 GET
GET 是最常用的方法。通常用於請求服務器發送某個資源。HTTP/1.1 要求服務器實現此方法。一個示例如下：
3.2 HEAD
HEAD 方法與 GET 方法的行爲很類似，但服務器在響應中只返回首部。使用HEAD方法，可以達到如下效果：
- 在不獲取資源的情況下了解資源的情況(如：判斷內容類型)；
- 通過查看響應碼，瞭解該資源是否存在；
- 通過查看首部，檢驗資源是否被修改了
3.3 PUT
與 GET 從服務器讀取文檔相反，PUT 方法會向服務器寫入文檔。PUT方法會讓服務器創建一個所請求URL命名的新文檔，如果該文檔已經存在，則會更新。
一個PUT請求示例如下：
3.4 POST
POST 方法起初是用來向服務器輸入數據的 。實際上，通常會用它來支持 HTML 的表單。這裏注意其與PUT方法的區別是POST僅僅是用來給服務器發送數據，至於數據怎麼處理完全由服務器自己決定，而PUT方法是讓服務器存儲數據的。
3.5 TRACE
客戶端發起一個請求時，這個請求可能要穿過防火牆、代理、網關或其他一些應用程序。每個中間節點都可能會修改原始的 HTTP 請求。TRACE 方法允許客戶端在最終將請求發送給服務器時，看看它變成了什麼樣子。其一般用於診斷請求過程中是否被修改或者毀壞。TRACE 請求中不能帶有實體的主體部分。
一個TRACE請求如下：
3.6 OPTIONS
OPTIONS 方法請求 Web 服務器告知其支持的各種功能。可以詢問服務器通常支持哪些方法，或者對某些特殊資源支持哪些方法。
3.7 DELETE
顧名思義，DELETE 方法所做的事情就是請服務器刪除請求 URL 所指定的資源。但是，客戶端應用程序無法保證刪除操作一定會被執行。因爲 HTTP 規範允許服務器在不通知客戶端的情況下撤銷請求。
3.8 擴展方法
HTTP 被設計成字段可擴展的，這樣新的特性就不會使老的軟件失效了。擴展方法指的就是沒有在 HTTP/1.1 規範中定義的方法。服務器會爲它所管理的資源實現一些 HTTP 服務，這些方法爲開發者提供了一種擴展這些 HTTP 服務能力的手段。
4 狀態碼
狀態碼總體被分爲5大類，之前已經介紹過了。這裏我們針對沒類做一些介紹。
4.1 100~199信息狀態碼
| 狀 態 碼 | 原因短語 | 含 義 |
|---|---|---|
| 100 | Continue | 說明收到了請求的初始部分，請客戶端繼續。發送了這個狀態碼之後，服務器在收到請求之後必須進行響應。更多信息請參見附錄C中的Expect 首部介紹 |
| 101 | Switching Protocols | 說明服務器正在根據客戶端的指定，將協議切換成Update 首部所列的協議 |
4.2 200~299成功狀態碼
客戶端發起請求時，這些請求通常都是成功的。服務器有一組用來表示成功的狀態碼。
| 狀態碼 | 原因短語 | 含 義 |
|---|---|---|
| 200 | OK | 請求沒問題，實體的主體部分包含了所請求的資源 |
| 201 | Created | 用於創建服務器對象的請求（比如，PUT）。響應的實體主體部分中應該包含各種引用了已創建的資源的URL，Location首部包含的則是最具體的引用。服務器必須在發送這個狀態碼之前創建好對象 |
| 202 | Accepted | 請求已被接受，但服務器還未對其執行任何動作。不能保證服務器會完成這個請求；這只是意味着接受請求時，它看起來是有效的。 服務器應該在實體的主體部分包含對請求狀態的描述，或許還應該有對請求完成時間的估計（或者包含一個指針，指向可以獲取此信息的位置） |
| 203 | Non-Authoritative Information | 實體首部包含的信息不是來自於源端服務器，而是來自資源的一份副本。如果中間節點上有一份資源副本，但無法或者沒有對它所發送的與資源有關的元信息（首部）進行驗證，就會出現這種情況。 這種響應碼並不是非用不可的；如果實體首部來自源端服務器，響應爲200狀態的應用程序就可以將其作爲一種可選項使用 |
| 204 | No Content | 響應報文中包含若干首部和一個狀態行，但沒有實體的主體部分。主要用於在瀏覽器不轉爲顯示新文檔的情況下，對其進行更新（比如刷新一個表單頁面） |
| 205 | Reset Content | 另一個主要用於瀏覽器的代碼。負責告知瀏覽器清除當前頁面中的所有HTML 表單元素 |
| 206 | Partial Content | 成功執行了一個部分或Range（範圍）請求。稍後我們會看到，客戶端可以通過一些特殊的首部來獲取部分或某個範圍內的文檔——這個狀態碼就說明範圍請求成功了。 206響應中必須包含Content-Range、Date以及ETag或Content-Location 首部 |
4.3 300~399重定向狀態碼
重定向狀態碼要麼告知客戶端使用替代位置來訪問他們所感興趣的資源，要麼就提供一個替代的響應而不是資源的內容。如果資源已被移動，可發送一個重定向狀態碼和一個可選的 Location 首部來告知客戶端資源已被移走，以及現在可以在哪裏找到它。請求示例如下：
常見的重定向狀態碼如下：
| 狀態碼 | 原因短語 | 含 義 |
|---|---|---|
| 300 | Multiple Choices | 客戶端請求一個實際指向多個資源的URL時會返回這個狀態碼，比如服務器上有某個HTML文檔的英語和法語版本。返回這個代碼時會帶有一個選項列表；這樣用戶就可以選擇他希望使用的那一項了。有多個版本可用時，客戶端需要溝通解決。服務器可以在Location 首部包含首選URL |
| 301 | Moved Permanently | 在請求的URL已被移除時使用。響應的Location 首部中應該包含資源現在所處的URL |
| 302 | Found | 與301狀態碼類似；但是，客戶端應該使用Location 首部給出的URL來臨時定位資源。將來的請求仍應使用老的URL |
| 303 | See Other | 告知客戶端應該用另一個URL來獲取資源。新的URL位於響應報文的 Location 首部。其主要目的是允許POST請求的響應將客戶端定向到某個資源上去 |
| 304 | Not Modified | 客戶端可以通過所包含的請求首部，使其請求變成有條件的。更多有關條件首部的內容請參見第3章。如果客戶端發起了一個條件GET請求，而最近資源未被修改的話，就可以用這個狀態碼來說明資源未被修改。帶有這個狀態碼的響應不應該包含實體的主體部分 |
| 305 | Use Proxy | 用來說明必須通過一個代理來訪問資源；代理的位置由Location 首部給出。很重要的一點是，客戶端是相對某個特定資源來解析這條響應的，不能假定所有請求，甚至所有對持有所請求資源的服務器的請求都通過這個代理進行。如果客戶端錯誤地讓代理介入了某條請求，可能會引發破壞性的行爲，而且會造成安全漏洞 |
| 306 | （未使用） | 當前未使用 |
| 307 | Temporary Redirect | 與301狀態碼類似；但客戶端應該使用Location 首部給出的URL來臨時定位資源。將來的請求應該使用老的URL |
其中302，303，307的區別如下：
- 302 主要是HTTP1.0的狀態碼，本身規定是除非是HEAD或者GET請求，否則必須經過用戶同意才能重定向，但是一般瀏覽器處理是直接重定向到新的URL了。
- 303 HTTP1.1新添加的。由於之前瀏覽器對302的處理大部分都是直接重定向了，所以新的HTTP協議細分出了303和307，303是允許瀏覽器自動重定向的。
- 307 HTTP1.1新添加。除非是GET或者HEAD請求，否則需要用戶同意才能重定向。
這幾個狀態碼總的說來關係就是，HTTP1.0的時候只有302，要求非GET或HEAD請求必須經用戶同意才能重定向，但是大部分瀏覽器並沒有這樣做，所以在HTTP1.1的時候，將302細分出了303和307。303是可以自動重定向，307要求非GET或者HEAD必須經用戶同意，保留302是爲了和1.0版本兼容。
4.4 400~499客戶端錯誤狀態碼
有時客戶端會發送一些服務器無法處理的東西，比如格式錯誤的請求報文，這時服務器就會返回400系列錯誤碼告知客戶端。
常用錯誤碼如下：
| 狀態碼 | 原因短語 | 含 義 |
|---|---|---|
| 400 | Bad Request | 用於告知客戶端它發送了一個錯誤的請求 |
| 401 | Unauthorized | 與適當的首部一同返回，在這些首部中請求客戶端在獲取對資源的訪問權之前，對自己進行認證。 |
| 402 | Payment Required | 現在這個狀態碼還未使用，但已經被保留，以作未來之用 |
| 403 | Forbidden | 用於說明請求被服務器拒絕了。如果服務器想說明爲什麼拒絕請求，可以包含實體的主體部分來對原因進行描述。但這個狀態碼通常是在服務器不想說明拒絕原因的時候使用的 |
| 404 | Not Found | 用於說明服務器無法找到所請求的URL。通常會包含一個實體，以便客戶端應用程序顯示給用戶看 |
| 405 | Method Not Allowed | 發起的請求中帶有所請求的URL不支持的方法時，使用此狀態碼。應該在響應中包含Allow首部，以告知客戶端對所請求的資源可以使用哪些方法。 |
| 406 | Not Acceptable | 客戶端可以指定參數來說明它們願意接收什麼類型的實體。服務器沒有與客戶端可接受的URL相匹配的資源時，使用此代碼。通常，服務器會包含一些首部，以便客戶端弄清楚爲什麼請求無法滿足。更多信息請參見第17章 |
| 407 | Proxy Authentication Required | 與401狀態碼類似，但用於要求對資源進行認證的代理服務器 |
| 408 | Request Timeout | 如果客戶端完成請求所花的時間太長，服務器可以回送此狀態碼，並關閉連接。超時時長隨服務器的不同有所不同，但通常對所有的合法請求來說，都是夠長的 |
| 409 | Conflict | 用於說明請求可能在資源上引發的一些衝突。服務器擔心請求會引發衝突時，可以發送此狀態碼。響應中應該包含描述衝突的主體 |
| 410 | Gone | 與404類似，只是服務器曾經擁有過此資源。主要用於Web站點的維護，這樣服務器的管理者就可以在資源被移除的情況下通知客戶端了 |
| 411 | Length Required | 服務器要求在請求報文中包含Content-Length首部時使用。 |
| 412 | Precondition Failed | 客戶端發起了條件請求，且其中一個條件失敗了的時候使用。客戶端包含了Expect首部時發起的就是條件請求。 |
| 413 | Request Entity Too Large | 客戶端發送的實體主體部分比服務器能夠或者希望處理的要大時，使用此狀態碼 |
| 414 | Request URI Too Long | 客戶端所發請求中的請求URL比服務器能夠或者希望處理的要長時，使用此狀態碼 |
| 415 | Unsupported Media Type | 服務器無法理解或無法支持客戶端所發實體的內容類型時，使用此狀態碼 |
| 416 | Requested Range Not Satisfiable | 請求報文所請求的是指定資源的某個範圍，而此範圍無效或無法滿足時，使用此狀態碼 |
| 417 | Expectation Failed | 請求的Expect請求首部包含了一個期望，但服務器無法滿足此期望時，使用此狀態碼。如果代理或其他中間應用程序有確切證據說明源端服務器會爲某請求產生一個失敗的期望，就可以發送這個響應狀 |
4.5 500~599服務器錯誤狀態碼
如果客戶端發出了正確的請求，但是服務器由於自身的原因無法正確處理，或者內部出現錯誤，這個時候就會返回該系列錯誤碼用於說明具體是什麼錯誤。
常見的錯誤碼如下：
| 狀態碼 | 原因短語 | 含 義 |
|---|---|---|
| 500 | Internal Server Error | 服務器遇到一個妨礙它爲請求提供服務的錯誤時，使用此狀態碼 |
| 501 | Not Implemented | 客戶端發起的請求超出服務器的能力範圍（比如，使用了服務器不支持的請求方法）時，使用此狀態碼 |
| 502 | Bad Gateway | 作爲代理或網關使用的服務器從請求響應鏈的下一條鏈路上收到了一條僞響應（比如，它無法連接到其父網關）時，使用此狀態碼 |
| 503 | Service Unavailable | 用來說明服務器現在無法爲請求提供服務，但將來可以。如果服務器知道什麼時候資源會變爲可用的，可以在響應中包含一個Retry-After首部。 |
| 504 | Gateway Timeout | 與狀態碼408類似，只是這裏的響應來自一個網關或代理，它們在等待另一服務器對其請求進行響應時超時了 |
| 505 | HTTP Version Not Supported | 服務器收到的請求使用了它無法或不願支持的協議版本時，使用此狀態碼。有些服務器應用程序會選擇不支持協議的早期 |
5 首部(Header)
前面概述的時候，已經大致說了Header可以分爲幾類，下面就針對沒類再進行一些說明。
5.1 通用首部
所謂通用首部，就是不區分是請求首部還是響應首部，都可以使用的首部，一般用於提供報文的基本信息。
常用的通用首部如下：
| 首 部 | 描 述 |
|---|---|
| Connection | 允許客戶端和服務器指定與請求/響應連接有關的選項 |
| Date | 提供日期和時間標誌，說明報文是什麼時間創建的 |
| MIME-Version | 給出了發送端使用的MIME版本 |
| Trailer | 如果報文采用了分塊傳輸編碼（chunked transfer encoding）方式，就可以用這個首部列出位於報文拖掛（trailer）部分的首部集合2 |
| Transfer-Encoding | 告知接收端爲了保證報文的可靠傳輸，對報文采用了什麼編碼方式 |
| Update | 給出了發送端可能想要“升級”使用的新版本或協議 |
| Via | 顯示了報文經過的中間節點（代理、網關） |
| Cache-Control | 用於隨報文傳送緩存指示 |
| Pragma | 另一種隨報文傳送指示的方式，但並不專用於緩存 |
5.2 請求首部
請求首部是指只能用在請求當中的首部信息。常用請求首部如下：
| 首 部 | 描 述 |
|---|---|
| Client-IP4 | 提供了運行客戶端的機器的IP地址 |
| From | 提供了客戶端用戶的E-mail地址 |
| Host | 給出了接收請求的服務器的主機名和端口號 |
| Referer | 提供了包含當前請求URI的文檔的URL |
| UA-Color | 提供了與客戶端顯示器的顯示顏色有關的信息 |
| UA-CPU | 給出了客戶端CPU的類型或製造商 |
| UA-Disp | 提供了與客戶端顯示器（屏幕）能力有關的信息 |
| UA-OS | 給出了運行在客戶端機器上的操作系統名稱及版本 |
| UA-Pixels | 提供了客戶端顯示器的像素信息 |
| User-Agent | 將發起請求的應用程序名稱告知服務器 |
如果我們再細分一下，請求首部一般分爲下面幾種類型：
5.2.1 Accept首部
該首部告訴服務器客戶端可以接收哪些條件的響應數據，具體如下：
| 首 部 | 描 述 |
|---|---|
| Accept | 告訴服務器能夠發送哪些媒體類型 |
| Accept-Charset | 告訴服務器能夠發送哪些字符集 |
| Accept-Encoding | 告訴服務器能夠發送哪些編碼方式 |
| Accept-Language | 告訴服務器能夠發送哪些語言 |
| TE7 | 告訴服務器可以使用哪些擴展傳輸編碼 |
5.2.2 條件請求首部
客戶端在某些情況下會對請求加上一部分條件限制，比如我們已經在本地緩存了一份文檔的數據，通過 If-Modified-Since 條件首部就可以判斷我們的緩存是否還有效，是否需要重新從服務器獲取新的文檔。常見的條件首部如下：
| 首 部 | 描 述 |
|---|---|
| Expect | 允許客戶端列出某請求所要求的服務器行爲 |
| If-Match | 如果實體標記與文檔當前的實體標記相匹配，就獲取這份文檔 |
| If-Modified-Since | 除非在某個指定的日期之後資源被修改過，否則就限制這個請求 |
| If-None-Match | 如果提供的實體標記與當前文檔的實體標記不相符，就獲取文檔 |
| If-Range | 允許對文檔的某個範圍進行條件請求 |
| If-Unmodified-Since | 除非在某個指定日期之後資源沒有被修改過，否則就限制這個請求 |
| Range | 如果服務器支持範圍請求，就請求資源的指定範圍9 |
5.2.3 安全請求首部
HTTP 本身就支持一種簡單的機制，可以對請求進行質詢 / 響應認證。這種機制要求客戶端在獲取特定的資源之前，先對自身進行認證，這樣就可以使事務稍微安全一些。常用的安全首部如下：
| 首 部 | 描 述 |
|---|---|
| Authorization | 包含了客戶端提供給服務器，以便對其自身進行認證的數據 |
| Cookie | 客戶端用它向服務器傳送一個令牌——它並不是真正的安全首部，但確實隱含了安全功能 |
| Cookie2 | 用來說明請求端支持的cookie版本 |
5.2.4 代理請求首部
隨着因特網上代理的普遍應用，人們定義了幾個首部來協助其更好地工作。
| 首 部 | 描 述 |
|---|---|
| Max-Forward | 在通往源端服務器的路徑上，將請求轉發給其他代理或網關的最大次數——與TRACE方法一同使用 |
| Proxy-Authorization | 與Authorization 首部相同，但這個首部是在與代理進行認證時使用的 |
| Proxy-Connection | 與Connection 首部相同，但這個首部是在與代理建立連接時使用的 |
5.3 響應首部
響應首部是指用在響應的首部信息，常用的響應首部如下：
| 首 部 | 描 述 |
|---|---|
| Age | （從最初創建開始）響應持續時間 |
| Public | 服務器爲其資源支持的請求方法列表 |
| Retry-After | 如果資源不可用的話，在此日期或時間重試 |
| Server | 服務器應用程序軟件的名稱和版本 |
| Title | 對HTML文檔來說，就是HTML文檔的源端給出的標題 |
| Warning | 比原因短語中更詳細一些的警告報文 |
同請求首部一樣，響應首部也可進一步細分。
5.3.1 協商首部
協商首部是用於一些可協商資源的情況。如：同樣一份穩定，有中文，英文等幾種語言。這個時候，就可以通過協商首部確定是哪種語言的資源。
| 首 部 | 描 述 |
|---|---|
| Accept-Ranges | 對此資源來說，服務器可接受的範圍類型 |
| Vary | 服務器查看的其他首部的列表，可能會使響應發生變化；也就是說，這是一個首部列表，服務器會根據這些首部的內容挑選出最適合的資源版本發送給客戶端 |
5.3.2 安全響應首部
其意義同安全請求首部，只是用於響應而已，常用的首部如下：
| 首 部 | 描 述 |
|---|---|
| Proxy-Authenticate | 來自代理的對客戶端的質詢列表 |
| Set-Cookie | 不是真正的安全首部，但隱含有安全功能；可以在客戶端設置一個令牌，以便服務器對客戶端進行標識 |
| Set-Cookie2 | 與Set-Cookie 類似，RFC 2965 Cookie定義； |
| WWW-Authenticate | 來自服務器的對客戶端的質詢列表 |
5.4 實體首部
有部分首部是用於描述實體(body)部分數據的信息的，這個部分首部被稱爲實體首部，由於請求和響應報文都可攜帶實體數據，所以該部分首部並不一定區分是請求首部還是響應首部。
5.4.1 內容首部
該部分內容主要用於描述實體內容的信息，常見的如下表：
| 首 部 | 描 述 |
|---|---|
| Content-Base | 解析主體中的相對URL時使用的基礎URL |
| Content-Encoding | 對主體執行的任意編碼方式 |
| Content-Language | 理解主體時最適宜使用的自然語言 |
| Content-Length | 主體的長度或尺寸 |
| Content-Location | 資源實際所處的位置 |
| Content-MD5 | 主體的MD5校驗和 |
| Content-Range | 在整個資源中此實體表示的字節範圍 |
| Content-Type | 這個主體的對象類型 |
5.4.2 實體緩存首部
該部分首部主要用於描述緩存相關信息，常見如下：
| 首 部 | 描 述 |
|---|---|
| ETag | 與此實體相關的實體標記17 |
| Expires | 實體不再有效，要從原始的源端再次獲取此實體的日期和時間 |
| Last-Modified | 這個實體最後一次被修改的日期和時間 |
到這裏，HTTP報文的相關簡要介紹都這就結束了，本篇只是對整體進行了簡要介紹。其中有些重要的內容後續章節會進行展開詳細說明。