Http協議基礎之HTTP請求首部字段

請求首部字段

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

Accept

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8

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= 來額外表示權重值，用分號（;）進行分隔。權重值 q 的範圍是 0~1（可精確到小數點後 3 位），且 1 爲最大值。不指定權重 q 值時，默認權重爲 q=1.0。

當服務器提供多種內容時，將會首先返回權重值最高的媒體類型。

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 生成的編碼格式，採用 Lempel-Ziv-Welch 算法（LZW）。

deflate
組合使用 zlib 格式（RFC1950）及由 deflate 壓縮算法（RFC1951）生成的編碼格式。

identity
不執行壓縮或不會變化的默認編碼格式

採用權重 q 值來表示相對優先級，這點與首部字段 Accept 相同。另外，也可使用星號（*）作爲通配符，指定任意的編碼格式。

Accept-Language

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

首部字段 Accept-Language 用來告知服務器用戶代理能夠處理的自然語言集（指中文或英文等），以及自然語言集的相對優先級。可一次指定多種自然語言集。

和 Accept 首部字段一樣，按權重值 q 來表示相對優先級。在上述圖例中，客戶端在服務器有中文版資源的情況下，會請求其返回中文版對應的響應，沒有中文版時，則請求返回英文版響應。

Authorization

Authorization: Basic dWVub3NlbjpwYXNzd29yZA==

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

Expect

Expect: 100-continue

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

客戶端可以利用該首部字段，寫明所期望的擴展。雖然 HTTP/1.1 規範只定義了 100-continue（狀態碼 100 Continue 之意）。等待狀態碼 100 響應的客戶端在發生請求時，需要指定 Expect:100-continue。

From

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

Host

Host: www.hackr.jp

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

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

請求被髮送至服務器時，請求中的主機名會用 IP 地址直接替換解決。但如果這時，相同的 IP 地址下部署運行着多個域名，那麼服務器就會無法理解究竟是哪個域名對應的請求。因此，就需要使用首部字段 Host 來明確指出請求的主機名。若服務器未設定主機名，那直接發送一個空值即可。如下所示。

Host:

If-Match

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

If-Match: “123456”

首部字段 If-Match，屬附帶條件之一，它會告知服務器匹配資源所用的實體標記（ETag）值。這時的服務器無法使用弱 ETag 值。

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

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

If-Modified-Since

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

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

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

If-None-Match

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

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

If-Range

首部字段 If-Range 屬於附帶條件之一。它告知服務器若指定的 If-Range 字段值（ETag 值或者時間）和請求資源的 ETag 值或時間相一致時，則作爲範圍請求處理。反之，則返回全體資源。
不使用首部字段 If-Range 發送請求時，服務器端的資源如果更新，那客戶端持有資源中的一部分也會隨之無效，當然，範圍請求作爲前提是無效的。這時，服務器會暫且以狀態碼 412 Precondition Failed 作爲響應返回，其目的是催促客戶端再次發送請求。這樣一來，與使用首部字段 If-Range 比起來，就需要花費兩倍的功夫。

If-Unmodified-Since

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

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

Max-Forwards

Max-Forwards: 10

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

使用 HTTP 協議通信時，請求可能會經過代理等多臺服務器。途中，如果代理服務器由於某些原因導致請求轉發失敗，客戶端也就等不到服務器返回的響應了。對此，我們無從可知。

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

Proxy-Authorization

Proxy-Authorization: Basic dGlwOjkpNLAGfFY5

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

這個行爲是與客戶端和服務器之間的 HTTP 訪問認證相類似的，不同之處在於，認證行爲發生在客戶端與代理之間。客戶端與服務器之間的認證，使用首部字段 Authorization 可起到相同作用。

Range

Range: bytes=5001-10000

對於只需獲取部分資源的範圍請求，包含首部字段 Range 即可告知服務器資源的指定範圍。上面的示例表示請求獲取從第 5001 字節至第 10000 字節的資源。

接收到附帶 Range 首部字段請求的服務器，會在處理請求之後返回狀態碼爲 206 Partial Content 的響應。無法處理該範圍請求時，則會返回狀態碼 200 OK 的響應及全部資源。

Referer

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

首部字段 Referer 會告知服務器請求的原始資源的 URI。

客戶端一般都會發送 Referer 首部字段給服務器。但當直接在瀏覽器的地址欄輸入 URI，或出於安全性的考慮時，也可以不發送該首部字段。

因爲原始資源的 URI 中的查詢字符串可能含有 ID 和密碼等保密信息，要是寫進 Referer 轉發給其他服務器，則有可能導致保密信息的泄露。

TE

TE: gzip, deflate;q=0.5

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

首部字段 TE 除指定傳輸編碼之外，還可以指定伴隨 trailer 字段的分塊傳輸編碼的方式。應用後者時，只需把 trailers 賦值給該字段值。

TE: trailers

User-Agent

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1

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

由網絡爬蟲發起請求時，有可能會在字段內添加爬蟲作者的電子郵件地址。此外，如果請求經過代理，那麼中間也很可能被添加上代理服務器的名稱。