圖解HTTP——總結

來源書籍《圖解HTTP》學習總結。

TCP/IP協議族

協議中存在各式各樣的內容。 從電纜的規格到 IP 地址的選定方法、尋找異地用戶的方法、 雙方創建通訊的順序， 以及 Web 頁面顯示須要處理的步驟，

一、TCP/IP 的分層管理：應用層、 傳輸層、 網絡層和數據鏈路層。

（1）、應用層：應用層決定了向用戶提供應用服務時通訊的活動，如：FTP（File Transfer Protocol， 文件傳輸協議） 和 DNS（Domain Name System， 域名系統）服務，HTTP協議；
（2）、傳輸層：對上層應用層， 提供處於網絡鏈接中的兩臺計算機之間的 數據傳輸， TCP（Transmission Control Protocol，傳輸控制協議）和 UDP（User Data Protocol， 用戶數據報協議）；
（3）、網絡層：用來 處理在網絡上流動的 數據包。該層規定了經過怎樣的路徑（所謂的 傳輸路線）到達對方計算機，並把數據包傳送給對方；
（4）、鏈路層（又名數據鏈路層， 網絡接口層：用來處理鏈接網絡的硬件部分。包括控制操做系統、硬件的設備驅動、NIC（Network Interface Card，網絡適配器，即網卡），及光纖等 物理可見部分。

二、TCP/IP 通訊傳輸流

TCP/IP協議族進行網絡通訊時，會經過分層順序與對方進行通訊。發送端從應用層往下走，接收端則往應用層往上走。

發送端在層與層之間傳輸數據時，每通過一層時一定會被打上一個該層所屬的首部信息。反之，接收端在層與層傳輸數據時，每通過一層時會把對應的首部消去。

三、與 HTTP 關係密切的協議：IP、TCP、DNS

1）IP協議：（Internet Protocol）協議位於網絡層，做用是把各類數據包傳送給對方。其中兩個重要的條件是 IP 地址和 MAC地址（Media Access Control Address）。IP 地址指明瞭節點被分配到的地址，MAC 地址是指網卡所屬的固定地址。IP 地址能夠和 MAC 地址進行配對。IP 地址可變換，但 MAC地址基本上不會更改。

2）TCP協議：位於傳輸層， 提供可靠的字節流服務,TCP 協議爲了更容易傳送大數據才把數據分割， 並且 TCP 協議可以確認數據最終是否送達到對方。
TCP 協議採用了三次握手three-way handshaking）策略,握手過程當中使用了 TCP 的標誌 —— SYN（synchronize）和 ACK（acknowledgement）。

3）負責域名解析的 DNS 服務：和 HTTP 協議同樣位於應用層的協議。它提供域名到 IP 地址之間的解析服務。DNS 協議提供經過域名查找 IP 地址，或逆向從 IP 地址反查域名的服務。

HTTP 協議的通訊過程：

四、URI（統一資源標識符）和 URL（Uniform Resource Locator，統一資源定位符）

URI 用字符串標識某一互聯網資源，而 URL 表示資源的地點（互聯網上所處的位置） 。可見 URL 是 URI 的子集。

URI格式以下：

以下URI例子：
ftp://ftp.is.co.za/rfc/rfc1808.txt
http://www.ietf.org/rfc/rfc23...
ldap://[2001:db8::7]/c=GB?objectClass?one
mailto:John.Doe@example.com
news:comp.infosystems.www.servers.unix
tel:+1-816-555-1212
telnet://192.0.2.16:80/
urn:oasis:names:specification:docbook:dtd:xml:4.1.2

簡單的 HTTP 協議

一、HTTP 協議用於客戶端和服務器端之間的通訊
請求網頁資源得例子：

請求報文：是由請求方法、請求 URI、協議版本、可選的請求首部字段和內容實體構成的。

響應報文：基本上由協議版本、狀態碼（表示請求成功或失敗的數字代碼）、用以解釋狀態碼的緣由短語、可選的響應首部字段以及實體主體構成。稍後咱們會對這些內容進行詳細說明。

HTTP 是一種不保存狀態，即無狀態（stateless）協議。不具有保存以前發送過的請求或響應的功能。爲了實現指望的保持狀態功能，因而引入了 Cookie 技術。

二、請求 URI 定位資源

HTTP 協議使用 URI 定位互聯網上的資源。

指定請求URI得方式：（ 若是不是訪問特定資源而是對服務器自己發起請求，能夠用一個 * 來代替請求 URI。）

三、告知服務器意圖的 HTTP 方法
1）、GET：獲取資源,用來請求訪問已被 URI 識別的資源;
2）、POST：傳輸實體主體；
3）、PUT：傳輸文件——鑑於 HTTP/1.1 的 PUT 方法自身不帶驗證機制，任何人均可以上傳文件 , 存在安全性問題， 所以通常的 Web 網站不使用該方法；
4）、HEAD：得到報文首部,和 GET 方法同樣，只是不返回報文主體部分。用於確認URI 的有效性及資源更新的日期時間等；
5）、DELETE：刪除文件，與 PUT 相反的方法。按請求 URI 刪除指定的資源；
6）、OPTIONS：詢問支持的方法；
7）、TRACE：追蹤路徑，讓 Web 服務器端將以前的請求通訊環回給客戶端的方法。發送請求時，在 Max-Forwards 首部字段中填入數值，每通過一個服務器端就將該數字減 1，當數值恰好減到 0 時，就中止繼續傳輸，最後接收到請求的服務器端則返回狀態碼 200 OK 的響應。客戶端經過 TRACE 方法能夠查詢發送出去的請求是怎樣被加工修改 / 篡改的。不經常使用易引起XST（Cross-Site Tracing， 跨站追蹤）攻擊；
8）、CONNECT：要求用隧道協議鏈接代理，要求在與代理服務器通訊時創建隧道，實現用隧道協議進行 TCP 通訊。主要使用 SSL（Secure Sockets Layer，安全套接層）和 TLS（Transport Layer Security，傳輸層安全）協議把通訊內容加密後經網絡隧道傳輸。

四、持久鏈接節省通訊量

1）、持久鏈接

HTTP 協議的初始版本中，每進行一次 HTTP 通訊就要斷開一次 TCP鏈接。每次的請求都會形成無謂的 TCP 鏈接創建和斷開，增長通訊量的開銷。爲解決上述 TCP 鏈接的問題，HTTP/1.1 和一部分的 HTTP/1.0 想出了持久鏈接（HTTP Persistent Connections，也稱爲 HTTP keep-alive 或 HTTP connection reuse）的方法。持久鏈接的特色是，只要任意一端沒有明確提出斷開鏈接，則保持 TCP 鏈接狀態。

2）、管線化

從前發送請求後需等待並收到響應， 才能發送下一個請求。管線化技術出現後，不用等待響應亦可直接發送下一個請求

五、使用 Cookie 的狀態管理

Cookie 會根據從服務器端發送的響應報文內的一個叫作 Set-Cookie 的首部字段信息， 通知客戶端保存 Cookie。當下次客戶端再往該服務器發送請求時，客戶端會自動在請求報文中加入 Cookie 值後發送出去。服務器端發現客戶端發送過來的 Cookie 後，會去檢查到底是從哪個客戶端發來的鏈接請求，而後對比服務器上的記錄，最後獲得以前的狀態信息。

HTTP 報文內的 HTTP信息

一、HTTP 報文
用於 HTTP 協議交互的信息被稱爲 HTTP 報文。

請求端（客戶端）的HTTP 報文叫作請求報文，響應端（服務器端）的叫作響應報文。TTP 報文自己是由多行（用 CR+LF 做換行符）數據構成的字符串文本。並不必定要有報文主體。

請求行：包含用於請求的方法， 請求 URI 和 HTTP 版本。
狀態行：包含代表響應結果的狀態碼， 緣由短語和 HTTP 版本。
首部字段：包含表示請求和響應的各類條件和屬性的各種首部。通常有 4 種首部，分別是：通用首部、請求首部、響應首部和實體首部。

二、編碼提高傳輸速率

能夠在傳輸過程當中經過編碼提高傳輸速率。經過在傳輸時編碼，能有效地處理大量的訪問請求。當傳輸中進行編碼操做時，實體主體的內容發生變化，將會致使它和報文主體產生差別。一般， 報文主體等於實體主體。

報文（message）：是 HTTP 通訊中的基本單位，由 8 位組字節流（octet sequence，其中 octet 爲 8 個比特）組成，經過 HTTP 通訊傳輸。
實體（entity）：做爲請求或響應的有效載荷數據（補充項）被傳輸，其內容由實體首部和實體主體組成。
1）、壓縮傳輸的內容編碼
經常使用的內容編碼有如下幾種。
gzip（GNU zip）
compress（UNIX 系統的標準壓縮）
deflate（zlib）
identity（不進行編碼）
2）、分割發送的分塊傳輸編碼
分塊傳輸編碼會將實體主體分紅多個部分（塊）。每一塊都會用十六進制來標記塊的大小，而實體主體的最後一塊會使用「0(CR+LF)」來標記。

三、發送多種數據的多部分對象集合

就是利用 MIME 來描述標記數據類型。而在 MIME 擴展中會使用一種稱爲多部分對象集合（Multipart）的方法，來容納多份不一樣類型的數據。

多部分對象集合包含的對象以下。
multipart/form-data:在 Web 表單文件上傳時使用。
multipart/byteranges:狀態碼 206（Partial Content，部份內容）響應報文包含了多個範圍的內容時使用。
在 HTTP報文中使用多部分對象集合時， 須要在首部字段里加上Content-type。使用 boundary字符串來劃分多部分對象集合指明的各種實體。在boundary字符串指定的各個實體的起始行以前插入「--」標記（例如： --AaB03x、 --THIS_STRING_SEPARATES） ， 而在多部分對象集合對應的字符串的最後插入「--」標記（例如： --AaB03x--、 --THIS_STRING_SEPARATES--） 做爲結束。

四、獲取部份內容的範圍請求
執行範圍請求時，會用到首部字段 Range （Range: bytes=-3000, 5000-7000，7000-）來指定資源的 byte 範圍。響應會返回狀態碼爲 206 Partial Content 的響應報文。另外，對於多重範圍的範圍請求， 響應會在首部字段 ContentType 標明 multipart/byteranges 後返回響應報文。若是服務器端沒法響應範圍請求，則會返回狀態碼 200 OK 和完整的實體內容。

五、內容協商返回最合適的內容

返回結果的 HTTP 狀態碼

狀態碼的職責是當客戶端向服務器端發送請求時，描述返回的請求結果。 如 200 OK，以 3 位數字和緣由短語組，數字中的第一位指定了響應類別， 後兩位無分類。成。

一、2XX成功：的響應結果代表請求被正常處理了。
1)、200 ok：請求成功並根據方法的不一樣，返回不一樣的實體；
2)、204 No Content：該狀態碼錶明服務器接收的請求已成功處理，但在返回的響應報文中不含實體的主體部分。無資源可返回；
3)、206 Partial Content：範圍請求後，服務器成功執行了該請求；
二、3XX重定向：代表瀏覽器須要執行某些特殊的處理以正確處理請求。
1)、 301 Moved Permanently：永久性重定向，表示請求的資源已被分配了新的 URI，之後應使用資源如今所指的 URI。
2)、302 Found：臨時重定向，該狀態碼錶示請求的資源已被分配了新的 URI，但願用戶（本次）能使用新的 URI 訪問。
3)、303 See Other:因爲請求對應的資源存在着另外一個 URI，應使用 GET方法定向獲取請求的資源。303 狀態碼和 302 Found 狀態碼有着相同的功能，但 303 狀態碼明確表示客戶端應當採用 GET方法獲取資源，這點與 302 狀態碼有區別。

當 30一、 0二、303響應狀態碼返回時，幾乎全部的瀏覽器都會把POST 改爲 GET，並刪除請求報文內的主體，以後請求會自動再次發送。30一、302 標準是禁止將 POST 方法改變成 GET 方法的，但實際使用時你們都會這麼作。

4)、304 Not Modified:表示客戶端發送附帶條件的請求 2 時，服務器端容許請求訪資源，但未知足條件的狀況。 (附帶條件的請求是指採用 GET方法的請求報文中包含 If-Match， If-ModifiedSince， If-None-Match， If-Range， If-Unmodified-Since 中任一首部。)
5)、307 Temporary Redirect:臨時重定向
三、4XX 客戶端錯誤
1)、400 Bad Request：表示請求報文中存在語法錯誤。
2)、401 Unauthorized：表示發送的請求須要有經過 HTTP 認證（BASIC 認證、DIGEST 認證）的認證信息。另外若以前已進行過 1 次請求， 則表示用戶認證失敗。返回含有 401 的響應必須包含一個適用於被請求資源的 WWW-Authenticate 首部用以質詢（challenge） 用戶信息。
3)、403 Forbidden：代表對請求資源的訪問被服務器拒絕了。
4)、404 Not Found：代表服務器上沒法找到請求的資源。
四、5XX 服務器錯誤
1)、500 Internal Server Error：代表服務器端在執行請求時發生了錯誤。有多是 Web應用存在的 bug 或某些臨時的故障。
2)、503 Service Unavailable：代表服務器暫時處於超負載或正在進行停機維護，如今沒法處理請求。

與 HTTP 協做的 Web 服務器

一臺 Web 服務器可搭建多個獨立域名的 Web 網站，也可做爲通訊路徑上的中轉服務器提高傳輸效率。利用虛擬主機（Virtual Host，又稱虛擬服務器）的功能,在相同的 IP 地址下，因爲虛擬主機能夠寄存多個不一樣主機名和域名的 Web 網站，所以在發送 HTTP 請求時，必須在 Host 首部內完整指定主機名或域名的 URI。

一、通訊數據轉發程序 ： 代理、網關、隧道
1）、代理：是一種有轉發功能的應用程序，代理不改變請求 URI，會直接發送給前方持有資源的目標服務器。可級聯多臺代理服務器。須要附加Via 首部字段以標記出通過的主機信息；
代理有多種使用方法，按兩種基準分類。 一種是是否使用緩存，另外一種是是否會修改報文。
緩存代理（Caching Proxy） 會預先將資源的副本（緩存）保存在代理服務器上。代理再次接收到對相同資源的請求時，就能夠不從源服務器那裏獲取資源， 而是將以前緩存的資源做爲響應返回。
不對報文作任何加工的代理類型被稱爲透明代理（Transparent Proxy）。反之，對報文內容進行加工的代理被稱爲非透明代理。

2）、網關：是轉發其餘服務器通訊數據的服務器，接收從客戶端發送來的請求時，它就像本身擁有資源的源服務器同樣對請求進行處理。利用網關能提升通訊的安全性，由於能夠在客戶端與網關之間的通訊線路上加密以確保鏈接的安全。
3）、隧道：是在相隔甚遠的客戶端和服務器二者之間進行中轉，並保持雙方通訊鏈接的應用程序。可按要求創建起一條與其餘服務器的通訊線路，屆時使用 SSL等加密手段進行通訊。確保客戶端能與服務器進行安全的通訊。

二、保存資源的緩存

緩存是指代理服務器或客戶端本地磁盤內保存的 資源副本。 緩存服務器是代理服務器的一種，並歸類在緩存代理類型中。可避免屢次從源服務器轉發資源。緩存是有 有效期限的，緩存失效， 緩存服務器將會再次從源服務器上獲取「新」資源。

HTTP 首部

一、在請求中， HTTP 報文由方法、 URI、 HTTP 版本、 HTTP 首部字段等部分構成。
二、在響應中， HTTP 報文由HTTP 版本、 狀態碼（數字和緣由短語） 、HTTP 首部字段 3 部分構成。
使用首部字段是爲了給瀏覽器和服務器提供報文主體大小、 所使用的語言、 認證信息等內容。
首部字段結構：首部字段名和字段值構成的， 中間用冒號「:」 分隔,eg:Content-Type: text/html,Keep-Alive:timeout=15, max=100。

一、首部字段類型
通用首部字段（General Header Fields）：請求報文和響應報文兩方都會使用的首部。
請求首部字段（Request Header Fields）：從客戶端向服務器端發送請求報文時使用的首部。補充了請求的附加內容、 客戶端信息、 響應內容相關優先級等信息。
響應首部字段（Response Header Fields）：從服務器端向客戶端返回響應報文時使用的首部。補充了響應的附加內容， 也會要求客戶端附加額外的內容信息。
實體首部字段（Entity Header Fields）：針對請求報文和響應報文的實體部分使用的首部。補充了資源內容更新時間等與實體有關的信息。

表 6-2： 請求首部字段

二、End-to-end 首部和 Hop-by-hop 首部
端到端首部（End-to-end Header）：會轉發給請求 / 響應對應的最終接收目標，且必須保存在由緩存生成的響應中，另外規定它必須被轉發。
逐跳首部（Hop-by-hop Header）：首部只對單次轉發有效，會因經過緩存或代理而再也不轉發。 使用 hop-by-hop 首部，需提供 Connection 首部字段。只有這8個字段Connection，Keep-Alive，Proxy-Authenticate，Proxy-Authorization，Trailer，TE，Transfer-Encoding，Upgrade

三、通用首部字段
1）、Cache-Control：eg Cache-Control: private, max-age=0, no-cache,利用緩存代理服務器進行緩存的管理。

no-cache指令：客戶端請求：不接受緩存過的響應，服務器端的響應：包含該字段，表示，詢問後緩存服務器不能緩存該資源，no-cache=Location：響應指令中指定該參數。客戶端在接收到這個被指定參數值的首部字段對應的響應報文後， 不能使用緩存。

no-store ：暗示請求（和對應的響應） 或響應中包含機密信息。不能對其進行緩存。
s-maxage：Cache-Control: s-maxage=604800（單位 ：秒），指定緩存期限和認證的指令，和 max-age 指令的相同，只適用於供多位用戶使用的公共緩存服務器，當使用 s-maxage 指令後，則直接忽略對 Expires 首部字段及max-age 指令的處理。
max-age：Cache-Control: max-age=604800（單位： 秒）,當緩存時間小於該值值，客戶端可接受緩存的值，服務端指定該指令時，小於指定時間不用確認緩存有效性直接返回該緩存。指定 max-age 值爲 0，那麼緩存服務器一般須要將請求轉發給源服務器。
min-fresh ：Cache-Control: min-fresh=60（單位： 秒），請求指令：要求緩存服務器返回至少還未過指定時間的緩存資源。
max-stale ：Cache-Control: max-stale=3600（單位： 秒），請求指令：即便過時緩存但仍處於 max-stale指定的時間內，仍舊會被客戶端接收。不指定參數則爲永久。
only-if-cached：Cache-Control: only-if-cached，請求指令：僅在接受緩存服務器內的資源，若緩存服務器無該資源則返回 504 Gateway Timeout。
must-revalidate：Cache-Control: must-revalidate，響應指令：必須向服務器確認資源的有效性，若服務器無響應返回 504 Gateway Timeout，使用該指令會忽略 max-stale。
proxy-revalidate：Cache-Control: proxy-revalidate，請求指令，要求緩存服務器，在響應以前必須確認緩存的有效性。
no-transform：Cache-Control: no-transform，請求和相應中，緩存不能改變實體主體的媒體類型。

Cache-Control 擴展：cache-extension token，擴展Cache-Control的指令。

2）、Connection：做用有，控制再也不轉發給代理的首部字段，管理持久鏈接。
再也不轉發給代理的首部字段——Hop-by-hop 首部，如圖，Upgrade首部字段。

管理持久鏈接：Close指令:關閉該鏈接，Keep-Alive:HTTP/1.1 以前的 HTTP 版本的默認鏈接都是非持久鏈接,使用該字段創建持久鏈接。

3）、Date：建立HTTP報文的日期和時間。

4）、Pragma： HTTP/1.1 以前版本的歷史遺留字段，Pragma: no-cache，可以使用Cache-Control:no-cache替代。

5）、Trailer:事先說明在報文主體後記錄了哪些首部字段。

6）、Transfer-Encoding：規定傳輸報文主體時採用的編碼方式。HTTP/1.1 的傳輸編碼方式僅對分塊傳輸編碼有效。Transfer-Encoding: chunked。分塊傳輸。

7）、Upgrade：用於檢測 HTTP 協議及其餘協議是否可以使用更高的版本進行通訊，其參數值能夠用來指定一個徹底不一樣的通訊協議。

Upgrade 首部字段產生做用的 Upgrade 對象僅限於客戶端和鄰接服務器之間。所以，使用首部字段 Upgrade時，還須要額外指定Connection:Upgrade。

8）、Via ：爲了追蹤客戶端與服務器之間的請求和響應報文的傳輸路徑，還可避免請求迴環的發生。。每經過一個代理服務器或網管追加一個via首部字段內容（服務器信息）。常常會和 TRACE 方法一塊兒使用。代理服務器接收到TRACE 方法發送過來的請求（Max-Forwards: 0） 時，代理服務器就不能再轉發該請求了，代理服務器會將自身的信息附加到 Via 首部後， 返回該請求的響
應。

9）、Warning：告知用戶一些與緩存相關的問題的警告。結構：Warning: 警告碼「[警告內容]」([日期時間]), eg:Warning: 113 gw.hackr.jp:8080 "Heuristic expiration" Tue, 03

四、請求首部字段：客戶端往服務器端發送請求報文中所使用的字段
1）、Accept：用戶代理可以處理的媒體類型及媒體類型的相對優先級。 type/subtype 結構一次指定多種媒體類型。用分號分隔多種文件類型，用q=權重值(0~1),來表示優先級。1最大，默認爲1。

文本文件：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 ...

2）、Accept-Charset：支持的字符集及字符集的相對優先順序（權重 q 值表示）。eg:Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

3）、Accept-Encoding：支持的內容編碼及內容編碼的優先級順序（權重 q 值表示），也可用「*」,指定任意彪馬格式。

gzip：由文件壓縮程序 gzip（GNU zip） 生成的編碼格式RFC1952），採用 Lempel-Ziv 算法（LZ77）及 32 位循環冗餘校驗（Cyclic Redundancy Check，稱 CRC）。
compress：由 UNIX 文件壓縮程序 compress 生成的編碼格式， 採用 LempelZiv-Welch 算法（LZW） 。
deflate： 組合使用 zlib 格式（RFC1950） 及由 deflate 壓縮算法（RFC1951） 生成的編碼格式。
identity：不執行壓縮或不會變化的默認編碼格式

4）、Accept-Language：Accept-Language: zh-cn,zh;q=0.7,en-us,en;q=0.3，告知服務器用戶代理可以處理的天然語言集（指中文或英文等）

5）、Authorization：認證信息。

6）、Expect：指望服務器出現指定的行爲。若不能服務器返回錯誤狀態碼 417 Expectation Failed。

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

8）、Host：虛擬主機運行在同一個 IP 上，所以使用首部字段 Host 加以區分，告知服務器，請求的資源所處的互聯網主機名和端口號， HTTP/1.1規範必須請求首部信息。服務器未設定主機名，那直接發送一個空值便可。

形如 If-xxx 這種樣式的 請求首部字段， 均可稱爲 條件請求。只有判斷指定條件爲真時，纔會執行請求。不然返回錯誤412 Precondition Failed。

9）、If-Match：告知服務器匹配資源所用實體標記（ETag）值比較。If-Match: "123456"。

10）、If-Modified-Since：判斷資源指定時間以後是否已更新。若已更新則處理該請求，不然返回狀態碼 304 Not Modified，用於確認代理或客戶端擁有的本地資源的有效性。獲取資源的更新日期時間，可經過確認首部字段 Last-Modified 來肯定。If-Modified-Since: Thu, 15 Apr 2004 00:00:00 GMT。

11）、If-None-Match： 判斷字段值與 ETag 值不一致時，處理該請求。在 GET 或 HEAD 方法中使用首部字段 If-None-Match 可獲取最新的資源。與 If-Modified-Since 有些相似，與 If-Match 首部字段相反。

12）、If-Range：告知服務器若指定的 IfRange 字段值（ETag 值或者時間）和請求資源的 ETag 值或時間相一致時，則做爲範圍請求處理。反之，則返回全體資源。

13）、If-Unmodified-Since：If-Unmodified-Since: Thu, 03 Jul 2012 00:00:00 GMT，指定時間以後未更新才處理該請求。不然返回 412 Precondition Failed。

14）、Max-Forwards：Max-Forwards: 10（10進制整數），TRACE 方法或 OPTIONS 方法，發送包含首部字段 MaxForwards 的請求時，指定可通過的服務器最大數目。經過一個代理服務器減一從新賦值，爲0時，處理請求，返回響應。

15）、Proxy-Authorization：Proxy-Authorization: Basic dGlwOjkpNLAGfFY5，代理服務器發來的認證信息。

16）、Range：Range: bytes=5001-10000，請求資源的範圍信息。成功處理請求以後返回狀態碼爲 206 Partial Content 的響應，沒法處理該範圍請求時，則返回狀態碼 200 OK 的響應及所有資源。

17）、Referer：告知服務器請求的原始資源的 URI。

18）、TE：TE: gzip, deflate;q=0.5，客戶端可以處理響應的傳輸編碼方式及相對優先級。 TE: trailers，分塊傳輸方式。

19）、User-Agent：請求的瀏覽器和用戶代理名稱等信息。請求通過代理， 那麼中間也極可能被添加上代理服
務器的名稱。

五、響應首部字段：服務器端向客戶端返回響應報文中所使用的字段
1）、Accept-Ranges：告知客戶端服務器是否能處理範圍請求，可處理範圍請求：Accept-Ranges: bytes，不能處理範圍請求： Accept-Ranges: none

2）、Age：Age: 600（秒）告知客戶端， 源服務器在多久前建立了響應

3）、ETag：告知客戶端實體標識。

資源被緩存時，就會被分配惟一性標識。是一種可將資源以字符串形式作惟一性標識的方式，資源更新時，ETag 值也須要更新。
強 ETag 值：不論實體發生多麼細微的變化都會改變其值。
弱 ETag 值：只用於提示資源是否相同。ETag: "usagi-1234"，產生差別時最開始的地方附加 W/：ETag: W/"usagi-1234"

4）、Location：將響應接收方引導至某個與請求 URI 位置不一樣的資源。配合3xx ： Redirection，提供重定向的URI

5）、Proxy-Authenticate：代理服務器所要求的認證信息發送給客戶端。

6）、Retry-After：告知客戶端應該在多久以後再次發送請求。配合狀態碼503 Service Unavailable。或 3xx Redirect。Retry-After: 120（秒）/ 日期

7）、Server：告知客戶端當前服務器上安裝的 HTTP 服務器應用程序的信息。Server: Apache/2.2.17 (Unix)，Server: Apache/2.2.6 (Unix) PHP/5.2.5

8）、Vary：可對緩存進行控制。源服務器會向代理服務器傳達關於本地緩存使用方法的命令。僅對請求中含有相同 Vary 指定首部字段的請求返回緩存。 不然即便資源相同也要向服務器從新獲取資源。

9）、WWW-Authenticate：知客戶端適用於訪問請求 URI 所指定資源的認證方案（Basic 或是 Digest）和帶參數提示的質詢（challenge）。狀態碼 401 Unauthorized 響應中，確定帶有首部字段 WWW-Authenticate。WWW-Authenticate: Basic realm="Usagidesign Auth"

六、實體首部字段：請求報文和響應報文中的實體部分所使用的首
部

1）、Allow：通知客戶端可以支持 Request-URI 指定資源的全部 HTTP 方法。服務器接收到不支持的 HTTP 方法時，會以狀態碼405 Method Not Allowed 做爲響應返回。Allow: GET, HEAD。

2）、Content-Encoding：告知客戶端服務器對實體的主體部分選用的內容編碼方式。內容編碼方式： gzip，compress，deflate，identity

3）、Content-Language：告知客戶端，實體主體使用的天然語言。Content-Language: zh-CN

4）、Content-Length ：代表了實體主體部分的大小（單位是字節）。Content-Length: 15000

5）、Content-Location：與報文主體部分相對應的 URI。和首部字段 Location 不一樣，Content-Location 表示的是報文主體返回資源對應的 URI。

6）、Content-MD5：目的在於檢查報文主體在傳輸過程當中是否保持完整，以及確認傳輸到達。Content-MD5: OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==，對報文主體執行 MD5 算法得到的 128 位二進制數，再經過Base64 編碼後將結果寫入 Content-MD5 字段值。因爲 HTTP 首部沒法記錄二進制值，因此要經過 Base64 編碼處理。爲確保報文的有效性，做爲接收方的客戶端會對報文主體再執行一次相同的 MD5 算法。計算出的值與字段值做比較後，便可判斷出報文主體的準確性。

7）、Content-Range：告知客戶端做爲響應返回的實體的哪一個部分符合範圍請求。Content-Range: bytes 5001-10000/10000（字節爲單位）

8）、Content-Type：實體主體內對象的媒體類型。

9）、Expires：首部字段 Expires 會將資源失效的日期告知客戶端。

10）、Last-Modified：指明資源最終修改的時間。

七、爲Cookie 服務的首部字段

Cookie 的工做機制是用戶識別及狀態管理。 把一些數據臨時寫入用戶的計算機內。 接當用戶訪問該Web網站時， 可經過通訊方式取回以前發放的Cookie。調用 Cookie 時，因爲可校驗 Cookie 的有效期，以及發送方的域、路徑、 協議等信息，

1)、Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; path
表 6-9： Set-Cookie 字段的屬性

expires:瀏覽器可發送 Cookie 的有效期。省略 expires 屬性時，其有效期僅限於維持瀏覽器會話（Session）時間段內。

一旦 Cookie 從服務器端發送至客戶端，服務器端就不存在能夠顯式刪除 Cookie 的方法。但可經過 覆蓋已過時的 Cookie，實現對客戶端 Cookie 的實質性刪除操做。

path:限制指定 Cookie 的發送範圍的文件目錄。
domain:指定的域名可作到與結尾匹配一致,當指定 example.com 後，除 example.com 之外，www.example.com或 www2.example.com 等均可以發送 Cookie。
secure:用於限制 Web 頁面僅在 HTTPS 安全鏈接時，才能夠發送 Cookie。Set-Cookie: name=value; secure
HttpOnly:它使 JavaScript 腳本沒法得到 Cookie。其主要目的爲防止跨站腳本攻擊（Cross-site scripting， XSS）對 Cookie 的信息竊取。Set-Cookie: name=value; HttpOnly

2）、Cookie：Cookie: status=enable，會告知服務器，當客戶端想得到 HTTP 狀態管理支持時，就會在請求中包含從服務器接收到的 Cookie。

八、其餘首部字段

HTTP 首部字段是能夠自行擴展的。因此在 Web 服務器和瀏覽器的應用上，會出現各類非標準的首部字段。

X-Frame-Options：X-Frame-Options: DENY（拒絕顯示），HTTP 響應首部，用於控制網站內容在其餘 Web 網站的 Frame 標籤內的顯示問題。目的是爲了防止點擊劫持（clickjacking）攻擊。SAMEORIGIN：僅同源域名下的頁面（Top-level-browsingcontext） 匹配時能夠顯示。

X-XSS-Protection： HTTP 響應首部，它是針對跨站腳本攻擊（XSS）的一種對策，用於控制瀏覽器 XSS 防禦機制的開關。0，關，1：開

DNT： HTTP 請求首部， 拒絕我的信息被收集，0：贊成被追蹤，1：拒絕被追蹤。

P3P： HTTP 響應首部，可讓 Web 網站上的我的隱私變成一種僅供程序可理解的形式，以達到保護用戶隱私的目的。