1.首部字段概述
先來回顧一下首部字段在報文的位置，HTTP 報文包含報文首部和報文主體，報文首部包含請求行（或狀態行）和首部字段。
在報文衆多的字段當中，HTTP 首部字段包含的信息最爲豐富。首部字段同時存在於請求和響應報文內，並涵蓋 HTTP 報文相關的內容信息。使用首部字段是爲了給客服端和服務器端提供報文主體大小、所使用的語言、認證信息等內容。
2.首部字段結構
- HTTP 首部字段是由首部字段名和字段值構成的，中間用冒號“：”分隔。
- 另外，字段值對應單個 HTTP 首部字段可以有多個值。
- 當 HTTP 報文首部中出現了兩個或以上具有相同首部字段名的首部字段時，這種情況在規範內尚未明確，根據瀏覽器內部處理邏輯的不同，優先處理的順序可能不同，結果可能並不一致。
| 首部字段名 | 冒號 | 字段值 |
|---|---|---|
| Content-Type | ： | text/html |
| Keep-Alive | ： | timeout=30, max=120 |
3.首部字段類型
首部字段根據實際用途被分爲以下4種類型：
| 類型 | 描述 |
|---|---|
| 通用首部字段 | 請求報文和響應報文兩方都會使用的首部 |
| 請求首部字段 | 從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、客戶端信息、響應內容相關優先級等信息 |
| 響應首部字段 | 從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容，也會要求客戶端附加額外的內容信息。 |
| 實體首部字段 | 針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的的信息。 |
4.通用首部字段（HTTP/1.1）
| 首部字段名 | 說明 |
|---|---|
| Cache-Control | 控制緩存的行爲 |
| Connection | 逐挑首部、連接的管理 |
| Date | 創建報文的日期時間 |
| Pragma | 報文指令 |
| Trailer | 報文末端的首部一覽 |
| Transfer-Encoding | 指定報文主體的傳輸編碼方式 |
| Upgrade | 升級爲其他協議 |
| Via | 代理服務器的相關信息 |
| Warning | 錯誤通知 |
4.1 Cache-Control
通過指定首部字段 Cache-Control 的指令，就能操作緩存的工作機制。
4.1.1 可用的指令一覽
可用的指令按請求和響應分類如下：
緩存請求指令
| 指令 | 參數 | 說明 |
|---|---|---|
| no-cache | 無 | 強制向服務器再次驗證 |
| no-store | 無 | 不緩存請求或響應的任何內容 |
| max-age = [秒] | 必需 | 響應的最大Age值 |
| max-stale( =[秒]) | 可省略 | 接收已過期的響應 |
| min-fresh = [秒] | 必需 | 期望在指定時間內的響應仍有效 |
| no-transform | 無 | 代理不可更改媒體類型 |
| only-if-cached | 無 | 從緩存獲取資源 |
| cache-extension | - | 新指令標記（token） |
緩存響應指令
| 指令 | 參數 | 說明 |
|---|---|---|
| public | 無 | 可向任意方提供響應的緩存 |
| private | 可省略 | 僅向特定用戶返回響應 |
| no-cache | 可省略 | 緩存前必須先確認其有效性 |
| no-store | 無 | 不緩存請求或響應的任何內容 |
| no-transform | 無 | 代理不可更改媒體類型 |
| must-revalidate | 無 | 可緩存但必須再向源服務器進行確認 |
| proxy-revalidate | 無 | 要求中間緩存服務器對緩存的響應有效性再進行確認 |
| max-age = [秒] | 必需 | 響應的最大Age值 |
| s-maxage = [秒] | 必需 | 公共緩存服務器響應的最大Age值 |
| cache-extension | - | 新指令標記（token） |
4.1.2 表示能否緩存的指令
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 指令時，暗示請求（和對應的響應）或響應中包含機密信息。因此，該指令規定緩存不能在本地存儲請求或響應的任一部分。
注意：no-cache 指令代表不緩存過期的指令，緩存會向源服務器進行有效期確認後處理資源；no-store 指令纔是真正的不進行緩存。
4.1.3 指定緩存期限和認證的指令
s-maxage 指令Cache-Control: s-maxage=604800（單位：秒）
- s-maxage 指令的功能和 max-age 指令的相同，它們的不同點是 s-maxage 指令只適用於供多位用戶使用的公共緩存服務器（一般指代理）。也就是說，對於向同一用戶重複返回響應的服務器來說，這個指令沒有任何作用。
- 另外，當使用 s-maxage 指令後，則直接忽略對 Expires 首部字段及 max-age 指令的處理。
max-age 指令Cache-Control: max-age=604800（單位：秒）
- 當客戶端發送的請求中包含 max-age 指令時，如果判定緩存資源的緩存時間數值比指定的時間更小，那麼客戶端就接收緩存的資源。另外，當指定 max-age 的值爲0，那麼緩存服務器通常需要將請求轉發給源服務器。
- 當服務器返回的響應中包含 max-age 指令時，緩存服務器將不對資源的有效性再作確認，而 max-age 數值代表資源保存爲緩存的最長時間。
- 應用 HTTP/1.1 版本的緩存服務器遇到同時存在 Expires 首部字段的情況時，會優先處理 max-age 指令，並忽略掉 Expires 首部字段；而 HTTP/1.0 版本的緩存服務器則相反。
min-fresh 指令Cache-Control: min-fresh=60（單位：秒）
min-fresh 指令要求緩存服務器返回至少還未過指定時間的緩存資源。
max-stale 指令Cache-Control: max-stale=3600（單位：秒）
- 使用 max-stale 可指示緩存資源，即使過期也照常接收。
- 如果指令未指定參數值，那麼無論經過多久，客戶端都會接收響應；如果指定了具體參數值，那麼即使過期，只要仍處於 max-stale 指定的時間內，仍舊會被客戶端接收。
only-if-cached 指令Cache-Control: only-if-cached
表示客戶端僅在緩存服務器本地緩存目標資源的情況下才會要求其返回。換言之，該指令要求緩存服務器不重新加載響應，也不會再次確認資源的有效性。
must-revalidate 指令Cache-Control: must-revalidate
使用 must-revalidate 指令，代理會向源服務器再次驗證即將返回的響應緩存目前是否仍有效。另外，使用 must-revalidate 指令會忽略請求的 max-stale 指令。
proxy-revalidate 指令Cache-Control: proxy-revalidate
proxy-revalidate 指令要求所有的緩存服務器在接收到客戶端帶有該指令的請求返回響應之前，必須再次驗證緩存的有效性。
no-transform 指令Cache-Control: no-transform
使用 no-transform 指令規定無論是在請求還是響應中，緩存都不能改變實體主體的媒體類型。這樣做可防止緩存或代理壓縮圖片等類似操作。
4.1.4 Cache-Control 擴展
Cache-Control: private, community="UCI"
通過 cache-extension 標記（token），可以擴展 Cache-Control 首部字段內的指令。上述 community 指令即擴展的指令，如果緩存服務器不能理解這個新指令，就會直接忽略掉。
4.2 Connection
Connection 首部字段具備以下兩個作用：
控制不再轉發的首部字段Connection: Upgrade
在客戶端發送請求和服務器返回響應中，使用 Connection 首部字段，可控制不再轉發給代理的首部字段，即刪除後再轉發（即Hop-by-hop首部）。
管理持久連接Connection: close
HTTP/1.1 版本的默認連接都是持久連接。當服務器端想明確斷開連接時，則指定 Connection 首部字段的值爲 close。Connection: Keep-Alive
HTTP/1.1 之前的 HTTP 版本的默認連接都是非持久連接。爲此，如果想在舊版本的 HTTP 協議上維持持續連接，則需要指定 Connection 首部字段的值爲 Keep-Alive。
4.3 Date
表明創建 HTTP 報文的日期和時間。Date: Mon, 10 Jul 2017 15:50:06 GMT
HTTP/1.1 協議使用在 RFC1123 中規定的日期時間的格式。
4.4 Pragma
Pragma 首部字段是 HTTP/1.1 版本之前的歷史遺留字段，僅作爲與 HTTP/1.0 的向後兼容而定義。Pragma: no-cache
- 該首部字段屬於通用首部字段，但只用在客戶端發送的請求中，要求所有的中間服務器不返回緩存的資源。
- 所有的中間服務器如果都能以 HTTP/1.1 爲基準，那直接採用
Cache-Control: no-cache指定緩存的處理方式最爲理想。但是要整體掌握所有中間服務器使用的 HTTP 協議版本卻是不現實的，所以，發送的請求會同時包含下面兩個首部字段：
Cache-Control: no-cache
Pragma: no-cache
4.5 Trailer
Trailer: Expires
首部字段 Trailer 會事先說明在報文主體後記錄了哪些首部字段。可應用在 HTTP/1.1 版本分塊傳輸編碼時。
4.6 Transfer-Encoding
Transfer-Encoding: chunked
- 規定了傳輸報文主體時採用的編碼方式。
- HTTP/1.1 的傳輸編碼方式僅對分塊傳輸編碼有效。
4.7 Upgrade
Upgrade: TSL/1.0
用於檢測 HTTP 協議及其他協議是否可使用更高的版本進行通信，其參數值可以用來指定一個完全不同的通信協議。
4.8 Via
Via: 1.1 a1.sample.com(Squid/2.7)
- 爲了追蹤客戶端和服務器端之間的請求和響應報文的傳輸路徑。
- 報文經過代理或網關時，會現在首部字段 Via 中附加該服務器的信息，然後再進行轉發。
- 首部字段 Via 不僅用於追蹤報文的轉發，還可避免請求迴環的發生。
4.9 Warning
該首部字段通常會告知用戶一些與緩存相關的問題的警告。
Warning 首部字段的格式如下：Warning：[警告碼][警告的主機:端口號] "[警告內容]"([日期時間])
最後的日期時間可省略。
HTTP/1.1 中定義了7種警告，警告碼對應的警告內容僅推薦參考，另外，警告碼具備擴展性，今後有可能追加新的警告碼。
| 警告碼 | 警告內容 | 說明 |
|---|---|---|
| 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(持久雜項警告) | 任意的警告內容 |
5. 請求首部字段（HTTP/1.1）
| 首部字段名 | 說明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型 |
| Accept-Charset | 優先的字符集 |
| Accept-Encoding | 優先的內容編碼 |
| Accept-Language | 優先的語言（自然語言） |
| Authorization | Web認證信息 |
| Expect | 期待服務器的特定行爲 |
| From | 用戶的電子郵箱地址 |
| Host | 請求資源所在服務器 |
| If-Match | 比較實體標記（ETag） |
| If-Modified-Since | 比較資源的更新時間 |
| If-None-Match | 比較實體標記（與 If-Macth 相反） |
| If-Range | 資源未更新時發送實體 Byte 的範圍請求 |
| If-Unmodified-Since | 比較資源的更新時間(與 If-Modified-Since 相反) |
| Max-Forwards | 最大傳輸逐跳數 |
| Proxy-Authorization | 代理服務器要求客戶端的認證信息 |
| Range | 實體的字節範圍請求 |
| Referer | 對請求中 URI 的原始獲取方 |
| TE | 傳輸編碼的優先級 |
| User-Agent | HTTP 客戶端程序的信息 |
5.1 Accept
Accept: text/html, application/xhtml+xml, application/xml; q=0.5
- Accept 首部字段可通知服務器，用戶代理能夠處理的媒體類型及媒體類型的相對優先級。可使用 type/subtype 這種形式，一次指定多種媒體類型。
- 若想要給顯示的媒體類型增加優先級，則使用
q=[數值]來表示權重值，用分號（;）進行分隔。權重值的範圍 0~1（可精確到小數點後三位），且 1 爲最大值。不指定權重值時，默認爲 1。
5.2 Accept-Charset
Accept-Charset: iso-8859-5, unicode-1-1; q=0.8
Accept-Charset 首部字段可用來通知服務器用戶代理支持的字符集及字符集的相對優先順序。另外，可一次性指定多種字符集。同樣使用 q=[數值] 來表示相對優先級。
5.3 Accept-Encoding
Accept-Encoding: gzip, deflate
Accept-Encoding 首部字段用來告知服務器用戶代理支持的內容編碼及內容編碼的優先順序，並可一次性指定多種內容編碼。同樣使用 q=[數值] 來表示相對優先級。也可使用星號（*）作爲通配符，指定任意的編碼格式。
5.4 Accept-Language
Accept-Lanuage: zh-cn,zh;q=0.7,en=us,en;q=0.3
告知服務器用戶代理能夠處理的自然語言集（指中文或英文等），以及自然語言集的相對優先級，可一次性指定多種自然語言集。同樣使用 q=[數值] 來表示相對優先級。
5.5 Authorization
Authorization: Basic ldfKDHKfkDdasSAEdasd==
告知服務器用戶代理的認證信息（證書值）。通常，想要通過服務器認證的用戶代理會在接收到返回的 401 狀態碼響應後，把首部字段 Authorization 加入請求中。共用緩存在接收到含有 Authorization 首部字段的請求時的操作處理會略有差異。
5.6 Expect
Expect: 100-continue
告知服務器客戶端期望出現的某種特定行爲。
5.7 From
From: [email protected]
告知服務器使用用戶代理的電子郵件地址。
5.8 Host
Host: www.jianshu.com
- 告知服務器，請求的資源所處的互聯網主機和端口號。
- Host 首部字段是 HTTP/1.1 規範內唯一一個必須被包含在請求內的首部字段。
- 若服務器未設定主機名，那直接發送一個空值即可
Host:。
5.9 If-Match
形如 If-xxx 這種樣式的請求首部字段，都可稱爲條件請求。服務器接收到附帶條件的請求後，只有判斷指定條件爲真時，纔會執行請求。
If-Match: "123456"
- 首部字段 If-Match，屬附帶條件之一，它會告知服務器匹配資源所用的實體標記（ETag）值。這時的服務器無法使用弱 ETag 值。
- 服務器會比對 If-Match 的字段值和資源的 ETag 值，僅當兩者一致時，纔會執行請求。反之，則返回狀態碼
412 Precondition Failed的響應。 - 還可以使用星號（*）指定 If-Match 的字段值。針對這種情況，服務器將會忽略 ETag 的值，只要資源存在就處理請求。
5.10 If-Modified-Since
If-Modified-Since: Mon, 10 Jul 2017 15:50:06 GMT
- 首部字段 If-Modified-Since，屬附帶條件之一，用於確認代理或客戶端擁有的本地資源的有效性。
- 它會告知服務器若 If-Modified-Since 字段值早於資源的更新時間，則希望能處理該請求。而在指定 If-Modified-Since 字段值的日期時間之後，如果請求的資源都沒有過更新，則返回狀態碼
304 Not Modified的響應。
5.11 If-None-Match
If-None-Match: "123456"
首部字段 If-None-Match 屬於附帶條件之一。它和首部字段 If-Match 作用相反。用於指定 If-None-Match 字段值的實體標記（ETag）值與請求資源的 ETag 不一致時，它就告知服務器處理該請求。
5.12 If-Range
If-Range: "123456"
- 首部字段 If-Range 屬於附帶條件之一。它告知服務器若指定的 If-Range 字段值（ETag 值或者時間）和請求資源的 ETag 值或時間相一致時，則作爲範圍請求處理。反之，則返回全體資源。
- 下面我們思考一下不使用首部字段 If-Range 發送請求的情況。服務器端的資源如果更新，那客戶端持有資源中的一部分也會隨之無效，當然，範圍請求作爲前提是無效的。這時，服務器會暫且以狀態碼
412 Precondition Failed作爲響應返回，其目的是催促客戶端再次發送請求。這樣一來，與使用首部字段 If-Range 比起來，就需要花費兩倍的功夫。
5.13 If-Unmodified-Since
If-Unmodified-Since: Mon, 10 Jul 2017 15:50:06 GMT
首部字段 If-Unmodified-Since 和首部字段 If-Modified-Since 的作用相反。它的作用的是告知服務器，指定的請求資源只有在字段值內指定的日期時間之後，未發生更新的情況下，才能處理請求。如果在指定日期時間後發生了更新，則以狀態碼 412 Precondition Failed 作爲響應返回。
5.14 Max-Forwards
Max-Forwards: 10
通過 TRACE 方法或 OPTIONS 方法，發送包含首部字段 Max-Forwards 的請求時，該字段以十進制整數形式指定可經過的服務器最大數目。服務器在往下一個服務器轉發請求之前，Max-Forwards 的值減 1 後重新賦值。當服務器接收到 Max-Forwards 值爲 0 的請求時，則不再進行轉發，而是直接返回響應。
5.15 Proxy-Authorization
Proxy-Authorization: Basic dGlwOjkpNLAGfFY5
- 接收到從代理服務器發來的認證質詢時，客戶端會發送包含首部字段 Proxy-Authorization 的請求，以告知服務器認證所需要的信息。
- 這個行爲是與客戶端和服務器之間的 HTTP 訪問認證相類似的，不同之處在於，認證行爲發生在客戶端與代理之間。
5.16 Range
Range: bytes=5001-10000
- 對於只需獲取部分資源的範圍請求，包含首部字段 Range 即可告知服務器資源的指定範圍。
- 接收到附帶 Range 首部字段請求的服務器，會在處理請求之後返回狀態碼爲
206 Partial Content的響應。無法處理該範圍請求時，則會返回狀態碼200 OK的響應及全部資源。
5.17 Referer
Referer: http://www.sample.com/index.html
首部字段 Referer 會告知服務器請求的原始資源的 URI。
5.18 TE
TE: gzip, deflate; q=0.5
- 首部字段 TE 會告知服務器客戶端能夠處理響應的傳輸編碼方式及相對優先級。它和首部字段 Accept-Encoding 的功能很相像，但是用於傳輸編碼。
- 首部字段 TE 除指定傳輸編碼之外，還可以指定伴隨 trailer 字段的分塊傳輸編碼的方式。應用後者時，只需把 trailers 賦值給該字段值。
TE: trailers
5.19 User-Agent
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101
- 首部字段 User-Agent 會將創建請求的瀏覽器和用戶代理名稱等信息傳達給服務器。
- 由網絡爬蟲發起請求時，有可能會在字段內添加爬蟲作者的電子郵件地址。此外，如果請求經過代理，那麼中間也很可能被添加上代理服務器的名稱。
6. 響應首部字段（HTTP/1.1）
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節範圍請求 |
| Age | 推算資源創建經過時間 |
| ETag | 資源的匹配信息 |
| Location | 令客戶端重定向至指定 URI |
| Proxy-Authenticate | 代理服務器對客戶端的認證信息 |
| Retry-After | 對再次發起請求的時機要求 |
| Server | HTTP 服務器的安裝信息 |
| Vary | 代理服務器緩存的管理信息 |
| WWW-Authenticate | 服務器對客戶端的認證信息 |
6.1 Accept-Ranges
Accept-Ranges: bytes
- 首部字段 Accept-Ranges 是用來告知客戶端服務器是否能處理範圍請求，以指定獲取服務器端某個部分的資源。
- 可指定的字段值有兩種，可處理範圍請求時指定其爲 bytes，反之則指定其爲 none。
6.2 Age
Age: 1200
- 首部字段 Age 能告知客戶端，源服務器在多久前創建了響應。字段值的單位爲秒。
- 若創建該響應的服務器是緩存服務器，Age 值是指緩存後的響應再次發起認證到認證完成的時間值。代理創建響應時必須加上首部字段 Age。
6.3 ETag
ETag: "usagi-1234"
- 首部字段 ETag 能告知客戶端實體標識。它是一種可將資源以字符串形式做唯一性標識的方式。服務器會爲每份資源分配對應的 ETag 值。
- 另外，當資源更新時，ETag 值也需要更新。生成 ETag 值時，並沒有統一的算法規則，而僅僅是由服務器來分配。
- ETag 中有強 ETag 值和弱 ETag 值之分。強 ETag 值，不論實體發生多麼細微的變化都會改變其值；弱 ETag 值只用於提示資源是否相同。只有資源發生了根本改變，產生差異時纔會改變 ETag 值。這時，會在字段值最開始處附加 W/：
ETag: W/"usagi-1234"。
6.4 Location
Location: http://www.sample.com/sample.html
- 使用首部字段 Location 可以將響應接收方引導至某個與請求 URI 位置不同的資源。
- 基本上，該字段會配合 3xx ：Redirection 的響應，提供重定向的 URI。
- 幾乎所有的瀏覽器在接收到包含首部字段 Location 的響應後，都會強制性地嘗試對已提示的重定向資源的訪問。
6.5 Proxy-Authenticate
Proxy-Authenticate: Basic realm="Usagidesign Auth"
- 首部字段 Proxy-Authenticate 會把由代理服務器所要求的認證信息發送給客戶端。
- 它與客戶端和服務器之間的 HTTP 訪問認證的行爲相似，不同之處在於其認證行爲是在客戶端與代理之間進行的。
6.6 Retry-After
Retry-After: 180
- 首部字段 Retry-After 告知客戶端應該在多久之後再次發送請求。主要配合狀態碼
503 Service Unavailable響應，或 3xx Redirect 響應一起使用。 - 字段值可以指定爲具體的日期時間（Mon, 10 Jul 2017 15:50:06 GMT 等格式），也可以是創建響應後的秒數。
6.7 Server
Server: Apache/2.2.6 (Unix) PHP/5.2.5
首部字段 Server 告知客戶端當前服務器上安裝的 HTTP 服務器應用程序的信息。不單單會標出服務器上的軟件應用名稱，還有可能包括版本號和安裝時啓用的可選項。
6.8 Vary
Vary: Accept-Language
- 首部字段 Vary 可對緩存進行控制。源服務器會向代理服務器傳達關於本地緩存使用方法的命令。
- 從代理服務器接收到源服務器返回包含 Vary 指定項的響應之後，若再要進行緩存，僅對請求中含有相同 Vary 指定首部字段的請求返回緩存。即使對相同資源發起請求，但由於 Vary 指定的首部字段不相同，因此必須要從源服務器重新獲取資源。
6.9 WWW-Authenticate
WWW-Authenticate: Basic realm="Usagidesign Auth"
首部字段 WWW-Authenticate 用於 HTTP 訪問認證。它會告知客戶端適用於訪問請求 URI 所指定資源的認證方案（Basic 或是 Digest）和帶參數提示的質詢（challenge）。
7. 實體首部字段（HTTP/1.1）
| 首部字段名 | 說明 |
|---|---|
| Allow | 資源可支持的 HTTP 方法 |
| Content-Encoding | 實體主體適用的編碼方式 |
| Content-Language | 實體主體的自然語言 |
| Content-Length | 實體主體的大小（單位：字節） |
| Content-Location | 替代對應資源的 URI |
| Content-MD5 | 實體主體的報文摘要 |
| Content-Range | 實體主體的位置範圍 |
| Content-Type | 實體主體的媒體類型 |
| Expires | 實體主體過期的日期時間 |
| Last-Modified | 資源的最後修改日期時間 |
7.1 Allow
Allow: GET, HEAD
- 首部字段 Allow 用於通知客戶端能夠支持 Request-URI 指定資源的所有 HTTP 方法。
- 當服務器接收到不支持的 HTTP 方法時，會以狀態碼
405 Method Not Allowed作爲響應返回。與此同時，還會把所有能支持的 HTTP 方法寫入首部字段 Allow 後返回。
7.2 Content-Encoding
Content-Encoding: gzip
- 首部字段 Content-Encoding 會告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼是指在不丟失實體信息的前提下所進行的壓縮。
- 主要採用這 4 種內容編碼的方式（gzip、compress、deflate、identity）。
7.3 Content-Language
Content-Language: zh-CN
首部字段 Content-Language 會告知客戶端，實體主體使用的自然語言（指中文或英文等語言）。
7.4 Content-Length
Content-Length: 15000
首部字段 Content-Length 表明了實體主體部分的大小（單位是字節）。對實體主體進行內容編碼傳輸時，不能再使用 Content-Length首部字段。
7.5 Content-Location
Content-Location: http://www.sample.com/index.html
首部字段 Content-Location 給出與報文主體部分相對應的 URI。和首部字段 Location 不同，Content-Location 表示的是報文主體返回資源對應的 URI。
7.6 Content-MD5
Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==
首部字段 Content-MD5 是一串由 MD5 算法生成的值，其目的在於檢查報文主體在傳輸過程中是否保持完整，以及確認傳輸到達。
7.7 Content-Range
Content-Range: bytes 5001-10000/10000
針對範圍請求，返回響應時使用的首部字段 Content-Range，能告知客戶端作爲響應返回的實體的哪個部分符合範圍請求。字段值以字節爲單位，表示當前發送部分及整個實體大小。
7.8 Content-Type
Content-Type: text/html; charset=UTF-8
首部字段 Content-Type 說明了實體主體內對象的媒體類型。和首部字段 Accept 一樣，字段值用 type/subtype 形式賦值。參數 charset 使用 iso-8859-1 或 euc-jp 等字符集進行賦值。
7.9 Expires
Expires: Mon, 10 Jul 2017 15:50:06 GMT
- 首部字段 Expires 會將資源失效的日期告知客戶端。
- 緩存服務器在接收到含有首部字段 Expires 的響應後，會以緩存來應答請求，在 Expires 字段值指定的時間之前，響應的副本會一直被保存。當超過指定的時間後，緩存服務器在請求發送過來時，會轉向源服務器請求資源。
- 源服務器不希望緩存服務器對資源緩存時，最好在 Expires 字段內寫入與首部字段 Date 相同的時間值。
7.10 Last-Modified
Last-Modified: Mon, 10 Jul 2017 15:50:06 GMT
首部字段 Last-Modified 指明資源最終修改的時間。一般來說，這個值就是 Request-URI 指定資源被修改的時間。但類似使用 CGI 腳本進行動態數據處理時，該值有可能會變成數據最終修改時的時間。
8. 爲 Cookie 服務的首部字段
| 首部字段名 | 說明 | 首部類型 |
|---|---|---|
| Set-Cookie | 開始狀態管理所使用的 Cookie 信息 | 響應首部字段 |
| Cookie | 服務器接收到的 Cookie 信息 | 請求首部字段 |
8.1 Set-Cookie
Set-Cookie: status=enable; expires=Mon, 10 Jul 2017 15:50:06 GMT; path=/;
下面的表格列舉了 Set-Cookie 的字段值。
| 屬性 | 說明 |
|---|---|
| NAME=VALUE | 賦予 Cookie 的名稱和其值（必需項） |
| expires=DATE | Cookie 的有效期（若不明確指定則默認爲瀏覽器關閉前爲止） |
| path=PATH | 將服務器上的文件目錄作爲Cookie的適用對象（若不指定則默認爲文檔所在的文件目錄） |
| domain=域名 | 作爲 Cookie 適用對象的域名 （若不指定則默認爲創建 Cookie的服務器的域名） |
| Secure | 僅在 HTTPS 安全通信時纔會發送 Cookie |
| HttpOnly | 加以限制，使 Cookie 不能被 JavaScript 腳本訪問 |
8.1.1 expires 屬性
- Cookie 的 expires 屬性指定瀏覽器可發送 Cookie 的有效期。
- 當省略 expires 屬性時，其有效期僅限於維持瀏覽器會話（Session）時間段內。這通常限於瀏覽器應用程序被關閉之前。
- 另外，一旦 Cookie 從服務器端發送至客戶端，服務器端就不存在可以顯式刪除 Cookie 的方法。但可通過覆蓋已過期的 Cookie，實現對客戶端 Cookie 的實質性刪除操作。
8.1.2 path 屬性
Cookie 的 path 屬性可用於限制指定 Cookie 的發送範圍的文件目錄。
8.1.3 domain 屬性
- 通過 Cookie 的 domain 屬性指定的域名可做到與結尾匹配一致。比如，當指定 example.com 後，除example.com 以外，www.example.com 或 www2.example.com 等都可以發送 Cookie。
- 因此，除了針對具體指定的多個域名發送 Cookie 之 外，不指定 domain 屬性顯得更安全。
8.1.4 secure 屬性
Cookie 的 secure 屬性用於限制 Web 頁面僅在 HTTPS 安全連接時，纔可以發送 Cookie。
8.1.5 HttpOnly 屬性
- Cookie 的 HttpOnly 屬性是 Cookie 的擴展功能，它使 JavaScript 腳本無法獲得 Cookie。其主要目的爲防止跨站腳本攻擊（Cross-site scripting，XSS）對 Cookie 的信息竊取。
- 通過上述設置，通常從 Web 頁面內還可以對 Cookie 進行讀取操作。但使用 JavaScript 的 document.cookie 就無法讀取附加 HttpOnly 屬性後的 Cookie 的內容了。因此，也就無法在 XSS 中利用 JavaScript 劫持 Cookie 了。
8.2 Cookie
Cookie: status=enable
首部字段 Cookie 會告知服務器，當客戶端想獲得 HTTP 狀態管理支持時，就會在請求中包含從服務器接收到的 Cookie。接收到多個 Cookie 時，同樣可以以多個 Cookie 形式發送。
9. 其他首部字段
HTTP 首部字段是可以自行擴展的。所以在 Web 服務器和瀏覽器的應用上，會出現各種非標準的首部字段。
以下是最爲常用的首部字段。
9.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://sample.com/sample.html 頁面爲 SAMEORIGIN 時，那麼 sample.com 上所有頁面的 frame 都被允許可加載該頁面，而 example.com 等其他域名的頁面就不行了）
9.2 X-XSS-Protection
X-XSS-Protection: 1
首部字段 X-XSS-Protection 屬於 HTTP 響應首部，它是針對跨站腳本攻擊（XSS）的一種對策，用於控制瀏覽器 XSS 防護機制的開關。首部字段 X-XSS-Protection 可指定的字段值如下:
- 0 ：將 XSS 過濾設置成無效狀態
- 1 ：將 XSS 過濾設置成有效狀態
9.3 DNT
DNT: 1
首部字段 DNT 屬於 HTTP 請求首部，其中 DNT 是 Do Not Track 的簡稱，意爲拒絕個人信息被收集，是表示拒絕被精準廣告追蹤的一種方法。首部字段 DNT 可指定的字段值如下：
- 0 ：同意被追蹤
- 1 ：拒絕被追蹤
由於首部字段 DNT 的功能具備有效性，所以 Web 服務器需要對 DNT做對應的支持。
9.4 P3P
P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS IND
首部字段 P3P 屬於 HTTP 響應首部，通過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺）技術，可以讓 Web 網站上的個人隱私變成一種僅供程序可理解的形式，以達到保護用戶隱私的目的。
要進行 P3P 的設定，需按以下操作步驟進行：
- 步驟 1：創建 P3P 隱私
- 步驟 2：創建 P3P 隱私對照文件後，保存命名在 /w3c/p3p.xml
- 步驟 3：從 P3P 隱私中新建 Compact policies 後，輸出到 HTTP 響應中