TCP/IP基礎總結性學習（6）

HTTP 首部

一.　HTTP 報文首部

1.HTTP 報文的結構:

2.HTTP 請求報文

• 圖示：

• 舉例子：

3.HTTP 響應報文：

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

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

在報文衆多的字段當中，HTTP 首部字段包含的信息最爲豐富。首部字段同時存在於請求和響應報文內，並涵蓋 HTTP 報文相關的內容信息。

---

二.　HTTP 首部字段

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

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

  

2.HTTP 首部字段結構 :

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

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

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

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

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

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

請求報文和響應報文兩方都會使用的首部。

• 請求首部字段（Request Header Fields）

從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息。

• 響應首部字段（Response Header Fields）

從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。

• 實體首部字段（Entity Header Fields）

針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

4.HTTP/1.1 首部字段一覽

HTTP/1.1 規範定義了以下 47 種首部字段。

• 通用首部字段

• 請求首部字段

• 響應首部字段

• 實體首部字段

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 首部 HTTP 首部字段將定義成緩存代理和非緩存代理的行爲，分紅 2 種類型。

端到端首部（End-to-end Header） 分在此類別中的首部會轉發給請求 / 響應對應的最終接收目標，且必須保存在由緩存生成的響應中，另外規定它必須被轉發。
逐跳首部（Hop-by-hop Header）
分在此類別中的首部只對單次轉發有效，會因經過緩存或代理而再也不轉發。HTTP/1.1 和以後版本中，若是要使用 hop-by-hop 首部，需提供 Connection 首部字段。
下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個首部字段以外， 其餘全部字段都屬於端到端首部。
注意：下面列舉了 HTTP/1.1 中的逐跳首部字段。除這 8 個首部字段以外， 其餘全部字段都屬於端到端首部。
Connection
Keep-Alive
Proxy-Authenticate
Proxy-Authorization
Trailer
TE
Transfer-Encoding
Upgrade

---

三.HTTP/1.1 通用首部字段
1.Cache-Control 經過指定首部字段 ,Cache-Control 的指令，就能操做緩存的工做機制。

• 圖：首部字段 Cache-Control 可以控制緩存的行爲

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

• Cache-Control 指令一覽

緩存請求指令：

緩存響應指令：

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

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

private 指令

no-cache 指令

客戶端發送的請求中若是包含 no-cache 指令，則表示客戶端將不會接收緩存過的響應。因而，「中間」的緩存服務器必須把客戶端請求轉發給源服務器。若是服務器返回的響應中包含 no-cache 指令，那麼緩存服務器不能對資源進行緩存。源服務器之後也將再也不對緩存服務器請求中提出的資源有效性進行確認，且禁止其對響應資源進行緩存操做。

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

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

no-store 指令

當使用 no-store 指令（從字面意思上很容易把 no-cache 誤解成爲不緩存，但事實上 no-cache 表明不緩存過時的資源，緩存會向源服務器進行有效期確認後處理資源，也許稱爲 do-notserve-from-cache-without-revalidation 更合適。no-store 纔是真正地不進行緩存，請讀者注意區別理解。） 時，暗示請求（和對應的響應）或響應中包含機密信息。所以，該指令規定緩存不能在本地存儲請求或響應的任一部分。

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

s-maxage 指令

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

max-age 指令

當客戶端發送的請求中包含 max-age 指令時，若是斷定緩存資源的緩存時間數值比指定時間的數值更小，那麼客戶端就接收緩存的資源。 另外，當指定 max-age 值爲 0，那麼緩存服務器一般須要將請求轉發給源服務器。當服務器返回的響應中包含 max-age 指令時，緩存服務器將不對資源的有效性再做確認，而 max-age 數值表明資源保存爲緩存的最長時間。應用 HTTP/1.1 版本的緩存服務器遇到同時存在 Expires 首部字段的狀況時，會優先處理 max-age 指令，而忽略掉 Expires 首部字段。而 HTTP/1.0 版本的緩存服務器的狀況卻相反，max-age 指令會被忽略。

min-fresh 指令

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

max-stale 指令

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

only-if-cached 指令

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

must-revalidate 指令

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

proxy-revalidate 指令

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

no-transform 指令

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

Cache-Control 擴展
cache-extension token

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

2.Connection

Connection 首部字段具有以下兩個做用：
　

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

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

• 管理持久鏈接

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

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

3.Date

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

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

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

4.Pragma

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

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

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

5.Trailer

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

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

6.Transfer-Encoding

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

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

7.Upgrade

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

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

8.Via

• 使用首部字段 Via 是爲了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑。報文通過代理或網關時，會先在首部字段 Via 中附加該服務器的信息，而後再進行轉發。這個作法和 traceroute 及電子郵件的 Received 首部的工做機制很相似。首部字段 Via 不只用於追蹤報文的轉發，還可避免請求迴環的發生。 因此必須在通過代理時附加該首部字段內容。

上圖用例中，在通過代理服務器 A 時，Via 首部附加了「1.0 gw.hackr.jp (Squid/3.1)」這樣的字符串值。行頭的 1.0 是指接收請求的服務器上應用的 HTTP 協議版本。接下來通過代理服務器 B 時亦是如此，在 Via 首部附加服務器信息，也可增長 1 個新的 Via 首部寫入服務器信息。Via 首部是爲了追蹤傳輸路徑，因此常常會和 TRACE 方法一塊兒使 用。好比，代理服務器接收到由 TRACE 方法發送過來的請求（其中 Max-Forwards: 0）時，代理服務器就不能再轉發該請求了。這種狀況下，代理服務器會將自身的信息附加到 Via 首部後，返回該請求的響應。
9.Warning

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

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

• HTTP/1.1 中定義了 7 種警告。警告碼對應的警告內容僅推薦參考。 另外，警告碼具有擴展性，從此有可能追加新的警告碼。

---

四.請求首部字段

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

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= 來額外表示權重值 (原文是「品質係數」。在 RFC2616 定義中，此處的 q 是指 qvalue，即 quality factor。直譯的話就是質量數，但通過綜合考慮理解記憶的便利性後，彷佛採用權 重值更爲穩妥。)，用分號（;）進行分隔。權重值 q 的範圍是 0~1（可精確到小數點後 3 位），且 1 爲最大值。不指定權重 q 值時，默認權重爲 q=1.0。當服務器提供多種內容時，將會首先返回權重值最高的媒體類型。

2.Accept-Charset

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

3.Accept-Encoding

• 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 相同。另外，也可以使用星號（*）做爲通配符，指定任意的編碼格式。

4.Accept-Language

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

5.Authorization

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

6.Expect

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

7.From

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

8.　Host

• 首部字段 Host 會告知服務器，請求的資源所處的互聯網主機名和端口號。Host 首部字段在 HTTP/1.1 規範內是惟一一個必須被包含在請求內的首部字段。首部字段 Host 和以單臺服務器分配多個域名的虛擬主機的工做機制有很密切的關聯，這是首部字段 Host 必須存在的意義。 請求被髮送至服務器時，請求中的主機名會用 IP 地址直接替換解決。但若是這時，相同的 IP 地址下部署運行着多個域名，那麼服務器就會沒法理解到底是哪一個域名對應的請求。所以，就須要使用首部字段 Host 來明確指出請求的主機名。若服務器未設定主機名，那直接發送一個空值便可。以下所示:

9.If-Match

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

• 首部字段 If-Match，屬附帶條件之一，它會告知服務器匹配資源所用的實體標記（ETag）值。這時的服務器沒法使用弱 ETag 值。服務器會比對 If-Match 的字段值和資源的 ETag 值，僅當二者一致 時，纔會執行請求。反之，則返回狀態碼 412 Precondition Failed 的響 應。還可使用星號（*）指定 If-Match 的字段值。針對這種狀況，服務器將會忽略 ETag 的值，只要資源存在就處理請求。

10.If-Modified-Since

首部字段 If-Modified-Since，屬附帶條件之一，它會告知服務器若 IfModified-Since 字段值早於資源的更新時間，則但願能處理該請求。 而在指定 If-Modified-Since 字段值的日期時間以後，若是請求的資源都沒有過更新，則返回狀態碼 304 Not Modified 的響應。 If-Modified-Since 用於確認代理或客戶端擁有的本地資源的有效性。 獲取資源的更新日期時間，可經過確認首部字段 Last-Modified 來肯定。

11.If-None-Match

• 圖：只有在 If-None-Match 的字段值與 ETag 值不一致時，可處理 該請求。與 If-Match 首部字段的做用相反 首部字段 If-None-Match 屬於附帶條件之一。它和首部字段 If-Match 做用相反。用於指定 If-None-Match 字段值的實體標記（ETag）值與 請求資源的 ETag 不一致時，它就告知服務器處理該請求。 在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可獲取最新的資 源。所以，這與使用首部字段 If-Modified-Since 時有些相似。

12.If-Range

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

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

13.If-Unmodified-Since

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

14.Max-Forwards

• 經過 TRACE 方法或 OPTIONS 方法，發送包含首部字段 MaxForwards 的請求時，該字段以十進制整數形式指定可通過的服務器最大數目。服務器在往下一個服務器轉發請求以前，Max-Forwards 的值減 1 後從新賦值。當服務器接收到 Max-Forwards 值爲 0 的請求 時，則再也不進行轉發，而是直接返回響應。使用 HTTP 協議通訊時，請求可能會通過代理等多臺服務器。途中，若是代理服務器因爲某些緣由致使請求轉發失敗，客戶端也就等不到服務器返回的響應了。對此，咱們無從可知。能夠靈活使用首部字段 Max-Forwards，針對以上問題產生的緣由展開調查。因爲當 Max-Forwards 字段值爲 0 時，服務器就會當即返回響應，由此咱們至少能夠對以那臺服務器爲終點的傳輸路徑的通訊情況有所把握。

15.Proxy-Authorization

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

16.Range

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

17.Referer

• 首部字段 Referer 會告知服務器請求的原始資源的 URI。 客戶端通常都會發送 Referer 首部字段給服務器。但當直接在瀏覽器的地址欄輸入 URI，或出於安全性的考慮時，也能夠不發送該首部字段。由於原始資源的 URI 中的查詢字符串可能含有 ID 和密碼等保密信息，要是寫進 Referer 轉發給其餘服務器，則有可能致使保密信息的泄露。另外，Referer 的正確的拼寫應該是 Referrer，但不知爲什麼，你們一直沿用這個錯誤的拼寫。

18.TE

• 首部字段 TE 會告知服務器客戶端可以處理響應的傳輸編碼方式及相對優先級。它和首部字段 Accept-Encoding 的功能很相像，可是用於傳輸編碼。首部字段 TE 除指定傳輸編碼以外，還能夠指定伴隨 trailer 字段的分 塊傳輸編碼的方式。應用後者時，只需把 trailers 賦值給該字段值。

19.User-Agent

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

---

五.響應首部字段

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

1.Accept-Ranges

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

2.Age

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

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

3.ETag

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

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

強 ETag 值和弱 Tag 值

強 ETag 值不論實體發生多麼細微的變化都會改變其值。

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

4.Location

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

5.Proxy-Authenticate

• 首部字段 Proxy-Authenticate 會把由代理服務器所要求的認證信息發送給客戶端。

它與客戶端和服務器之間的 HTTP 訪問認證的行爲類似，不一樣之處在於其認證行爲是在客戶端與代理之間進行的。而客戶端與服務器之間 進行認證時，首部字段 WWW-Authorization 有着相同的做用。

6.Retry-After

• 首部字段 Retry-After 告知客戶端應該在多久以後再次發送請求。主要配合狀態碼 503 Service Unavailable 響應，或 3xx Redirect 響應一塊兒使用。

字段值能夠指定爲具體的日期時間（Wed, 04 Jul 2012 06：34：24 GMT 等格式），也能夠是建立響應後的秒數。

7.Server

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

8.Vary

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

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

9.WWW-Authenticate

• 首部字段 WWW-Authenticate 用於 HTTP 訪問認證。它會告知客戶端適用於訪問請求 URI 所指定資源的認證方案（Basic 或是 Digest）和帶參數提示的質詢（challenge）。狀態碼 401 Unauthorized 響應中，確定帶有首部字段 WWW-Authenticate。 上述示例中，realm 字段的字符串是爲了辨別請求 URI 指定資源所受到的保護策略。

---

六.實體首部字段

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

1.Allow

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

2.Content-Encoding

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

• 主要採用如下 4 種內容編碼的方式。

gzip
compress
deflate
identity

3.Content-Language

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

4.Content-Length

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

5.Content-Location

• 首部字段 Content-Location 給出與報文主體部分相對應的 URI。和首部字段 Location 不一樣，Content-Location 表示的是報文主體返回資源對應的 URI。 好比，對於使用首部字段 Accept-Language 的服務器驅動型請求，當返回的頁面內容與實際請求的對象不一樣時，首部字段 Content-Location 內會寫明 URI。（訪問 http://www.hackr.jp/ 返回的對象倒是 http://www.hackr.jp/index-ja.... 等相似狀況）

6.Content-MD5

• 首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在於檢查報文主體在傳輸過程當中是否保持完整，以及確認傳輸到達。對報文主體執行 MD5 算法得到的 128 位二進制數，再經過 Base64 編碼後將結果寫入 Content-MD5 字段值。因爲 HTTP 首部沒法記錄二進制值，因此要經過 Base64 編碼處理。爲確保報文的有效性，做爲接收方的客戶端會對報文主體再執行一次相同的 MD5 算法。計算出的值與字段值做比較後，便可判斷出報文主體的準確性。採用這種方法，對內容上的偶發性改變是無從查證的，也沒法檢測出惡意篡改。其中一個緣由在於，內容若是可以被篡改，那麼同時意味着 Content-MD5 也可從新計算而後被篡改。因此處在接收階段的客戶端是沒法意識到報文主體以及首部字段 Content-MD5 是已經被篡改過的。

7.Content-Range

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

8.Content-Type

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

9.Expires

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

10.Last-Modified

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

---

七.爲 Cookie 服務的首部字段

• 管理服務器與客戶端之間狀態的 Cookie，雖然沒有被編入標準化 HTTP/1.1 的 RFC2616 中，但在 Web 網站方面獲得了普遍的應用。 Cookie 的工做機制是用戶識別及狀態管理。Web 網站爲了管理用戶的狀態會經過 Web 瀏覽器，把一些數據臨時寫入用戶的計算機內。接着當用戶訪問該Web網站時，可經過通訊方式取回以前發放的 Cookie。 調用 Cookie 時，因爲可校驗 Cookie 的有效期，以及發送方的域、路徑、協議等信息，因此正規發佈的 Cookie 內的數據不會因來自其餘 Web 站點和攻擊者的攻擊而泄露。
• 至 2013 年 5 月，Cookie 的規格標準文檔有如下 4 種。

RFC2109
某企業嘗試以獨立技術對 Cookie 規格進行標準化統籌。本來的意圖是想和網景公司制定的標準交互應用，惋惜發生了微妙的差別。如今該標準已淡出了人們的視線。
RFC2965
爲終結 Internet Explorer 瀏覽器與 Netscape Navigator 的標準差別而致使的瀏覽器戰爭，RFC2965 內定義了新的 HTTP 首部 Set-Cookie2 和 Cookie2。可事實上，它們幾乎沒怎麼投入使用。
RFC6265
將網景公司制定的標準做爲業界事實標準（De facto standard），從新定義 Cookie 標準後的產物。 目前使用最普遍的 Cookie 標準卻不是 RFC 中定義的任何一個。而是在網景公司制定的標準上進行擴展後的產物。

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

1.Set-Cookie

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

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 屬性的方法以下所示。

以上例子僅當在 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 的方法以下所示。

• 經過上述設置，一般從 Web 頁面內還能夠對 Cookie 進行讀取操做。 但使用 JavaScript 的 document.cookie 就沒法讀取附加 HttpOnly 屬性後 的 Cookie 的內容了。所以，也就沒法在 XSS 中利用 JavaScript 劫持 Cookie 了。 雖然是獨立的擴展功能，但 Internet Explorer 6 SP1 以上版本等當下的主流瀏覽器都已經支持該擴展了。另外順帶一提，該擴展並不是是爲了防止 XSS 而開發的。

2.Cookie

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

---

八.其餘首部字段

• HTTP 首部字段是能夠自行擴展的。因此在 Web 服務器和瀏覽器的應用上，會出現各類非標準的首部字段。
• 接下來，咱們就一些最爲經常使用的首部字段進行說明。

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

1.X-Frame-Options

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

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

• 支持該首部字段的瀏覽器有：Internet Explorer 八、Firefox 3.6.9+、 Chrome 4.1.249.1042+、Safari 4+ 和 Opera 10.50+ 等。如今主流的瀏覽器都已經支持。

能在全部的 Web 服務器端預先設定好 X-Frame-Options 字段值是最理想的狀態。

• 對 apache2.conf 的配置實例:

<IfModule mod_headers.c>
Header append X-FRAME-OPTIONS "SAMEORIGIN"
</IfModule>

2.X-XSS-Protection

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

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

3.DNT

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

0 ：贊成被追蹤
1 ：拒絕被追蹤
因爲首部字段 DNT 的功能具有有效性，因此 Web 服務器須要對 DNT 作對應的支持。

4.P3P

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

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

• 有關 P3P 的詳細規範標準請參看下方連接。

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

協議中對 X- 前綴的廢除 在 HTTP 等多種協議中，經過給非標準參數加上前綴 X-，來區別。 於標準參數，並使那些非標準的參數做爲擴展變成可能。可是這種簡單粗暴的作法有百害而無一益，所以在「RFC 6648 - Deprecating the "X-" Prefix and Similar Constructs in Application Protocols」中提議中止該作法。
然而，對已經在使用中的 X- 前綴來講，不該該要求其變動。

如下是往日學習總結，有須要的盆友能夠去看看噢~~
TCP/IP基礎總結性學習（1）：瞭解web和網絡基礎
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（2）：簡單的HTTP協議
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（3）：HTTP 報文內的 HTTP 信息
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（4）：返回結果的 HTTP 狀態碼
https://segmentfault.com/a/11...
TCP/IP基礎總結性學習（5）：與 HTTP 協做的 Web 服務器
https://segmentfault.com/a/11...