《圖解Http》閱讀筆記——6.HTTP 首部

《圖解Http》閱讀筆記——6.HTTP 首部

---

6.1 HTTP 報文首部

圖：HTTP 報文的結構

HTTP 協議的請求和響應報文中一定包含 HTTP 首部。首部內容爲客 戶端和服務器分別處理請求和響應提供所須要的信息。對於客戶端用 戶來講，這些信息中的大部份內容都無須親自查看。

報文首部由幾個字段構成。

HTTP 請求報文

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

圖：請求報文

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

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/ 時，返回的響應報文的首部 信息。

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 報文的要素之一。在客戶端與服務器之 間以 HTTP 協議進行通訊的過程當中，不管是請求仍是響應都會使用首 部字段，它能起到傳遞額外重要信息的做用。

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

6.2.2 HTTP 首部字段結構

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

首部字段名: 字段值

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

Content-Type: text/html

另外，字段值對應單個 HTTP 首部字段能夠有多個值，以下所示。

Keep-Alive: timeout=15, max=100

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

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 非 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 首部

端到端首部（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 可以控制緩存的行爲

指令的參數是可選的，多個指令之間經過「,」分隔。首部字段 CacheControl 的指令可用於請求及響應時。

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）

表示是否能緩存的指令

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: 從字面意思上很容易把 no-cache 誤解成爲不緩存，但事實上 no-cache 表明不緩存過時的資源，緩存會向源服務器進行有效期確認後處理資源，也許稱爲 do-notserve-from-cache-without-revalidation 更合適。no-store 纔是真正地不進行緩存，請讀者注意區別理解。——譯者注

所以，該指令規定緩存不能在本地存儲請求或響應的任一部分

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

s-maxage 指令

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

s-maxage 指令的功能和 max-age 指令的相同，它們的不一樣點是 smaxage 指令只適用於供多位用戶使用的公共緩存服務器[2]。也就是 說，對於向同一用戶重複返回響應的服務器來講，這個指令沒有任何 做用。

2 這裏通常指代理。 ——譯者注

另外，當使用 s-maxage 指令後，則直接忽略對 Expires 首部字段及 max-age 指令的處理。

max-age 指令

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

當客戶端發送的請求中包含 max-age 指令時，若是斷定緩存資源的緩 存時間數值比指定時間的數值更小，那麼客戶端就接收緩存的資源。 另外，當指定 max-age 值爲 0，那麼緩存服務器一般須要將請求轉發 給源服務器。

當服務器返回的響應中包含 max-age 指令時，緩存服務器將不對資源 的有效性再做確認，而 max-age 數值表明資源保存爲緩存的最長時 間。

應用 HTTP/1.1 版本的緩存服務器遇到同時存在 Expires 首部字段的情 況時，會優先處理 max-age 指令，而忽略掉 Expires 首部字段。而 HTTP/1.0 版本的緩存服務器的狀況卻相反，max-age 指令會被忽略掉。

min-fresh 指令

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

max-stale 指令

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

使用 max-stale 可指示緩存資源，即便過時也照常接收。

若是指令未指定參數值，那麼不管通過多久，客戶端都會接收響應； 若是指令中指定了具體數值，那麼即便過時，只要仍處於 max-stale 指定的時間內，仍舊會被客戶端接收。

only-if-cached 指令

Cache-Control: only-if-cached

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

must-revalidate 指令

Cache-Control: must-revalidate

使用 must-revalidate 指令，代理會向源服務器再次驗證即將返回的響 應緩存目前是否仍然有效。 若代理沒法連通源服務器再次獲取有效資源的話，緩存必須給客戶端 一條 504（Gateway Timeout）狀態碼。

另外，使用 must-revalidate 指令會忽略請求的 max-stale 指令（即便已經在首部使用了 max-stale，也不會再有效果）。

proxy-revalidate 指令

Cache-Control: proxy-revalidate

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

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 首 部）。

管理持久鏈接

onnection: 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 報文的日期和時間

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

以前的 HTTP 協議版本中使用在 RFC850 中定義的格式，以下所示。

Date: Tue, 03-Jul-12 04:40:59 GMT

除此以外，還有一種格式。它與 C 標準庫內的 asctime() 函數的輸出 格式一致。

Date: Tue Jul 03 04:40:59 2012

6.3.4 Pragma

Pragma 是 HTTP/1.1 以前版本的歷史遺留字段，僅做爲與 HTTP/1.0 的向後兼容而定義。

規範定義的形式惟一，以下所示。

Pragma: no-cache

6.3.5 Trailer

首部字段 Trailer 會事先說明在報文主體後記錄了哪些首部字段。該 首部字段可應用在 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 以後）出現了首部字段 Expires。

6.3.6 Transfer-Encoding

首部字段 Transfer-Encoding 規定了傳輸報文主體時採用的編碼方式。 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字節分塊數據...
392 ←16進制(10進製爲914)
...914字節分塊數據...
0

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

6.3.7 Upgrade

首部字段 Upgrade 用於檢測 HTTP 協議及其餘協議是否可以使用更高的 版本進行通訊，其參數值能夠用來指定一個徹底不一樣的通訊協議。

上圖用例中，首部字段 Upgrade 指定的值爲 TLS/1.0。請注意此處兩 個字段首部字段的對應關係，Connection 的值被指定爲 Upgrade。 Upgrade 首部字段產生做用的 Upgrade 對象僅限於客戶端和鄰接服務 器之間。所以，使用首部字段 Upgrade 時，還須要額外指定 Connection:Upgrade。

對於附有首部字段 Upgrade 的請求，服務器可用 101 Switching Protocols 狀態碼做爲響應返回。

對於附有首部字段 Upgrade 的請求，服務器可用 101 Switching Protocols 狀態碼做爲響應返回。

6.3.8 Via

(略)

6.3.9 Warning

(略)

6.4 請求首部字段

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

6.4.1 Accept

Accept:text/html,application/xhtml+xml,application/xml;q=0.

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 ...

好比，若是瀏覽器不支持 PNG 圖片的顯示，那 Accept 就不指定 image/png，而指定可處理的 image/gif 和 image/jpeg 等圖片類型。

若想要給顯示的媒體類型增長優先級，則使用 q= 來額外表示權重值 1，用分號（;）進行分隔。權重值 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 值來表示相對優先級。

該首部字段應用於內容協商機制的服務器驅動協商。

Accept-Encoding

Accept-Encoding: gzip, deflate

Accept-Encoding 首部字段用來告知服務器用戶代理支持的內容編碼及 內容編碼的優先級順序。可一次性指定多種內容編碼。

• gzip

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

• compress

  由 UNIX 文件壓縮程序 compress 生成的編碼格式，採用 LempelZiv-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 用來告知服務器用戶代理可以處理的天然 語言集（指中文或英文等），以及天然語言集的相對優先級。可一次 指定多種天然語言集。

6.4.5 Authorization

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

首部字段 Authorization 是用來告知服務器，用戶代理的認證信息（證 書值）。一般，想要經過服務器認證的用戶代理會在接收到返回的 401 狀態碼響應後，把首部字段 Authorization 加入請求中。共用緩存 在接收到含有 Authorization 首部字段的請求時的操做處理會略有差 異。

.4.6 Expect

Expect: 100-continue

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

6.4.7 From

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

6.4.8 Host

首部字段 Host 會告知服務器，請求的資源所處的互聯網主機名和端 口號。Host 首部字段在 HTTP/1.1 規範內是惟一一個必須被包含在請求內的首部字段。

首部字段 Host 和以單臺服務器分配多個域名的虛擬主機的工做機制 有很密切的關聯，這是首部字段 Host 必須存在的意義。

6.4.9 If-Match

圖：附帶條件請求

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

If-Match: "123456"

首部字段 If-Match，屬附帶條件之一，它會告知服務器匹配資源所用 的實體標記（ETag）值。這時的服務器沒法使用弱 ETag 值。（請參 照本章有關首部字段 ETag 的說明）

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

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

6.4.10 If-Modified-Since

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

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

if-Modified-Since 用於確認代理或客戶端擁有的本地資源的有效性。 獲取資源的更新日期時間，可經過確認首部字段 Last-Modified 來確 定。

6.4.11 If-None-Match

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

在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可獲取最新的資 源。所以，這與使用首部字段 If-Modified-Since 時有些相似。

6.4.12 If-Range

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

6.4.13 If-Unmodified-Since

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

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

6.4.14 Max-Forwards

Max-Forwards: 10

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

使用 HTTP 協議通訊時，請求可能會通過代理等多臺服務器。途中， 若是代理服務器因爲某些緣由致使請求轉發失敗，客戶端也就等不到 服務器返回的響應了。對此，咱們無從可知。

能夠靈活使用首部字段 Max-Forwards，針對以上問題產生的緣由展 開調查。因爲當 Max-Forwards 字段值爲 0 時，服務器就會當即返回 響應，由此咱們至少能夠對以那臺服務器爲終點的傳輸路徑的通訊狀 況有所把握。

6.4.15 Proxy-Authorization

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

接收到從代理服務器發來的認證質詢時，客戶端會發送包含首部字段 Proxy-Authorization 的請求，以告知服務器認證所須要的信息。

這個行爲是與客戶端和服務器之間的 HTTP 訪問認證相相似的，不一樣 之處在於，認證行爲發生在客戶端與代理之間。客戶端與服務器之間 的認證，使用首部字段 Authorization 可起到相同做用。有關 HTTP 訪 問認證，後面的章節會做詳盡闡述。

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

(略)

6.4.19 User-Agent

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: bytes

首部字段 Accept-Ranges 是用來告知客戶端服務器是否能處理範圍請 求，以指定獲取服務器端某個部分的資源。

可指定的字段值有兩種，可處理範圍請求時指定其爲 bytes，反之則 指定其爲 none。

6.5.2 Age

Age: 600

首部字段 Age 能告知客戶端，源服務器在多久前建立了響應。字段值 的單位爲秒。

若建立該響應的服務器是緩存服務器，Age 值是指緩存後的響應再次 發起認證到認證完成的時間值。代理建立響應時必須加上首部字段 Age。

6.5.3 ETag

ETag: "82e22293907ce725faf67773957acd12"

首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串 形式作惟一性標識的方式。服務器會爲每份資源分配對應的 ETag 值。

另外，當資源更新時，ETag 值也須要更新。生成 ETag 值時，並無 統一的算法規則，而僅僅是由服務器來分配。

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 訪問認證的行爲類似，不一樣之處在 於其認證行爲是在客戶端與代理之間進行的。而客戶端與服務器之間 進行認證時，首部字段 WWW-Authorization 有着相同的做用。有關 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 可對緩存進行控制。源服務器會向代理服務器傳達關 於本地緩存使用方法的命令。

從代理服務器接收到源服務器返回包含 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 會告知客戶端服務器對實體的主體部分選 用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行 的壓縮。

6.6.3 Content-Language

Content-Language: zh-CN

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

6.6.4 Content-Length

Content-Length: 15000

首部字段 Content-Length 代表了實體主體部分的大小（單位是字 節）。對實體主體進行內容編碼傳輸時，不能再使用 Content-Length 首部字段。因爲實體主體大小的計算方法略微複雜，因此在此再也不展 開。讀者若想一探究竟，可參考 RFC2616 的 4.4。

6.6.5 Content-Location

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

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

6.6.6 Content-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 字段值指定的時間以前，響應的副本會一直被保存。當超過 指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求 資源。

源服務器不但願緩存服務器對資源緩存時，最好在 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 有關的首部字段。

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

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

下面的表格列舉了 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 了。

雖然是獨立的擴展功能，但 Internet Explorer 6 SP1 以上版本等當下的 主流瀏覽器都已經支持該擴展了。另外順帶一提，該擴展並不是是爲了 防止 XSS 而開發的。

6.7.2 Cookie

Cookie: status=enable

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

6.8 其餘首部字段

(略)