摘要：源服務(wù)器以后也將不再對(duì)緩存服務(wù)器請(qǐng)求中提出的資源有效性進(jìn)行確認(rèn)，且禁止其對(duì)響應(yīng)資源進(jìn)行緩存操作。換言之，該指令要求緩存服務(wù)器不重新加載響應(yīng)，也不會(huì)再次確認(rèn)資源有效性。若發(fā)生請(qǐng)求緩存服務(wù)器的本地緩存無(wú)響應(yīng)，則返回狀態(tài)碼。

一.　HTTP 報(bào)文首部

1.HTTP 報(bào)文的結(jié)構(gòu):

2.HTTP 請(qǐng)求報(bào)文

圖示：

舉例子：

3.HTTP 響應(yīng)報(bào)文：

下面的示例是訪問(wèn) http://hackr.jp 時(shí)，請(qǐng)求報(bào)文的首部信息：

以下示例是之前請(qǐng)求訪問(wèn) http://hackr.jp/ 時(shí)，返回的響應(yīng)報(bào)文的首部信息：

在報(bào)文眾多的字段當(dāng)中，HTTP 首部字段包含的信息最為豐富。首部字段同時(shí)存在于請(qǐng)求和響應(yīng)報(bào)文內(nèi)，并涵蓋 HTTP 報(bào)文相關(guān)的內(nèi)容信息。

二.　HTTP 首部字段

1.HTTP 首部字段傳遞重要信息:

HTTP 首部字段是構(gòu)成 HTTP 報(bào)文的要素之一。在客戶端與服務(wù)器之間以 HTTP 協(xié)議進(jìn)行通信的過(guò)程中，無(wú)論是請(qǐng)求還是響應(yīng)都會(huì)使用首部字段，它能起到傳遞額外重要信息的作用。使用首部字段是為了給瀏覽器和服務(wù)器提供報(bào)文主體大小、所使用的 語(yǔ)言、認(rèn)證信息等內(nèi)容。

圖：首部字段內(nèi)可使用的附加信息較多

2.HTTP 首部字段結(jié)構(gòu) :

HTTP 首部字段是由首部字段名和字段值構(gòu)成的，中間用冒號(hào)“:” 分 隔。

例如，在 HTTP 首部中以 Content-Type 這個(gè)字段來(lái)表示報(bào)文主體的對(duì)象類型。

就以上述示例來(lái)看，首部字段名為 Content-Type，字符串 text/html 是 字段值。

另外，字段值對(duì)應(yīng)單個(gè) HTTP 首部字段可以有多個(gè)值，如下所示。

注意：若 HTTP 首部字段重復(fù)了會(huì)如何當(dāng) HTTP 報(bào)文首部中出現(xiàn)了兩個(gè)或兩個(gè)以上具有相同首部字段名時(shí)會(huì)怎么樣？這種情況在規(guī)范內(nèi)尚未明確，根據(jù)瀏覽器內(nèi)部處理邏輯的不同，結(jié)果可能并不一致。有些瀏覽器會(huì)優(yōu)先處理第一次出現(xiàn)的首部字段，而有些則會(huì)優(yōu)先處理最后出現(xiàn)的首部字段。

3.4 種 HTTP 首部字段類型:
HTTP 首部字段根據(jù)實(shí)際用途被分為以下 4 種類型。

通用首部字段（General Header Fields）

請(qǐng)求報(bào)文和響應(yīng)報(bào)文兩方都會(huì)使用的首部。

請(qǐng)求首部字段（Request Header Fields）

從客戶端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部。補(bǔ)充了請(qǐng)求的附加內(nèi)容、客戶端信息、響應(yīng)內(nèi)容相關(guān)優(yōu)先級(jí)等信息。

響應(yīng)首部字段（Response Header Fields）

從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容，也會(huì)要求客戶端附加額外的內(nèi)容信息。

實(shí)體首部字段（Entity Header Fields）

針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部。補(bǔ)充了資源內(nèi)容更新時(shí)間等與實(shí)體有關(guān)的信息。

4.HTTP/1.1 首部字段一覽

HTTP/1.1 規(guī)范定義了如下 47 種首部字段。

通用首部字段

請(qǐng)求首部字段

響應(yīng)首部字段

實(shí)體首部字段

5.非 HTTP/1.1 首部字段

在 HTTP 協(xié)議通信交互中使用到的首部字段，不限于 RFC2616 中定義的 47 種首部字段。還有 Cookie、Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段，它們的使用頻率也很高。 這些非正式的首部字段統(tǒng)一歸納在 RFC4229 HTTP Header Field Registrations 中。 6.2.6　End-to-end 首部和 Hop-by-hop 首部 HTTP 首部字段將定義成緩存代理和非緩存代理的行為，分成 2 種類型。

端到端首部（End-to-end Header） 分在此類別中的首部會(huì)轉(zhuǎn)發(fā)給請(qǐng)求 / 響應(yīng)對(duì)應(yīng)的最終接收目標(biāo)，且必須保存在由緩存生成的響應(yīng)中，另外規(guī)定它必須被轉(zhuǎn)發(fā)。
逐跳首部（Hop-by-hop Header）
分在此類別中的首部只對(duì)單次轉(zhuǎn)發(fā)有效，會(huì)因通過(guò)緩存或代理而不再轉(zhuǎn)發(fā)。HTTP/1.1 和之后版本中，如果要使用 hop-by-hop 首部，需提供 Connection 首部字段。
下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個(gè)首部字段之外， 其他所有字段都屬于端到端首部。
注意：下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個(gè)首部字段之外， 其他所有字段都屬于端到端首部。
Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
Trailer
TE
Transfer-Encoding
Upgrade

三.HTTP/1.1 通用首部字段
1.Cache-Control 通過(guò)指定首部字段 ,Cache-Control 的指令，就能操作緩存的工作機(jī)制。

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

指令的參數(shù)是可選的，多個(gè)指令之間通過(guò)“,”分隔。首部字段 CacheControl 的指令可用于請(qǐng)求及響應(yīng)時(shí)。

Cache-Control 指令一覽

緩存請(qǐng)求指令：

緩存響應(yīng)指令：

表示是否能緩存的指令：
public 指令

當(dāng)指定使用 public 指令時(shí)，則明確表明其他用戶也可利用緩存。

private 指令

no-cache 指令

客戶端發(fā)送的請(qǐng)求中如果包含 no-cache 指令，則表示客戶端將不會(huì)接收緩存過(guò)的響應(yīng)。于是，“中間”的緩存服務(wù)器必須把客戶端請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器。如果服務(wù)器返回的響應(yīng)中包含 no-cache 指令，那么緩存服務(wù)器不能對(duì)資源進(jìn)行緩存。源服務(wù)器以后也將不再對(duì)緩存服務(wù)器請(qǐng)求中提出的資源有效性進(jìn)行確認(rèn)，且禁止其對(duì)響應(yīng)資源進(jìn)行緩存操作。

由服務(wù)器返回的響應(yīng)中，若報(bào)文首部字段 Cache-Control 中對(duì) no-cache 字段名具體指定參數(shù)值，那么客戶端在接收到這個(gè)被指定參數(shù)值的首部字段對(duì)應(yīng)的響應(yīng)報(bào)文后，就不能使用緩存。換言之，無(wú)參數(shù)值的首部字段可以使用緩存。只能在響應(yīng)指令中指定該參數(shù)。

控制可執(zhí)行緩存的對(duì)象的指令：

no-store 指令

當(dāng)使用 no-store 指令（從字面意思上很容易把 no-cache 誤解成為不緩存，但事實(shí)上 no-cache 代表不緩存過(guò)期的資源，緩存會(huì)向源服務(wù)器進(jìn)行有效期確認(rèn)后處理資源，也許稱為 do-notserve-from-cache-without-revalidation 更合適。no-store 才是真正地不進(jìn)行緩存，請(qǐng)讀者注意區(qū)別理解。） 時(shí)，暗示請(qǐng)求（和對(duì)應(yīng)的響應(yīng)）或響應(yīng)中包含機(jī)密信息。因此，該指令規(guī)定緩存不能在本地存儲(chǔ)請(qǐng)求或響應(yīng)的任一部分。

指定緩存期限和認(rèn)證的指令：

s-maxage 指令

s-maxage 指令的功能和 max-age 指令的相同，它們的不同點(diǎn)是 smaxage 指令只適用于供多位用戶使用的公共緩存服務(wù)器（這里一般指代理） 。也就是說(shuō)，對(duì)于向同一用戶重復(fù)返回響應(yīng)的服務(wù)器來(lái)說(shuō)，這個(gè)指令沒(méi)有任何作用。另外，當(dāng)使用 s-maxage 指令后，則直接忽略對(duì) Expires 首部字段及 max-age 指令的處理。

max-age 指令

當(dāng)客戶端發(fā)送的請(qǐng)求中包含 max-age 指令時(shí)，如果判定緩存資源的緩存時(shí)間數(shù)值比指定時(shí)間的數(shù)值更小，那么客戶端就接收緩存的資源。 另外，當(dāng)指定 max-age 值為 0，那么緩存服務(wù)器通常需要將請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器。當(dāng)服務(wù)器返回的響應(yīng)中包含 max-age 指令時(shí)，緩存服務(wù)器將不對(duì)資源的有效性再作確認(rèn)，而 max-age 數(shù)值代表資源保存為緩存的最長(zhǎng)時(shí)間。應(yīng)用 HTTP/1.1 版本的緩存服務(wù)器遇到同時(shí)存在 Expires 首部字段的情況時(shí)，會(huì)優(yōu)先處理 max-age 指令，而忽略掉 Expires 首部字段。而 HTTP/1.0 版本的緩存服務(wù)器的情況卻相反，max-age 指令會(huì)被忽略。

min-fresh 指令

min-fresh 指令要求緩存服務(wù)器返回至少還未過(guò)指定時(shí)間的緩存資源。 比如，當(dāng)指定 min-fresh 為 60 秒后，過(guò)了 60 秒的資源都無(wú)法作為響應(yīng)返回了。

max-stale 指令

使用 max-stale 可指示緩存資源，即使過(guò)期也照常接收。如果指令未指定參數(shù)值，那么無(wú)論經(jīng)過(guò)多久，客戶端都會(huì)接收響應(yīng)； 如果指令中指定了具體數(shù)值，那么即使過(guò)期，只要仍處于 max-stale 指定的時(shí)間內(nèi)，仍舊會(huì)被客戶端接收。

only-if-cached 指令

使用 only-if-cached 指令表示客戶端僅在緩存服務(wù)器本地緩存目標(biāo)資源的情況下才會(huì)要求其返回。換言之，該指令要求緩存服務(wù)器不重新加載響應(yīng)，也不會(huì)再次確認(rèn)資源有效性。若發(fā)生請(qǐng)求緩存服務(wù)器的本地緩存無(wú)響應(yīng)，則返回狀態(tài)碼 504 Gateway Timeout。

must-revalidate 指令

使用 must-revalidate 指令，代理會(huì)向源服務(wù)器再次驗(yàn)證即將返回的響應(yīng)緩存目前是否仍然有效。若代理無(wú)法連通源服務(wù)器再次獲取有效資源的話，緩存必須給客戶端 一條 504（Gateway Timeout）狀態(tài)碼。 另外，使用 must-revalidate 指令會(huì)忽略請(qǐng)求的 max-stale 指令（即使已經(jīng)在首部使用了 max-stale，也不會(huì)再有效果）。

proxy-revalidate 指令

proxy-revalidate 指令要求所有的緩存服務(wù)器在接收到客戶端帶有該指令的請(qǐng)求返回響應(yīng)之前，必須再次驗(yàn)證緩存的有效性。

no-transform 指令

使用 no-transform 指令規(guī)定無(wú)論是在請(qǐng)求還是響應(yīng)中，緩存都不能改變實(shí)體主體的媒體類型。
這樣做可防止緩存或代理壓縮圖片等類似操作。

Cache-Control 擴(kuò)展
cache-extension token

通過(guò) cache-extension 標(biāo)記（token），可以擴(kuò)展 Cache-Control 首部字段內(nèi)的指令。
如上例，Cache-Control 首部字段本身沒(méi)有 community 這個(gè)指令。借助 extension tokens 實(shí)現(xiàn)了該指令的添加。如果緩存服務(wù)器不能理解 community 這個(gè)新指令，就會(huì)直接忽略。因此，extension tokens 僅對(duì)能理解它的緩存服務(wù)器來(lái)說(shuō)是有意義的。

2.Connection

Connection 首部字段具備如下兩個(gè)作用：
　

控制不再轉(zhuǎn)發(fā)給代理的首部字段

在客戶端發(fā)送請(qǐng)求和服務(wù)器返回響應(yīng)內(nèi)，使用 Connection 首部字段，可控制不再轉(zhuǎn)發(fā)給代理的首部字段（即 Hop-by-hop 首 部）

管理持久連接

HTTP/1.1 版本的默認(rèn)連接都是持久連接。為此，客戶端會(huì)在持久連接上連續(xù)發(fā)送請(qǐng)求。當(dāng)服務(wù)器端想明確斷開(kāi)連接時(shí)，則指定 Connection 首部字段的值為 Close。

HTTP/1.1 之前的 HTTP 版本的默認(rèn)連接都是非持久連接。為此，如果想在舊版本的 HTTP 協(xié)議上維持持續(xù)連接，則需要指定 Connection 首部字段的值為 Keep-Alive。
如上圖①所示，客戶端發(fā)送請(qǐng)求給服務(wù)器時(shí)，服務(wù)器端會(huì)像上圖 ②那樣加上首部字段 Keep-Alive 及首部字段 Connection 后返回響應(yīng)。

3.Date

首部字段 Date 表明創(chuàng)建 HTTP 報(bào)文的日期和時(shí)間。

HTTP/1.1 協(xié)議使用在 RFC1123 中規(guī)定的日期時(shí)間的格式，如下示例：

之前的 HTTP 協(xié)議版本中使用在 RFC850 中定義的格式，如下所示：

除此之外，還有一種格式。它與 C 標(biāo)準(zhǔn)庫(kù)內(nèi)的 asctime() 函數(shù)的輸出格式一致：

4.Pragma

Pragma 是 HTTP/1.1 之前版本的歷史遺留字段，僅作為與 HTTP/1.0 的向后兼容而定義。

規(guī)范定義的形式唯一，如下所示。

該首部字段屬于通用首部字段，但只用在客戶端發(fā)送的請(qǐng)求中。客戶端會(huì)要求所有的中間服務(wù)器不返回緩存的資源。

所有的中間服務(wù)器如果都能以 HTTP/1.1 為基準(zhǔn)，那直接采用 CacheControl: no-cache 指定緩存的處理方式是最為理想的。但要整體掌握全部中間服務(wù)器使用的 HTTP 協(xié)議版本卻是不現(xiàn)實(shí)的。因此，發(fā)送的 請(qǐng)求會(huì)同時(shí)含有下面兩個(gè)首部字段。

5.Trailer

首部字段 Trailer 會(huì)事先說(shuō)明在報(bào)文主體后記錄了哪些首部字段。該首部字段可應(yīng)用在 HTTP/1.1 版本分塊傳輸編碼時(shí)。

以上用例中，指定首部字段 Trailer 的值為 Expires，在報(bào)文主體之后（分塊長(zhǎng)度 0 之后）出現(xiàn)了首部字段 Expires。

6.Transfer-Encoding

首部字段 Transfer-Encoding 規(guī)定了傳輸報(bào)文主體時(shí)采用的編碼方式。 HTTP/1.1 的傳輸編碼方式僅對(duì)分塊傳輸編碼有效。

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

7.Upgrade

首部字段 Upgrade 用于檢測(cè) HTTP 協(xié)議及其他協(xié)議是否可使用更高的版本進(jìn)行通信，其參數(shù)值可以用來(lái)指定一個(gè)完全不同的通信協(xié)議。

上圖用例中，首部字段 Upgrade 指定的值為 TLS/1.0。請(qǐng)注意此處兩個(gè)字段首部字段的對(duì)應(yīng)關(guān)系，Connection 的值被指定為 Upgrade。 Upgrade 首部字段產(chǎn)生作用的 Upgrade 對(duì)象僅限于客戶端和鄰接服務(wù)器之間。因此，使用首部字段 Upgrade 時(shí)，還需要額外指定 Connection:Upgrade。 對(duì)于附有首部字段 Upgrade 的請(qǐng)求，服務(wù)器可用 101 Switching Protocols 狀態(tài)碼作為響應(yīng)返回。

8.Via

使用首部字段 Via 是為了追蹤客戶端與服務(wù)器之間的請(qǐng)求和響應(yīng)報(bào)文的傳輸路徑。報(bào)文經(jīng)過(guò)代理或網(wǎng)關(guān)時(shí)，會(huì)先在首部字段 Via 中附加該服務(wù)器的信息，然后再進(jìn)行轉(zhuǎn)發(fā)。這個(gè)做法和 traceroute 及電子郵件的 Received 首部的工作機(jī)制很類似。首部字段 Via 不僅用于追蹤報(bào)文的轉(zhuǎn)發(fā)，還可避免請(qǐng)求回環(huán)的發(fā)生。 所以必須在經(jīng)過(guò)代理時(shí)附加該首部字段內(nèi)容。

上圖用例中，在經(jīng)過(guò)代理服務(wù)器 A 時(shí)，Via 首部附加了“1.0 gw.hackr.jp (Squid/3.1)”這樣的字符串值。行頭的 1.0 是指接收請(qǐng)求的服務(wù)器上應(yīng)用的 HTTP 協(xié)議版本。接下來(lái)經(jīng)過(guò)代理服務(wù)器 B 時(shí)亦是如此，在 Via 首部附加服務(wù)器信息，也可增加 1 個(gè)新的 Via 首部寫(xiě)入服務(wù)器信息。Via 首部是為了追蹤傳輸路徑，所以經(jīng)常會(huì)和 TRACE 方法一起使 用。比如，代理服務(wù)器接收到由 TRACE 方法發(fā)送過(guò)來(lái)的請(qǐng)求（其中 Max-Forwards: 0）時(shí)，代理服務(wù)器就不能再轉(zhuǎn)發(fā)該請(qǐng)求了。這種情況下，代理服務(wù)器會(huì)將自身的信息附加到 Via 首部后，返回該請(qǐng)求的響應(yīng)。
9.Warning

HTTP/1.1 的 Warning 首部是從 HTTP/1.0 的響應(yīng)首部（Retry-After）演變過(guò)來(lái)的。該首部通常會(huì)告知用戶一些與緩存相關(guān)的問(wèn)題的警告。

Warning 首部的格式如下。最后的日期時(shí)間部分可省略。

HTTP/1.1 中定義了 7 種警告。警告碼對(duì)應(yīng)的警告內(nèi)容僅推薦參考。 另外，警告碼具備擴(kuò)展性，今后有可能追加新的警告碼。

四.請(qǐng)求首部字段

請(qǐng)求首部字段是從客戶端往服務(wù)器端發(fā)送請(qǐng)求報(bào)文中所使用的字段， 用于補(bǔ)充請(qǐng)求的附加信息、客戶端信息、對(duì)響應(yīng)內(nèi)容相關(guān)的優(yōu)先級(jí)等內(nèi)容。

1.　Accept

Accept 首部字段可通知服務(wù)器，用戶代理能夠處理的媒體類型及媒體類型的相對(duì)優(yōu)先級(jí)?？墒褂?type/subtype 這種形式，一次指定多種媒體類型

文本文件
text/html, text/plain, text/css ... application/xhtml+xml, application/xml ...
圖片文件
image/jpeg, image/gif, image/png ...
視頻文件
video/mpeg, video/quicktime ...
應(yīng)用程序使用的二進(jìn)制文件
application/octet-stream, application/zip ...

若想要給顯示的媒體類型增加優(yōu)先級(jí)，則使用 q= 來(lái)額外表示權(quán)重值 (原文是“品質(zhì)係數(shù)”。在 RFC2616 定義中，此處的 q 是指 qvalue，即 quality factor。直譯的話就是質(zhì)量數(shù)，但經(jīng)過(guò)綜合考慮理解記憶的便利性后，似乎采用權(quán) 重值更為穩(wěn)妥。)，用分號(hào)（;）進(jìn)行分隔。權(quán)重值 q 的范圍是 0~1（可精確到小數(shù)點(diǎn)后 3 位），且 1 為最大值。不指定權(quán)重 q 值時(shí)，默認(rèn)權(quán)重為 q=1.0。當(dāng)服務(wù)器提供多種內(nèi)容時(shí)，將會(huì)首先返回權(quán)重值最高的媒體類型。

2.Accept-Charset

Accept-Charset 首部字段可用來(lái)通知服務(wù)器用戶代理支持的字符集及字符集的相對(duì)優(yōu)先順序。另外，可一次性指定多種字符集。與首部字段 Accept 相同的是可用權(quán)重 q 值來(lái)表示相對(duì)優(yōu)先級(jí)。該首部字段應(yīng)用于內(nèi)容協(xié)商機(jī)制的服務(wù)器驅(qū)動(dòng)協(xié)商。

3.Accept-Encoding

Accept-Encoding 首部字段用來(lái)告知服務(wù)器用戶代理支持的內(nèi)容編碼及內(nèi)容編碼的優(yōu)先級(jí)順序?？梢淮涡灾付ǘ喾N內(nèi)容編碼。

下面試舉出幾個(gè)內(nèi)容編碼的例子。

gzip
由文件壓縮程序 gzip（GNU zip）生成的編碼格式 （RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循環(huán)冗余校驗(yàn)（Cyclic Redundancy Check，通稱 CRC）。
compress
由 UNIX 文件壓縮程序 compress 生成的編碼格式，采用 LempelZiv-Welch 算法（LZW）。 deflate
組合使用 zlib 格式（RFC1950）及由 deflate 壓縮算法 （RFC1951）生成的編碼格式。 identity
不執(zhí)行壓縮或不會(huì)變化的默認(rèn)編碼格式

采用權(quán)重 q 值來(lái)表示相對(duì)優(yōu)先級(jí)，這點(diǎn)與首部字段 Accept 相同。另外，也可使用星號(hào)（*）作為通配符，指定任意的編碼格式。

4.Accept-Language

首部字段 Accept-Language 用來(lái)告知服務(wù)器用戶代理能夠處理的自然語(yǔ)言集（指中文或英文等），以及自然語(yǔ)言集的相對(duì)優(yōu)先級(jí)?？梢淮沃付ǘ喾N自然語(yǔ)言集。和 Accept 首部字段一樣，按權(quán)重值 q 來(lái)表示相對(duì)優(yōu)先級(jí)。在上述圖例中，客戶端在服務(wù)器有中文版資源的情況下，會(huì)請(qǐng)求其返回中文版對(duì)應(yīng)的響應(yīng)，沒(méi)有中文版時(shí)，則請(qǐng)求返回英文版響應(yīng)。

5.Authorization

首部字段 Authorization 是用來(lái)告知服務(wù)器，用戶代理的認(rèn)證信息（證書(shū)值）。通常，想要通過(guò)服務(wù)器認(rèn)證的用戶代理會(huì)在接收到返回的 401 狀態(tài)碼響應(yīng)后，把首部字段 Authorization 加入請(qǐng)求中。共用緩存在接收到含有 Authorization 首部字段的請(qǐng)求時(shí)的操作處理會(huì)略有差異。

6.Expect

客戶端使用首部字段 Expect 來(lái)告知服務(wù)器，期望出現(xiàn)的某種特定行為。因服務(wù)器無(wú)法理解客戶端的期望作出回應(yīng)而發(fā)生錯(cuò)誤時(shí)，會(huì)返回狀態(tài)碼 417 Expectation Failed?？蛻舳丝梢岳迷撌撞孔侄危瑢?xiě)明所期望的擴(kuò)展。雖然 HTTP/1.1 規(guī)范只定義了 100-continue（狀態(tài)碼 100 Continue 之意）。等待狀態(tài)碼 100 響應(yīng)的客戶端在發(fā)生請(qǐng)求時(shí)，需要指定 Expect:100continue。

7.From

首部字段 From 用來(lái)告知服務(wù)器使用用戶代理的用戶的電子郵件地址。通常，其使用目的就是為了顯示搜索引擎等用戶代理的負(fù)責(zé)人的電子郵件聯(lián)系方式。使用代理時(shí)，應(yīng)盡可能包含 From 首部字段（但可能會(huì)因代理不同，將電子郵件地址記錄在 User-Agent 首部字段內(nèi)）。

8.　Host

首部字段 Host 會(huì)告知服務(wù)器，請(qǐng)求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號(hào)。Host 首部字段在 HTTP/1.1 規(guī)范內(nèi)是唯一一個(gè)必須被包含在請(qǐng)求內(nèi)的首部字段。首部字段 Host 和以單臺(tái)服務(wù)器分配多個(gè)域名的虛擬主機(jī)的工作機(jī)制有很密切的關(guān)聯(lián)，這是首部字段 Host 必須存在的意義。 請(qǐng)求被發(fā)送至服務(wù)器時(shí)，請(qǐng)求中的主機(jī)名會(huì)用 IP 地址直接替換解決。但如果這時(shí)，相同的 IP 地址下部署運(yùn)行著多個(gè)域名，那么服務(wù)器就會(huì)無(wú)法理解究竟是哪個(gè)域名對(duì)應(yīng)的請(qǐng)求。因此，就需要使用首部字段 Host 來(lái)明確指出請(qǐng)求的主機(jī)名。若服務(wù)器未設(shè)定主機(jī)名，那直接發(fā)送一個(gè)空值即可。如下所示:

9.If-Match

形如 If-xxx 這種樣式的請(qǐng)求首部字段，都可稱為條件請(qǐng)求。服務(wù)器接收到附帶條件的請(qǐng)求后，只有判斷指定條件為真時(shí)，才會(huì)執(zhí)行請(qǐng)求。

首部字段 If-Match，屬附帶條件之一，它會(huì)告知服務(wù)器匹配資源所用的實(shí)體標(biāo)記（ETag）值。這時(shí)的服務(wù)器無(wú)法使用弱 ETag 值。服務(wù)器會(huì)比對(duì) If-Match 的字段值和資源的 ETag 值，僅當(dāng)兩者一致 時(shí)，才會(huì)執(zhí)行請(qǐng)求。反之，則返回狀態(tài)碼 412 Precondition Failed 的響 應(yīng)。還可以使用星號(hào)（*）指定 If-Match 的字段值。針對(duì)這種情況，服務(wù)器將會(huì)忽略 ETag 的值，只要資源存在就處理請(qǐng)求。

10.If-Modified-Since

首部字段 If-Modified-Since，屬附帶條件之一，它會(huì)告知服務(wù)器若 IfModified-Since 字段值早于資源的更新時(shí)間，則希望能處理該請(qǐng)求。 而在指定 If-Modified-Since 字段值的日期時(shí)間之后，如果請(qǐng)求的資源都沒(méi)有過(guò)更新，則返回狀態(tài)碼 304 Not Modified 的響應(yīng)。 If-Modified-Since 用于確認(rèn)代理或客戶端擁有的本地資源的有效性。 獲取資源的更新日期時(shí)間，可通過(guò)確認(rèn)首部字段 Last-Modified 來(lái)確定。

11.If-None-Match

圖：只有在 If-None-Match 的字段值與 ETag 值不一致時(shí)，可處理 該請(qǐng)求。與 If-Match 首部字段的作用相反 首部字段 If-None-Match 屬于附帶條件之一。它和首部字段 If-Match 作用相反。用于指定 If-None-Match 字段值的實(shí)體標(biāo)記（ETag）值與 請(qǐng)求資源的 ETag 不一致時(shí)，它就告知服務(wù)器處理該請(qǐng)求。 在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可獲取最新的資 源。因此，這與使用首部字段 If-Modified-Since 時(shí)有些類似。

12.If-Range

首部字段 If-Range 屬于附帶條件之一。它告知服務(wù)器若指定的 IfRange 字段值（ETag 值或者時(shí)間）和請(qǐng)求資源的 ETag 值或時(shí)間相一 致時(shí)，則作為范圍請(qǐng)求處理。反之，則返回全體資源。

下面我們思考一下不使用首部字段 If-Range 發(fā)送請(qǐng)求的情況。服務(wù)器端的資源如果更新，那客戶端持有資源中的一部分也會(huì)隨之無(wú)效，當(dāng)然，范圍請(qǐng)求作為前提是無(wú)效的。這時(shí)，服務(wù)器會(huì)暫且以狀態(tài)碼 412 Precondition Failed 作為響應(yīng)返回，其目的是催促客戶端再次發(fā)送請(qǐng) 求。這樣一來(lái)，與使用首部字段 If-Range 比起來(lái)，就需要花費(fèi)兩倍的功夫。

13.If-Unmodified-Since

首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相 反。它的作用的是告知服務(wù)器，指定的請(qǐng)求資源只有在字段值內(nèi)指定 的日期時(shí)間之后，未發(fā)生更新的情況下，才能處理請(qǐng)求。如果在指定 日期時(shí)間后發(fā)生了更新，則以狀態(tài)碼 412 Precondition Failed 作為響應(yīng) 返回

14.Max-Forwards

通過(guò) TRACE 方法或 OPTIONS 方法，發(fā)送包含首部字段 MaxForwards 的請(qǐng)求時(shí)，該字段以十進(jìn)制整數(shù)形式指定可經(jīng)過(guò)的服務(wù)器最大數(shù)目。服務(wù)器在往下一個(gè)服務(wù)器轉(zhuǎn)發(fā)請(qǐng)求之前，Max-Forwards 的值減 1 后重新賦值。當(dāng)服務(wù)器接收到 Max-Forwards 值為 0 的請(qǐng)求 時(shí)，則不再進(jìn)行轉(zhuǎn)發(fā)，而是直接返回響應(yīng)。使用 HTTP 協(xié)議通信時(shí)，請(qǐng)求可能會(huì)經(jīng)過(guò)代理等多臺(tái)服務(wù)器。途中，如果代理服務(wù)器由于某些原因?qū)е抡?qǐng)求轉(zhuǎn)發(fā)失敗，客戶端也就等不到服務(wù)器返回的響應(yīng)了。對(duì)此，我們無(wú)從可知?？梢造`活使用首部字段 Max-Forwards，針對(duì)以上問(wèn)題產(chǎn)生的原因展開(kāi)調(diào)查。由于當(dāng) Max-Forwards 字段值為 0 時(shí)，服務(wù)器就會(huì)立即返回響應(yīng)，由此我們至少可以對(duì)以那臺(tái)服務(wù)器為終點(diǎn)的傳輸路徑的通信狀況有所把握。

15.Proxy-Authorization

接收到從代理服務(wù)器發(fā)來(lái)的認(rèn)證質(zhì)詢時(shí)，客戶端會(huì)發(fā)送包含首部字段 Proxy-Authorization 的請(qǐng)求，以告知服務(wù)器認(rèn)證所需要的信息。 這個(gè)行為是與客戶端和服務(wù)器之間的 HTTP 訪問(wèn)認(rèn)證相類似的，不同之處在于，認(rèn)證行為發(fā)生在客戶端與代理之間?？蛻舳伺c服務(wù)器之間的認(rèn)證，使用首部字段 Authorization 可起到相同作用。

16.Range

對(duì)于只需獲取部分資源的范圍請(qǐng)求，包含首部字段 Range 即可告知服務(wù)器資源的指定范圍。上面的示例表示請(qǐng)求獲取從第 5001 字節(jié)至第 10000 字節(jié)的資源。接收到附帶 Range 首部字段請(qǐng)求的服務(wù)器，會(huì)在處理請(qǐng)求之后返回狀態(tài)碼為 206 Partial Content 的響應(yīng)。無(wú)法處理該范圍請(qǐng)求時(shí)，則會(huì)返回狀態(tài)碼 200 OK 的響應(yīng)及全部資源。

17.Referer

首部字段 Referer 會(huì)告知服務(wù)器請(qǐng)求的原始資源的 URI。 客戶端一般都會(huì)發(fā)送 Referer 首部字段給服務(wù)器。但當(dāng)直接在瀏覽器的地址欄輸入 URI，或出于安全性的考慮時(shí)，也可以不發(fā)送該首部字段。因?yàn)樵假Y源的 URI 中的查詢字符串可能含有 ID 和密碼等保密信息，要是寫(xiě)進(jìn) Referer 轉(zhuǎn)發(fā)給其他服務(wù)器，則有可能導(dǎo)致保密信息的泄露。另外，Referer 的正確的拼寫(xiě)應(yīng)該是 Referrer，但不知為何，大家一直沿用這個(gè)錯(cuò)誤的拼寫(xiě)。

18.TE

首部字段 TE 會(huì)告知服務(wù)器客戶端能夠處理響應(yīng)的傳輸編碼方式及相對(duì)優(yōu)先級(jí)。它和首部字段 Accept-Encoding 的功能很相像，但是用于傳輸編碼。首部字段 TE 除指定傳輸編碼之外，還可以指定伴隨 trailer 字段的分 塊傳輸編碼的方式。應(yīng)用后者時(shí)，只需把 trailers 賦值給該字段值。

19.User-Agent

首部字段 User-Agent 會(huì)將創(chuàng)建請(qǐng)求的瀏覽器和用戶代理名稱等信息傳達(dá)給服務(wù)器。由網(wǎng)絡(luò)爬蟲(chóng)發(fā)起請(qǐng)求時(shí)，有可能會(huì)在字段內(nèi)添加爬蟲(chóng)作者的電子郵件地址。此外，如果請(qǐng)求經(jīng)過(guò)代理，那么中間也很可能被添加上代理服務(wù)器的名稱。

五.響應(yīng)首部字段

響應(yīng)首部字段是由服務(wù)器端向客戶端返回響應(yīng)報(bào)文中所使用的字段， 用于補(bǔ)充響應(yīng)的附加信息、服務(wù)器信息，以及對(duì)客戶端的附加要求等信息。

1.Accept-Ranges

首部字段 Accept-Ranges 是用來(lái)告知客戶端服務(wù)器是否能處理范圍請(qǐng)求，以指定獲取服務(wù)器端某個(gè)部分的資源?？芍付ǖ淖侄沃涤袃煞N，可處理范圍請(qǐng)求時(shí)指定其為 bytes，反之則 指定其為 none。

2.Age

首部字段 Age 能告知客戶端，源服務(wù)器在多久前創(chuàng)建了響應(yīng)。字段值的單位為秒。

若創(chuàng)建該響應(yīng)的服務(wù)器是緩存服務(wù)器，Age 值是指緩存后的響應(yīng)再次發(fā)起認(rèn)證到認(rèn)證完成的時(shí)間值。代理創(chuàng)建響應(yīng)時(shí)必須加上首部字段 Age。

3.ETag

首部字段 ETag 能告知客戶端實(shí)體標(biāo)識(shí)。它是一種可將資源以字符串形式做唯一性標(biāo)識(shí)的方式。服務(wù)器會(huì)為每份資源分配對(duì)應(yīng)的 ETag 值。另外，當(dāng)資源更新時(shí)，ETag 值也需要更新。生成 ETag 值時(shí)，并沒(méi)有統(tǒng)一的算法規(guī)則，而僅僅是由服務(wù)器來(lái)分配。

資源被緩存時(shí)，就會(huì)被分配唯一性標(biāo)識(shí)。例如，當(dāng)使用中文版的瀏覽器訪問(wèn) http://www.google.com/ 時(shí)，就會(huì)返回中文版對(duì)應(yīng)的資源，而使用英文版的瀏覽器訪問(wèn)時(shí)，則會(huì)返回英文版對(duì)應(yīng)的資源。兩者的 URI 是相同的，所以僅憑 URI 指定緩存的資源是相當(dāng)困難的。若在下載過(guò)程中出現(xiàn)連接中斷、再連接的情況，都會(huì)依照 ETag 值來(lái)指定資 源。

強(qiáng) ETag 值和弱 Tag 值

強(qiáng) ETag 值不論實(shí)體發(fā)生多么細(xì)微的變化都會(huì)改變其值。

弱 ETag 值只用于提示資源是否相同。只有資源發(fā)生了根本改變，產(chǎn)生差異時(shí)才會(huì)改變 ETag 值。這時(shí)，會(huì)在字段值最開(kāi)始處附加 W/。

4.Location

使用首部字段 Location 可以將響應(yīng)接收方引導(dǎo)至某個(gè)與請(qǐng)求 URI 位置不同的資源?；旧希撟侄螘?huì)配合 3xx ：Redirection 的響應(yīng)，提供重定向的 URI。 幾乎所有的瀏覽器在接收到包含首部字段 Location 的響應(yīng)后，都會(huì)強(qiáng)制性地嘗試對(duì)已提示的重定向資源的訪問(wèn)。

5.Proxy-Authenticate

首部字段 Proxy-Authenticate 會(huì)把由代理服務(wù)器所要求的認(rèn)證信息發(fā)送給客戶端。

它與客戶端和服務(wù)器之間的 HTTP 訪問(wèn)認(rèn)證的行為相似，不同之處在于其認(rèn)證行為是在客戶端與代理之間進(jìn)行的。而客戶端與服務(wù)器之間 進(jìn)行認(rèn)證時(shí)，首部字段 WWW-Authorization 有著相同的作用。

6.Retry-After

首部字段 Retry-After 告知客戶端應(yīng)該在多久之后再次發(fā)送請(qǐng)求。主要配合狀態(tài)碼 503 Service Unavailable 響應(yīng)，或 3xx Redirect 響應(yīng)一起使用。

字段值可以指定為具體的日期時(shí)間（Wed, 04 Jul 2012 06：34：24 GMT 等格式），也可以是創(chuàng)建響應(yīng)后的秒數(shù)。

7.Server

首部字段 Server 告知客戶端當(dāng)前服務(wù)器上安裝的 HTTP 服務(wù)器應(yīng)用程序的信息。不單單會(huì)標(biāo)出服務(wù)器上的軟件應(yīng)用名稱，還有可能包括版本號(hào)和安裝時(shí)啟用的可選項(xiàng)。

8.Vary

圖：當(dāng)代理服務(wù)器接收到帶有 Vary 首部字段指定獲取資源的請(qǐng)求時(shí)，如果使用的Accept-Language 字段的值相同，那么就直接從緩存返回響應(yīng)。反之，則需要先從源服務(wù)器端獲取資源后才能作響應(yīng)返回。

首部字段 Vary 可對(duì)緩存進(jìn)行控制。源服務(wù)器會(huì)向代理服務(wù)器傳達(dá)關(guān)于本地緩存使用方法的命令。從代理服務(wù)器接收到源服務(wù)器返回包含 Vary 指定項(xiàng)的響應(yīng)之后，若再要進(jìn)行緩存，僅對(duì)請(qǐng)求中含有相同 Vary 指定首部字段的請(qǐng)求返回緩存。即使對(duì)相同資源發(fā)起請(qǐng)求，但由于 Vary 指定的首部字段不相同，因此必須要從源服務(wù)器重新獲取資源。

9.WWW-Authenticate

首部字段 WWW-Authenticate 用于 HTTP 訪問(wèn)認(rèn)證。它會(huì)告知客戶端適用于訪問(wèn)請(qǐng)求 URI 所指定資源的認(rèn)證方案（Basic 或是 Digest）和帶參數(shù)提示的質(zhì)詢（challenge）。狀態(tài)碼 401 Unauthorized 響應(yīng)中，肯定帶有首部字段 WWW-Authenticate。 上述示例中，realm 字段的字符串是為了辨別請(qǐng)求 URI 指定資源所受到的保護(hù)策略。

六.實(shí)體首部字段

實(shí)體首部字段是包含在請(qǐng)求報(bào)文和響應(yīng)報(bào)文中的實(shí)體部分所使用的首部，用于補(bǔ)充內(nèi)容的更新時(shí)間等與實(shí)體相關(guān)的信息。

1.Allow

首部字段 Allow 用于通知客戶端能夠支持 Request-URI 指定資源的所有 HTTP 方法。當(dāng)服務(wù)器接收到不支持的 HTTP 方法時(shí)，會(huì)以狀態(tài)碼 405 Method Not Allowed 作為響應(yīng)返回。與此同時(shí)，還會(huì)把所有能支持的 HTTP 方法寫(xiě)入首部字段 Allow 后返回。

2.Content-Encoding

首部字段 Content-Encoding 會(huì)告知客戶端服務(wù)器對(duì)實(shí)體的主體部分選用的內(nèi)容編碼方式。內(nèi)容編碼是指在不丟失實(shí)體信息的前提下所進(jìn)行的壓縮。

主要采用以下 4 種內(nèi)容編碼的方式。

gzip
compress
deflate
identity

3.Content-Language

首部字段 Content-Language 會(huì)告知客戶端，實(shí)體主體使用的自然語(yǔ)言（指中文或英文等語(yǔ)言）。

4.Content-Length

首部字段 Content-Length 表明了實(shí)體主體部分的大?。▎挝皇亲止?jié)）。對(duì)實(shí)體主體進(jìn)行內(nèi)容編碼傳輸時(shí)，不能再使用 Content-Length 首部字段。由于實(shí)體主體大小的計(jì)算方法略微復(fù)雜，所以在此不再展開(kāi)。

5.Content-Location

首部字段 Content-Location 給出與報(bào)文主體部分相對(duì)應(yīng)的 URI。和首部字段 Location 不同，Content-Location 表示的是報(bào)文主體返回資源對(duì)應(yīng)的 URI。 比如，對(duì)于使用首部字段 Accept-Language 的服務(wù)器驅(qū)動(dòng)型請(qǐng)求，當(dāng)返回的頁(yè)面內(nèi)容與實(shí)際請(qǐng)求的對(duì)象不同時(shí)，首部字段 Content-Location 內(nèi)會(huì)寫(xiě)明 URI。（訪問(wèn) http://www.hackr.jp/ 返回的對(duì)象卻是 http://www.hackr.jp/index-ja.... 等類似情況）

6.Content-MD5

首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在于檢查報(bào)文主體在傳輸過(guò)程中是否保持完整，以及確認(rèn)傳輸?shù)竭_(dá)。對(duì)報(bào)文主體執(zhí)行 MD5 算法獲得的 128 位二進(jìn)制數(shù)，再通過(guò) Base64 編碼后將結(jié)果寫(xiě)入 Content-MD5 字段值。由于 HTTP 首部無(wú)法記錄二進(jìn)制值，所以要通過(guò) Base64 編碼處理。為確保報(bào)文的有效性，作為接收方的客戶端會(huì)對(duì)報(bào)文主體再執(zhí)行一次相同的 MD5 算法。計(jì)算出的值與字段值作比較后，即可判斷出報(bào)文主體的準(zhǔn)確性。采用這種方法，對(duì)內(nèi)容上的偶發(fā)性改變是無(wú)從查證的，也無(wú)法檢測(cè)出惡意篡改。其中一個(gè)原因在于，內(nèi)容如果能夠被篡改，那么同時(shí)意味著 Content-MD5 也可重新計(jì)算然后被篡改。所以處在接收階段的客戶端是無(wú)法意識(shí)到報(bào)文主體以及首部字段 Content-MD5 是已經(jīng)被篡改過(guò)的。

7.Content-Range

針對(duì)范圍請(qǐng)求，返回響應(yīng)時(shí)使用的首部字段 Content-Range，能告知客戶端作為響應(yīng)返回的實(shí)體的哪個(gè)部分符合范圍請(qǐng)求。字段值以字節(jié)為單位，表示當(dāng)前發(fā)送部分及整個(gè)實(shí)體大小。

8.Content-Type

首部字段 Content-Type 說(shuō)明了實(shí)體主體內(nèi)對(duì)象的媒體類型。和首部字 段 Accept 一樣，字段值用 type/subtype 形式賦值。 參數(shù) charset 使用 iso-8859-1 或 euc-jp 等字符集進(jìn)行賦值。

9.Expires

首部字段 Expires 會(huì)將資源失效的日期告知客戶端。緩存服務(wù)器在接收到含有首部字段 Expires 的響應(yīng)后，會(huì)以緩存來(lái)應(yīng)答請(qǐng)求，在 Expires 字段值指定的時(shí)間之前，響應(yīng)的副本會(huì)一直被保存。當(dāng)超過(guò)指定的時(shí)間后，緩存服務(wù)器在請(qǐng)求發(fā)送過(guò)來(lái)時(shí)，會(huì)轉(zhuǎn)向源服務(wù)器請(qǐng)求 資源。源服務(wù)器不希望緩存服務(wù)器對(duì)資源緩存時(shí)，最好在 Expires 字段內(nèi)寫(xiě)入與首部字段 Date 相同的時(shí)間值。但是,當(dāng)首部字段 Cache-Control 有指定 max-age 指令時(shí)，比起首部字段 Expires，會(huì)優(yōu)先處理 max-age 指令。

10.Last-Modified

首部字段 Last-Modified 指明資源最終修改的時(shí)間。一般來(lái)說(shuō)，這個(gè)值就是 Request-URI 指定資源被修改的時(shí)間。但類似使用 CGI 腳本進(jìn)行動(dòng)態(tài)數(shù)據(jù)處理時(shí)，該值有可能會(huì)變成數(shù)據(jù)最終修改時(shí)的時(shí)間。

七.為 Cookie 服務(wù)的首部字段

管理服務(wù)器與客戶端之間狀態(tài)的 Cookie，雖然沒(méi)有被編入標(biāo)準(zhǔn)化 HTTP/1.1 的 RFC2616 中，但在 Web 網(wǎng)站方面得到了廣泛的應(yīng)用。 Cookie 的工作機(jī)制是用戶識(shí)別及狀態(tài)管理。Web 網(wǎng)站為了管理用戶的狀態(tài)會(huì)通過(guò) Web 瀏覽器，把一些數(shù)據(jù)臨時(shí)寫(xiě)入用戶的計(jì)算機(jī)內(nèi)。接著當(dāng)用戶訪問(wèn)該Web網(wǎng)站時(shí)，可通過(guò)通信方式取回之前發(fā)放的 Cookie。 調(diào)用 Cookie 時(shí)，由于可校驗(yàn) Cookie 的有效期，以及發(fā)送方的域、路徑、協(xié)議等信息，所以正規(guī)發(fā)布的 Cookie 內(nèi)的數(shù)據(jù)不會(huì)因來(lái)自其他 Web 站點(diǎn)和攻擊者的攻擊而泄露。

至 2013 年 5 月，Cookie 的規(guī)格標(biāo)準(zhǔn)文檔有以下 4 種。

RFC2109
某企業(yè)嘗試以獨(dú)立技術(shù)對(duì) Cookie 規(guī)格進(jìn)行標(biāo)準(zhǔn)化統(tǒng)籌。原本的意圖是想和網(wǎng)景公司制定的標(biāo)準(zhǔn)交互應(yīng)用，可惜發(fā)生了微妙的差異?，F(xiàn)在該標(biāo)準(zhǔn)已淡出了人們的視線。
RFC2965
為終結(jié) Internet Explorer 瀏覽器與 Netscape Navigator 的標(biāo)準(zhǔn)差異而導(dǎo)致的瀏覽器戰(zhàn)爭(zhēng)，RFC2965 內(nèi)定義了新的 HTTP 首部 Set-Cookie2 和 Cookie2?？墒聦?shí)上，它們幾乎沒(méi)怎么投入使用。
RFC6265
將網(wǎng)景公司制定的標(biāo)準(zhǔn)作為業(yè)界事實(shí)標(biāo)準(zhǔn)（De facto standard），重新定義 Cookie 標(biāo)準(zhǔn)后的產(chǎn)物。 目前使用最廣泛的 Cookie 標(biāo)準(zhǔn)卻不是 RFC 中定義的任何一個(gè)。而是在網(wǎng)景公司制定的標(biāo)準(zhǔn)上進(jìn)行擴(kuò)展后的產(chǎn)物。

下面的表格內(nèi)列舉了與 Cookie 有關(guān)的首部字段。

1.Set-Cookie

當(dāng)服務(wù)器準(zhǔn)備開(kāi)始管理客戶端的狀態(tài)時(shí)，會(huì)事先告知各種信息。下面的表格列舉了 Set-Cookie 的字段值。

表 6-9：Set-Cookie 字段的屬性

expires 屬性
Cookie 的 expires 屬性指定瀏覽器可發(fā)送 Cookie 的有效期。當(dāng)省略 expires 屬性時(shí)，其有效期僅限于維持瀏覽器會(huì)話（Session） 時(shí)間段內(nèi)。這通常限于瀏覽器應(yīng)用程序被關(guān)閉之前。另外，一旦Cookie從服務(wù)器端發(fā)送至客戶端，服務(wù)器端就不存在可以顯式刪除Cookie 的方法。但可通過(guò)覆蓋已過(guò)期的Cookie，實(shí)現(xiàn)對(duì) 客戶端 Cookie 的實(shí)質(zhì)性刪除操作。
path 屬性
Cookie 的 path 屬性可用于限制指定 Cookie 的發(fā)送范圍的文件目錄。不過(guò)另有辦法可避開(kāi)這項(xiàng)限制，看來(lái)對(duì)其作為安全機(jī)制的效果不能抱有期待。
domain 屬性
通過(guò) Cookie 的 domain 屬性指定的域名可做到與結(jié)尾匹配一致。比如，當(dāng)指定 example.com 后，除 example.com 以外，www.example.com 或 www2.example.com 等都可以發(fā)送 Cookie。因此，除了針對(duì)具體指定的多個(gè)域名發(fā)送 Cookie 之外，不指定 domain 屬性顯得更安全。
secure 屬性
Cookie 的 secure 屬性用于限制 Web 頁(yè)面僅在 HTTPS 安全連接時(shí)，才可以發(fā)送 Cookie。

發(fā)送 Cookie 時(shí)，指定 secure 屬性的方法如下所示。

以上例子僅當(dāng)在 https://www.example.com/（HTTPS）安全連接的情況下才會(huì)進(jìn)行 Cookie 的回收。也就是說(shuō)，即使域名相同， http://www.example.com/（HTTP）也不會(huì)發(fā)生 Cookie 回收行為。 當(dāng)省略 secure 屬性時(shí)，不論 HTTP 還是 HTTPS，都會(huì)對(duì) Cookie 進(jìn)行回收。
HttpOnly 屬性
Cookie 的 HttpOnly 屬性是 Cookie 的擴(kuò)展功能，它使 JavaScript 腳本 無(wú)法獲得 Cookie。其主要目的為防止跨站腳本攻擊（Cross-site scripting，XSS）對(duì) Cookie 的信息竊取。 發(fā)送指定 HttpOnly 屬性的 Cookie 的方法如下所示。

通過(guò)上述設(shè)置，通常從 Web 頁(yè)面內(nèi)還可以對(duì) Cookie 進(jìn)行讀取操作。 但使用 JavaScript 的 document.cookie 就無(wú)法讀取附加 HttpOnly 屬性后 的 Cookie 的內(nèi)容了。因此，也就無(wú)法在 XSS 中利用 JavaScript 劫持 Cookie 了。 雖然是獨(dú)立的擴(kuò)展功能，但 Internet Explorer 6 SP1 以上版本等當(dāng)下的主流瀏覽器都已經(jīng)支持該擴(kuò)展了。另外順帶一提，該擴(kuò)展并非是為了防止 XSS 而開(kāi)發(fā)的。

2.Cookie

首部字段 Cookie 會(huì)告知服務(wù)器，當(dāng)客戶端想獲得 HTTP 狀態(tài)管理支持時(shí)，就會(huì)在請(qǐng)求中包含從服務(wù)器接收到的 Cookie。接收到多個(gè) Cookie 時(shí)，同樣可以以多個(gè) Cookie 形式發(fā)送。

八.其他首部字段

HTTP 首部字段是可以自行擴(kuò)展的。所以在 Web 服務(wù)器和瀏覽器的應(yīng)用上，會(huì)出現(xiàn)各種非標(biāo)準(zhǔn)的首部字段。

接下來(lái)，我們就一些最為常用的首部字段進(jìn)行說(shuō)明。

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

1.X-Frame-Options

首部字段 X-Frame-Options 屬于 HTTP 響應(yīng)首部，用于控制網(wǎng)站內(nèi)容在其他 Web 網(wǎng)站的 Frame 標(biāo)簽內(nèi)的顯示問(wèn)題。其主要目的是為了防止點(diǎn)擊劫持（clickjacking）攻擊。 首部字段 X-Frame-Options 有以下兩個(gè)可指定的字段值。

DENY ：拒絕
SAMEORIGIN ：僅同源域名下的頁(yè)面（Top-level-browsingcontext）匹配時(shí)許可。（比如，當(dāng)指定 http://hackr.jp/sample.html 頁(yè)面為 SAMEORIGIN 時(shí)，那么 hackr.jp 上所有頁(yè)面的 frame 都被允許可加載該頁(yè)面，而 example.com 等其他域名的頁(yè)面就不行了）

支持該首部字段的瀏覽器有：Internet Explorer 8、Firefox 3.6.9+、 Chrome 4.1.249.1042+、Safari 4+ 和 Opera 10.50+ 等。現(xiàn)在主流的瀏覽器都已經(jīng)支持。

能在所有的 Web 服務(wù)器端預(yù)先設(shè)定好 X-Frame-Options 字段值是最理想的狀態(tài)。

對(duì) apache2.conf 的配置實(shí)例:

Header append X-FRAME-OPTIONS "SAMEORIGIN"

2.X-XSS-Protection

X-XSS-Protection: 1

首部字段 X-XSS-Protection 屬于 HTTP 響應(yīng)首部，它是針對(duì)跨站腳本攻擊（XSS）的一種對(duì)策，用于控制瀏覽器 XSS 防護(hù)機(jī)制的開(kāi)關(guān)。首部字段 X-XSS-Protection 可指定的字段值如下。

0 ：將 XSS 過(guò)濾設(shè)置成無(wú)效狀態(tài)
1 ：將 XSS 過(guò)濾設(shè)置成有效狀態(tài)

3.DNT

首部字段 DNT 屬于 HTTP 請(qǐng)求首部，其中 DNT 是 Do Not Track 的簡(jiǎn) 稱，意為拒絕個(gè)人信息被收集，是表示拒絕被精準(zhǔn)廣告追蹤的一種方法。

首部字段 DNT 可指定的字段值如下。

0 ：同意被追蹤
1 ：拒絕被追蹤
由于首部字段 DNT 的功能具備有效性，所以 Web 服務(wù)器需要對(duì) DNT 做對(duì)應(yīng)的支持。

4.P3P

首部字段 P3P 屬于 HTTP 相應(yīng)首部，通過(guò)利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺(tái)）技術(shù)，可以讓 Web 網(wǎng)站上 的個(gè)人隱私變成一種僅供程序可理解的形式，以達(dá)到保護(hù)用戶隱私的目的。要進(jìn)行 P3P 的設(shè)定，需按以下操作步驟進(jìn)行。

步驟 1：創(chuàng)建 P3P 隱私
步驟 2：創(chuàng)建 P3P 隱私對(duì)照文件后，保存命名在 /w3c/p3p.xml
步驟 3：從 P3P 隱私中新建 Compact policies 后，輸出到 HTTP 響應(yīng) 中

有關(guān) P3P 的詳細(xì)規(guī)范標(biāo)準(zhǔn)請(qǐng)參看下方鏈接。

The Platform for Privacy Preferences 1.0（P3P1.0）Specification http://www.w3.org/TR/P3P/

協(xié)議中對(duì) X- 前綴的廢除  在 HTTP 等多種協(xié)議中，通過(guò)給非標(biāo)準(zhǔn)參數(shù)加上前綴 X-，來(lái)區(qū)別。 于標(biāo)準(zhǔn)參數(shù)，并使那些非標(biāo)準(zhǔn)的參數(shù)作為擴(kuò)展變成可能。但是這種簡(jiǎn)單粗暴的做法有百害而無(wú)一益，因此在“RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols”中提議停止該做法。 
然而，對(duì)已經(jīng)在使用中的 X- 前綴來(lái)說(shuō)，不應(yīng)該要求其變更。

以下是往日學(xué)習(xí)總結(jié)，有需要的盆友可以去看看噢~~
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（1）：了解web和網(wǎng)絡(luò)基礎(chǔ)
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（2）：簡(jiǎn)單的HTTP協(xié)議
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（3）：HTTP 報(bào)文內(nèi)的 HTTP 信息
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（4）：返回結(jié)果的 HTTP 狀態(tài)碼
https://segmentfault.com/a/11...
TCP/IP基礎(chǔ)總結(jié)性學(xué)習(xí)（5）：與 HTTP 協(xié)作的 Web 服務(wù)器
https://segmentfault.com/a/11...