HTTP協議詳解（二）

本文是HTTP解析系列第二篇，如果對http協議不是很瞭解，可以選去看第一篇：帶新手走進神祕的HTTP協議，本文主要是對Http的首部字段進行詳細解析。

HTTP 協議的請求和響應報文中必定包含 HTTP 首部，只是我們平時在使用 Web 的過程中感受不到它。本章 我們一起來學習 HTTP 首部的結構，以及首部中各字段的用法。

6.1 HTTP 報文首部

首部內容爲客戶端和服務器分別處理請求和響應提供 所需要的信息。對於客戶端用戶來說，這些信息中的大部分內容都無須親自查看。

HTTP 請求報文

在請求中，HTTP 報文由方法、URI、HTTP 版本、HTTP 首部字段等部分構成。

下面的示例是訪問 http://hackr.jp 時，請求報文的首部信息。

1 2 3 4 5 6 7 8 9 10

GET / HTTP/1.1 Host: hackr.jp User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*; q=0.8 Accept-Language: ja,en-us;q=0.7,en;q=0.3 Accept-Encoding: gzip, deflate DNT: 1 Connection: keep-alive If-Modified-Since: Fri, 31 Aug 2007 02:02:20 GMT If-None-Match: "45bae1-16a-46d776ac" Cache-Control: max-age=0

HTTP 響應報文
在響應中，HTTP 報文由 HTTP 版本、狀態碼（數字和原因短語）、HTTP 首部字段 3 部分構成。

圖：響應報文 
以下示例是之前請求訪問 http://hackr.jp/ 時，返回的響應報文的首部信息。

1 2 3 4 5

HTTP/1.1 304 Not Modified Date: Thu, 07 Jun 2012 07:21:36 GMT Server: Apache Connection: close Etag: "45bae1-16a-46d776ac"

在報文衆多的字段當中，HTTP 首部字段包含的信息最爲豐富。首部字段同時存在於請求和響應報文內，並涵蓋 HTTP 報文相關的內容信息。
因 HTTP 版本或擴展規範的變化，首部字段可支持的字段內容略有不同。本書主要涉及 HTTP/1.1 及常用的 首部字段。

6.2 HTTP 首部字段

使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

6.2.1　HTTP 首部字段結構

HTTP 首部字段是由首部字段名和字段值構成的，中間用冒號“:” 分隔。

  首部字段名: 字段值

例如，在 HTTP 首部中以 Content-Type 這個字段來表示報文主體的對象類型。

1	Content-Type: text/html

就以上述示例來看，首部字段名爲 Content-Type，字符串 text/html 是字段值。
另外，字段值對應單個 HTTP 首部字段可以有多個值，如下所示。

1	Keep-Alive: timeout=15, max=100

注意：若 HTTP 首部字段重複了會如何？
當 HTTP 報文首部中出現了兩個或兩個以上具有相同首部字段名時會怎麼樣？這種情況在規範內尚未明確，根據瀏覽器內部處理邏輯的不同，結果可能並不一致。有些瀏覽器會優先處理第一次出現的首部字段，而有些則會優先處理最後出現的首部字段。

6.2.2   4 種 HTTP 首部字段類型

HTTP 首部字段根據實際用途被分爲以下 4 種類型：
通用首部字段（General Header Fields）
請求報文和響應報文兩方都會使用的首部。
請求首部字段（Request Header Fields）
從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。
響應首部字段（Response Header Fields）
從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。
實體首部字段（Entity Header Fields）
針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

6.2.3　HTTP/1.1 首部字段一覽

HTTP/1.1 規範定義瞭如下 47 種首部字段。
表 6-1：通用首部字段

表 6-2：請求首部字段

首部字段名                  說明
Accept                         用戶代理可處理的媒體類型
Accept-Charset            優先的字符集
Accept-Encoding         優先的內容編碼
Accept-Language        優先的語言（自然語言）
Authorization               Web認證信息
Expect                          期待服務器的特定行爲
From                             用戶的電子郵箱地址
Host                              請求資源所在服務器
If-Match                        比較實體標記（ETag）
If-Modified-Since          比較資源的更新時間
If-None-Match              比較實體標記（與 If-Match 相反）
If-Range                        資源未更新時發送實體 Byte 的範圍請求
If-Unmodified-Since     比較資源的更新時間（與If-Modified-Since相反）
Max-Forwards               最大傳輸逐跳數
Proxy-Authorization     代理服務器要求客戶端的認證信息
Range                           實體的字節範圍請求
Referer                          對請求中 URI 的原始獲取方
TE                                  傳輸編碼的優先級
User-Agent                   HTTP 客戶端程序的信息

表 6-3：響應首部字段 

首部字段名                     說明
Accept-Ranges             是否接受字節範圍請求
Age                               推算資源創建經過時間
ETag                              資源的匹配信息
Location                        令客戶端重定向至指定URI
Proxy-Authenticate      代理服務器對客戶端的認證信息
Retry-After                   對再次發起請求的時機要求
Server HTTP                  服務器的安裝信息
Vary                              代理服務器緩存的管理信息
WWW-Authenticate     服務器對客戶端的認證信息

表 6-4：實體首部字段

首部字段名                    說明
Allow                            資源可支持的HTTP方法
Content-Encoding       實體主體適用的編碼方式
Content-Language      實體主體的自然語言
Content-Length           實體主體的大小（單位：字節）
Content-Location        替代對應資源的URI
Content-MD5              實體主體的報文摘要
Content-Range            實體主體的位置範圍
Content-Type              實體主體的媒體類型
Expires                         實體主體過期的日期時間
Last-Modified              資源的最後修改日期時間

6.2.4  非 HTTP/1.1 首部字段

在 HTTP 協議通信交互中使用到的首部字段，不限於 RFC2616 中定義的 47 種首部字段。還有 Cookie、 Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段，它們的使用頻率也很高。
這些非正式的首部字段統一歸納在 RFC4229 HTTP Header Field Registrations 中。

6.2.6　End-to-end 首部和Hop-by-hop 首部

HTTP 首部字段將定義成緩存代理和非緩存代理的行爲，分成 2 種類型。
端到端首部（End-to-end Header）

分在此類別中的首部會轉發給請求 / 響應對應的最終接收目標，且必須保存在由緩存生成的響應中，另外規 定它必須被轉發。

逐跳首部（Hop-by-hop Header）

分在此類別中的首部只對單次轉發有效，會因通過緩存或代理而不再轉發。HTTP/1.1 和之後版本中，如果要使用 hop-by-hop 首部，需提供 Connection 首部字段。

下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個首部字段之外，其他所有字段都屬於端到端首部。

• Connection
• Keep-Alive
• Proxy-Authenticate
• Proxy-Authorization
• Trailer
• TE
• Transfer-Encoding
• Upgrade

6.3　HTTP/1.1 通用首部字段

通用首部字段是指，請求報文和響應報文雙方都會使用的首部。

6.3.1  Cache-Control

通過指定首部字段 Cache-Control 的指令，就能操作緩存的工作機制。

圖：首部字段Cache-Control 能能夠控制緩存的行爲 

指令的參數是可選的，多個指令之間通過“,”分隔。首部字段 Cache-Control 的指令可用於請求及響應時。

1	Cache-Control: private, max-age=0, no-cache​

Cache-Control 指令一覽:

可用的指令按請求和響應分類如下所示。
表 6-5：緩存請求指令
指令                                  參數         說明
no-cache                          無            強制向源服務器再次驗證
no-store 無 不緩存請求或響應的任何內容
max-age = [ 秒] 必需 響應的最大Age值
max-stale( = [ 秒])
可省 略
接收已過期的響應
min-fresh = [ 秒] 必需 期望在指定時間內的響應仍有效
no-transform 無 代理不可更改媒體類型
only-if-cached 無 從緩存獲取資源
cache-extension - 新指令標記（token）

表 6-6：緩存響應指令

指令                                 參數           說明
public                              無              可向任意方提供響應的緩存
private                            可省略        僅向特定用戶返回響應
no-cache                        可省略        緩存前必須先確認其有效性
no-store                         無              不緩存請求或響應的任何內容
no-transform                 無               代理不可更改媒體類型
must-revalidate             無              可緩存但必須再向源服務器進行確認
proxy-revalidate            無              要求中間緩存服務器對緩存的響應有效性再進行 確認
max-age = [ 秒]            必需            響應的最大Age值
s-maxage = [ 秒]          必需             公共緩存服務器響應的最大Age值
cache-extension           -                 新指令標記（token）

剩下的內容是對上面字段的解析，在 ppt 87頁，實在太多了，需要時去看。

6.3.2  Connection

Connection 首部字段具備如下兩個作用。

• 控制不再轉發給代理的首部字段 
• 管理持久連接

  1. 控制不再轉發給代理的首部字段

1	Connection: 不再轉發的首部字段名

在客戶端發送請求和服務器返回響應內，使用 Connection 首部字段，可控制不再轉發給代理的首部字段（即 Hop-by-hop 首部）。

  2. 管理持久連接 

 

1	Connection: close

HTTP/1.1 版本的默認連接都是持久連接。爲此，客戶端會在持久連接上連續發送請求。當服務器端想明確斷開連接時，則指定 Connection 首部字段的值爲 Close。

1	Connection: Keep-Alive

HTTP/1.1 之前的 HTTP 版本的默認連接都是非持久連接。爲此，如果想在舊版本的 HTTP 協議上維持 持續連接，則需要指定 Connection 首部字段的值爲 Keep-Alive。
如上圖①所示，客戶端發送請求給服務器時，服務器端會像上圖②那樣加上首部字段 Keep-Alive 及首部字段 Connection 後返回響應。

太多了，下邊的內容只記重要的部分，做了省略。ppt 93頁

6.3.3　Date 首部字段

Date 表明創建 HTTP 報文的日期和時間

6.3.4　　Pragma

Pragma 是 HTTP/1.1 之前版本的歷史遺留字段，僅作爲與 HTTP/1.0 的向後兼容而定義。
規範定義的形式唯一，如下所示。

1	Pragma: no-cache​

該首部字段屬於通用首部字段，但只用在客戶端發送的請求中。客戶端會要求所有的中間服務器不返回緩存 的資源。

所有的中間服務器如果都能以 HTTP/1.1 爲基準，那直接採用 Cache-Control: no-cache 指定緩存的處理方式 是最爲理想的。但要整體掌握全部中間服務器使用的 HTTP 協議版本卻是不現實的。因此，發送的請求會同 時含有下面兩個首部字段。

1 2	Cache-Control: no-cache Pragma: no-cache​

6.3.5　Trailer

 

首部字段 Trailer 會事先說明在報文主體後記錄了哪些首部字段。該首部字段可應用在 HTTP/1.1 版本分塊傳 輸編碼時。

1 2 3 4 5 6 7 8 9

HTTP/1.1 200 OK Date: Tue, 03 Jul 2012 04:40:56 GMT Content-Type: text/html ... Transfer-Encoding: chunked Trailer: Expires ...(報文主體)... 0 Expires: Tue, 28 Sep 2004 23:59:59 GMT

以上用例中，指定首部字段 Trailer 的值爲 Expires，在報文主體之後（分塊長度 0 之後）出現了首部字段 Expires。

6.3.6　Transfer-Encoding

首部字段 Transfer-Encoding 規定了傳輸報文主體時採用的編碼方式。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

HTTP/1.1 200 OK Date: Tue, 03 Jul 2012 04:40:56 GMT Cache-Control: public, max-age=604800 Content-Type: text/javascript; charset=utf-8 Expires: Tue, 10 Jul 2012 04:40:56 GMT X-Frame-Options: DENY X-XSS-Protection: 1; mode=block Content-Encoding: gzip Transfer-Encoding: chunked Connection: keep-alive   cf0    ←16進制(10進製爲3312)   ...3312字節分塊數據...   392    ←16進制(10進製爲914)   ...914字節分塊數據...   0

以上用例中，正如在首部字段 Transfer-Encoding 中指定的那樣，有效使用分塊傳輸編碼，且分別被分成 3312 字節和 914 字節大小的分塊數據。

6.3.7　Upgrade

首部字段 Upgrade 用於檢測 HTTP 協議及其他協議是否可使用更高的版本進行通信，其參數值可以用來指定 一個完全不同的通信協議。

6.3.8　Via

使用首部字段 Via 是爲了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。

6.3.9　Warning

HTTP/1.1 的 Warning 首部是從 HTTP/1.0 的響應首部（Retry-After）演變過來的。該首部通常會告知用戶一 些與緩存相關的問題的警告。

1	Warning: 113 gw.hackr.jp:8080 "Heuristic expiration" Tue, 03 Jul 2012 05:09:44 GMT

Warning 首部的格式如下。最後的日期時間部分可省略。

1	Warning: [警告碼][警告的主機:端口號]“[警告內容]”([日期時間])​

ppt 95頁左右

6.4　　請求首部字段

請求首部字段是從客戶端往服務器端發送請求報文中所使用的字段，用於補充請求的附加信息、客戶端信 息、對響應內容相關的優先級等內容。

6.4.1　　Accept

1	Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8​

Accept 首部字段可通知服務器，用戶代理能夠處理的媒體類型及媒體類型的相對優先級。可使用 type/subtype 這種形式，一次指定多種媒體類型。
下面我們試舉幾個媒體類型的例子。

文本文件

1 2	text/html, text/plain, text/css ... application/xhtml+xml, application/xml ...​

圖片文件

1	image/jpeg, image/gif, image/png ...​

視頻文件

1	video/mpeg, video/quicktime ...​

應用程序使用的二進制文件

1	application/octet-stream, application/zip ...​

比如，如果瀏覽器不支持 PNG 圖片的顯示，那 Accept 就不指定 image/png，而指定可處理的 image/gif 和 image/jpeg 等圖片類型。 若想要給顯示的媒體類型增加優先級，則使用 q= 來額外表示權重值 1，用分號（;）進行分隔。權重值 q 的 範圍是 0~1（可精確到小數點後 3 位），且 1 爲最大值。不指定權重 q 值時，默認權重爲 q=1.0。
1 原文是“品質係數”。在 RFC2616 定義中，此處的 q 是指 qvalue，即 quality factor。直譯的話就是質量數，但經過綜合考慮理 解記憶的便利性後，似乎採用權重值更爲穩妥。——譯者注
當服務器提供多種內容時，將會首先返回權重值最高的媒體類型。

6.4.2　　Accept-Charset

1	Accept-Charset: iso-8859-5, unicode-1-1;q=0.8​

Accept-Charset 首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優先順序。另外，可一次 性指定多種字符集。與首部字段 Accept 相同的是可用權重 q 值來表示相對優先級。
該首部字段應用於內容協商機制的服務器驅動協商。

6.4.3　Accept-Encoding

1	Accept-Encoding: gzip, deflate​

Accept-Encoding 首部字段用來告知服務器用戶代理支持的內容編碼及內容編碼的優先級順序。可一次性指 定多種內容編碼。
下面試舉出幾個內容編碼的例子。
  gzip
   由文件壓縮程序 gzip（GNU zip）生成的編碼格式（RFC1952），採用 Lempel-Ziv 算法    （LZ77）及 32 位循環冗餘校驗（Cyclic Redundancy Check，通稱 CRC）。
    compress
    由 UNIX 文件壓縮程序 compress 生成的編碼格式，採用 Lempel-Ziv-Welch 算法（LZW）。
    deflate
    組合使用 zlib 格式（RFC1950）及由 deflate 壓縮算法（RFC1951）生成的編碼格式。
    identity
    不執行壓縮或不會變化的默認編碼格式
採用權重 q 值來表示相對優先級，這點與首部字段 Accept 相同。另外，也可使用星號（*）作爲通配符，指 定任意的編碼格式。

6.4.4　Accept-Language

1	Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3​

首部字段 Accept-Language 用來告知服務器用戶代理能夠處理的自然語言集（指中文或英文等），以及自然 語言集的相對優先級。可一次指定多種自然語言集。
和 Accept 首部字段一樣，按權重值 q 來表示相對優先級。在上述圖例中，客戶端在服務器有中文版資源的情 況下，會請求其返回中文版對應的響應，沒有中文版時，則請求返回英文版響應。

6.4.5　Authorization

1	Authorization: Basic dWVub3NlbjpwYXNzd29yZA==​

首部字段 Authorization 是用來告知服務器，用戶代理的認證信息（證書值）。通常，想要通過服務器認證的 用戶代理會在接收到返回的 401 狀態碼響應後，把首部字段 Authorization 加入請求中。共用緩存在接收到含 有 Authorization 首部字段的請求時的操作處理會略有差異。
有關 HTTP 訪問認證及 Authorization 首部字段，稍後的章節還會詳細說明。另外，讀者也可參閱 RFC2616。

6.4.6　Expect

1	Expect: 100-continue​

客戶端使用首部字段 Expect 來告知服務器，期望出現的某種特定行爲。因服務器無法理解客戶端的期望作出 迴應而發生錯誤時，會返回狀態碼 417 Expectation Failed。
客戶端可以利用該首部字段，寫明所期望的擴展。雖然 HTTP/1.1 規範只定義了 100-continue（狀態碼 100 Continue 之意）。
等待狀態碼 100 響應的客戶端在發生請求時，需要指定 Expect:100-continue

6.4.7  From

首部字段 From 用來告知服務器使用用戶代理的用戶的電子郵件地址。通常，其使用目的就是爲了顯示搜索 引擎等用戶代理的負責人的電子郵件聯繫方式。使用代理時，應儘可能包含 From 首部字段（但可能會因代 理不同，將電子郵件地址記錄在 User-Agent 首部字段內）。

6.4.8　　Host

1	Host: www.hackr.jp​

首部字段 Host 會告知服務器，請求的資源所處的互聯網主機名和端口號。Host 首部字段在 HTTP/1.1 規範內是唯一一個必須被包含在請求內的首部字段。
首部字段 Host 和以單臺服務器分配多個域名的虛擬主機的工作機制有很密切的關聯，這是首部字段 Host 必須存在的意義。

6.4.9  If-xxx 

形如 If-xxx 這種樣式的請求首部字段，都可稱爲條件請求。服務器接收到附帶條件的請求後，只有判斷指定條 件爲真時，纔會執行請求。

每個if的詳細內容去看ppt106頁，實在是太多了

6.4.16　　Range

1	Range: bytes=5001-10000​

對於只需獲取部分資源的範圍請求，包含首部字段 Range 即可告知服務器資源的指定範圍。上面的示例表示 請求獲取從第 5001 字節至第 10000 字節的資源。

6.4.19　User-Agent

1	User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1

首部字段 User-Agent 會將創建請求的瀏覽器和用戶代理名稱等信息傳達給服務器。
由網絡爬蟲發起請求時，有可能會在字段內添加爬蟲作者的電子郵件地址。此外，如果請求經過代理，那麼 中間也很可能被添加上代理服務器的名稱。

6.5　響應首部字段

響應首部字段是由服務器端向客戶端返回響應報文中所使用的字段，用於補充響應的附加信息、服務器信 息，以及對客戶端的附加要求等信息。

6.5.1　　Accept-Ranges

當不能處理範圍請求時，Accept-Ranges: none

1	Accept-Ranges: bytes​

首部字段 Accept-Ranges 是用來告知客戶端服務器是否能處理範圍請求，以指定獲取服務器端某個部分的資 源。
可指定的字段值有兩種，可處理範圍請求時指定其爲 bytes，反之則指定其爲 none。

6.5.2　　Age

1

Age: 600​

首部字段 Age 能告知客戶端，源服務器在多久前創建了響應。字段值的單位爲秒。
若創建該響應的服務器是緩存服務器，Age 值是指緩存後的響應再次發起認證到認證完成的時間值。代理創 建響應時必須加上首部字段 Age。

6.6　　實體首部字段

實體首部字段是包含在請求報文和響應報文中的實體部分所使用的首部，用於補充內容的更新時間等與實體相關的信息。

6.6.1　　Allow

1	Allow: GET, HEAD​

首部字段 Allow 用於通知客戶端能夠支持 Request-URI 指定資源的所有 HTTP 方法。當服務器接收到不支持 的 HTTP 方法時，會以狀態碼 405 Method Not Allowed 作爲響應返回。與此同時，還會把所有能支持的 HTTP 方法寫入首部字段 Allow 後返回。

6.6.2　　Content-Encoding

Content-Encoding: gzip

首部字段 Content-Encoding 會告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不 丟失實體信息的前提下所進行的壓縮。

主要採用以下 4 種內容編碼的方式。（各方式的說明請參考 6.4.3 節 Accept-Encoding 首部字段）。
gzip
compress
deflate
identity

6.6.3　Content-Language

Content-Language: zh-CN
首部字段 Content-Language 會告知客戶端，實體主體使用的自然語言（指中文或英文等語言）。

6.6.4　Content-Length

Content-Length: 15000
首部字段 Content-Length 表明了實體主體部分的大小（單位是字節）。對實體主體進行內容編碼傳輸時，不 能再使用 Content-Length 首部字段。由於實體主體大小的計算方法略微複雜，所以在此不再展開。

6.6.5　　Content-Location

1	Content-Location: http://www.hackr.jp/index-ja.html​

首部字段 Content-Location 給出與報文主體部分相對應的 URI。和首部字段 Location 不同，ContentLocation 表示的是報文主體返回資源對應的 URI。

比如，對於使用首部字段 Accept-Language 的服務器驅動型請求，當返回的頁面內容與實際請求的對象不同 時，首部字段 Content-Location 內會寫明 URI。（訪問 http://www.hackr.jp/ 返回的對象卻是 http://www.hackr.jp/index-ja.html 等類似情況）

6.6.6　Content-MD5

Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在於檢查報文主體在傳輸過程中是否保持完 整，以及確認傳輸到達。

6.6.7　　Content-Range

Content-Range: bytes 5001-10000/10000
針對範圍請求，返回響應時使用的首部字段 Content-Range，能告知客戶端作爲響應返回的實體的哪個部分 符合範圍請求。字段值以字節爲單位，表示當前發送部分及整個實體大小。

6.6.8　　Content-Type

Content-Type: text/html; charset=UTF-8
首部字段 Content-Type 說明了實體主體內對象的媒體類型。和首部字段 Accept 一樣，字段值用 type/subtype 形式賦值。
參數 charset 使用 iso-8859-1 或 euc-jp 等字符集進行賦值。

6.6.9　　Expires

Expires: Wed, 04 Jul 2012 08:26:05 GMT

首部字段 Expires 會將資源失效的日期告知客戶端。緩存服務器在接收到含有首部字段 Expires 的響應後，會以緩存來應答請求，在 Expires 字段值指定的時間之前，響應的副本會一直被保存。當超過指定的時間後， 緩存服務器在請求發送過來時，會轉向源服務器請求資源。

6.6.10　　Last-Modified

Last-Modified: Wed, 23 May 2012 09:59:55 GMT
首部字段 Last-Modified 指明資源最終修改的時間。一般來說，這個值就是 Request-URI 指定資源被修改的 時間。但類似使用 CGI 腳本進行動態數據處理時，該值有可能會變成數據最終修改時的時間。

ppt 121頁

6.7　爲 Cookie 服務的首部字段  

ppt 125頁

管理服務器與客戶端之間狀態的 Cookie，雖然沒有被編入標準化 HTTP/1.1 的 RFC2616 中，但在 Web 網 站方面得到了廣泛的應用。
Cookie 的工作機制是用戶識別及狀態管理。Web 網站爲了管理用戶的狀態會通過 Web 瀏覽器，把一些數據 臨時寫入用戶的計算機內。接着當用戶訪問該Web網站時，可通過通信方式取回之前發放的 Cookie。

下面的表格內列舉了與 Cookie 有關的首部字段。

表 6-8：爲 Cookie 服務的首部字段

首部字段名                 說明                                                 首部類型
Set-Cookie                開始狀態管理所使用的Cookie信息     響應首部字段
Cookie                      服務器接收到的Cookie信息                請求首部字段

6.7.1　　Set-Cookie

1	Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path=/; domain=.hackr.jp;​

當服務器準備開始管理客戶端的狀態時，會事先告知各種信息。
下面的表格列舉了 Set-Cookie 的字段值。

表 6-9：：Set-Cookie 字段的屬性
屬性                                說明
NAME=VALUE               賦予 Cookie 的名稱和其值（必需項）
expires=DATE               Cookie的有效期（若不明確指定則默認爲瀏覽器關閉前爲止）
path=PATH                   將服務器上的文件目錄作爲Cookie的適用對象（若不指定則默認爲文檔 所在的文件目錄）
domain=域名                作爲 Cookie 適用對象的域名 （若不指定則默認爲創建 Cookie 的服務 器的域名）
Secure                           僅在 HTTPS 安全通信時纔會發送 Cookie
HttpOnly                       加以限制，使 Cookie 不能被 JavaScript 腳本訪問

expires 屬性

Cookie 的 expires 屬性指定瀏覽器可發送 Cookie 的有效期。
當省略 expires 屬性時，其有效期僅限於維持瀏覽器會話（Session）時間段內。這通常限於瀏覽器應用程序被關閉之前。
另外，一旦 Cookie 從服務器端發送至客戶端，服務器端就不存在可以顯式刪除 Cookie 的方法。但可通過覆蓋已過期的 Cookie，實現對客戶端 Cookie 的實質性刪除操作。

6.7.2　　Cookie

Cookie: status=enable

首部字段 Cookie 會告知服務器，當客戶端想獲得 HTTP 狀態管理支持時，就會在請求中包含從服務器接收到的 Cookie。接收到多個 Cookie 時，同樣可以以多個 Cookie 形式發送。

6.8　其他首部字段

HTTP 首部字段是可以自行擴展的。所以在 Web 服務器和瀏覽器的應用上，會出現各種非標準的首部字段。
接下來，我們就一些最爲常用的首部字段進行說明。

• X-Frame-Options
• X-XSS-Protection
• DNT
• P3P

上面字段的詳細說明去看ppt128頁

轉自：http://www.cnblogs.com/jycboy/archive/2017/02/17/http_head.html