圖解HTTP六：HTTP 首部

6.1 HTTP 報文首部

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

請求報文

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

請求報文

6.2 HTTP 首部字段

6.2.1 HTTP 首部字段傳遞重要信息

HTTP 首部字段是構成 HTTP 報文的要素之一。在客戶端與服務器之間以 HTTP 協議進行通信的過程中，無論是請求還是響應都會使用首部字段，它能起到傳遞額外重要信息的作用。使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、所使用的語言、認證信息等內容。

6.2.2 HTTP 首部字段結構

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

首部字段名: 字段值

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

Content-Type: text/html

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

Keep-Alive: timeout=15, max=100

6.2.3 4 種 HTTP 首部字段類型

HTTP 首部字段根據實際用途被分爲以下 4 種類型。

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

6.2.4 HTTP/1.1 首部字段一覽

表 6-1：通用首部字段

首部字段名	說明
Cache-Control	控制緩存的行爲
Connection	逐跳首部、連接的管理
Date	創建報文的日期時間
Pragma	報文指令
Trailer	報文末端的首部一覽
Transfer-Encoding	指定報文主體的傳輸編碼方式
Upgrade	升級爲其他協議
Via	代理服務器的相關信息
Warning	錯誤通知

表 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.5 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 的指令可用於請求及響應時。

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

表 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）

public 指令

Cache-Control: public

當指定使用 public 指令時，則明確表明其他用戶也可利用緩存。
private 指令

Cache-Control: private

當指定 private 指令後，響應只以特定的用戶作爲對象，這與 public 指令的行爲相反。緩存服務器會對該特定用戶提供資源緩存的服務，對於其他用戶發送過來的請求，代理服務器則不會返回緩存。

no-cache 指令

Cache-Control: no-cache

使用 no-cache 指令的目的是爲了防止從緩存中返回過期的資源。
客戶端發送的請求中如果包含 no-cache 指令，則表示客戶端將不會接收緩存過的響應。於是， “中間”的緩存服務器必須把客戶端請求轉發給源服務器。
如果服務器返回的響應中包含 no-cache 指令，那麼緩存服務器不能對資源進行緩存。源服務器以後也將不再對緩存服務器請求中提出的資源有效性進行確認，且禁止其對響應資源進行緩存操作。

Cache-Control: no-cache=Location

由服務器返回的響應中，若報文首部字段 Cache-Control 中對 no-cache 字段名具體指定參數值，那麼客戶端在接收到這個被指定參數值的首部字段對應的響應報文後，就不能使用緩存。換言之，無參數值的首部字段可以使用緩存。只能在響應指令中指定該參數。

控制可執行緩存的對象的指令：no-store 指令

Cache-Control: no-store

當使用 no-store 指令 1 時，暗示請求（和對應的響應）或響應中包含機密信息。因此，該指令規定緩存不能在本地存儲請求或響應的任一部分。

指定緩存期限和認證的指令

1. s-maxage 指令

Cache-Control: s-maxage=604800（單位 ：秒）

s-maxage 指令的功能和 max-age 指令的相同，它們的不同點是 s-maxage 指令只適用於供多位用戶使用的公共緩存服務器。也就是說，對於向同一用戶重複返回響應的服務器來說，這個指令沒有任何作用。另外，當使用 s-maxage 指令後，則直接忽略對 Expires 首部字段及 max-age 指令的處理

2. max-age 指令

Cache-Control: max-age=604800（單位：秒）

當客戶端發送的請求中包含 max-age 指令時，如果判定緩存資源的緩存時間數值比指定時間的數值更小，那麼客戶端就接收緩存的資源。另外，當指定 max-age 值爲 0，那麼緩存服務器通常需要將請求轉發給源服務器。
當服務器返回的響應中包含 max-age 指令時，緩存服務器將不對資源的有效性再作確認，而 max-age 數值代表資源保存爲緩存的最長時間。

3. min-fresh 指令

Cache-Control: min-fresh=60（單位：秒）

min-fresh 指令要求緩存服務器返回至少還未過指定時間的緩存資源。比如，當指定 min-fresh 爲 60 秒後，過了 60 秒的資源都無法作爲響應返回了。

4. max-stale 指令

Cache-Control: max-stale=3600（單位：秒）

使用 max-stale 可指示緩存資源，即使過期也照常接收。如果指令未指定參數值，那麼無論經過多久，客戶端都會接收響應；如果指令中指定了具體數值，那麼即使過期，只要仍處於 max-stale 指定的時間內，仍舊會被客戶端接收。

5. only-if-cached 指令

Cache-Control: only-if-cached

使用 only-if-cached 指令表示客戶端僅在緩存服務器本地緩存目標資源的情況下才會要求其返回。換言之，該指令要求緩存服務器不重新加載響應，也不會再次確認資源有效性。若發生請求緩存服務器的本地緩存無響應，則返回狀態碼 504 Gateway Timeout。

6. must-revalidate 指令

Cache-Control: must-revalidate

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

7. proxy-revalidate 指令

Cache-Control: proxy-revalidate

proxy-revalidate 指令要求所有的緩存服務器在接收到客戶端帶有該指令的請求返回響應之前，必須再次驗證緩存的有效性。

8. no-transform 指令

Cache-Control: no-transform

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

Cache-Control 擴展：cache-extension token

Cache-Control: private, community=“UCI”

通過 cache-extension 標記（token），可以擴展 Cache-Control 首部字段內的指令。
如上例， Cache-Control 首部字段本身沒有 community 這個指令。藉助 extension tokens 實現了該指令的添加。如果緩存服務器不能理解 community 這個新指令，就會直接忽略。因此， extension tokens 僅對能理解它的緩存服務器來說是有意義的。

6.3.2 Connection

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

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

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

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

• 管理持久連接

Connection: close

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

Connection: Keep-Alive

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

6.3.3 Date

首部字段 Date 表明創建 HTTP 報文的日期和時間。HTTP/1.1 協議使用在 RFC1123 中規定的日期時間的格式，如下示例。

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

6.3.4 Trailer

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

6.3.5 Transfer-Encoding

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

6.3.6 Upgrade

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

上圖用例中，首部字段 Upgrade 指定的值爲 TLS/1.0。請注意此處兩個字段首部字段的對應關係， Connection 的值被指定爲 Upgrade。 Upgrade 首部字段產生作用的 Upgrade 對象僅限於客戶端和鄰接
服務器之間。因此，使用首部字段 Upgrade 時，還需要額外指定 Connection:Upgrade。對於附有首部字段 Upgrade 的請求，服務器可用 101 Switching Protocols 本文檔由Linux公社 狀態碼作爲響應返回。

6.3.7 Via

使用首部字段 Via 是爲了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑，報文經過代理或網關時，會先在首部字段 Via 中附加該服務器的信息，然後再進行轉發。首部字段 Via 不僅用於追蹤報文的轉發，還可避免請求迴環的發生。所以必須在經過代理時附加該首部字段內容。

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

6.3.9 Warning

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

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

表 6-7： HTTP/1.1 警告碼

警告碼	警告內容	說明
110	Response is stale（響應已過期）	代理返回已過期的資源
111	Revalidation failed（再驗證失敗）	代理再驗證資源有效性時失敗（服務器無法到達等原因）
112	Disconnection operation （斷開連接操作）	代理與互聯網連接被故意切斷
113	Heuristic expiration（試探性過期）	響應的使用期超過24小時（有效緩存的設定時間大於24小時的情況下）
199	Miscellaneous warning（雜項警告）	任意的警告內容
214	Transformation applied（使用了轉換）	代理對內容編碼或媒體類型等執行了某些處理時
299	Miscellaneous persistent warning（持久雜項警告）	任意的警告內容

6.4 請求首部字段

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

6.4.1 Accept

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

• 文本文件：text/html, text/plain, text/css …application/xhtml+xml, application/xml …
• 圖片文件：image/jpeg, image/gif, image/png …
• 視頻文件：video/mpeg, video/quicktime …
• 應用程序使用的二進制文件：application/octet-stream, application/zip …

若想要給顯示的媒體類型增加優先級，則使用 q= 來額外表示權重值，用分號（;）進行分隔。權重值 q 的範圍是 0~1（可精確到小數點後 3 位），且 1 爲最大值。不指定權重 q 值時，默認權重爲 q=1.0。當服務器提供多種內容時，將會首先返回權重值最高的媒體類型。

6.4.2 Accept-Charset

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

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

6.4.3 Accept-Encoding

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

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

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

6.4.5 Authorization

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

首部字段 Authorization 是用來告知服務器，用戶代理的認證信息（證書值）。通常，想要通過服務器認證的用戶代理會在接收到返回的 401 狀態碼響應後，把首部字段 Authorization 加入請求中。

6.4.6 Expect

客戶端使用首部字段 Expect 來告知服務器，期望出現的某種特定行爲。因服務器無法理解客戶端的期望作出迴應而發生錯誤時，會返回狀態碼 417 Expectation Failed。

6.4.7 From

首部字段 From 用來告知服務器使用用戶代理的用戶的電子郵件地址。通常，其使用目的就是爲了顯示搜索引擎等用戶代理的負責人的電子郵件聯繫方式。

6.4.8 Host

圖：虛擬主機運行在同一個 IP 上，因此使用首部字段 Host 加以區分

首部字段 Host 會告知服務器，請求的資源所處的互聯網主機名和端口號。 Host 首部字段在 HTTP/1.1 規範內是唯一一個必須被包含在請求內的首部字段。首部字段 Host 和以單臺服務器分配多個域名的虛擬主機的工作機制有很密切的關聯，這是首部字段 Host 必須存在的意義。
請求被髮送至服務器時，請求中的主機名會用 IP 地址直接替換解決。但如果這時，相同的 IP 地址下部署運行着多個域名，那麼服務器就會無法理解究竟是哪個域名對應的請求。因此，就需要使用首部字段 Host 來明確指出請求的主機名。

6.4.9 If-Match

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

服務器會比對 If-Match 的字段值和資源的 ETag 值，僅當兩者一致時，纔會執行請求。反之，則返回狀態碼 412 Precondition Failed 的響應。

6.4.10 If-Modified-Since

如果在 If-Modified-Since 字段指定的日期時間後，資源發生了更新，服務器會接受請求

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

6.4.11 If-None-Match

只有在 If-None-Match 的字段值與 ETag 值不一致時，可處理該請求。與 If-Match 首部字段的作用相反

首部字段 If-None-Match 屬於附帶條件之一。它和首部字段 If-Match 作用相反。用於指定 If-None-Match 字段值的實體標記（ETag）值與請求資源的 ETag 不一致時，它就告知服務器處理該請求。

6.4.12 If-Range

首部字段 If-Range 屬於附帶條件之一。它告知服務器若指定的 If-Range 字段值（ETag 值或者時間）和請求資源的 ETag 值或時間相一致時，則作爲範圍請求處理。反之，則返回全體資源。

下面我們思考一下不使用首部字段 If-Range 發送請求的情況。服務器端的資源如果更新，那客戶端持有資源中的一部分也會隨之無效，當然，範圍請求作爲前提是無效的。這時，服務器會暫且以狀態碼 412 Precondition Failed 作爲響應返回，其目的是催促客戶端再次發送請求。這樣一來，與使用首部字段 IfRange 比起來，就需要花費兩倍的功夫。

6.4.13 If-Unmodified-Since

首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相反。它的作用的是告知服務器，指定的請求資源只有在字段值內指定的日期時間之後，未發生更新的情況下，才能處理請求。如果在指定日期時間後發生了更新，則以狀態碼 412 Precondition Failed 作爲響應返回

6.4.14 Max-Forwards

每次轉發數值減 1。當數值變 0 時返回響應

通過 TRACE 方法或 OPTIONS 方法，發送包含首部字段 Max-Forwards 的請求時，該字段以十進制整數形式指定可經過的服務器最大數目。服務器在往下一個服務器轉發請求之前， Max-Forwards 的值減 1 後重新賦值。當服務器接收到 Max-Forwards 值爲 0 的請求時，則不再進行轉發，而是直接返回響應。

6.4.15 Proxy-Authorization

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

接收到從代理服務器發來的認證質詢時，客戶端會發送包含首部字段 Proxy-Authorization 的請求，以告知服務器認證所需要的信息。這個行爲是與客戶端和服務器之間的 HTTP 訪問認證相類似的，不同之處在於，認證行爲發生在客戶端與代理之間。客戶端與服務器之間的認證，使用首部字段 Authorization 可起到相同作用。

6.4.16 Range

Range: bytes=5001-10000

對於只需獲取部分資源的範圍請求，包含首部字段 Range 即可告知服務器資源的指定範圍。上面的示例表示請求獲取從第 5001 字節至第 10000 字節的資源。
接收到附帶 Range 首部字段請求的服務器，會在處理請求之後返回狀態碼爲 206 Partial Content 的響應。無法處理該範圍請求時，則會返回狀態碼 200 OK 的響應及全部資源。

6.4.17 Referer

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

首部字段 Referer 會告知服務器請求的原始資源的 URI。客戶端一般都會發送 Referer 首部字段給服務器。但當直接在瀏覽器的地址欄輸入 URI，或出於安全性的考慮時，也可以不發送該首部字段。
因爲原始資源的 URI 中的查詢字符串可能含有 ID 和密碼等保密信息，要是寫進 Referer 轉發給其他服務器，則有可能導致保密信息的泄露。

6.4.18 TE

TE: gzip, deflate;q=0.5

首部字段 TE 會告知服務器客戶端能夠處理響應的傳輸編碼方式及相對優先級。它和首部字段AcceptEncoding 的功能很相像，但是用於傳輸編碼。

6.4.19 User-Agent

首部字段 User-Agent 會將創建請求的瀏覽器和用戶代理名稱等信息傳達給服務器。

6.5 響應首部字段

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

6.5.1 Accept-Ranges

Accept-Ranges: bytes

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

6.5.2 Age

Age: 600

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

6.5.3 ETag

首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串形式做唯一性標識的方式。服務器會爲每份資源分配對應的 ETag 值。
另外，當資源更新時， ETag 值也需要更新。生成 ETag 值時，並沒有統一的算法規則，而僅僅是由服務器來分配。

資源被緩存時，就會被分配唯一性標識。例如，當使用中文版的瀏覽器訪問 http://www.google.com/ 時，就會返回中文版對應的資源，而使用英文版的瀏覽器訪問時，則會返回英文版對應的資源。兩者的 URI 是相同的，所以僅憑 URI 指定緩存的資源是相當困難的。若在下載過程中出現連接中斷、再連接的情況，都會依照ETag 值來指定資源。

強 ETag 值和弱 Tag 值
ETag 中有強 ETag 值和弱 ETag 值之分。
強 ETag 值
強 ETag 值，不論實體發生多麼細微的變化都會改變其值。

ETag: “usagi-1234”

弱 ETag 值
弱 ETag 值只用於提示資源是否相同。只有資源發生了根本改變，產生差異時纔會改變 ETag 值。這時，會在字段值最開始處附加 W/。

ETag: W/“usagi-1234”

6.5.4 Location

Location: http://www.usagidesign.jp/sample.html

使用首部字段 Location 可以將響應接收方引導至某個與請求 URI 位置不同的資源。基本上，該字段會配合 3xx ： Redirection 的響應，提供重定向的 URI。幾乎所有的瀏覽器在接收到包含首部字段 Location 的響應後，都會強制性地嘗試對已提示的重定向資源的訪問。

6.5.5 Proxy-Authenticate

Proxy-Authenticate: Basic realm=“Usagidesign Auth”

首部字段 Proxy-Authenticate 會把由代理服務器所要求的認證信息發送給客戶端。它與客戶端和服務器之間的 HTTP 訪問認證的行爲相似，不同之處在於其認證行爲是在客戶端與代理之間進行的。

6.5.6 Retry-After

Retry-After: 120

首部字段 Retry-After 告知客戶端應該在多久之後再次發送請求。主要配合狀態碼 503 Service Unavailable 響應，或 3xx Redirect 響應一起使用。字段值可以指定爲具體的日期時間（Wed, 04 Jul 2012 06： 34： 24 GMT 等格式），也可以是創建響應後的秒數。

6.5.7 Server

Server: Apache/2.2.17 (Unix)

首部字段 Server 告知客戶端當前服務器上安裝的 HTTP 服務器應用程序的信息。不單單會標出服務器上的軟件應用名稱，還有可能包括版本號和安裝時啓用的可選項。

Server: Apache/2.2.6 (Unix) PHP/5.2.5

6.5.8 Vary

當代理服務器接收到帶有 Vary 首部字段指定獲取資源的請求時，如果使用的 Accept-Language 字段的值相同，那麼就直接從緩存返回響應。反之，則需要先從源服務器端獲取資源後才能作爲響應 返回

Vary: Accept-Language

首部字段 Vary 可對緩存進行控制。源服務器會向代理服務器傳達關於本地緩存使用方法的命令。從代理服務器接收到源服務器返回包含 Vary 指定項的響應之後，若再要進行緩存，僅對請求中含有相同Vary 指定首部字段的請求返回緩存。即使對相同資源發起請求，但由於 Vary 指定的首部字段不相同，因此必須要從源服務器重新獲取資源。

6.5.9 WWW-Authenticate

WWW-Authenticate: Basic realm=“Usagidesign Auth”

首部字段 WWW-Authenticate 用於 HTTP 訪問認證。它會告知客戶端適用於訪問請求 URI 所指定資源的認證方案（Basic 或是 Digest）和帶參數提示的質詢（challenge）。狀態碼 401 Unauthorized 響應中，肯定帶有首部字段 WWW-Authenticate。

6.6 實體首部字段

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

6.6.1 Allow

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 種內容編碼的方式。

• 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 表明了實體主體部分的大小（單位是字節）。

6.6.5 Content-Location

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

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

6.6.6 Content-MD5

客戶端會對接收的報文主體執行相同的 MD5 算法，然後與首部字段 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 形式賦值。

6.6.9 Expires

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

首部字段 Expires 會將資源失效的日期告知客戶端。緩存服務器在接收到含有首部字段 Expires 的響應後，會以緩存來應答請求，在 Expires 字段值指定的時間之前，響應的副本會一直被保存。當超過指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求資源。源服務器不希望緩存服務器對資源緩存時，最好在 Expires 字段內寫入與首部字段 Date 相同的時間值。但是，當首部字段 Cache-Control 有指定 max-age 指令時，比起首部字段 Expires，會優先處理 max-age 指令。

6.6.10 Last-Modified

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

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

6.7 爲 Cookie 服務的首部字段

Cookie 的工作機制是用戶識別及狀態管理。 Web 網站爲了管理用戶的狀態會通過 Web 瀏覽器，把一些數據臨時寫入用戶的計算機內。接着當用戶訪問該Web網站時，可通過通信方式取回之前發放的Cookie。

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

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

6.7.1 Set-Cookie

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

當服務器準備開始管理客戶端的狀態時，會事先告知各種信息。

表 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 的實質性刪除操作
path 屬性
Cookie 的 path 屬性可用於限制指定 Cookie 的發送範圍的文件目錄。不過另有辦法可避開這項限制，看來對其作爲安全機制的效果不能抱有期待。
domain 屬性
通過 Cookie 的 domain 屬性指定的域名可做到與結尾匹配一致。比如，當指定 example.com 後，除
example.com 以外， www.example.com 或 www2.example.com 等都可以發送 Cookie。因此，除了針對具體指定的多個域名發送 Cookie 之 外，不指定 domain 屬性顯得更安全。
secure 屬性
Cookie 的 secure 屬性用於限制 Web 頁面僅在 HTTPS 安全連接時，纔可以發送 Cookie。發送 Cookie 時，指定 secure 屬性的方法如下所示。

Set-Cookie: name=value; secure

以上例子僅當在 https://www.example.com/（HTTPS）安全連接的情況下才會進行 Cookie 的回收。也就是說，即使域名相同， http://www.example.com/（HTTP）也不會發生 Cookie 回收行爲。當省略 secure 屬性時，不論 HTTP 還是 HTTPS，都會對 Cookie 進行回收。

HttpOnly 屬性
Cookie 的 HttpOnly 屬性是 Cookie 的擴展功能，它使 JavaScript 腳本無法獲得 Cookie。其主要目的爲防止跨站腳本攻擊（Cross-site scripting， XSS）對 Cookie 的信息竊取。發送指定 HttpOnly 屬性的 Cookie 的方法如下所示。

Set-Cookie: name=value; HttpOnly

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

6.7.2 Cookie

Cookie: status=enable

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

6.8 其他首部字段

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

6.8.1 X-Frame-Options

X-Frame-Options: DENY

首部字段 X-Frame-Options 屬於 HTTP 響應首部，用於控制網站內容在其他 Web 網站的 Frame 標籤內的顯示問題。其主要目的是爲了防止點擊劫持（clickjacking）攻擊。首部字段 X-Frame-Options 有以下兩個可指定的字段值。

• DENY ：拒絕
• SAMEORIGIN ：僅同源域名下的頁面（Top-level-browsing-context）匹配時許可。（比如，當指定 http://hackr.jp/sample.html 頁面爲 SAMEORIGIN 時，那麼 hackr.jp 上所有頁面的 frame 都被允許可加載該頁面，而 example.com 等其他域名的頁面就不行了）

6.8.2 X-XSS-Protection

X-XSS-Protection: 1

首部字段 X-XSS-Protection 屬於 HTTP 響應首部，它是針對跨站腳本攻擊（XSS）的一種對策，用於控制瀏覽器 XSS 防護機制的開關。首部字段 X-XSS-Protection 可指定的字段值如下。

• 0 ：將 XSS 過濾設置成無效狀態
• 1 ：將 XSS 過濾設置成有效狀態

6.8.3 DNT

DNT: 1

首部字段 DNT 屬於 HTTP 請求首部，其中 DNT 是 Do Not Track 的簡稱，意爲拒絕個人信息被收集，是表示拒絕被精準廣告追蹤的一種方法。首部字段 DNT 可指定的字段值如下。

• 0 ：同意被追蹤
• 1 ：拒絕被追蹤

由於首部字段 DNT 的功能具備有效性，所以 Web 服務器需要對 DNT 做對應的支持。

6.8.4 P3P

P3P: CP=“CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND UNI COM NAV INT”

首部字段 P3P 屬於 HTTP 相應首部，通過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺）技術，可以讓 Web 網站上的個人隱私變成一種僅供程序可理解的形式，以達到保護用戶隱私的目的。要進行 P3P 的設定，需按以下操作步驟進行。

• 步驟 1：創建 P3P 隱私
• 步驟 2：創建 P3P 隱私對照文件後，保存命名在 /w3c/p3p.xml
• 步驟 3：從 P3P 隱私中新建 Compact policies 後，輸出到 HTTP 響應中