引言

HTTP報文是在HTTP應(yīng)用程序之間發(fā)送的數(shù)據(jù)塊。這些數(shù)據(jù)塊以一些文本形式的元信息開頭，這些信息描述了報文的內(nèi)容及含義，后面跟著可選的數(shù)據(jù)部分核偿。HTTP使用術(shù)語流入和流出來描述事務(wù)處理方向，報文像流水一樣向下游流動顽染，所有報文發(fā)送者都在接受者的上游漾岳。

報文的組成部分

Http報文是簡單的格式化數(shù)據(jù)塊，有三部分組成：對報文進(jìn)行描述的起始行粉寞；包含屬性的首部快尼荆；包含數(shù)據(jù)主體。

所有Http報文都可以分為兩類唧垦，請求報文和響應(yīng)報文捅儒。請求報文都會向Web服務(wù)器請求一個動作，響應(yīng)報文都會將請求的結(jié)果返回給客戶端振亮。

請求報文與響應(yīng)報文的格式

請求報文格式： <method> <request-URL> <version> <headers>? ? ? ? ? ? ? <entity-body>
響應(yīng)報文格式：<version> <status-code> <reason-phrase> <headers>? ? ? ? ? ? ? ? <entity-body>

方法（method）:方法是客戶端希望服務(wù)器對資源執(zhí)行的操作巧还，是一個單獨(dú)的詞，比如GET坊秸、POST等

請求URL（Request-URI）:命名了所請求資源麸祷，或者URL路徑組成的完整URL。如何直接與服務(wù)器進(jìn)行對話褒搔，只要URL路徑組件是資源的絕對路徑阶牍，通常就不會有什么問題---服務(wù)器可以假定自己是URL的主機(jī)或者是端口喷面。

版本（version）： 報文所使用的HTTP版本，格式是HTTP/<major>.<minor>, 其中主要版本號（major）和次要版本號（minor）都是整數(shù)走孽。

狀態(tài)碼（status-code）:描述請求過程中發(fā)生的情況惧辈。每個狀態(tài)碼的第一位數(shù)字都是描述狀態(tài)的一般類別（成功and出錯）。

原因短語（reason-phrase）：數(shù)字狀態(tài)碼的可讀辦磕瓷，包含行終止序列之前的所有文本咬像。

首部（headers）：可以有零個或多個首部，每個首部都包含一個名字生宛，后面跟著一個冒號（：），然后還是一個可選的空格肮柜，接著是一個值陷舅，最后是一個CRLF（回車符和換行符）。首部使用一個CRLF結(jié)束的审洞，表示了首部列表的結(jié)束和實(shí)體主體部分的開始莱睁。

實(shí)體的主體部分（entity-body）：實(shí)體的主體部分包含一個有任意數(shù)據(jù)組成的數(shù)據(jù)塊，并不是所有的報文都包含實(shí)體的主體部分芒澜，有時報文只是一個CRLF結(jié)束仰剿。

起始行

所有HTTP報文都是以一個起始行作為開始。

1.請求行： 請求報文請求服務(wù)器對資源進(jìn)行一些操作痴晦，請求報文的起始行南吮，也叫報文的請求行，包含了一個方法和一個請求URL誊酌，這個方法描述了服務(wù)器應(yīng)該執(zhí)行的操作部凑，請求URL描述了要對那個資源執(zhí)行這個方法。請求行中還包含HTTP的版本碧浊，用來告知服務(wù)器涂邀，客戶端使用得是哪種HTTP。

2.響應(yīng)行：響應(yīng)報文承載了狀態(tài)信息和操作產(chǎn)生的所有結(jié)果的數(shù)據(jù)箱锐，將其返回給客戶端比勉。響應(yīng)報文的起始行，也成為響應(yīng)行驹止，包含了響應(yīng)報文使用得HTTP版本浩聋、數(shù)字狀態(tài)碼，以及描述操作狀態(tài)的文本形式操作原因短語臊恋。

3.方法：請求的起始行以方法作為開始赡勘，方法用來告知服務(wù)器要做些什么。

4.狀態(tài)碼： 狀態(tài)碼用來告訴服務(wù)器發(fā)生了什么捞镰。

5.原因短語：原因短語是響應(yīng)起始行中的最后一個組件闸与。它為狀態(tài)碼提供了文本形式的解釋毙替。原因短語與狀態(tài)碼成對出現(xiàn)。

6.版本號:版本號會以HTTP/x.y的形式出現(xiàn)在請求響應(yīng)報文的起始行中践樱。為HTTP應(yīng)用程序提供一種將自己所遵循的協(xié)議版本告知對方的方式厂画。 ? ?? ??
? ? ? ? 使用版本號的目的是為了使用HTTP的應(yīng)用程序提供一種線索，以便相互了解對方的能力好報文格式拷邢。在與使用HTTP1.1的應(yīng)用程序進(jìn)行通訊的HTTP1.2應(yīng)用程序應(yīng)該知道袱院，他不能使用任何新的1.2特性，因?yàn)槭褂美习姹緟f(xié)議的應(yīng)用程序很有可能無法實(shí)現(xiàn)這些特性瞭稼。

首部

首部分為：?

常見的首部實(shí)例

????????一.通用首部：?通用首部既可以出現(xiàn)在請求報文中忽洛，也可以出現(xiàn)在響應(yīng)報文中。

通用的消息性首部

通用緩存首部

????????二环肘。請求首部：?提供更多有關(guān)請求的信息欲虚。

請求的信息性首部

? ? ? 1.Accept首部： 為客戶端提供了一種將其喜好和能力告知服務(wù)器的方式，包括他們想要什么悔雹，可以是用什么复哆，以及最重要的，他們不想要什么腌零。這樣服務(wù)器就可以根據(jù)這些額外信息梯找，對要發(fā)送的內(nèi)容作出更明智的決定.

Accept首部

? ? ? 2.條件請求首部：有時客戶端希望為請求加上某些限制。

條件請求首部

? ? ? 3.安全請求首部：HTTP本身就支持一種簡單的機(jī)制益涧，可以對請求進(jìn)行質(zhì)詢 / 響應(yīng)認(rèn)證锈锤。這種機(jī)制要求客戶端在獲取特定的資源之前，先對自身進(jìn)行認(rèn)證闲询，這樣就可以使事物稍微安全一些牙咏。

安全請求首部

? ? ? ? 4.代理請求首部：

請求代理首部

? ? ? 三。響應(yīng)首部：提供更多有關(guān)響應(yīng)的信息嘹裂。

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

? ? ?1.協(xié)商首部：如果資源有多種表示方法妄壶，服務(wù)器可以用他們來傳遞和協(xié)商資源有關(guān)的信息。

協(xié)商首部

? ? ? ?2.安全響應(yīng)首部： HTTP的質(zhì)詢 / 響應(yīng)認(rèn)證機(jī)制的響應(yīng)側(cè)

安全響應(yīng)首部

? ? ? 四.實(shí)體首部：描述主體的長度和內(nèi)容寄狼，或者資源自身

實(shí)體的信息性首部

? ? ? ? 1.內(nèi)容首部：內(nèi)容首部提供了與實(shí)體內(nèi)容有關(guān)的特定信息丁寄，說明了其類型、尺寸以及處理它所需的其他有用信息泊愧。

內(nèi)容首部

? ? ? ?2.實(shí)體緩存首部： 通用的緩存首部說明了如果或什么時候進(jìn)行緩存伊磺。實(shí)體的緩存首部提供了與被緩存實(shí)體有關(guān)的信息。

實(shí)體緩存首部

? ? ? ? 五删咱、擴(kuò)展首部屑埋。規(guī)范中沒有定義的新首部。

方法

HTTP定義了一組被稱為安全方法的方法痰滋，GET方法和HEAD方法為安全方法摘能，使用它們的HTTP請求不會產(chǎn)生什么動作续崖，但不一定什么動作也不執(zhí)行。

一 ? GET方法： GET方法通常用于請求服務(wù)器發(fā)送某個資源

GET請求

二 ? HEAD方法： HEAD方法與GET方法的行為很類似团搞，但服務(wù)器在響應(yīng)中只返回首部严望。不會返回實(shí)體的主體部分。這就允許允許客戶端在未獲取實(shí)際資源的情況下逻恐，對資源的首部進(jìn)行檢查像吻。? ??? ??? ???
????????????1.在不獲取資源的情況下了解資的情況? ??? ??? ??
? ? ? ? ? ? 2.通過查看響應(yīng)中的狀態(tài)碼，看看某個對象是否存在
? ? ? ? ? ? 3.通過查看首部复隆，測試資源是否被修改過
? ?服務(wù)器不許確保返回的首部與GET請求返回的首部完全相同拨匆。遵循HTTP/1.1規(guī)范，必須實(shí)現(xiàn)HEAD方法挽拂。

HEAD請求

三 ? ?PUT方法：與GET從服務(wù)器讀取文檔相反惭每，PUT方法會向服務(wù)器寫入文檔。PUT方法的語義就是讓服務(wù)器用請求的主體部分來創(chuàng)建一個有所請求的URL命名的新文檔轻局，已存在的就用這個主體替代，Web服務(wù)器要求在執(zhí)行PUT之前用密碼登錄样刷。

PUT請求

四 ? POST：POST方法起初是用來向服務(wù)器輸入數(shù)據(jù)的仑扑。通常用它來支持HTML表單。表單中填好的數(shù)據(jù)送給服務(wù)器置鼻，然后服務(wù)器將他發(fā)送到要去的地方镇饮。

POST請求

五 ? TRACE：客戶端發(fā)起一個請求，這個請求可能要穿過防火墻箕母、代理储藐、網(wǎng)關(guān)或其他一些應(yīng)用程序。每個中間節(jié)點(diǎn)都可能會修改原始的HTTP請求嘶是。
? ? ? ?TRACE方法允許客戶端在最終將請求發(fā)送給服務(wù)器時钙勃，看看變成什么樣子。TRACE請求會在目的服務(wù)器發(fā)起一個“環(huán)回”診斷聂喇。行程最后一站的服務(wù)器彈回一條TRACE響應(yīng)辖源，并在響應(yīng)主體中攜帶它收到的原始請求報文。這樣客戶端就可以查看所有中間HTTP應(yīng)用程序組成的請求/響應(yīng)鏈上希太，原始報文是否克饶，以及如何被毀壞或修改。
????????TRACE方法主要用于診斷誊辉；用于驗(yàn)證請求是否如愿穿過請求/響應(yīng)鏈矾湃。查看代理和其他應(yīng)用程序?qū)τ脩粽埱笏a(chǎn)生效果。? ??
? ? ? ? TRACE缺點(diǎn)堕澄，假定中間應(yīng)用程序?qū)Ω鞣N不同類型請求（GET邀跃、HEAD霉咨、POST）的處理是相同的。很多HTTP應(yīng)用程序會根據(jù)方法的不同做出不同的事情坞嘀，TRACE并不提供區(qū)分這些方法的機(jī)制躯护。中間應(yīng)用程序自行決定TRACE請求的處理方式。?
? ? ? ? TRACE請求中不能帶有實(shí)體的主體部分丽涩。TRACE響應(yīng)的實(shí)體主體部分包含了響應(yīng)服務(wù)器收到的請求的精確副本棺滞。

TRACE請求

六 ? OPTIONS方法: OPTIONS方法請求Web服務(wù)器告知其支持的各種功能∈冈ǎ可以詢問服務(wù)器通常支持哪些方法继准，或者對某些特殊資源支持哪些方法。為客戶端提供一種手段矮男，使其不用實(shí)際訪問那些資源就能判定訪問各種資源的最優(yōu)方式移必。

OPTIONS請求

七 ? DELETE： DELETE方法所做的事情就是請求服務(wù)器刪除URL所指定的資源，但是客戶端應(yīng)用程序無法保證刪除操作一定會被執(zhí)行毡鉴。因?yàn)镠TTP規(guī)范允許服務(wù)器在不通知客戶端的情況下撤銷請求崔泵。

DELETE請求

八 ? 擴(kuò)展方法：HTTP被設(shè)計(jì)成字段可擴(kuò)展的，這樣新的特性就不會使老的軟件失效猪瞬。并不是所有擴(kuò)展方法都在正式規(guī)范中定義憎瘸，比如大部分HTTP應(yīng)用程序無法理解，能夠在不破壞端到端行為的情況下將帶有未知方法的報文傳遞給下游服務(wù)器的話陈瘦，代理會嘗試傳遞這些報文幌甘。

狀態(tài)碼
? ? ? ? 狀態(tài)碼為客戶端提供了一種理解事務(wù)處理結(jié)果的便捷方式。

一痊项。100~199 ?信息性狀態(tài)碼
? ? ? ? ? ? ?HTTP/1.1向協(xié)議中引入了信息性狀態(tài)碼锅风。 100 Continue狀態(tài)碼尤其讓人糊涂。它的目的是對HTTP客戶端應(yīng)用程序有一個實(shí)體的主體部分要發(fā)送給服務(wù)器鞍泉，但希望在發(fā)送之前查看一下服務(wù)器是否會接受這個實(shí)體進(jìn)行優(yōu)化皱埠。? ??? ??
? ? ? 1.客戶端與100 Continue? ??? ??
? ? ? ? ? ? ? ? 如果客戶端在向服務(wù)器發(fā)送一個實(shí)體，并且愿意在發(fā)送實(shí)體之前等待100 Continue響應(yīng)咖驮，那么漱逸，客戶端就要發(fā)送一個攜帶了值為100 Continue的Expect請求首部。如果客戶端沒有發(fā)送實(shí)體游沿，就不應(yīng)該發(fā)送100 Continue Expect首部饰抒，因?yàn)檫@樣會使服務(wù)器誤以為客戶端要發(fā)送一個實(shí)體。
? ? ? ? ? ? ? ?100 Continue是一種優(yōu)化诀黍〈樱客戶端應(yīng)用程序只有在避免向服務(wù)器發(fā)送一個服務(wù)無法處理或使用的大實(shí)體時，才應(yīng)該使用100 Continue。發(fā)送100 Continue的Expect首部的客戶端不應(yīng)該永遠(yuǎn)在哪里等待服務(wù)器發(fā)送100 Continue響應(yīng)枣宫。超過一段時間客戶端應(yīng)該將實(shí)體發(fā)送出去婆誓。? ??
? ? ? ? 2.服務(wù)器與100 Continue
? ? ? ? ? ? ? ? ? ?如果服務(wù)器收到一條帶有值為100 Continue的Expect首部的請求，他會用100 Continue響應(yīng)或一條錯誤碼來進(jìn)行響應(yīng)也颤。服務(wù)器永遠(yuǎn)也不應(yīng)該向沒有發(fā)送100 Continue期望的客戶端發(fā)送100 Continue狀態(tài)碼洋幻。如果服務(wù)器在發(fā)送100 Continue響應(yīng)之前收到部分或全部實(shí)體，說明客戶端決定發(fā)送數(shù)據(jù)翅娶，就不需要發(fā)送這個狀態(tài)碼文留，單服務(wù)器讀完請求后，還是要為請求發(fā)送一個最終狀態(tài)碼竭沫。
? ? ? ? 3.代理與100 Continue
? ? ? ? ? ? ? ? ? ? 如果代理從客戶端收到一條帶100 Continue期望的請求燥翅，如果代理知道下一個服務(wù)器是HTTP/1.1兼容的，或不知道與那個版本兼容蜕提，他都應(yīng)該將Expect首部放在請求中向下轉(zhuǎn)發(fā)森书。如果知道只能與HTTP/1.1之前版本兼容，應(yīng)該以417 Expectation Failed錯誤進(jìn)行相應(yīng) 谎势。

狀態(tài)碼與原因短語

二. ?200~299 ? 成功狀態(tài)碼??

狀態(tài)碼與原因短語

三 ? ?300~399 ? ?重定向狀態(tài)碼
? ? ? ? ?重定向狀態(tài)碼要么告知客戶端使用替代位置來訪問他們所感興趣的資源凛膏，要么就提供一個替代的響應(yīng)而不是資源的內(nèi)容。如果資源已被移動脏榆，可發(fā)送一個重定向狀態(tài)碼和一個可選的Location首部來告知客戶端資源已被移走猖毫，以及現(xiàn)在可以在哪里找到它。通過某些重定向狀態(tài)碼對資源的應(yīng)用程序本地副本與源端服務(wù)器上的資源進(jìn)行驗(yàn)證姐霍。

將請求重定向到新的位置

重定向?yàn)槭褂帽镜馗北镜恼埱?/div>

狀態(tài)碼與原因短語

四 ? 400~499 ? 客戶端錯誤狀態(tài)碼
? ? ? ? 有時客戶端會發(fā)送一些服務(wù)器無法處理的東西鄙麦，比如格式錯誤的請求報文或者不存在的URL典唇。

狀態(tài)碼與原因短語

狀態(tài)碼與原因短語

五 ? ?500~599 ? 服務(wù)器錯誤狀態(tài)碼? ??
? ? ? ? 有時客戶端發(fā)送一條有效請求镊折，服務(wù)器自身卻出現(xiàn)問題秦踪。

狀態(tài)碼與原因短語?