title: HTTP協(xié)議詳解（二）
date: 2018-05-18 18:16:47
tags:

HTTP頭部全羅列

HTTP報文結(jié)構(gòu)

HTTP請求報文

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

GET / HTTP/1.1
Host: www.baidu.com
Connection: keep-alive
Upgrade-Insecure-Requests: 1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: zh-CN,zh;q=0.9,en;q=0.8
Cookie: BAIDUID=9D8BBF109C54257FDF493BEFB21C48C0:FG=1; BIDUPSID=9D8BBF109C54257FDF493BEFB21C48C0; PSTM=1517121373; BD_LAST_QID=10303242358279539047

image.png

響應(yīng)報文

響應(yīng)報文由HTTP版本、狀態(tài)碼（數(shù)字和原因短語）、HTTP首部等字段組成。

HTTP/1.1 200 OK
Bdpagetype: 1
Bdqid: 0xa3f1718e00024488
Cache-Control: private
Connection: Keep-Alive
Content-Encoding: gzip
Content-Type: text/html
Cxy_all: baidu+a099bc6c5584759c3f26c3fae21e11fb
Date: Sun, 27 May 2018 09:57:02 GMT
Expires: Sun, 27 May 2018 09:56:48 GMT
Server: BWS/1.1
Set-Cookie: BDSVRTM=0; path=/
Set-Cookie: BD_HOME=0; path=/
Set-Cookie: H_PS_PSSID=1431_21107_26350_20927; path=/; domain=.baidu.com
Strict-Transport-Security: max-age=172800
Vary: Accept-Encoding
X-Ua-Compatible: IE=Edge,chrome=1
Transfer-Encoding: chunked

image.png

HTTP首部字段

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

HTTP首部字段是由首部字段名和字段值組成，中間用英文分號分隔。

首部字段名: 字段值

另外，字段值對應(yīng)單個HTTP首部字段可以有多個值，用英文逗號隔開。

Keep-Alive: timeout=15, max=100

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

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

HTTP 首部字段將定義成緩存代理和非緩存代理的行為，分成 2 種類型。

• 端到端首部（End-to-end Header）

分在此類別中的首部會轉(zhuǎn)發(fā)給請求 / 響應(yīng)對應(yīng)的最終接收目標(biāo)，且必 須保存在由緩存生成的響應(yīng)中，另外規(guī)定它必須被轉(zhuǎn)發(fā)。

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

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

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

Connection

Keep-Alive

Proxy-Authenticate

Proxy-Authorization

Trailer

TE

Transfer-Encoding

Upgrade

HTTP首部字段一覽

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

HTTP通用首部字段（General Header Fields）

請求報文和響應(yīng)報文兩方都會使用的首部。

Cache-Control

控制緩存的指令，詳見HTTP緩存技術(shù)詳解

Connection

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

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

Connection:  不再轉(zhuǎn)發(fā)的首部字段名

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

管理持久連接

Connection: close

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

Connection: Keep-Alive

HTTP/1.1 之前的 HTTP 版本的默認(rèn)連接都是非持久連接。為 此，如果想在舊版本的 HTTP 協(xié)議上維持持續(xù)連接，則需要指定 Connection 首部字段的值為 Keep-Alive。為了兼容HTTP/1.1之前的版本，因此一般都會在請求的時候加上這個字段。

Date

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

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

Date: Tue, 03 Jul 2012 04:40:59 GMT

Pragma

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

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

Pragma: no-cache

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

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

Cache-Control: no-cache

Pragma: no-cache

Trailer

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

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 之后）出現(xiàn)了首部字段 Expires。

Transfer-Encoding

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

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字節(jié)分塊數(shù)據(jù)...
392 ←16進制(10進制為914)
...914字節(jié)分塊數(shù)據(jù)...
0

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

image.png

上圖用例中，首部字段 Upgrade 指定的值為 TLS/1.0。請注意此處兩 個字段首部字段的對應(yīng)關(guān)系，Connection 的值被指定為 Upgrade。 Upgrade 首部字段產(chǎn)生作用的 Upgrade 對象僅限于客戶端和鄰接服務(wù) 器之間。因此，使用首部字段 Upgrade 時，還需要額外指定 Connection:Upgrade。

對于附有首部字段 Upgrade 的請求，服務(wù)器可用 101 Switching Protocols 狀態(tài)碼作為響應(yīng)返回。

Via

使用首部字段 Via 是為了追蹤客戶端與服務(wù)器之間的請求和響應(yīng)報文 的傳輸路徑。

報文經(jīng)過代理或網(wǎng)關(guān)時，會先在首部字段 Via 中附加該服務(wù)器的信 息，然后再進行轉(zhuǎn)發(fā)。這個做法和 traceroute 及電子郵件的 Received 首部的工作機制很類似。

首部字段 Via 不僅用于追蹤報文的轉(zhuǎn)發(fā)，還可避免請求回環(huán)的發(fā)生。 所以必須在經(jīng)過代理時附加該首部字段內(nèi)容。

Via 首部是為了追蹤傳輸路徑，所以經(jīng)常會和 TRACE 方法一起使 用。比如，代理服務(wù)器接收到由 TRACE 方法發(fā)送過來的請求（其中 Max-Forwards: 0）時，代理服務(wù)器就不能再轉(zhuǎn)發(fā)該請求了。這種情況 下，代理服務(wù)器會將自身的信息附加到 Via 首部后，返回該請求的響 應(yīng)。

Warning

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

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

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

請求首部字段

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

Accept

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.1

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

Accept-Charset

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

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

Accept-Encodeing

Accept-Encoding: gzip, deflate 

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

下面是常見的幾種編碼：

gzip

由文件壓縮程序 gzip（GNU zip）生成的編碼格式 （RFC1952），采用 Lempel-Ziv 算法（LZ77）及 32 位循環(huán)冗余 校驗（Cyclic Redundancy Check，通稱 CRC）。

compress

由 UNIX 文件壓縮程序 compress 生成的編碼格式，采用 LempelZiv-Welch 算法（LZW）。

deflate

組合使用 zlib 格式（RFC1950）及由 deflate 壓縮算法 （RFC1951）生成的編碼格式。

identity

不執(zhí)行壓縮或不會變化的默認(rèn)編碼格式

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

Accept-Language

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

首部字段 Accept-Language 用來告知服務(wù)器用戶代理能夠處理的自然 語言集（指中文或英文等），以及自然語言集的相對優(yōu)先級?？梢淮?指定多種自然語言集。 和 Accept 首部字段一樣，按權(quán)重值 q 來表示相對優(yōu)先級。

在上述示例中，客戶端在服務(wù)器有中文版資源的情況下，會請求其返回中文版 對應(yīng)的響應(yīng)，沒有中文版時，則請求返回英文版響應(yīng)。

Authorization

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

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

Host

Host: www.baidu.com:80

首部字段 Host 會告知服務(wù)器，請求的資源所處的互聯(lián)網(wǎng)主機名和端 口號。Host 首部字段在 HTTP/1.1 規(guī)范內(nèi)是唯一一個必須被包含在請 求內(nèi)的首部字段。

首部字段 Host 和以單臺服務(wù)器分配多個域名的虛擬主機的工作機制 有很密切的關(guān)聯(lián)，這是首部字段 Host 必須存在的意義。

請求被發(fā)送至服務(wù)器時，請求中的主機名會用 IP 地址直接替換解 決。但如果這時，相同的 IP 地址下部署運行著多個域名，那么服務(wù) 器就會無法理解究竟是哪個域名對應(yīng)的請求。因此，就需要使用首部 字段 Host 來明確指出請求的主機名。若服務(wù)器未設(shè)定主機名，那直 接發(fā)送一個空值即可。

If-Match

If-Match: "123456"

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

首部字段 If-Match，屬附帶條件之一，它會告知服務(wù)器匹配資源所用 的實體標(biāo)記（ETag）值。這時的服務(wù)器無法使用弱 ETag 值。

服務(wù)器會比對 If-Match 的字段值和資源的 ETag 值，僅當(dāng)兩者一致 時，才會執(zhí)行請求。反之，則返回狀態(tài)碼 412 Precondition Failed 的響 應(yīng)。

還可以使用星號（*）指定 If-Match 的字段值。針對這種情況，服務(wù) 器將會忽略 ETag 的值，只要資源存在就處理請求。

這是一個緩存字段，具體緩存機制可以參考HTTP緩存技術(shù)詳解

If-Modified-Since

If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT

首部字段 If-Modified-Since，屬附帶條件之一，它會告知服務(wù)器若 IfModified-Since 字段值早于資源的更新時間，則希望能處理該請求。 而在指定 If-Modified-Since 字段值的日期時間之后，如果請求的資源 都沒有過更新，則返回狀態(tài)碼 304 Not Modified 的響應(yīng)。

If-Modified-Since 用于確認(rèn)代理或客戶端擁有的本地資源的有效性。 獲取資源的更新日期時間，可通過確認(rèn)首部字段 Last-Modified 來確 定。

If-None-Match

If-None-Match: "123456"

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

If-Unmodified-Since

If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT

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

Referer

Referer: http://www.hackr.jp/index.htm

首部字段 Referer 會告知服務(wù)器請求的原始資源的 URI。

客戶端一般都會發(fā)送 Referer 首部字段給服務(wù)器。但當(dāng)直接在瀏覽器 的地址欄輸入 URI，或出于安全性的考慮時，也可以不發(fā)送該首部字 段。

因為原始資源的 URI 中的查詢字符串可能含有 ID 和密碼等保密信 息，要是寫進 Referer 轉(zhuǎn)發(fā)給其他服務(wù)器，則有可能導(dǎo)致保密信息的 泄露。

另外，Referer 的正確的拼寫應(yīng)該是 Referrer，但不知為何，大家一直 沿用這個錯誤的拼寫。

User-Agent

Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.117 Safari/537.36

首部字段 User-Agent 會將創(chuàng)建請求的瀏覽器和用戶代理名稱等信息傳 達(dá)給服務(wù)器。

由網(wǎng)絡(luò)爬蟲發(fā)起請求時，有可能會在字段內(nèi)添加爬蟲作者的電子郵件 地址。此外，如果請求經(jīng)過代理，那么中間也很可能被添加上代理服 務(wù)器的名稱。

響應(yīng)首部字段

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

Age

Age: 600

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

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

Etag

ETag: "82e22293907ce725faf67773957acd12"

首部字段 ETag 能告知客戶端實體標(biāo)識。它是一種可將資源以字符串 形式做唯一性標(biāo)識的方式。服務(wù)器會為每份資源分配對應(yīng)的 ETag 值。

另外，當(dāng)資源更新時，ETag 值也需要更新。生成 ETag 值時，并沒有 統(tǒng)一的算法規(guī)則，而僅僅是由服務(wù)器來分配。

這是一個緩存字段，具體緩存機制可以參考HTTP緩存技術(shù)詳解

Location

Location: http://www.baidu.com/sample.html

使用首部字段 Location 可以將響應(yīng)接收方引導(dǎo)至某個與請求 URI 位置 不同的資源。

基本上，該字段會配合 3xx ：Redirection 的響應(yīng)，提供重定向的 URI。

幾乎所有的瀏覽器在接收到包含首部字段 Location 的響應(yīng)后，都會強 制性地嘗試對已提示的重定向資源的訪問。

Retry-After

Retry-After: 120

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

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

Server

Server: Apache/2.2.6 (Unix) PHP/5.2.5

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

Vary

Vary: Accept-Language

首部字段 Vary 可對緩存進行控制。源服務(wù)器會向代理服務(wù)器傳達(dá)關(guān) 于本地緩存使用方法的命令。

從代理服務(wù)器接收到源服務(wù)器返回包含 Vary 指定項的響應(yīng)之后，若 再要進行緩存，僅對請求中含有相同 Vary 指定首部字段的請求返回 緩存。即使對相同資源發(fā)起請求，但由于 Vary 指定的首部字段不相 同，因此必須要從源服務(wù)器重新獲取資源。

實體首部字段

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

Allow

Allow: GET, HEAD

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

Content-Encoding

Content-Encoding: gzip 

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

主要采用以下 4 種內(nèi)容編碼的方式：gzip 、 compress、 deflate 、identity

Content-Language

Content-Language: zh-CN

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

Content-Length

Content-Length: 15000

首部字段 Content-Length 表明了實體主體部分的大?。▎挝皇亲?節(jié)）。對實體主體進行內(nèi)容編碼傳輸時，不能再使用 Content-Length 首部字段。

Content-Type

Content-Type: text/html; charset=UTF-8

首部字段 Content-Type 說明了實體主體內(nèi)對象的媒體類型。和首部字 段 Accept 一樣，字段值用 type/subtype 形式賦值。

Expires

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

首部字段 Expires 會將資源失效的日期告知客戶端。緩存服務(wù)器在接 收到含有首部字段 Expires 的響應(yīng)后，會以緩存來應(yīng)答請求，在 Expires 字段值指定的時間之前，響應(yīng)的副本會一直被保存。當(dāng)超過 指定的時間后，緩存服務(wù)器在請求發(fā)送過來時，會轉(zhuǎn)向源服務(wù)器請求 資源。

源服務(wù)器不希望緩存服務(wù)器對資源緩存時，最好在 Expires 字段內(nèi)寫 入與首部字段 Date 相同的時間值。

這是一個緩存字段，具體緩存機制可以參考HTTP緩存技術(shù)詳解

Last-Modified

Last-Modified: Wed, 23 May 2012 09:59:55 GMT

首部字段 Last-Modified 指明資源最終修改的時間。一般來說，這個 值就是 Request-URI 指定資源被修改的時間。

這是一個緩存字段，具體緩存機制可以參考HTTP緩存技術(shù)詳解

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

Cookie 的工作機制是用戶識別及狀態(tài)管理。Web 網(wǎng)站為了管理用戶的 狀態(tài)會通過 Web 瀏覽器，把一些數(shù)據(jù)臨時寫入用戶的計算機內(nèi)。接 著當(dāng)用戶訪問該Web網(wǎng)站時，可通過通信方式取回之前發(fā)放的 Cookie。

調(diào)用 Cookie 時，由于可校驗 Cookie 的有效期，以及發(fā)送方的域、路 徑、協(xié)議等信息，所以正規(guī)發(fā)布的 Cookie 內(nèi)的數(shù)據(jù)不會因來自其他 Web 站點和攻擊者的攻擊而泄露。

Set-Cookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 

當(dāng)服務(wù)器準(zhǔn)備開始管理客戶端的狀態(tài)時，會事先告知各種信息。

Set-Cookie 字段的屬性

expires

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

path

Cookie 的 path 屬性可用于限制指定 Cookie 的發(fā)送范圍的文件目錄。 不過另有辦法可避開這項限制，看來對其作為安全機制的效果不能抱 有期待。

domain

通過 Cookie 的 domain 屬性指定的域名可做到與結(jié)尾匹配一致。比 如，當(dāng)指定 example.com 后，除 example.com 以外，www.example.com 或 www2.example.com 等都可以發(fā)送 Cookie。

因此，除了針對具體指定的多個域名發(fā)送 Cookie 之 外，不指定 domain 屬性顯得更安全。

secure

Cookie 的 secure 屬性用于限制 Web 頁面僅在 HTTPS 安全連接時，才 可以發(fā)送 Cookie。

Set-Cookie: name=value; secure

HttpOnly

Cookie 的 HttpOnly 屬性是 Cookie 的擴展功能，它使 JavaScript 腳本 無法獲得 Cookie。其主要目的為防止跨站腳本攻擊（Cross-site scripting，XSS）對 Cookie 的信息竊取。

Set-Cookie: name=value; HttpOnly

通過上述設(shè)置，通常從 Web 頁面內(nèi)還可以對 Cookie 進行讀取操作。 但使用 JavaScript 的 document.cookie 就無法讀取附加 HttpOnly 屬性后 的 Cookie 的內(nèi)容了。因此，也就無法在 XSS 中利用 JavaScript 劫持 Cookie 了。

Cookie

Cookie: status=enable

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