http報文
重點：
- 報文是如何流動的棕叫；
- http報文的三個組成部分(起始行、首部奕删、和實體的主體部分)俺泣；
- 請求和響應之間的區(qū)別；
- 請求報文支持的各種功能完残；
- 和請求報文一起返回的各種狀態(tài)碼伏钠；
- 各種各樣的http首部都是用來做什么的；
報文流
http報文是在http應用程序之間發(fā)送的數(shù)據(jù)塊谨设。這些數(shù)據(jù)塊以一些文本形式的元信息（meta-information）開頭熟掂，這些信息報文描述了報文的內(nèi)容及含義，后面跟著可選數(shù)據(jù)部分扎拣。這些報文在客戶端赴肚、服務器和代理之間流動。術語 流入 流出 上游 下游 都是用來描述報文方向的二蓝。
3.11報文流入源端服務器
http使用流入（inbound）和流出（outbound）來描述事務處理（transation）的方向誉券。客戶端發(fā)向服務器為流入刊愚，服務器發(fā)向客戶端稱為流出踊跟。
3.1.2報文向下游流動
http會像河水一樣流動。不管是請求報文還是響應報文鸥诽，所有的報文都會向下游（downstream）流動商玫。所有報文發(fā)送者都在接受者的上游（upstream）。
3.2報文的組成部分
http報文是簡單的格式化數(shù)據(jù)塊牡借。每條報文都包含三個部分：對報文描述的起始行（start line）决帖，包含屬性的首部（header）塊，以及可選的蓖捶，包含數(shù)據(jù)主體（body）部分地回。
起始行和首部就是由行分隔的ascll文本。每行以回車換行符結(jié)束。主體是一個可選的數(shù)據(jù)塊刻像。與起始行不同的是畅买，主體可以包含文本或二進制數(shù)據(jù)，也可以為空细睡。
3.2.1報文的語法
所有的http報文可以分為兩類：請求報文（request message）和響應報文（response message）請求報文會向web服務器請求一個動作谷羞。響應報文會將請求的結(jié)果返回給客戶端。
請求報文格式
<method><request-url><version>
<headers>
<entity-body>
響應報文格式
<version><status><reason-phrase>
<headers>
<entity-body>
- 方法（method）
客戶端希望服務器對資源執(zhí)行的動作溜徙。是一個單獨的詞湃缎，比如get post - 請求url（request url）
命名了所請求資源，或者url路徑組件的完整url蠢壹。如果直接與服務器進行對話嗓违，只要url的路徑組件是資源的絕對路徑，通常不會有問題图贸。 - 版本（version）
報文所使用的http版本蹂季，其格式為：http/<major>.<minor>,其中主要版本號（major）和次要版本號（minor）都是整數(shù) - 狀態(tài)碼（status-code）
這三個數(shù)字描述了請求過程中發(fā)生的情況。每個狀態(tài)碼的第一位數(shù)字用于描述狀態(tài)的一般類別（成功疏日、出錯等） - 原因短語（reason-phrase）
數(shù)字狀態(tài)碼的可讀版本偿洁，包含行中止之前的所有文本。 - 首部（header）
可以有零個或多個首部沟优，每個首部包含一個名字涕滋，后面跟著一個冒號，然后一個可選空格挠阁，接著是一個值宾肺，最后是crlf。首部是一個crlf結(jié)束的鹃唯，有些http版本需要包含特定的首部 - 實體的主體部分
包含一個有任意數(shù)據(jù)組成的數(shù)據(jù)塊爱榕。
3.2.2起始行
所有的http報文都以一個起始行作為開始。請求報文的起始行說明了要做些什么坡慌，響應報文起始行說明發(fā)生了什么黔酥。
1.請求行
請求報文請求服務器對資源進行一些操作。請求報文的起始行洪橘，或者稱為請求行跪者，包含了一個方法和一個請求url，這個方法描述了服務器應該執(zhí)行的操作熄求，url描述了要對那個資源執(zhí)行這個方法渣玲。請求行還包含http版本，在http1.0以前不要求請求行包含http版本號弟晚。
2.響應行
響應報文承載了狀態(tài)信息和操作產(chǎn)生的所有結(jié)果數(shù)據(jù)忘衍，將其返回給客戶端逾苫。響應報文的起始行，或者稱為響應行枚钓，包含類響應報文的http版本铅搓。數(shù)字狀態(tài)碼，以及描述操作狀態(tài)的文本形式的原因短語搀捷。
3.方法
請求的起始行以方法作為開始星掰，方法用來告知服務器要做些什么。
| 方法 | 描述 | 是否包含主體 |
|---|---|---|
| get | 從服務器獲取一份文檔 | 否 |
| head | 只從服務器獲得文檔的首部 | 否 |
| post | 向服務器發(fā)送需要處理的數(shù)據(jù) | 是 |
| put | 將請求的主體存儲在服務器上 | 是 |
| trace | 對可能經(jīng)過代理服務器的報文進行追蹤 | 否 |
| options | 決定可以在服務器執(zhí)行那些方法 | 否 |
| delete | 從服務器上刪除一份文檔 | 否 |
4.狀態(tài)碼
狀態(tài)碼用來告訴客戶端發(fā)生了什么嫩舟，狀態(tài)碼位于起始行的行中氢烘。
| 整體范圍 | 分類 |
|---|---|
| 1xx | 信息提示 |
| 2xx | 成功 |
| 3xx | 重定向 |
| 4xx | 客戶端錯誤 |
| 5xx | 服務器錯誤 |
5.原因短語
響應起始行的最后一個組件，為狀態(tài)碼提供了一個文本解釋家厌。http沒有規(guī)定原因短語以何種方式出現(xiàn)播玖。
6版本號
版本號說明了應用程序支持的最高版本，但http1.0在解釋包含http1.1的響應時像街，會認為這個響應是個1.1響應黎棠。
版本號不會被當做分數(shù)處理晋渺，而是比較每個數(shù)字镰绎，http/2.22就比http/2.3高，因為22比3大木西。
3.2.3首部
1.首部分類
- 通用首部
既可以出現(xiàn)在請求報文中畴栖，也可以出現(xiàn)在響應報文中。 - 請求首部
提供更多有關請求的信息 - 響應首部
提供更多有關響應的信息 - 實體首部
描述主體的長度和內(nèi)容八千，或者資源自身 - 擴展首部
規(guī)范中沒有定義的新首部
2.首部延續(xù)行
將長的首部分為多行可以提高可讀性吗讶，多出來的每一行至少要有一個空格或制表符
3.2.4實體的主體部分
http報文的第三部分是可選的實體主體部分。實體的主體部分是http報文的負荷恋捆，就是http要傳輸?shù)膬?nèi)容照皆。
3.2.5版本0.9的報文
http/0.9也由請求和響應組成，但請求中只包含方法和請求url沸停，響應中只包含實體膜毁，它沒有版本信息，沒有狀態(tài)碼或原因短語愤钾，也沒有首部瘟滨。
3.3方法
不是每個服務器都實現(xiàn)了所有這些方法，如果一臺服務器要與http1.1兼容能颁，只要實現(xiàn)get杂瘸、head方法就可以了。
3.3.1安全方法
http定義了一組被稱為安全方法的方法伙菊。get和head都被認為是安全的方法败玉，這就意味著使用get或head方法的http請求不會產(chǎn)生什么動作敌土，安全方法不一定什么都不執(zhí)行的（這將由web開發(fā)者決定）
3.3.2get
get是最常用的方法。通常用于請求服務器發(fā)送某個資源运翼。
3.3.3head
head與get方法很相似纯赎，但服務器只返回首部。不會返回實體的主體部分南蹂。這就允許客戶端在未獲得實際資源的情況下對資源的首部進行檢查犬金。
3.3.4put
與get從服務器讀取文檔相反，普通方法會向服務器寫入文檔六剥。有些發(fā)布系統(tǒng)允許用戶創(chuàng)建web頁面晚顷，并用普通直接安裝到服務器上
put方法的語義就是讓服務器用請求的主體部分來創(chuàng)建一個由所請求的url命名的新文檔，或者如果url已存在疗疟，就用主體來替代它
3.3.5post
post起初是用來向服務器輸入數(shù)據(jù)的该默。實際上用它來支持html的表單。
3.3.6trace
客戶端發(fā)起一個請求這個請求可能要穿過防火墻策彤、代理栓袖、網(wǎng)關或其它一些程序。每個中間結(jié)點都有可能修改原始http請求店诗。trace方法允許客戶端在最終請求發(fā)送給服務器時看看它變成什么樣子裹刮。
trace請求會在目的服務器發(fā)起一個回環(huán)診斷。行程最后一站的服務器會彈回一條trace響應庞瘸，并在響應主體中攜帶它收到的原始請求報文捧弃。
3.3.7options
options方法請求web服務器告知其支持的功能〔聊遥可以查詢服務器通常支持那些方法违霞。
3.3.8delete
delete就是請求服務器刪除所請求的資源。但是客戶端應用無法保證刪除一定會被執(zhí)行瞬场。用為http協(xié)議允許服務器在不通知客戶端的情況下撤銷請求买鸽。
http被設計成字段可擴展的，這樣新特性就不會使老軟件失效了贯被。服務器會為他所管理的資源實現(xiàn)http服務眼五，這些方法為開發(fā)者提供了擴展http服務能力的手段。
| 方法 | 描述 |
|---|---|
| lock | 允許用戶鎖定資源刃榨，比如正在編輯 |
| mkcol | 允許別人創(chuàng)建資源 |
| copy | 便于在服務器復制資源 |
| move | 在服務器移動資源 |
并不是所有的方法都是正式規(guī)范中定義的弹砚，如果你定義了一個擴展方法，很可能大部分http應用程序都無法理解枢希。同樣你的http應用程序也有可能遇到一些其它應用程序正在使用桌吃，而并不理解的方法。
3.4狀態(tài)碼
多而雜苞轿，不抄了
3.5首部
3.5.1通用首部
有些首部提供了與報文相關的基本信息茅诱，被稱為通用首部逗物。
通用信息性首部
| 首部 | 描述 |
|---|---|
| connection | 允許客戶端和服務器指定與請求/響應連接相關的選項 |
| date | 提供日期和時間，說明報文是什么時間創(chuàng)建的 |
| mime-version | 給出了發(fā)送端的mime版本 |
| trailer | 如果報文采用了分塊傳輸編碼（chunked transfer encoding）方式就可以用這個首部列出位于報文拖掛（trailer）部分的首部集合 |
| update | 給出了發(fā)送端可能想要升級使用的新版本或協(xié)議 |
| via | 顯示報文經(jīng)過的中間結(jié)點 |
通用緩存首部
http1.0引入了第一個允許http應用緩存對象本地副本的首部瑟俭，這樣就不用總是從源服務器獲取了翎卓。
| 首部 | 描述 |
|---|---|
| cache-control | 用于報文傳送緩存指示 |
| pragma | 另一種報文傳送指示的方式，但并不用于緩存 |
3.5.2請求首部
請求首部是只在請求報文中有意義的首部摆寄。
請求的信息性首部
| 首部 | 描述 |
|---|---|
| client-ip | 提供了客戶端的ip地址 |
| from | 提供了客戶端的mail地址 |
| host | 給出了服務器的主機名和端口號 |
| referer | 提供了包含當前請求uri的文檔的url |
| ua-color | 提供了客戶端顯示器顏色相關的信息 |
| ua-cpu | 客戶端的cpu類型或制造商 |
| ua——disp | 提供了顯示器能力相關的信息 |
| ua-os | 客戶端的操作系統(tǒng)名稱和版本 |
| ua-pixels | 客戶端的像素信息 |
| user-agent | 發(fā)起請求的程序名稱 |
1.accept首部
accept將客戶端的喜好和能力告知服務器的方式
| 首部 | 描述 |
|---|---|
| accept | 告訴服務器能夠發(fā)送哪些媒體類型 |
| accept-charset | 哪些字符集 |
| accept-encoding | 哪些編碼方式 |
| accept-language | 哪些語言 |
| te | 哪些擴展傳輸編碼 |
2.條件請求首部
客戶端為請求添加限制失暴。
| 首部 | 描述 |
|---|---|
| expect | 允許客戶端列出請求所要求的服務器行為 |
| if-match | 如果實體標記與文檔當前的標記相同就獲取這份文檔 |
| if-modified-since | 除非在日期后修改過，否則限制該請求 |
| if-none-match | 如果文檔的標記與實體標記不符微饥，獲取該文檔 |
| if-range | 允許對文檔的某個范圍進行條件請求 |
| if-unmodified-since | 除非在某個日期后沒有修改過逗扒，否則限制該請求 |
| range | 如果服務器支持范圍請求，就請求資源的指定范圍 |
3.安全請求首部
http本身支持一種簡單的機制欠橘，可以對請求進行質(zhì)詢/響應認證矩肩。這種機制要求，在獲取資源之前肃续，先對自身進行認證黍檩，這樣使事務稍微安全一些。
| 首部 | 描述 |
|---|---|
| authorization | 包含了客戶端提供給服務器始锚，以便對自身進行認證的數(shù)據(jù) |
| cookie | 客戶端用它向服務器傳送一個令牌刽酱，它并不是真正的安全首部，但隱含了安全功能 |
| cookie2 | 用來說明請求端支持的cookie版本 |
安全請求首部
| 首部 | 描述 |
|---|---|
| authorization | 包含了客戶端提供給服務器疼蛾，以便對自身進行認證的數(shù)據(jù) |
| cookie | 客戶端用它向服務器傳送一個令牌肛跌，它并不是真正的安全首部艺配，但隱含了安全功能 |
| cookie2 | 用來說明請求端支持的cookie版本 |
4.請求代理首部
| 首部 | 描述 |
|---|---|
| max-forward | 在通往源服務器的路徑上察郁，將請求轉(zhuǎn)發(fā)給其它代理或網(wǎng)關的最大次數(shù)-與trace方法一起使用。 |
| proxy-authorization | 與authorization首部相同转唉，但這個首部是在與代理認證時使用的 |
| proxy-connection | 與connection相同皮钠，但這個首部是在與代理認證時使用的 |
3.5.3響應首部
響應報文有自己的響應首部集。響應首部為客戶端提供了一些額外的信息赠法。
| 首部 | 描述 |
|---|---|
| age | 從最初創(chuàng)建開始的持續(xù)響應時間 |
| public | 服務器為資源提供的請求方法列表 |
| retry-after | 如果資源不可用麦轰，在此日期之后重試 |
| server服務器應用程序的名稱和版本 | |
| title | 對html文檔來說，就是html文檔的標題 |
| warning | 比原因短語中更詳細的警告報文 |
1.協(xié)商首部
如果資源有多種便是方法砖织，http1.1可以為客戶端和服務器提供對資源進行協(xié)商的能力
| 首部 | 描述 |
|---|---|
| accept-ranges | 對此資源來說服務器可接受的范圍類型 |
| vary | 服務器查看的其它首部的列表款侵，可能會使響應發(fā)生變化 |
2.安全響應首部
| 首部 | 描述 |
|---|---|
| proxy-authenticate | 來自代理的對客戶端的質(zhì)詢列表 |
| set-cookie | 不是真正的安全首部，但隱含安全功能侧纯，可以在客戶端設置一個令牌新锈，以方便服務器對客戶端的標示 |
| set-cookie2 | 與set-cookie類似 |
| www-authenticate | 來自服務器對客戶端的質(zhì)詢列表 |
3.5.4實體首部
信息性首部
| 首部 | 描述 |
|---|---|
| allow | 列出了可以對實體執(zhí)行的請求方法 |
| location | 告知客戶端實際上位于何處 |
1.內(nèi)容首部
| 首部 | 描述 |
|---|---|
| content-base | 解析主體的相對url時使用的基礎url |
| content-encoding | 對主體執(zhí)行的任意編碼方式 |
| content-language | 理解主體是最適宜使用的自然語言 |
| content-length | 主體的長度或尺寸 |
| content-location | 資源實際所在的位置 |
| content-md5 | 主體的md5校驗和 |
| content-range | 在整個資源中此實體表示的字節(jié)范圍 |
| content-type | 主體的對象類型 |
2.實體緩存首部
通用的緩存首部說明了如何或什么時候進行緩存。實體的緩存提供了與被緩存實體有關的信息眶熬。
實體緩存
| 首部 | 描述 |
|---|---|
| etag | 榆次實體相關的實體標記 |
| expires | 實體不在有效妹笆，要從源端再次獲取次實體的日期和時間 |
| last-modified | 這個實體最后一次被修改的日期和時間 |
