如果說HTTP是因特網(wǎng)的信使，那么HTTP報文就是運送的包裹。所有的HTTP程序都是通過互相發(fā)送報文來完成工作的。本文將介紹HTTP報文的流動方式，報文的組成部分，請求和響應報文之間的區(qū)別等。

報文流
HTTP報文是在HTTP應用程序之間發(fā)送的數(shù)據(jù)塊，這些數(shù)據(jù)塊以文本形式存在，以描述了報文的內容及含義的元信息開頭，后面跟著可選的數(shù)據(jù)部分。這些報文在客戶端、服務器和代理之間流動。一般來說，報文流根據(jù)流向引用以下三種術語：報文流入（inbound）向服務器，工作完成之后，會流出（outbound）向客戶端或用戶Agent代理；不管是請求報文還是響應寶安溫，所有報文的接收者都在發(fā)送者的下游（downstream），報文只會向下游流動。

報文的組成部分
報文由起始行、首部，以及可選的包含數(shù)據(jù)的主體三個部分組成。所有的HTTP報文分為兩類：請求（request）報文和響應（response）報文，如下圖示例。前者會向Web服務器請求對資源進行一些操作，后者承載了狀態(tài)信息和操作產生的所有結果數(shù)據(jù)，把結果返回給客戶端。

起始行
所有的HTTP報文都以一個起始行作為開始。請求報文的起始行又稱為請求行，說明了要做些什么，響應報文的起始行又稱為響應行，說明了發(fā)生了什么。以下是兩種請求行的基本格式：
 

請求行方法
HTTP規(guī)范中定義了一組常用的請求方法，用來告知服務器要做些什么，如下所示：
GET：從服務器獲取請求URL所指定的資源。
HEAD：只從服務器獲取文檔的首部。和GET方法的行為很類似，但服務器只返回首部，不包含主體。此方法可以：在不獲取資源的情況下了解資源的情況（比如判斷類型）；通過查看響應中的狀態(tài)嗎，看看某個對象是否存在；通過查看首部，測試資源是否被修改了。
POST：向服務器發(fā)送需要處理的數(shù)據(jù)（包含主體）。通常用它來支持HTML的表單。
PUT：將請求的主體部分存儲在服務器上（包含主體）。有些系統(tǒng)允許用戶創(chuàng)建Web頁面或上傳文檔，該方法的語義就是讓服務器用請求的主體來創(chuàng)建一個由請求URL命名的新文檔，如果URL已存在則讓這個主體替代它。
DELETE：從服務器上刪除請求URL所指定的資源。但客戶端無法保證刪除操作一定被執(zhí)行，因為HTTP規(guī)范允許服務器在不通知客戶端的情況下撤銷請求。
TRACE：對可能經過代理、網(wǎng)管、防火墻等服務器的報文進行追蹤，主要用于診斷。報文行程最后一站的服務器會彈回一條TRACE響應，在主體中攜帶它收到的原始請求報文，這樣客戶端就可以查看報文在一整條請求/響應鏈上是如何被修改的。
OPTIONS：查詢可以在服務器上執(zhí)行哪些方法，讓客戶端不用實際訪問那些資源就能判定訪問各種資源的最優(yōu)方式。
如果一臺服務器要與HTPP 1.1兼容，只要為其資源實現(xiàn)GET和HEAD方法即可，這兩種方法被認為是安全的，它們產生的請求不會在服務器上產生什么結果（實際上，這是由Web開發(fā)者決定的，完全可以使用GET方法來提交一個表單，但嚴重不建議這么做！）。

HTTP還允許定義HTTP/1.1規(guī)范中沒有定義的擴展方法，這些方法為開發(fā)者提供了一種擴展HTTP服務能力的手段。很可能大部分HTTP應用程序都無法理解這些擴展方法，所以服務器最好對擴展方法寬容一些。

狀態(tài)碼與原因短語
每條響應報文都會包含一個3位數(shù)字和可讀的狀態(tài)，用來告訴客戶端，服務器發(fā)生了什么事情。數(shù)字狀態(tài)碼便于程序處理差錯，原因短語更便于人們理解。狀態(tài)碼分為5類（括號中為已定義范圍）：100~199為信息提示（100~101）；200~299為成功（200~206）；300~399為重定向（300~305），用于告知客戶端使用替代位置來訪問資源；400~499為客戶端錯誤（400~415）；500~599為服務器錯誤（500~505）。限于篇幅下面只介紹常見的狀態(tài)碼，詳情參見HTTP狀態(tài)碼維基百科

101 Switching Protocols：服務器正在根據(jù)客戶端的指定，將協(xié)議切換成Update首部所示的協(xié)議。
200 OK：服務器已成功處理了請求并提供了請求的網(wǎng)頁
204 No Content：服務器成功處理了請求，但沒有返回任何內容
301 Moved Permanently：請求的網(wǎng)頁已永久移動到新位置。響應的Location首部應包含資源現(xiàn)在所處的URL。
302 Found：與301類似，但這里的移除是臨時的。將來的請求仍應使用老的URL。
304 Not Modified：客戶的緩存資源是最新的，要客戶端使用緩存。
400 Bad Request：告知客戶端發(fā)送了一個錯誤的請求。
403 Forbidden：請求被服務器拒絕了。（可能是沒有訪問服務器的權限）
404 Not Found：服務器無法找到所請求的URL。
410 Gone：服務器曾經有這個資源，現(xiàn)在沒有了，與404類似。
500 Internal Server Error：服務器遇到一個錯誤，使其無法為請求提供服務。
502 Bad Gateway：作為代理或網(wǎng)關使用的服務器收到了上游的無效響應。
503 Service Unavailable：服務器現(xiàn)在無法為請求提供服務，但過一段時間就可以恢復服務。

首部
首部和方法配合工作，共同決定了客戶端和服務器能做什么事情?？梢詫⑹撞糠譃?個主要類型，以下將分類列舉一些首部。

（1）通用首部：客戶端和服務器都可以使用的通用首部，提供了與報文相關的最基本的信息。
Connection：允許客戶端和服務器指定與請求/響應連接相關的選項
Date：日期和時間標志，說明報文是什么時刻創(chuàng)建的
MIME-Version：給出了發(fā)送端使用的MIME版本
Transfer-Encoding：告知接收端為了保證報文的可靠傳輸，對報文采用了什么編碼方式
Via：顯示了報文經過的中間節(jié)點（代理、網(wǎng)關等等）
Cache-Control：用于隨報文傳送緩存指示
Pragma：另一種隨報文傳送指示的方式，但并不專用于緩存

（2）請求首部：只在請求報文中有意義，用于說明是誰或什么在發(fā)送請求、請求源自何處，或客戶端的喜好及能力等。
Accept：告訴服務器能夠發(fā)送哪些媒體類型。該首部可以使連接的兩端都受益，客戶端會得到它們想要的內容，服務器則不會浪費時間好帶寬來發(fā)送客戶端無法使用的東西
Accept-Encoding：告訴服務器能夠發(fā)送哪些編碼方式
Accept-Language：告訴服務器能夠發(fā)送哪些語言
Referer：提供了包含當前請求URI的文檔的URL
User-Agent：告訴服務器發(fā)起請求的應用程序名稱
有時客戶端希望為請求加上某些限制，要求服務器在對請求進行響應之前，確保某個條件為真，則可以添加條件請求首部，如Expect（允許客戶端列出某請求所要求的服務器行為）、If-Match（若實體標記相匹配，則獲取這份文檔）、If-Modified-Since（除非在某個指定日期之后資源被修改過，否則限制該請求）等等。
HTTP本身就支持一種對請求進行質詢/響應的認證機制，這樣可以使事務稍微安全一些。因此有安全請求首部，如Authorization（客戶端提供給服務器的對其自身進行認證的數(shù)據(jù)）、Cookie（這個不是真正的安全首部，但卻是隱含了安全功能）。

（3）響應首部：為客戶端提供了一些額外信息，比如誰在發(fā)送響應、響應者的功能、其它一些特殊指令等
Age：（從最初創(chuàng)建開始）響應持續(xù)時間
Public：服務器為其資源支持的請求方法列表
Retry-After：如果資源不可用，在此時間重試
Accept-Ranges：（協(xié)商首部）對此資源來說，服務器可接受的范圍類型
Set-Cookie：（安全首部）類似Cookie，用于設置Cookie

（4）實體首部：用來描述HTTP報文的負荷，提供了有關實體及其內容的大量信息，可以告知報文的接收者它在對什么進行處理
Allow：列出可以對此實體執(zhí)行的請求方法
Location：告知客戶端實體實際上位于何處，用于重定向資源
Content-Length：主體的長度
Content-Type：主體的對象類型
（還有很多關于主體的首部，如Content-Encoding、Content-Base、Content-MD5等等）
ETag：與此實體相關的實體標記（用于緩存，下同）
Expires：實體不再有效，要從源端再次獲取此實體的日期和時間
Last-Modified：這個實體最后一次被修改的日期和時間

HTTP請求報文實例解剖  

①是請求方法，GET和POST是最常見的HTTP方法，除此以外還包括DELETE、HEAD、OPTIONS、PUT、TRACE。不過，當前的大多數(shù)瀏覽器只支持GET和POST，Spring 3.0提供了一個HiddenHttpMethodFilter，允許你通過“_method”的表單參數(shù)指定這些特殊的HTTP方法（實際上還是通過POST提交表單）。服務端配置了HiddenHttpMethodFilter后，Spring會根據(jù)_method參數(shù)指定的值模擬出相應的HTTP方法，這樣，就可以使用這些HTTP方法對處理方法進行映射了。 
②為請求對應的URL地址，它和報文頭的Host屬性組成完整的請求URL，③是協(xié)議名稱及版本號。 
④是HTTP的報文頭，報文頭包含若干個屬性，格式為“屬性名:屬性值”，服務端據(jù)此獲取客戶端的信息。 
⑤是報文體，它將一個頁面表單中的組件值通過param1=value1&param2=value2的鍵值對形式編碼成一個格式化串，它承載多個請求參數(shù)的數(shù)據(jù)。不但報文體可以傳遞請求參數(shù)，請求URL也可以通過類似于“/chapter15/user.html? param1=value1&param2=value2”的方式傳遞請求參數(shù)。 
對照上面的請求報文，我們把它進一步分解，你可以看到一幅更詳細的結構圖：