如果HTTP是因特網(wǎng)的信使滞诺，那么HTTP報文就是它用來搬東西的包裹茵烈。
HTTP使用術(shù)語流入和流出來描述事務(wù)處理的方向百匆，報文流入源端服務(wù)器，工作完之后呜投，會流回客戶端。不管是請求報文還是響應(yīng)報文存璃，所有報文都會向下游流動仑荐，所有報文的發(fā)送者都在接收者的上游。

1報文的組成部分

所有的報文都可以被分成請求報文或者響應(yīng)報文纵东。報文由三個部分組成粘招，對報文進行描述的起始行，包含屬性的首部偎球，以及可選的包含數(shù)據(jù)的主題部分洒扎。
下面是HTTP請求報文的格式：
<method> <request-URL> <version>
<headers>
<entity-body>
HTTP響應(yīng)報文的格式：
<version> <status> <reason-phrase>
<headers>
<entity-body>
下面對每個部分分別進行說明。

• 方法
  客戶端希望服務(wù)器對資源執(zhí)行的操作衰絮，是一個單獨的詞袍冷，比如說put,get,delete。
• 請求URL
  命名了所請求資源或者URL路徑組件的完整URL猫牡。
• 版本
  報文所使用的HTTP版本胡诗，其格式通常為：
  HTTP/<major>.<minor>
• 狀態(tài)碼
  這個三位數(shù)字描述了請求過程中所發(fā)生的情況。每個狀態(tài)的第一個數(shù)字都描述了狀態(tài)的一般類型淌友。比如2開頭是請求完成煌恢，3開頭是重定向，4開頭是客戶端問題震庭，5開頭是服務(wù)器問題瑰抵。
• 原因短語
  原因短語是配合狀態(tài)碼一起，更詳細的描述響應(yīng)的狀態(tài)器联。
• 首部
  可以有零個首部或多個首部二汛，每個首部都包含一個名字，后面跟著一個":"主籍，然后是一個可選的空格习贫，接著是一個值，最后是一個CRLF千元。首部是由一個(CRLF)空行結(jié)束的苫昌，表示首部列表的結(jié)束和實體主體部分的開始。
• 實體的主體部分
  實體的主體部分包含一個由任意數(shù)據(jù)組成的數(shù)據(jù)塊幸海，并不是所有的報文都包含實體的主體部分祟身。

2方法

1.GET

get是最常用的方法奥务，通常用于請求服務(wù)器發(fā)送某個資源。

GET.png

2.HEAD方法和GET方法相似袜硫，都是從服務(wù)器端拉數(shù)據(jù)氯葬，不同的是使用HEAD方法時響應(yīng)只返回首部而不返回實體的主題部分。這樣既有允許客戶端在未獲取實際資源的情況下對資源的首部進行檢查婉陷。使用HEAD可以：

1.在不火氣資源的情況下了解資源的情況(如資源類型)
2.通過查看首部測試資源是否被修改了帚称。

HEAD.png

3.PUT

與get從服務(wù)器中讀取文檔相反，put會向服務(wù)器中寫入文檔秽澳。

PUT.png

PUT方法的語義就是讓服務(wù)器用請求的主題部分來創(chuàng)建一個由所請求的URL命名的新文檔闯睹，或者如果那個URL已經(jīng)存在的話，就用這個主體來替代它担神。因為普通允許用戶進行修改楼吃，所以很多web服務(wù)器都要求在執(zhí)行put之前進行驗證。

4.POST

5.TRACE

客戶端發(fā)起一個請求的時候妄讯，這個請求可能會穿過防火墻孩锡，網(wǎng)關(guān)，代理等亥贸，每一個中間節(jié)點都可能會修改原始的HTTP請求躬窜，TRACE允許客戶端在報文最終被發(fā)送給服務(wù)器時查看它最終的樣子。
發(fā)送TRACE請求時砌函，行程最后一站的服務(wù)器會彈回一條TRACE響應(yīng)斩披，并在響應(yīng)主體中攜帶它收到的請求報文，這樣發(fā)送端就可以檢查請求報文是否被修改或毀壞讹俊。

6.OPTIONS

OPTIONS方法請求web服務(wù)器告知其支持的各種方法垦沉。可以詢問服務(wù)器通常支持哪些方法仍劈，厕倍，或者對某些特殊資源支持哪些方法。這樣客戶端不用訪問那些資源就能知道訪問各種資源的最優(yōu)方式贩疙。

7.DELETE

DELETE方法所做的事情就是請求服務(wù)器刪除請求URL所指的資源讹弯。

3.狀態(tài)碼

HTTP狀態(tài)碼被分為5類，狀態(tài)碼是一個三位數(shù)字这溅，以1開頭的是信息性狀態(tài)碼组民，2開頭的是請求成功狀態(tài)碼，3開頭的是重定向狀態(tài)碼悲靴，4開頭的是客戶端錯誤狀態(tài)碼臭胜，5開頭的是服務(wù)器錯誤狀態(tài)碼。下面分別進行說明。

1. 100-199狀態(tài)碼

2. 200-299 ——成功狀態(tài)碼

這一類型的狀態(tài)碼乱陡，代表請求已經(jīng)被服務(wù)器成功接收，理解仪壮。

3. 300-399 ——重定向狀態(tài)碼

重定向狀態(tài)碼要么告訴客戶端使用替代位置來訪問他們所感興趣的資源薄货，要么就提供一個替代的響應(yīng)而不是資源的內(nèi)容翁都。如果資源已被移動，可發(fā)送一個重定向狀態(tài)碼和一個可選的location首部來告知客戶端資源已被移走谅猾，以及現(xiàn)在可以再哪里找到它柄慰。

4. 400-400 ——客戶端錯誤狀態(tài)碼

有時候客戶端會發(fā)送一些服務(wù)器無法處理的東西，比如格式錯誤的請求報文弧岳，或者請求一個不存在的URL凳忙。很多客戶端錯誤都是由瀏覽器來處理的，并不會打擾到用戶禽炬，只有少數(shù)比如404會穿過瀏覽器來到用戶面前涧卵。

5. 500-599 ——服務(wù)器錯誤狀態(tài)碼

有時候客戶端發(fā)送了一條有效請求伤提，服務(wù)器自身卻出錯了巫俺。代理嘗試著代表客戶端與服務(wù)器進行交流時經(jīng)常會出現(xiàn)問題。

4.首部

首部可以分為通用首部介汹，請求首部，響應(yīng)首部舶沛，實體首部嘹承。下面分別對這幾部分進行說明：

1.通用首部

這些是在客戶端和服務(wù)器都可以使用的首部，可以在客戶端如庭，服務(wù)器和其他應(yīng)用之間提供一些非常有用的通用功能叹卷。
下表是一些通用的信息性首部：

通用緩存首部：

2.請求首部

請求首部是只在請求報文中有意義的首部蒙揣，用于說明是誰或什么在發(fā)送請求，請求源于何處开瞭，或者客戶端的喜好或能力懒震。

1.請求的信息性首部

2.Accept首部

3.條件請求首部

4.安全請求首部

3.響應(yīng)首部

響應(yīng)報文都有自己的響應(yīng)首部集舞痰，響應(yīng)首部為客戶端提供了一些額外的信息土榴，比如誰在發(fā)送響應(yīng)，響應(yīng)者的功能响牛，甚至和響應(yīng)相關(guān)的一些特殊指令玷禽。這些首部有助于客戶端處理響應(yīng)赫段，并在將來發(fā)起更好的請求。

1.響應(yīng)的信息性首部

2.安全響應(yīng)首部

|首部|描述|
|Proxy-Authenticate|來自代理的隊客戶端的質(zhì)詢列表|
|Set-Cookie|不是真正的安全首部糯笙，但是隱含有安全功能，可以再客戶端設(shè)置一個令牌撩银，以便服務(wù)器對客戶端進行標識|

4.實體首部

有很多首部可以用來描述HTTP報文的負荷给涕，由于請求和響應(yīng)報文中都可能包含實體部分，所以在這兩種類型的報文中都可能出現(xiàn)這些首部额获。