HTTP請求報文和響應報文

HTTP報文分爲請求報文(request message)與響應報文(response message)。

1、報文的組成部分

　　一個HTTP報文由3部分組成，分別是:

　　(1)、起始行(start line)

　　(2)、首部(header)

　　(3)、主體(body)

　　示例：

HTTP/1.0 200 OK    //起始行

Content-type:text/plain    //首部
Content-length:19            //首部  

Hi I'm a message!    主體

　　1.1 請求報文與響應報文的格式

　　請求報文的格式：

<method> <request-UTL> <version>
<headers>

<entity-body>

　　響應報文的格式：

<version> <status><reason-phrase>
<header>

<entity-body>

　　留意到請求報文與響應報文只是起始行不一樣。

　　下面是對格式中各部分的簡要描述

　　一、方法(method)　　GET

　　　　客戶端但願服務器對資源執行的動做。是一個單獨的詞，好比GET、HEAD或POST。

　　二、請求的URL(request-URL)　　www.baidu.com

　　　　命名了全部請求資源，或者URL路徑組件的完整URL。若是直接與服務器進行對話，只要URL的路徑組件是資源的絕對路徑，一般就不會有什麼問題--服務器能夠假定　　　本身是URL的主機/端口。

　　三、版本(version)　　HTTP/1.1

　　　　報文所使用的HTTP版本，其格式以下：

　　　　HTTP/<major>.<minor>

　　　　其中主要版本號(major)和次要版本號(minor)都是整數。　　

　　四、狀態碼(status)

　　　　這三個數字描述了請求過程當中所發生的狀況。每一個狀態碼的第一位數字都用於描述狀態的通常類別("成功"、"出錯"等)。　　200

　　五、緣由短語(reason-phrase)

　　　　數字狀態碼的可讀版本，包含行終止序列以前的全部文本。緣由短語只是給人類看的，它不能說明什麼。客戶端依然採用狀態碼來判斷請求/響應是否成功！

　　　　例如：HTTP/1.0 200 NOT OK 客戶端依然會當請求已成功處理。由於狀態碼是200。而緣由短語只是說明而已，這對於自定義擴展狀態碼仍是比較有用的。

　　六、首部(header)

　　　　能夠有0個或多個首部，每一個首部都包含一個名字，後面跟着一個冒號(:)，而後是一個可選的空格，接着是一個值，最後是一個CRLF。首部是由一個空行(CRLF)結束　　　的，表示了首部列表的結束和實體主體的開始。

　　七、實體的主體部分(entity-body)

　　　　實體的主體部分包含一個由任意數據組成的數據塊。並非全部的報文都包含實體的主體部分。如GET請求就不包含實體。

2、起始行

　　一、請求行

　　請求報文的起始行，或稱爲請求行。包含了一個方法和一個請求的URL。這個方法描述了服務器應該執行的操做，請求URL描述了要對哪一個資源執行這個方法。請求行中還包含HTTP的版本，用來告知服務器，客戶端使用的是哪一種HTTP版本。如：

　　GET /info/123.html HTTP/1.1    //方法爲GET    URL爲 /info/123.html    HTTP協議版本爲1.1

　　1.1方法

　　下面給出請求報文中方法的列表

方法　　　　　　　　描述　　　　　　　　　　　　　　　　　　　　是否包含主體
GET 　　　　從服務器獲取一份文檔 　　　　　　　　 　　　　　　　　　否
HEAD 　　　只從服務器獲取文檔的首部 　　　　　　  　　　　　　　　   否
POST 　　   向服務器發送須要處理的數據　　　　　　　　　　　　　　　是
PUT 　　　　將請求的主體部分存儲在服務器上 　　　  　　　　　　　　　是
TRACE 　　 對可能通過代理服務器傳送到服務器上去的報文進行跟蹤 　　  否
OPTIONS 　 決定能夠在服務器上執行哪些方法 　　　　　　　　　　　　  否
DELETE 　　從服務器上刪除一份文檔 　　　　　　　　　　　　　　　　  否

 　 1.2 request-URL

　　跳過，不說你也知道。

　　1.3 版本(version)

　　版本號會以HTTP/x.y 的形式出如今請求和響應報文的起始行中。爲HTTP應用程序提供了一種將本身遵循的協議版本告知對方的方式。版本號說明了應用程序支持的最高HTTP版本。注意，版本號不會被當作小數來處理。所以在比較HTTP版本時，每一個數字都必須單獨作比較，以便肯定哪一個版本更高。如HTTP/2.22就比HTTP/2.3要高，由於22比3大。

　　1.4 狀態碼(status-code)

　　方法是用來告訴服務器作什麼事情，而狀態碼則用來告訴客戶端發生了什麼事情。

　　下面給出狀態碼的經常使用分類

總體範圍 　　　　  已定義範圍 　　分類
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對應的資源。

　　1.5緣由短語

　　緣由短語是響應起始行中的最後一個組件。它爲狀態碼提供了文本形式的解釋。好比在HTTP/1.0 200 OK 中，OK就是緣由短語。緣由短語和狀態碼是成對出現的。緣由短語是狀態碼的可讀版本，應用程序開發者將其傳送給用戶，用以說明請求期間發生了什麼狀況。客戶端判斷服務器狀態依據的是狀態碼，與緣由短語沒有半毛錢關係。

 3、首部

 　　HTTP首部字段向請求和響應報文中添加了一些附加信息。本質上來講，它們只是一些名/值對的列表。好比下面的首部行會向Content-Length首部字段賦值19：

　　　　Content-length:19

　　一、首部分類

　　　　HTTP規範定義了幾種首部字段。應用程序也能夠隨意發明本身所用的首部。HTTP首部能夠分爲如下幾類。

　　　　(1)、通用首部：既能夠出如今請求報文中，也能夠出如今響應報文中。

　　　　　　這些是客戶端和服務器均可以使用的通用首部。能夠在客戶端、服務器和其餘應用程序之間提供一些很是有用的通用功能。他們像和事佬同樣，，不論報文是何種　　　　　　類型，都爲其提供一些有用的信息。例如無論是構建請求報文仍是響應報文，建立報文的日期時間都是同一個意思，所以提供這類信息的首部對這兩種類型的報文來講　　　　　　都是通用的。下面用表格的形式給出通用的信息性首部。

　　　　通用的信息性首部：

首部 　　　　　　　　　　描述
Connection 　　　　　　 容許客戶端和服務器指定與請求/響應鏈接有關的選項
Date 　　　　　　　　　  提供日期和時間標誌，說明報文是什麼時間建立的
MIME-Version 　　　　　 給出了發送端使用的MIME版本
Trailer 　　　　　　　　　若是報文采用了分塊傳輸編碼(chunked transfer encoding)方式，就能夠用這個首部列出位於報文拖鞋 (trailer)部分的首部集合。
Transfer-Encoding 　　  告知接收端爲了保證報文的可靠傳輸，對報文采用了什麼編碼方式。
Update 　　　　　　　　 給出了發送端可能想要"升級"使用的新版本或協議
Via 　　　　　　　　　　 顯示了報文通過的中間節點(代理、網關)

通用緩存首部：

首部 　　　　　　　　　　描述
Cache-Control 　　　　  用於隨報文傳送緩存指示
Pragma 　　　　　　　　 另外一種隨報文傳送指示的方式，但並不專用於緩存

　　　　(2)、請求首部：提供更多有關請求的信息。

　　　　　　請求首部是在請求報文中有意義的首部。用於說明是誰或什麼在發送請求，請求源自何處，或者客戶端的喜愛及能力。服務器能夠根據請求首部給出的客戶端的信　　　　　　息，試着爲客戶端提供更好的響應。

請求的信息性首部：
首部 　　　　　　　　　　　　 描述
Client-IP 　　　　　　　　　　提供了運行客戶端的機器的IP地址
From 　　　　　　　　　　　  提供了客戶端用戶的E-mail地址
Host 　　　　　　　　　　　   給出了接收請求的服務器的主機名和端口號
Referer 　　　　　　　　　　  提供了包含當前請求URI的文檔的URL
UA-Color 　　　　　　　　　  提供了與客戶端顯示器的顯示顏色有關的信息
UA-CPU 　　　　　　　　　　 給出了客戶端CPU的類型或製造商
US-Disp 　　　　　　　　　　提供了與客戶端顯示器(屏幕)能力有關的信息
US-OS 　　　　　　　　　　  給出了客戶端顯示器的像素信息
UA-Pixels 　　　　　　　　　 提供了客戶端顯示器的像素信息
User-Agent 　　　　　　　　 將發起請求的應用程序名稱告知服務器(User-Agent)用戶代理，其實不就是瀏覽器嗎

　　Accept首部爲客戶端提供了一種將其喜愛和能力告知服務器的方式，包括他們想要什麼，可使用什麼，以及最重要的，他們不想要什麼。這樣服務器就能夠根據這些額外信息，對要發送的內容作出更明智的決定。Accept首部會使鏈接的兩端都受益。客戶端會獲得他們想要的內容，服務器則不會浪費其時間和帶寬來發送客戶端沒法使用的東西。

Accept首部：
首部 　　　　　　　　　　 描述
Accept 　　　　　　　　   告訴服務器可以發送哪些媒體類型
Accept-Charset 　　　　  告訴服務器可以發送哪些字符集
Accept-Encoding 　　　　告訴服務器可以發送哪些編碼方式
Accept-Language 　　　  告訴服務器可以發送哪些語言
TE 　　　　　　　　　　　 告訴服務器可使用哪些擴展傳輸編碼

　　條件請求首部：

　有時客戶端但願爲請求加上某些限制。好比客戶端已經有了一份副本，就但願只在服務器上的文檔與客戶端擁有的副本有所區別時，才請求服務器傳輸文檔。經過條件請求首部，客戶端就能夠加上這種限制，要求服務器在對請求進行相應以前，確保某個請求爲真。

條件請求首部：
首部 　　　　　　　　　　 描述
Expect 　　　　　　　　  容許客戶端列出某請求所要求的服務器行爲
If-Match 　　　　　　　　若是實體標記與文檔當前的實體標記相匹配，就或者這份文檔
If-Modified-Since 　　　　除非在某個指定的日期以後資源被修改過，不然就限制這個請求
If-Range 　　　　　　　　容許對文檔的某個範圍進行條件請求
If-Unmodified-Since 　　 除非在某個指定的日期以後資源沒有被修改過，不然就限制這個請求
Range 　　　　　　　　　若是服務器支持範圍請求，就請求資源的指定範圍

安全請求首部：

HTTP自己就支持一種簡單的機制，能夠對請求進行質詢/響應認證。這種機制要求客戶端在獲取特定的資源以前，先對自身進行認證，這樣就可使事務稍微安全一些。

安全請求首部:
首部 　　　　　　　　　　 描述
Authorization 　　　　　  包含了客戶端提供給服務器，以便對其自身進行認證的數據
Cookie 　　　　　　　　　 客戶端用它想服務器傳送一個令牌-他並非真正的安全首部，但倒是隱含了安全功能
Cookie2 　　　　　　　　  用來講明請求端支持的cookie版本

代理請求首部：

隨着因特網上代理的廣泛應用，人們定義了幾個首部來協助其更好地工做。

代理請求首部：
首部 　　　　　　　　　　 描述
Max-Forword 　　　　　 在通往源端服務器的路徑上，將請求轉發給其餘代理或網關的最大次數-與TRACE方法一同使用
Proxy-Authorization 　　與Authorization首部相同，但這個首部是在與代理進行認證時使用的
Proxy-Connection 　　　與Connection首部相同，但這個首部是在於代理創建鏈接時使用的

　　　　(3)、響應首部：提供更多有關響應的信息。

　　　　　　響應報文由本身的響應首部集。響應首部爲客戶端提供了一些額外的信息，好比誰在發送響應、響應者的功能，甚至與響應相關的一些特殊指令。這些首部有助於客　　　　　戶端處理響應，並在未來發起更好的請求。

響應的信息性首部：
首部 　　　　　　　　 描述
Age 　　　　　　　　 (從最初建立開始)響應持續時間
Public 　　　　　　　  服務器爲其資源支持的請求方法列表
Retry-After 　　　　  若是資源不可用的話，再第二天期或時間重試
Server 　　　　　　　 服務器應用程序軟件的名稱和版本
Title 　　　　　　　　 對HTML文檔來講，就是HTML文檔的源端給出的標題
Warning 　　　　　　 比緣由短語中更詳細的一些警告報文

　協商首部：若是資源有多種表示方法-好比，若是服務器上有某文檔的法語和德語譯稿，HTTP/1.1能夠爲服務器和客戶端提供對資源進行協商的能力。

協商首部：
首部　　　　　　　　 描述
Accept-Ranges 　　 對此資源來講，服務器可接受的範圍類型
Vary 　　　　　　　  服務器查看的其餘首部的列表，可能會使響應發生變化；也就是說，這是一個首部列表，服務器會根據這些首部的內容挑選出最合適的資源版本　　　　　　　　　　　 發送給客戶端。

安全響應首部：

咱們已經看到過安全請求首部了，本質上這裏說的就是HTTP的質詢/響應認證機制的響應側。

安全響應首部：
首部 描述
Proxy-Authenticate 來自代理的對客戶端的質詢列表
Set-Cookie 不是真正的安全首部，但隱含有安全功能；能夠在客戶端設置一個令牌，以便服務器對客戶端進行標識。
Set-Cookie2 與Set-Cookie相似。
WWW-Authenticate 來自服務器的對客戶端的質詢列表

　　　　d、實體首部：描述主體的長度和內容，或者資源自身。

　　　　有不少首部能夠用來描述HTTP報文的負荷。因爲請求和響應文本中均可能包含實體部分，因此在這兩種類型的報文中均可能出現這些首部。實體首部提供了有關實體及　　　　其內容的大量信息，從有關對象類型的信息，到可以對資源使用的各類有效的請求方法。總之，實體首部能夠告知報文的接收者它在對什麼進行處理。

實體信息性首部：
首部 　　　　　　　描述
Allow 　　　　　　 列出了能夠對此實體執行的請求方法
Location 　　　　  告知客戶端實體實際上位於何處；用於將接收端定向到資源的位置上去

內容首部：

　　　　內容首部提供了與實體內容有關的特定信息，說明了其類型、尺寸以及處理它所需的其餘有用信息。好比，Web瀏覽器能夠經過查看返回的內容類型，得知如何顯示對象。

內容首部：
首部 　　　　　　　　　　　  描述
Content-Base 　　　　　　  解析主體中的相對URL時使用的基礎URL
Content-Encoding 　　　　  對主體執行的任意編碼方式
Content-Language 　　　　 理解主體時最適宜使用的天然語言
Content-Length 　　　　　  主體的長度或尺寸
Content-Location 　　　　　資源實際所處的位置
Content-MD5 　　　　　　　主體的MD5校驗
Content-Range 　　　　　　在整個資源中此實體表示的字節範圍
Content-Type 　　　　　　  這個主體的對象模型

實體緩存首部：

　　通用的緩存首部說明了如何或何時進行緩存。實體的緩存首部提供了與被緩存實體有關的信息，好比驗證已緩存的資源副本是否仍然有效所需的信息，以及更好地估計已緩存資源合適失效所需的線索。

實體緩存首部
首部 　　　　　　 描述
ETag 　　　　　  與此實體有關的實體標記
Expires 　　　　 實體不在有效，要從原始的源端再次獲取此實體的日期和時間
Last-Modified 　 這個實體最後一次被修改的日期和時間

　　　　e、擴展首部：規範中沒有定義的新首部。

　　　　每一個HTTP首部都有一種簡單的語法：名字後面跟着冒號(:)，而後跟上可選的空格，再跟上字段值。最後是一個回車換行。

　　二、首部延續行

　　　　將長的首部行分爲多行能夠提升可讀性，多出來的每行前面至少要有一個空格或製表符(tab)。

HTTP/1.0 200 OK
Content-Type: image/gif
Content-Length: 8572
Server: Test Server
Version 1.0

 　　　　在上面的例子中，響應報文裏包含了一個Server首部，其值被劃分紅了多個延續行，該首部的完整值爲Test Server Version 1.0。

3、實體部分

　　HTTP的第三部分是可選的實體主體部分，實體的主體是HTTP報文的負荷。就是HTTP要傳輸的內容。

　　HTTP報文能夠承載不少類型的數字數據，圖片、視頻、HTML文檔、軟件應用程序、信用卡事務、電子郵件等。

　　下面來實戰下，咱們用瀏覽器打開百度首頁，將HTTP報文實戰解析下：

　　打開百度的請求報文：

GET / HTTP/1.1                //請求方法爲GET，HTTP協議爲1.1
Host: www.baidu.com            //URL爲www.baidu.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:19.0) Gecko/20100101 Firefox/19.0    //用戶代理，也就是瀏覽器了，顯示了瀏覽器的詳細信息
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8        //服務器可以發送的文件類型text/html的意思是HTML文本文檔類型，後面那些查文檔去
Accept-Language: zh-cn,zh;q=0.8,en-us;q=0.5,en;q=0.3                //服務器可以發送的語言 zh-cn爲中文，後面那些查文檔去
Accept-Encoding: gzip, deflate                            //服務器可以發送的編碼格式爲gzip，編碼格式不符合瀏覽器會解釋不了
Cookie: BAIDUID=AF6C346B14E94898933E5F858C63F889:FG=1; BDREFER=%7Burl%3A%22http%3A//news.baidu.com/%22%2Cword%3A%22%22%7D; H_PS_PSSID=2097_1464_2133_1944_1788    //cookie，服務器存儲在客戶端的信息，每次請求都會將服務器保存在客戶端的cookie一併發送上服務器。
Connection: keep-alive    //鏈接，keep-alive保持狀態
Cache-Control: max-age=0    //隨報文傳送緩存指示    cache-control max-age>0 時 直接從遊覽器緩存中 提取 max-age<=0 時 向server 發送http 請求確認 ,該資源是否有修改 有的話 返回200 ,無的話 返回304.

　　打開百度的響應報文：

HTTP/1.1 200 OK        //HTTP版本 1.1    狀態碼200 緣由短語OK
Date: Tue, 02 Apr 2013 04:27:50 GMT    //響應的時間日期
Server: BWS/1.0        //服務器應用程序軟件的名稱和版本 BWS/1.0
Content-Length: 4271    //響應的主體內容的長度爲4271個字節
Content-Type: text/html;charset=utf-8    //響應類型爲HTML文本，編碼類型爲utf-8
Cache-Control: private        //緩存指示
Expires: Tue, 02 Apr 2013 04:27:50 GMT    //實體不在有效，要從原始的源端再次獲取此實體的日期和時間
Content-Encoding: gzip        //對主體執行的編碼方式爲gzip
Set-Cookie: H_PS_PSSID=2097_1464_2133_1944_1788; path=/; domain=.baidu.com    //設置cookie，path,domain都是cookie的信息(做用範圍等等)
Connection: Keep-Alive    //狀態爲保持鏈接

　　響應就牛B了，就是頁面的源代碼：

<!DOCTYPE html><!--STATUS OK-->    <html><head>  <meta http-equiv="content-type" content="text/html;charset=utf-8">  <title>百度一下，你就知道</title> <style >html,body{height:100%}html{overflow-y:auto}#wrapper{position:relative;_position:;min-height:100%}#content{padding-bottom:100px;text-align:center}#ftCon{height:100px;position:absolute;bottom:44px;text-align:center;width:100%;margin:0 auto;z-index:0;overflow:hidden}#ftConw{width:720px;margin:0 auto}body{font:12px arial;text-align:;background:#fff}body,p,form,ul,li{margin:0;padding:0;list-style:none}body,form,#fm{position:relative}td{text-align:left}img{border:0}a{color:#00c}a:active{color:#f60}#u{color:#999;padding:4px 10px 5px 0;text-align:right}#u a{margin:0 5px}#u .reg{margin:0}#m{width:720px;margin:0 auto}#nv a,#nv b,.btn,#lk{font-size:14px}#fm{padding-left:110px;text-align:left;z-index:1}...
因爲內容比較多，因此省略後面部分

　　下面來看下一個須要提交表單的請求報文：打開百度的登陸窗口，填寫完信息後提交是的請求報文POST信息爲：

callback    parent.bdPass.api.login._postCallback
charset    utf-8
codestring    
index    0
isPhone    false
loginType    1
mem_pass    on
password    123
ppui_logintime    13905
safeflg    0
staticpage    http://www.baidu.com/cache/user/html/jump.html
token    d0de247f344d33dbb9692491dc5574cd
tpl    mn
u    
username    123@qwe.com
verifycode    

　　能夠看到在表單提交的請求帳號密碼都在請求報文的實體裏面傳送上服務器了。