本篇博客我們就來詳細的聊一下HTTP協(xié)議的常用頭部字段，當然我們將其分為請求頭和響應(yīng)頭進行闡述。下方是報文頭每個字段的格式，首先是頭部字段的名稱，如Accept，冒號后方緊跟的是該字段名所對應(yīng)的值，每個值之間有逗號分隔。如果該值需要優(yōu)先級，那么在值的后方跟上優(yōu)先級q=0.8(q的值由0~1，優(yōu)先級從低到高)。值與優(yōu)先級中間由分號相隔。
頭部字段名：值1, 值2;q=0.8
下方就是截取的網(wǎng)絡(luò)請求中Request Headers的部分內(nèi)容。紅框中的Accept-Language就是頭部字段名，冒號后邊就是該字段相應(yīng)的值了。如下所示：
HTTP頭部字段可以分為通用頭部字段，請求頭部字段，響應(yīng)頭部字段以及實體頭部字段，下方會給出詳細的介紹。
通用頭部字段 （General Header Fields）
該字段在請求頭和響應(yīng)頭都會使用到，下方是常用的通用頭部字段：
Cache-Control
用來操作緩存的工作機制，下方截圖響應(yīng)頭中的的Cache-Control的參數(shù)為private和max-age=10。private緩存是私有的，僅像特定用戶提供相應(yīng)的緩存信息。如果是public，那么就意味著可向任意方提供相應(yīng)的緩存信息。max-age = 10表示緩存有效期為10秒。從下方的Expires(過期時間)和Last-Modified(最后修改時間)就可以看出，這兩者之間的差值正好是10秒。
該字段還可以對應(yīng)其他的參數(shù)：
- no-cache：如果是客戶端的話，說明客戶端不會接收緩存過的響應(yīng)，要請求最新的內(nèi)容。而服務(wù)器端則表示緩存服務(wù)器不能對相應(yīng)的資源進行緩存。
- no-store：表示緩存不能在本地存儲。
- max-age：該參數(shù)后方會被賦值上相應(yīng)的秒數(shù)，在請求頭中表示如果緩存時間沒有超過這個值就返回給我。而在響應(yīng)頭中時，則表示資源在緩存服務(wù)器中緩存的最大時間。
- only-if-cached：表示客戶端僅僅請求緩存服務(wù)器上的內(nèi)容，如果緩存服務(wù)器上沒有請求的內(nèi)容，那么返回504 Gateway Timeout。
- must-revalidata：表示緩存服務(wù)器在返回資源是，必須向資源服務(wù)器確認其緩存的有效性。
- no-transform：無論請求還是響應(yīng)，都不能在傳輸?shù)倪^程中改變報文體的媒體類型。
Connection
該字段可以控制不轉(zhuǎn)發(fā)給代理服務(wù)器的首部字段以及管理持久連接，下方這個響應(yīng)報文頭中的Connection就是用來管理持久連接的，其參數(shù)為keep-alive，就是保持持久連接的意思?？梢允褂胏lose參數(shù)將其關(guān)閉。
Transfer-Encoding
該字段表示報文在傳輸過程中采用的編碼方式，在HTTP/1.1的報文傳輸過程中僅對分塊編碼有效。下方這個截圖就是Transfer-Encoding在Response Header中的使用，后邊根的chunked(分塊)的參數(shù)，說明報文是分塊進行傳輸?shù)摹?/p>
Via
該字段是為了追蹤請求和響應(yīng)報文測傳輸路徑，報文經(jīng)過代理或者網(wǎng)關(guān)是會在Via字段添加該服務(wù)器的信息，然后再進行轉(zhuǎn)發(fā)。
請求頭部字段 （Request Header Fields）
顧名思義，請求頭部字段當然是在請求頭中才使用的字段。該字段用于補充請求的附加信息，客戶端信息等。接下來將給出常用而且比較重要的幾個請求頭部字段。
Accept
該字段可通知服務(wù)器用戶代理能夠處理的媒體類型以及該媒體類型對應(yīng)的優(yōu)先級。媒體類型可使用“type/subtype”這種形式來指定，分號后邊緊跟著的是該類型的優(yōu)先級。如下所示。
Accept-Encoding
該字段用來告知服務(wù)器，客戶端這邊可支持的內(nèi)容編碼以及相應(yīng)內(nèi)容編碼的優(yōu)先級, 下方就是Accept-Encoding的用法。gzip表示由文件壓縮程序gzip(GNU zip)生成的編碼格式。compress表示UNIX文件壓縮程序compress生成的編碼格式。deflate表示組合使用zlib格式以及有deflate壓縮算法生成的編碼格式。identity表示不執(zhí)行壓縮或者使用一致的默認編碼格式。
Accept-Language
該字段用來告知服務(wù)器，客戶端可處理的自然語言集，以及對應(yīng)語言集的優(yōu)先級。以下方的截圖為例，Accept-Language后方跟了三個屬性，分別是“zh-CN”, "zh;q=0.8"，“en;q=0.6”。也就是說客戶端可處理三種自然預(yù)言集，zh-CN，其優(yōu)先級是1（最高）。第二種是zh ，其優(yōu)先級是0.8，次之。第三個是en，優(yōu)先級為0.6，優(yōu)先級在三者之間最低。
Authorization
用來告知服務(wù)器用戶端的認證信息，下方就是連接公司內(nèi)部SVN系統(tǒng)時需要認證時的請求頭部信息。
如果你沒有填寫認證信息的話，那么就會返回401 Unauthorized。如下所示：
If-Match 與If-None-Match
上面這兩個請求頭部字段都是帶有邏輯判斷的，從上面的英文我們不難看出兩者恰好相反。兩者后方都跟著串字符串，如If-Match "xcsldjh49773hce", 后邊這個字符的匹配對象是ETag(稍后會介紹)。If-Match的請求是如果后方的字符串與ETag相等則服務(wù)器端進行請求，否則不進行處理。If-None-Match是If-Match的非操作，同樣是匹配ETag, 如果Etag沒有匹配成功就處理請求，否則不處理。
If-Modified-Since與If-Unmodified-Since
If-Modified-Since也是帶有邏輯判斷的請求頭部字段，該字段后方跟的是一個日期，意思是在該日期后發(fā)生了資源更新，那么服務(wù)器就會處理該請求。If-Unmodified-Since就是 If-Modified-Since的非操作。
If-Range
if-Range字段后方也是跟的Etag, 該字段要結(jié)合著Range字段進行使用。其所代表的意思就是如果Etag匹配成功，請求的內(nèi)容就按照Range字段所規(guī)定的范圍進行返回，否則返回全部的內(nèi)容。用法如下所示：
If-Range: "etag_code"
Range: bytes=1000-5000
Referer
其實Referer是一個錯誤的拼寫，但是一直在使用。正確的英文單詞應(yīng)該是Referrer(此處可翻譯為:來歷、來路)。Referer字段后方跟的是一個URI, 該URI就是發(fā)起請求的URI，具體如下所示：
User-Agent
該字段會將請求方的瀏覽器和用戶代理名稱等信息傳達給服務(wù)器。下方就是從我當前筆記本的Chrome瀏覽器請求網(wǎng)絡(luò)時的User-Agent信息。
響應(yīng)頭部字段 （Request Header Fields）
聊完請求報文頭部字段后，我們接下來來聊一下響應(yīng)報文頭部字段。響應(yīng)頭是由Server向Client返回響應(yīng)報文中使用的頭部信息。用戶補充響應(yīng)的附加信息、服務(wù)信息等。下方是幾個常見響應(yīng)頭部字段。
Accept-Ranges
該字段用來告知客戶端服務(wù)器那邊是否支持范圍請求（請求部分內(nèi)容，請求頭中使用Range字段）。Accept-Ranges的值為bytes時，就說明服務(wù)器支持范圍請求，為none時，說明服務(wù)器不支持客戶端的范圍請求。下方是博客園的頁面的加載，從下方可以看出是支持范圍請求的，如下所示：
Age
該字段告知客戶端，源服務(wù)器在多久前創(chuàng)建了該響應(yīng)。
Etag
Etag是服務(wù)器當前請求的服務(wù)器資源（圖片，HTML頁面等）所對應(yīng)的一個獨有的字符串。不同資源間的Etag是不同的，當資源更新時Etag也會進行更新。
所以結(jié)合著請求頭中的If-Match等邏輯請求頭，可以判斷當前Client端已經(jīng)加載的資源在服務(wù)器端是否已經(jīng)更新了。當初次請求一個資源，如圖片時，我們可以將其Etag進行保存，在此請求時，可放在If-None-Match后方，進行資源更新。如果服務(wù)器資源并未修改，就不對該請求做出響應(yīng)。下方就是網(wǎng)頁中某張圖片對應(yīng)著的Etag，如下所示。
Location
Location字段一般與重定向結(jié)合著使用。下方是我訪問“www.baidu.com/hello”這個連接的響應(yīng)報文。因為服務(wù)器上并沒有/hello這個資源路徑，所以給我重定向了error.html頁面，這個重定向的URL就存儲在Location字段中，如下所示：
Server
該響應(yīng)字段表明了服務(wù)器端使用的服務(wù)器型號，下方是博客園某張圖片的響應(yīng)頭，使用的Web服務(wù)器是Tengine, Tengin是淘寶發(fā)起的Web服務(wù)器項目，是基于Nginx的，關(guān)于Tengin的相關(guān)內(nèi)容，請自行Google吧。
Vary
Vary可對緩存進行控制，通過該字段，源服務(wù)器會向代理服務(wù)器傳達關(guān)于本地緩存使用方法的命令。下方就是Vary的使用，Vary后方的參數(shù)是Accept-Encoding。其意思是返回的緩存要以Accept-Encoding為準。當請求的Accept-Encoding的參數(shù)與緩存內(nèi)容的Accept-Encoding參數(shù)一致時就返回緩存內(nèi)容，否則就請求源服務(wù)器。
WWW-Authenticate
該字段用于HTTP的訪問認證，在狀態(tài)碼401 Unauthorized中肯定帶有此字段，該字段用來指定客戶端的認證方案（Basic或者Digest）。參數(shù)realm的字符串是為了辨別請求URL指定資源所受到的保護策略。如下所示：
實體頭部字段（Content Header Fields）
接下來我們就來聊聊常見的實體頭部字段，實體頭部字段是報文實體所使用的頭部，用來補充與報文實體相關(guān)的信息。
Allow
該字段用于服務(wù)器通知客戶端服務(wù)器這邊所支持的所有請求方法（GET、POST等）。如果服務(wù)器找不到客戶端請求中所提到的方法的話，就會返回405 Method Not Allowed，于此同時還會把所有能支持的HTTP方法寫入到首部字段Allow后返回。
Allow : GET, POST, HEAD, PUT, DELETE
Content-Encoding
該字段用來說明報文實體的編碼方式，下方這段報文頭中的Content-Encoding的參數(shù)為gzip，說明是使用gzip對報文實體進行壓縮的。
Content-Language
該字段表示報文實體使用的自然語言，使用方式如下所示：
Content-Language: zh-CN
Content-Length
顧名思義，該字段用來指定報文實體的字節(jié)長度，如下所示：
Content-MD5
該字段中存儲的是報文實體進行MD5加密然后再使用Base64進行編碼的字符串?？蛻舳耸盏巾憫?yīng)報文后，可以對報文實體進行MD5加密，然后再對其進行Base64編碼，然后與Content-MD5中的字符串進行比較來確定報文是否進行修改，可以說這是一個簡單的驗簽功能。但是此方法并不能確定報文是否被修改了，因為Content-MD5這個值也有可能被篡改。
Cookie相關(guān)的頭部字段
因為HTTP協(xié)議本身是無狀態(tài)的，在Web站點中使用Cookie來管理服務(wù)器與客戶端之間的狀態(tài)。解析來我就來介紹一下Cookie相關(guān)的頭部字段。
Set-Cookie
響應(yīng)報文中會使用到該字段。當服務(wù)器準備開始管理客戶端的狀態(tài)時，會事先告知其各種信息。下方字段是登錄知乎時所返回的所要設(shè)置的Cookie信息。接下來我們就要對這串Cookie信息進行解析。
- 鍵值對：在Set-Cookie字段中，“z_co=Mi4……”這就是要存入Cookie中的信息，當然可以是多個鍵值對，中間使用逗號進行分割即可。
- Domain：然后是Domain屬性，由下方不難看出，Domain中存儲的就是Cookie適用對象的域名，若不指定Domain的值，那么默認就是創(chuàng)建Cookie的服務(wù)器的域名。
- expire：該字段屬性的值是一個時間，也就是Cookie的有效期，若不指定該屬性的值，默認就是當前會話有效，關(guān)閉瀏覽器Cookie即失效。
- httponly：設(shè)置該屬性的目的是讓JavaScript腳本無法獲取Cookie，其主要目的是防止跨站腳本攻擊對Cookie信息的竊取。
- path： 用于限制指定Cookie的發(fā)送范圍的文件目錄。
- Secure：僅在HTTPS安全通信時才會發(fā)送Cookie。
Cookie
請求報文頭中會使用該字段，用于將本地存儲的Cookie信息發(fā)送給服務(wù)端。下方就是知乎上每次請求文章所帶有的Cookie信息，當然下方只是部分信息，但是我們還是從中可以找到之前我們存儲的“z_co=Mi4……”這個鍵值對的。
其他比較常見而且比較簡單的頭部字段就不做過多贅述了，今天博客就先到這兒吧。
