請求首部字段

請求的首部字段主要是客戶端用來告知服務端自己能夠支持的內(nèi)容，讓服務端盡量根據(jù)自己滿足的優(yōu)先級內(nèi)容來響應。
請求的首部字段很多都是支持多個值的，并且有下面兩個常見特性：

• 通配符：值類型支持用通配符表示，如 *；
• 添加因子權(quán)重 q 任何值都按照稱為權(quán)重的相對質(zhì)量值的優(yōu)先順序排列。

1. Accept

告知服務端客戶側(cè)能夠處理的媒體類型，一般是 類型/子類型的格式，支持多種類型根據(jù)優(yōu)先級排序。

GET /9_Q4simg2RQJ8t7jm9iCKT-xh_/s.gif HTTP/1.1
Accept: image/png,image/svg+xml,image/*;q=0.8,video/*;q=0.8,*/*;q=0.5

2. Accept-Charset

告知服務端客戶側(cè)能夠接收的字符集類型，支持多個根據(jù)優(yōu)先級排序。服務端選擇一個提議，使用它并在 Content-Type 響應頭中通知客戶它選擇的內(nèi)容。

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

3. Accept-Encoding

告知服務端客戶側(cè)能夠支持的內(nèi)容編碼，通常是一種壓縮算法。

Accept-Encoding: br, gzip, deflate

4. Accept-Language

告知服務端客戶側(cè)支持的語言類型，讓服務端從中選擇一種響應。

Accept-Language: zh-cn

5. From

告知服務器使用用戶代理的用戶的電子郵件地址，以便在出現(xiàn)異常時候通知你。

From: imooc@example.org

6. Host

告訴服務器自己要訪問的的服務域名信息，有可能一臺服務器綁定了多個不同域名，并且不同域名對應了不同服務。

Host: www.imocc.com

7. Authorization

Authorization: <type> <credentials>

• <type> 認證類型。常見的類型是Basic；
• <credentials> 如果使用 Basic 身份驗證方案，則憑證的構(gòu)造方式如下所示：

base64(user:passwd)

Authorization: Basic GJxhZGRpbjpvcGWun3VzYW1l

這種認證方式目前是比較少用了，比較用戶名和密碼放在請求頭，而且 base64 簡單加密是可逆的。建議用 Https 的加密協(xié)議。

8. Proxy-Authorization

跟 Authorization 類似，不同的是 Authorization 是客戶端與服務端的認證，Proxy-Authorization 是客戶端與代理服務器的認證。

9. If-Match

在請求頭部添加資源條件，服務器會驗證條件為真才會返回請求的資源。

If-Match: <etag_value>, <etag_value>, …

ETag（Entity Tag） 是資源版本的標識符。工作方式類似于 Last-Modified，只是 ETag 值是資源的 Digest（比如，MD5 hash）：

10. if-None-Match

與 if-Match 的作用相反，即 Etag 判斷為 false 服務端才會處理該請求：

If-None-Match: <etag_value>

11. if-Modified-Since

也是在請求頭部的條件，只是它關(guān)注的是資源的更新時間。如果服務端端資源在客戶端 if-Modified-Since 指定的日期沒有更新過，即資源不夠新鮮就不會返回給客戶端。

12. if-Range

if-Range 通常會帶一個 Range 屬性，當 if-Range 對應的 Etag 匹配時，服務端需要返回 Range 范圍內(nèi)的資源。最常見的場景就是斷點續(xù)傳，先根據(jù) Etag 確定好一個資源。在斷點續(xù)傳中時間比較久資源更能會被修改到，可能會影響到客戶端的資源 Range。如果 Etag 對應的 Digest 摘要一致就代表資源跟客戶端想要的是一樣，此時根據(jù)客戶端要的 Range 部分返回。

If-Match: "123456"
Range: bytes=1000-2000

13. If-Unmodified-Since

If-Unmodified-Since 和 If-Modified-Since 的作用 相反。它的作用的是告知服務器，指定的請求資源只有在字段值內(nèi)指定的日期時間之后，未發(fā)生更新的情況下，才能處理請求。

14. Max-Forwards

客戶端端請求有可能被服務端轉(zhuǎn)發(fā)到其它代理服務，該字段限制服務端的轉(zhuǎn)發(fā)次數(shù)。

15. User-Agent

通常存儲了瀏覽器客戶端的信息

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/13.0.5 Safari/605.1.15

16. Referer

資源在請求的過程中有可能被轉(zhuǎn)發(fā)，Referer 字段記錄了請求的原始地址
比如在 www.google.com 里有一個 www.baidu.com 鏈接，那么點擊這個 www.baidu.com ，它的 header信息里就有如下：

Referer=http://www.google.com

17. TE

Transfer Encode 告訴服務端自己能夠處理的傳輸編碼。

18. 小結(jié)

后臺的開發(fā)人員能夠從請求頭部信息或者到很多有價值的東西，如 User-Agent 獲取客戶端信息，假設某個客戶端一直訪問，有可能是爬蟲代碼來抓取我們網(wǎng)站的資源了。Referer 字段可以知道請求從哪里來，假如別人的網(wǎng)站引用了你的圖片，我們是可以從該字段得知的，可以禁用這類請求的響應。當然，根據(jù)具體的場景其它字段也可能有很多用處，利用好頭部信息，也可以某種程度避免我們所有信息都定義在請求體參數(shù)中，也許都能實現(xiàn)，但是不夠規(guī)范。