HTTP 訊息頭

HTTP 請求頭提供請求或答覆的所需資訊,或者表示關於訊息正文中傳送的物件. 一共有四種請求頭型別:

• General-header: 同時適用於請求和響應訊息，但與最終訊息主體中傳輸的資料無關的訊息頭.
• Client Request-header: 這些標頭欄位僅適用於請求訊息.
• Server Response-header: 這些標頭欄位僅適用於響應訊息.
• Entity-header: 這些標頭欄位定義有關實體主體的元資訊，如果沒有主體，則定義有關請求標識的資源的元資訊.

General Headers

Cache-Control

Cache-Control 請求頭欄位用於指定所有快取系統必須遵守的指令。語法如下：

Cache-Control : cache-request-directive|cache-response-directive

HTTP 客戶端或伺服器可以使用 Cache-control 來指定快取引數或從快取中請求某些型別的文件。快取指令在逗號分隔的列表中指定。例如：

Cache-control: no-cache

下表列出了客戶端可以在其 HTTP 請求中使用的重要快取請求指令：

The following important cache response directives that can be used by the server in its HTTP response:

Connection

Connection 欄位允許傳送方指定該特定連線所需的選項，並且代理不能通過其他連線傳達這些選項。以下是使用連線頭的簡單語法:

Connection : "Connection"

HTTP / 1.1 為傳送者定義了“關閉”連線選項，以指示響應完成後將關閉連線。例如：

Connection: close

預設情況下，HTTP 1.1 使用持久連線，該連線在事務處理後不會自動關閉。另一方面，預設情況下，HTTP 1.0 沒有持久連線。如果 1.0 客戶端希望使用持久連線，則使用 keep-alive 引數，如下所示：

Connection: keep-alive

Date

所有 HTTP 日期/時間戳都必須毫無例外地以格林威治標準時間（GMT）表示。允許 HTTP 應用程式使用日期/時間戳的以下三種表示形式中的任何一種：

Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format

第一種格式是最優選的格式。

Pragma

Pragma 欄位用於包含特定指令的實現，這些指令可能適用於請求/響應鏈中的任何接收者。例如：

Pragma: no-cache

HTTP / 1.0 中定義的唯一指令是 no-cache 指令，並在 HTTP 1.1 中進行維護以實現向後相容。將來不會定義新的 Pragma 指令。

Trailer

Trailer 欄位允許傳送方在分塊傳送的訊息後面新增額外的元資訊，這些元資訊可能是隨著訊息主體的傳送動態生成的，比如訊息的完整性校驗，訊息的數字簽名，或者訊息經過處理之後的最終狀態等。

Trailer : field-name

出現在分塊資訊掛載部分的訊息首部。以下首部欄位不允許出現：

• 用於資訊分幀的首部 (例如 Transfer-Encoding 和 Content-Length),
• 用於路由用途的首部 (例如 Host)，
• 請求修飾首部 (例如控制類和條件類的，如 Cache-Control，Max-Forwards，或者 TE)，
• 身份驗證首部 (例如 Authorization 或者 Set-Cookie)，
• Content-Encoding, Content-Type, Content-Range，以及 Trailer 自身。

Transfer-Encoding

Transfer-Encoding 訊息首部指明瞭將 entity 安全傳遞給使用者所採用的編碼形式。
Transfer-Encoding 是一個逐跳傳輸訊息首部，即僅應用於兩個節點之間的訊息傳遞，而不是所請求的資源本身。一個多節點連線中的每一段都可以應用不同的 Transfer-Encoding 值。如果你想要將壓縮後的資料應用於整個連線，那麼請使用端到端傳輸訊息請求頭 Content-Encoding 。

Transfer-Encoding: chunked

所有傳輸編碼值都不區分大小寫。

Upgrade

Upgrade 允許客戶端指定其支援的其他通訊協議並在伺服器認為適合切換協議時優先使用. 例如：

Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11

Upgrade 旨在提供一種從 HTTP / 1.1 過渡到其他不相容協議的簡單機制。

Via

閘道器和代理必須使用 Via 來指示中間協議和收件人. 例如，可以將請求訊息從 HTTP / 1.0 使用者代理髮送到名為“ fred”的內部代理，該代理使用 HTTP / 1.1 將請求轉發到 nowhere.com 上的公共代理，從而完成請求通過將其轉發到位於www.ics.uci.edu的原始伺服器。 www.ics.uci.edu收到的請求將具有以下Via標頭欄位：

Via: 1.0 fred, 1.1 nowhere.com (Apache/1.1)

Upgrade 旨在提供一種從 HTTP / 1.1 過渡到其他不相容協議的簡單機制。

Warning

Warning 用於承載有關狀態訊息或轉換資訊，這些資訊可能未反映在訊息中。一個響應可能包含多個警告標頭。

Warning : warn-code SP warn-agent SP warn-text SP warn-date

Client Request Headers

Accept

Accept 可用於某些特定的對響應方可接受的媒體型別。通用語法如下：

Accept: type/subtype [q=qvalue]

可以列出多個用逗號分隔的媒體型別，可選的 qvalue 表示可接受型別的可接受質量等級，範圍為 0 到 1。以下是一個示例：

Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c

這將被解釋為 text / html和text / xc是首選的媒體型別，但是如果它們不存在，則傳送text / x-dvi實體，如果如果不存在，則傳送text / plain實體。

Accept-Charset

Accept-Charset 可以用來指示響應可接受的字符集。以下是一般語法：

Accept-Charset: character_set [q=qvalue]
可以列出多個字符集，以逗號隔開，可選的 qvalue 表示非首選字符集的可接受質量等級，範圍為 0 到 1。以下是一個示例：

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

特殊值“ \ *”（如果出現在** Accept-Charset 欄位中）與每個字符集匹配，並且如果不存在 Accept-Charset **頭，則預設為任何字符集都是可接受的。

Accept-Encoding

Accept-Encoding 與“Accept”相似，但限制了響應中可接受的內容編碼。通用語法為：

Accept-Encoding: encoding types
示例如下：

Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: \*
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, \*;q=0

Accept-Language

Accept-Language 與“Accept”相似，但限制了優先用於響應請求的自然語言集。通用語法為：

Accept-Language: language [q=qvalue]

可以列出多種語言，以逗號分隔，可選的 qvalue 表示非首選語言的可接受質量等級，範圍為 0 到 1。以下是一個示例：

Accept-Language: da, en-gb;q=0.8, en;q=0.7

Authorization

Authorization 值由憑證組成，憑證包含用於所請求資源領域的使用者代理的認證資訊。通用語法為：

Authorization : credentials

HTTP / 1.0 規範定義了 BASIC 授權方案，其中授權引數是以 base 64 編碼的username：password字串。以下是一個示例：

Authorization: BASIC Z3Vlc3Q6Z3Vlc3QxMjM=

解碼為的值是guest：guest123，其中guest 是使用者 ID，而 guest123 **是密碼。

Cookie

Cookie 包含為該 URL 儲存的名稱/值資訊對。以下是一般語法：

Cookie: name=value

可以指定多個 cookie，並用分號隔開，如下所示：

Cookie: name1=value1;name2=value2;name3=value3

Expect

表示伺服器只有在滿足此期望條件的情況下才能妥善地處理請求。

Expect : 100-continue | expectation-extension

如果伺服器收到的請求包含包含不支援的期望副檔名的 Expect 欄位，則伺服器必須以 417（期望失敗）狀態進行響應。

From

From 包含用於控制請求使用者代理的人工使用者的 Internet 電子郵件地址。以下是一個簡單的示例：

From: [email protected]

該頭欄位可以用於登入目的，並且可以用作鑑別不想要或者不合規請求的手段。

Host

Host 用於指定 Internet 主機和所請求資源的埠號。通用語法為：

Host : "Host" ":" host [ ":" port ] ;

沒有任何尾隨埠資訊的主機表示預設埠為 80。例如，原始伺服器上對http://www.w3.org/pub/WWW/的請求為：

GET /pub/WWW/ HTTP/1.1
Host: www.w3.org

If-Match

If-Match 與方法一起使用,它是方法執行的條件。僅當此標記中的給定值與ETag表示的給定實體標記匹配時，此標頭才請求伺服器執行請求的方法。通用語法為：

If-Match : entity-tag

星號（*）與任何實體匹配，並且僅當該實體存在時交換才繼續。以下是可能的示例：

If-Match: "xyzzy"
If-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-Match: *

如果沒有任何實體標記匹配，或者給出了“ *”並且不存在當前實體，則伺服器不得執行請求的方法，並且必須返回 412（失敗的前提條件）響應。

If-Modified-Since

If-Modified-Since 與方法一起使用,它是方法執行的條件。如果自此欄位中指定的時間以來未修改請求的 URL，則不會從伺服器返回實體；相反，將返回 304（未修改）響應，而沒有任何訊息正文。 if-modified-since 的一般語法為：

If-Modified-Since : HTTP-date

該欄位的示例是：

If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

如果沒有任何實體標記匹配，或者給出了“ *”並且不存在當前實體，則伺服器不得執行請求的方法，並且必須返回 412（失敗的前提條件）響應。

If-None-Match

If-None-Match 與方法一起使用,它是方法執行的條件。僅當此標記中給定值之一與ETag表示的給定實體標記匹配時，此標頭才請求伺服器執行請求的方法。通用語法為：

If-None-Match : entity-tag

星號（\ *）與任何實體匹配，並且僅當該實體不存在時交易才繼續。以下是可能的示例：

If-None-Match: "xyzzy"
If-None-Match: "xyzzy", "r2d2xxxx", "c3piozzzz"
If-None-Match: *

If-Range

if-Range 可以與條件 GET 一起使用，如果尚未更改，僅請求缺少的實體部分，如果已更改則請求整個實體。通用語法如下：

If-Range : entity-tag | HTTP-date

實體標籤或日期均可用於標識已接收的部分實體。例如：

If-Range: Sat, 29 Oct 1994 19:43:31 GMT

如果自給定日期以來未對文件進行過修改，則伺服器將返回 Range 標頭給出的位元組範圍，否則它將返回所有新文件。

If-Unmodified-Since

If-Unmodified-Since 與方法一起使用,它是方法執行的條件。通用語法為：

If-Unmodified-Since : HTTP-date

如果自此欄位中指定的時間以來尚未修改請求的資源，則伺服器應執行請求的操作，就像不存在 If-Unmodified-Since 標頭一樣。例如：

If-Unmodified-Since: Sat, 29 Oct 1994 19:43:31 GMT

如果請求的結果不是 2xx 或 412 狀態，則 If-Unmodified-Since 標頭應被忽略。

Max-Forwards

Max-Forwards 提供一種用 TRACE 和 OPTIONS 方法限制可以將請求轉發到下一個入站伺服器的代理或閘道器的數量的機制。以下是一般語法：

Max-Forwards : n

Max-Forwards 值是一個十進位制整數，指示可以轉發此請求訊息的剩餘次數。這對於使用 TRACE 方法進行除錯很有用，可避免無限迴圈。例如：

Max-Forwards : 5

Max-Forwards 對於 HTTP 規範中定義的所有其他方法，可以忽略。

Proxy-Authorization

代理授權允許客戶端向需要身份驗證的代理標識自己（或其使用者）。以下是一般語法：

Proxy-Authorization : credentials

Proxy-Authorization 由憑證組成，憑證包含用於所請求資源的代理和/或領域的使用者代理的認證資訊。

Range

Range 指定從文件請求的內容的範圍。通用語法為：

Range: bytes-unit=first-byte-pos "-" [last-byte-pos]

指定的位元組位置包括在內。您可以將位元組單位指定為位元組。位元組偏移量從零開始。一些簡單的示例如下：

- The first 500 bytes
Range: bytes=0-499

- The second 500 bytes
Range: bytes=500-999

- The final 500 bytes
Range: bytes=-500

- The first and last bytes only
Range: bytes=0-0,-1

可以列出多個範圍，以逗號分隔。如果缺少逗號分隔的位元組範圍內的第一個數字，則假定該範圍從文件末尾開始計數。如果缺少第二個數字，則範圍是位元組 n 到文件末尾。

Referer

Referer 允許客戶端指定從中請求 URL 的資源的地址（URI）。通用語法如下：

Referer : absoluteURI | relativeURI

以下是一個簡單的示例：

Referer: http://www.tutorialspoint.org/http/index.htm

如果欄位值是相對 URI，則應相對於 Request-URI 進行解釋。

TE

TE 請求型頭部用來指定使用者代理希望使用的傳輸編碼型別。(可以將其非正式稱為 Accept-Transfer-Encoding， 這個名稱顯得更直觀一些)。 以下是一般語法：

TE : t-codings

關鍵字“ trailers”的存在表明客戶端願意以分塊的傳輸編碼方式接受尾部欄位，並且通過以下兩種方式之一進行指定：

TE: deflate
TE:
TE: trailers, deflate;q=0.5

如果 TE 欄位值為空或不存在 TE 欄位，則僅傳輸編碼為 chunked。沒有傳輸編碼的訊息總是可以接受的。

User-Agent

User-Agent 包含有關發起請求的使用者代理的資訊。以下是一般語法：

User-Agent : product | comment

例子:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)

Server Response Headers

Accept-Ranges

Accept-Ranges 允許伺服器指示其接受資源的範圍請求。通用語法為：

Accept-Ranges : range-unit | none

例如，接受位元組範圍請求的伺服器可以傳送：

Accept-Ranges: bytes

不接受任何型別的資源範圍請求的伺服器可以傳送：

Accept-Ranges: none

這將建議客戶端不要嘗試範圍請求。

Age

Age 傳達了發件人對自始端伺服器生成響應（或其響應）以來的時間量的估計。通用語法為：

Age : delta-seconds

Age 值是非負十進位制整數，以秒為單位表示時間。以下是一個簡單的示例：

Age: 1030

包含快取的 HTTP / 1.1 伺服器必須在其自己的快取生成的每個響應中都包含 Age 標頭欄位。

ETag

ETag 提供所請求變體的實體標籤的當前值。通用語法為：

ETag : entity-tag

以下是一些簡單的示例：

ETag: "xyzzy"
ETag: W/"xyzzy"
ETag: ""

Location

Location 用於將收件人重定向到 Request-URI 以外的其他位置以完成操作。通用語法為：

Location : absoluteURI

以下是一個簡單的示例：

Location: http://www.tutorialspoint.org/http/index.htm

Content-Location 標頭欄位與 Location 的不同之處在於 Content-Location 標識請求中包含的實體的原始位置。

Proxy-Authenticate

Proxy-Authenticate 是一個響應首部，指定了獲取 proxy server （代理伺服器）上的資源訪問許可權而採用的身份驗證方式。代理伺服器對請求進行驗證，以便它進一步傳遞請求。Proxy-Authenticate 首部需要與 407 Proxy Authentication Required 響應一起傳送。

Proxy-Authenticate : challenge

Retry-After

Retry-After 可以與 503（服務不可用）響應一起使用，以指示請求客戶端不希望使用該服務多長時間。通用語法為：

Retry-After : HTTP-date | delta-seconds

例子:

Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120

在後一個示例中，延遲為 2 分鐘。

Server

伺服器包含有關原始伺服器用來處理請求的軟體的資訊。通用語法為：

Server : product | comment

以下是一個簡單的示例：

Server: Apache/2.2.14 (Win32)

如果響應是通過代理轉發的，則代理應用程式不得修改伺服器響應頭。

Set-Cookie

Set-Cookie 包含一個名稱/值資訊對，用於此 URL。通用語法為：

Set-Cookie: NAME=VALUE; OPTIONS

Set-Cookie 響應標頭包含令牌 Set-Cookie，後跟一個或多個 Cookie 的逗號分隔列表。以下是可以指定為選項的可能值：

以下是伺服器生成的簡單 Cookie 標頭的示例：

Set-Cookie: name1=value1,name2=value2; Expires=Wed, 09 Jun 2021 10:18:14 GMT

Vary

Vary 指定實體具有多個源，因此可能因指定的請求標頭列表而異。以下是常規語法：

Vary : field-name

您可以指定多個按逗號分隔的標頭和星號 "
" 的值，表示未指定的引數不限於請求標頭。以下是一個簡單的示例：

Vary: Accept-Language, Accept-Encoding

此處欄位名稱不區分大小寫。

WWW-Authenticate

401（未授權）響應訊息中必須包含 WWW-Authenticate。欄位值由至少一個質詢組成，該質詢指示適用於請求 URI 的身份驗證方案和引數。一般語法是：

WWW-Authenticate : challenge

WWW- Authenticate 可能包含多個質詢，或者如果提供了多個WWW- Authenticate，則質詢本身的內容可以包含身份驗證引數的逗號分隔列表。以下是一個簡單的示例：

WWW-Authenticate: BASIC realm="Admin"

Entity Headers

Allow

Allow列出請求 URI 標識的資源支援的方法集。一般語法是：

Allow : Method

您可以指定用逗號分隔的多個方法。以下是一個簡單的示例：

Allow: GET, HEAD, PUT

此欄位無法阻止客戶端嘗試其他方法。

Content-Encoding

Content-Encoding用作介質型別的修改器。一般語法是：

Content-Encoding : content-coding

content-coding用於對特定媒體型別的資料進行壓縮。當這個首部出現的時候，它的值表示訊息主體進行了何種方式的內容編碼轉換。這個訊息首部用來告知客戶端應該怎樣解碼才能獲取在 Content-Type 中標示的媒體型別內容。。以下是一個簡單的示例：

Content-Encoding: gzip

如果源伺服器不能接受請求訊息中實體的內容編碼，則伺服器應響應狀態程式碼為 415（不支援的媒體型別）。

Content-Language

Content-Language 描述封閉實體的預期受眾的自然語言。以下是常規語法：

Content-Language : language-tag

對於面向多個受眾的內容，可能會列出多種語言。以下是一個簡單的示例：

Content-Language: mi, en

內容語言的主要目的是允許使用者根據使用者自己的首選語言識別和區分實體。

Content-Length

Content-Length 表示實體體的大小，以十進位制數字表示，傳送到收件人，或者，在 HEAD 方法中，如果請求是 GET，則表示將傳送的實體體的大小。一般語法是：

Content-Length : DIGITS

以下是一個簡單的示例：

Content-Length: 3495

大於或等於零的任何內容長度都是有效值。

Content-Location

當該實體可從獨立於請求的資源的 URI 的位置訪問時，可以使用"Content-Location"實體標頭欄位為訊息中包含的實體提供資源位置。一般語法是：

Content-Location: absoluteURI | relativeURI

例子:

Content-Location: http://www.tutorialspoint.org/http/index.htm

內容位置的值還定義實體的基URI。

Content-MD5
Content-MD5 可用於提供實體的 MD5 摘要，用於在收到郵件時檢查訊息的完整性。一般語法是：

Content-MD5 : md5-digest using base64 of 128 bit MD5 digest as per RFC 1864

例子:

Content-MD5 : 8c2d46911f3f5a326455f0ed7a8ed3b3

MD5 摘要是根據實體體的內容計算的，包括已應用的任何內容編碼，但不包括應用於訊息正文的任何傳輸編碼。

Content-Range

在HTTP協議中，響應首部 Content-Range 顯示的是一個數據片段在整個檔案中的位置:

Content-Range : bytes-unit SP first-byte-pos "-" last-byte-pos

位元組內容範圍規格值的示例，假設實體總共包含 1234 個位元組：

- The first 500 bytes:
Content-Range : bytes 0-499/1234

- The second 500 bytes:
Content-Range : bytes 500-999/1234

- All except for the first 500 bytes:
Content-Range : bytes 500-1233/1234

- The last 500 bytes:
Content-Range : bytes 734-1233/1234

當 HTTP 訊息包含單個範圍的內容時，此內容將和顯示實際傳輸位元組數的Content-Length標頭一起使用。例如，

HTTP/1.1 206 Partial content
Date: Wed, 15 Nov 1995 06:25:24 GMT
Last-Modified: Wed, 15 Nov 1995 04:58:08 GMT
Content-Range: bytes 21010-47021/47022
Content-Length: 26012
Content-Type: image/gif

Content-Type

Content-Type 表示傳送到收件人的實體主體的媒體型別，或者，在 HEAD 方法中，如果請求是 GET，則將傳送的媒體型別。一般語法是：

Content-Type : media-type

例子:

Content-Type: text/html; charset=ISO-8859-4

Expires

Expires 給出日期/時間，之後響應被視為過時。一般語法是

Expires : HTTP-date

例子:

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Last-Modified

Last-Modified 指示源伺服器認為上次修改變體的日期和時間。一般語法是：

Last-Modified: HTTP-date

例子:

Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT