第6章 HTTP首部
6.1 http封包首部
6.2 http首部字段
http首部字段根據實際用途分為以下4種類型：
通用首部字段、請求首部字段、響應首部字段、實體首部字段（針對請求封包和響應封包的實體部分使用的首部。補充了資源内容更新時間等與實體有關的資訊）
6.3 HTTP/1.1 通用首部字段
cache-control: 取值比較常見的有no-cache，如果在響應頭中，代表源伺服器跟緩存伺服器說，你可以使用緩存，但是每次使用都要通知我一下。如果在請求頭中，代表用戶端跟緩存伺服器說，我不要緩存，你直接從源伺服器上拿資源。
1.no-cache指令
2.no-store指令
代表傳輸的資訊是保密的，不允許存儲。
3.max-age指令
從用戶端的角度：如果請求頭中有max-age這個參數，那麼，緩存伺服器拿到參數後，會根據其值判斷資源是否過期，如果過期，會向源伺服器重新請求新的資源。
從源伺服器角度：如果響應頭中有max-age這個參數，那麼，源伺服器在告訴緩存伺服器，我這個資源隻要沒過期，你都不用跟我要新的。
另外，cache-control可能的取值還有：max-stale、only-if-cache、must-revalidate、proxy-revalidate、no-transform
6.3.2 Connection
connection有2個作用：
1.控制不再轉發給代理的首部字段
2.管理持久連接配接
6.3.3 Date字段
首部字段Date為建立封包的時間。
6.3.4 Pragma
這個字段是http1.1之前的遺留字段，為了相容http1.0。一般用在用戶端上，意思為告訴中間伺服器，我不要緩存資源。
所有的中間伺服器如果都能以 HTTP/1.1 為基準,那直接采用 Cache-Control: no-cache 指定緩存的處理方式是最為理想的。但要整體掌握全部中間伺服器使用的 HTTP 協定版本卻是不現實的。是以,發送的請求會同時含有下面兩個首部字段。
Cache-Control: no-cache Pragma: no-cache
6.3.5 Trailer
這個字段說明，在封包主體後有哪些重要字段，以免伺服器忘記檢視，一般用來分塊傳輸。
6.3.6 Transfer-Encoding
6.3.7 Upgrade
用戶端利用此字段詢問服務端，能讓我使用更高版本或者其他協定通信嗎？
6.3.8 via
資源在各個代理伺服器，或者中轉伺服器之間轉發時，都會在封包頭部加上此字段，以便用來追蹤資源的蹤迹。
6.3.9 warning
6.4 請求首部字段
6.4.1 accept
q表示權重，傳回資料格式的優先級。
資料格式包括：文本、圖檔檔案、視訊檔案、應用程式使用的二進制檔案
6.4.2 accept-charset
通知伺服器，可以接收的資源的字元集
6.4.3 accept-encoding
使用者代理告訴伺服器，是否可以把壓縮過後的資源吐給他。
6.4.4 accept-language
告訴伺服器，它想要的資源的語言
6.4.5 authorization
使用者代理收到伺服器傳回的401之後，就知道，伺服器需要驗證資訊才能把資訊傳回，這個時候，使用者代理會在請求頭上添加：Authorization字段。
6.4.6 Expect
使用執行個體：Expect: 100-continue
用戶端通過這個字段告訴伺服器，用戶端希望伺服器做出的回應，如果伺服器無法了解用戶端的意圖，會傳回417，表示expectation failed。等待100狀态碼的用戶端在發送請求時，需要指定Expect: 100-continue
6.4.7 From
首部字段 From 用來告知伺服器使用使用者代理的使用者的電子郵件位址。通常,其使用目的就是為了顯示搜尋引擎等使用者代理的負責人的電子郵件聯系方式。使用代理時,應盡可能包含 From 首部字段(但可能會因代理不同,将電子郵件位址記錄在 User-Agent 首部字段内)。
6.4.8 Host
host 是http1.1請求中唯一一個被要求強制性的寫在請求頭中的字段。此字段為了解決以下問題：當用戶端請求到達伺服器的時候，host已經被解析成了ip，但是，如果同一個ip下配置設定了多個不同的域名（對應不同的虛拟主機），這個時候就無法判斷，用戶端需要哪個虛拟主機下的資源。
6.4.9 If-Match
形如if-xxx的請求，叫做條件請求，隻有用戶端的請求符合條件時，伺服器才會執行請求。
If-Match: '123456'
伺服器會将資源的ETag與用戶端給的相比較，如果一樣，那麼會執行請求，将資源傳回給用戶端，否則會傳回412 Precondition failed
6.4.10 If-Modified-Since
If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT
用戶端跟伺服器說：如果資源在2004-4-15 00:00:00之後，被更改過，就執行這個請求，傳回資源。如果沒有更改過，伺服器就會傳回304，not modified.
6.4.11 If-None-Match
用戶端在告訴伺服器，如果請求的資源的ETag與我發送的值不一緻，那麼你就處理請求，給我最新的資源。它的作用與If-Match相反。在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可擷取最新的資源。是以,這與使用首部字段 If-Modified-Since 時有些類似。
6.4.12 If-Range
6.4.14 Max-Forwards
通過 TRACE 方法或 OPTIONS 方法,發送包含首部字段 Max-Forwards 的請求時,該字段以十進制整數形式指定可經過的伺服器最大數目。伺服器在往下一個伺服器轉發請求之前,Max-Forwards 的值減 1 後重新指派。當伺服器接收到 Max-Forwards 值為 0 的請求時,則不再進行轉發,而是直接傳回響應。
使用 HTTP 協定通信時,請求可能會經過代理等多台伺服器。途中,如果代理伺服器由于某些原因導緻請求轉發失敗,用戶端也就等不到伺服器傳回的響應了。對此,我們無從可知。
可以靈活使用首部字段 Max-Forwards,針對以上問題産生的原因展開調查。由于當 Max-Forwards 字段值為0 時,伺服器就會立即傳回響應,由此我們至少可以對以那台伺服器為終點的傳輸路徑的通信狀況有所把握。
6.4.15 Proxy-Authorization
Proxy-Authorization: Basic dGlwOjkpNLAGfFY5
接收到從代理伺服器發來的認證質詢時,用戶端會發送包含首部字段 Proxy-Authorization 的請求,以告知伺服器認證所需要的資訊。
這個行為是與用戶端和伺服器之間的 HTTP 通路認證相類似的,不同之處在于,認證行為發生在用戶端與代理之間。用戶端與伺服器之間的認證,使用首部字段 Authorization 可起到相同作用。有關 HTTP 通路認證,後面的章節會作詳盡闡述。
6.4.16 Range
Range: bytes=5001-10000
表示用戶端想要位元組5001到10000的資源，如果伺服器有此段資源，則傳回206 Partial Content, 如果無法給予此段資訊，則傳回200 ok，傳回全部資源。
6.4.17 Referer
Referer: http://www.hackr.jp/index.htm
首部字段 Referer 會告知伺服器請求的原始資源的 URI。
用戶端一般都會發送 Referer 首部字段給伺服器。但當直接在浏覽器的位址欄輸入 URI,或出于安全性的考
慮時,也可以不發送該首部字段。
因為原始資源的 URI 中的查詢字元串可能含有 ID 和密碼等保密資訊,要是寫進 Referer 轉發給其他伺服器,則有可能導緻保密資訊的洩露。
另外,Referer 的正确的拼寫應該是 Referrer,但不知為何,大家一直沿用這個錯誤的拼寫。
6.4.18 TE
TE: gzip, deflate;q=0.5
首部字段 TE 會告知伺服器用戶端能夠處理響應的傳輸編碼方式及相對優先級。它和首部字段 Accept-Encoding 的功能很相像,但是用于傳輸編碼。
首部字段 TE 除指定傳輸編碼之外,還可以指定伴随 trailer 字段的分塊傳輸編碼的方式。應用後者時,隻需把 trailers 指派給該字段值。
TE: trailers
6.4.19 User-Agent
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20100101 Firefox/13.0.1
将發送請求的使用者代理發送給伺服器，由網絡爬蟲發起請求時，有可能會在字段内添加爬蟲作者的電子郵件，此外，如果請求經過代理，那麼，有可能會在字段内添加上代理伺服器的名稱。