因?yàn)楣ぷ鞯脑虬闪居埃谶@里把HTTP首部總結(jié)一下，做一個(gè)學(xué)習(xí)筆記黍特。由于HTTP版本或擴(kuò)展規(guī)范的變化蛙讥，首部字段可支持的字段內(nèi)容略有不同。本文主要涉及HTTP/1.1及常用的首部字段灭衷。
先說一下HTTP首部字段吧次慢，有的書上也稱為HTTP消息頭，本文以首部簡(jiǎn)之翔曲。首部是構(gòu)成HTTP報(bào)文的要素之一迫像，在客戶端與服務(wù)器之間以HTTP協(xié)議進(jìn)行通信的過程中，無論是請(qǐng)求還是響應(yīng)都會(huì)使用首部瞳遍，它能起到傳遞額外重要信息的作用闻妓。首部構(gòu)成是這樣的，首先是首部字段傅蹂，后面跟著冒號(hào)（:）纷闺，然后跟上可選的空格，再跟上字段值份蝴，最后是一個(gè)CRLF犁功。
HTTP規(guī)范定義了幾種首部。應(yīng)用程序也可以隨意發(fā)明自己所用的首部婚夫。HTTP首部可以分為以下幾類浸卦。
-
通用首部
既可以出現(xiàn)在請(qǐng)求報(bào)文中，也可以出現(xiàn)在響應(yīng)報(bào)文中案糙。
-
請(qǐng)求首部
從客戶端向服務(wù)器端發(fā)送請(qǐng)求報(bào)文時(shí)使用的首部限嫌。補(bǔ)充了請(qǐng)求的附加內(nèi)容、客戶端信息时捌、響應(yīng)內(nèi)容優(yōu)先級(jí)等信息怒医。
-
響應(yīng)首部
從服務(wù)器端向客戶端返回響應(yīng)報(bào)文時(shí)使用的首部。補(bǔ)充了響應(yīng)的附加內(nèi)容奢讨，也會(huì)要求客戶端附加額外的內(nèi)容信息稚叹。
-
實(shí)體首部
針對(duì)請(qǐng)求報(bào)文和響應(yīng)報(bào)文的實(shí)體部分使用的首部。補(bǔ)充了資源內(nèi)容更新時(shí)間等與實(shí)體有關(guān)的信息拿诸。
-
擴(kuò)展首部
擴(kuò)展首部是非標(biāo)準(zhǔn)的首部扒袖，由應(yīng)用程序開發(fā)者創(chuàng)建，但還未添加到已經(jīng)批準(zhǔn)的HTTP規(guī)范中去亩码。即使不知道這些擴(kuò)展首部的含義季率，HTTP程序也要接受并對(duì)其進(jìn)行轉(zhuǎn)發(fā)。
通用首部
| 首部字段名 | 說明 |
|---|---|
| Cache-Control | 控制緩存的行為描沟。 |
| Connection | 逐跳首部飒泻、連接的管理鞭光。允許客戶端和服務(wù)器指定與請(qǐng)求/響應(yīng)連接有關(guān)的選項(xiàng)，用于告訴通信的另一端泞遗，在完成HTTP傳輸之后是關(guān)閉TCP連接還是保持連接開放以接受其他消息衰猛。 |
| Date | 創(chuàng)建報(bào)文的日期時(shí)間。說明報(bào)文是什么時(shí)間創(chuàng)建的刹孔。 |
| Pragma | 報(bào)文指令。另一種隨報(bào)文傳送指示的方式 |
| Trailer | 報(bào)文末端的首部一覽娜睛。如果報(bào)文采用了分塊傳輸編碼(chunked transfer encoding)方式髓霞，就可以用這個(gè)首部列出位于報(bào)文拖掛(trailer)部分的首部集合。 |
| Transfer-Encoding | 指定報(bào)文主體的傳輸編碼方式畦戒。如果使用這個(gè)首部方库，通常用它制定塊編碼。 |
| Upgrade | 升級(jí)為其他協(xié)議障斋。給出了發(fā)送端可能想要“升級(jí)”使用的新版本或協(xié)議 |
| Via | 代理服務(wù)器的相關(guān)信息纵潦。顯示報(bào)文經(jīng)過的中間節(jié)點(diǎn)(代理、網(wǎng)關(guān)) |
| Warning | 錯(cuò)誤通知垃环。 |
請(qǐng)求首部
| 首部字段名 | 說明 |
|---|---|
| Accept | 用戶代理可處理的媒體類型邀层。 |
| Accept-Charset | 優(yōu)先的字符集。 |
| Accept-Encoding | 優(yōu)先的內(nèi)容編碼遂庄。 |
| Accept-Language | 優(yōu)先的語言(自然語言)寥院。 |
| Authorization | Web認(rèn)證信息。包含了客戶端提供給服務(wù)器以便對(duì)其自身進(jìn)行認(rèn)證的數(shù)據(jù)涛目。 |
| Expect | 期待服務(wù)器的特定行為秸谢。 |
| From | 用戶的電子郵箱地址。 |
| Host | 請(qǐng)求資源所在服務(wù)器霹肝。 |
| If-Match | 比較實(shí)體標(biāo)記(ETag)估蹄，如果匹配，就獲取這份文檔沫换。 |
| If-Modified-Since | 比較資源的更新時(shí)間臭蚁。這個(gè)首部用于說明瀏覽器最后一次收到所請(qǐng)求的資源的時(shí)間，如果自那以后資源沒有發(fā)生變化苗沧，服務(wù)器會(huì)發(fā)出一個(gè)帶狀態(tài)碼304的響應(yīng)刊棕，指示瀏覽器使用資源的緩存副本。 |
| If-None-Match | 比較實(shí)體標(biāo)記(與If-Match相反)待逞。 |
| If-Range | 資源未更新時(shí)發(fā)送的實(shí)體Byte的范圍請(qǐng)求甥角。允許對(duì)文檔的某個(gè)范圍進(jìn)行條件請(qǐng)求。 |
| If-Unmodified-Since | 比較資源的更新時(shí)間(與If-Modified-Since相反)识樱。 |
| Max-Forwards | 最大傳輸逐跳數(shù)嗤无。在通往源端服務(wù)器的路徑上震束，將請(qǐng)求轉(zhuǎn)發(fā)給其他代理或網(wǎng)關(guān)的最大次數(shù)——與TRACE方法一同試用。 |
| Proxy-Authorization | 代理服務(wù)器要求客戶端的認(rèn)證信息当犯。 |
| Range | 實(shí)體的字節(jié)范圍請(qǐng)求垢村。 |
| Referer | 對(duì)請(qǐng)求中的URI的原始獲取方，或者說是提供了包含當(dāng)前URI文檔的URL |
| TE | 傳輸編碼的優(yōu)先級(jí)嚎卫。 |
| User-Agent | HTTP客戶端程序的信息嘉栓。 |
響應(yīng)首部
| 首部字段名 | 說明 |
|---|---|
| Accept-Ranges | 是否接受字節(jié)范圍請(qǐng)求。 |
| Age | 推算資源創(chuàng)建經(jīng)過時(shí)間拓诸。 |
| ETag | 資源的匹配信息侵佃。 |
| Location | 令客戶端重定向至指定URI。 |
| Proxy-Authenticate | 代理服務(wù)器對(duì)客戶端的認(rèn)證信息奠支。 |
| Retry-After | 對(duì)再次發(fā)起請(qǐng)求的時(shí)機(jī)要求馋辈。 |
| Server | HTTP服務(wù)器的安裝信息。 |
| Vary | 代理服務(wù)器緩存的管理信息倍谜。服務(wù)器查看其他首部的列表迈螟，可能會(huì)使響應(yīng)發(fā)生變化，也就是說尔崔，這是一個(gè)首部列表答毫，服務(wù)器會(huì)根據(jù)這些首部的內(nèi)容挑選出來最合適的資源版本發(fā)送給客戶端。 |
| WWW-Authenticate | 服務(wù)器對(duì)客戶端的認(rèn)證信息季春。用在帶401狀態(tài)碼的響應(yīng)中烙常，提供與服務(wù)器所支持的身份驗(yàn)證類型有關(guān)的信息。 |
實(shí)體首部
| 首部字段名 | 說明 |
|---|---|
| Allow | 資源可支持的HTTP方法鹤盒。 |
| Content-Encoding | 實(shí)體主體適用的編碼方式蚕脏。 |
| Content-Language | 實(shí)體主體的自然語言。 |
| Content-Length | 實(shí)體主體的大小(單位：字節(jié))侦锯。用于規(guī)定消息主體的字節(jié)長(zhǎng)度驼鞭。(HEAD語法的響應(yīng)例外，它在對(duì)應(yīng)的GET請(qǐng)求的響應(yīng)中指出主體的長(zhǎng)度) |
| Content-Location | 代替對(duì)應(yīng)資源的URI尺碰。 |
| Content-MD5 | 實(shí)體主體的報(bào)文摘要挣棕。 |
| Content-Range | 實(shí)體主體的位置范圍。 |
| Content-Type | 實(shí)體主體的媒體類型亲桥。 |
| Expires | 實(shí)體主體過期的日期時(shí)間洛心。 |
| Last-Modified | 資源的最后修改日期時(shí)間。 |
在 HTTP 協(xié)議通信交互中使用到的首部字段题篷，不限于 RFC2616 中定義的 47 種首部字段词身。還有 Cookie、 Set-Cookie 和 Content-Disposition 等在其他 RFC 中定義的首部字段番枚，它們的使用頻率也很高法严。自定義專用首部可通過'X-' 前綴來添加损敷；其他的首部在 IANA 注冊(cè)表 中列出，其原始內(nèi)容在 RFC 4229中定義深啤。IANA 同時(shí)還維護(hù)了被提議的新HTTP 首部注冊(cè)表拗馒。
擴(kuò)展首部
| 首部字段名 | 說明 |
|---|---|
| Cookie | 服務(wù)器接收到的Cookie信息。 |
| Origin | 在跨域Ajax請(qǐng)求中溯街，用于指示提出請(qǐng)求的域诱桂。 |
| Access-Control-Allow-Origin | 指示可否通過跨域Ajax請(qǐng)求獲取資源。 |
| Set-Cookie | 開始狀態(tài)管理所使用的Cookie信息呈昔。 |
| X-Frame-Options | 用戶控制網(wǎng)站內(nèi)容在其他Web網(wǎng)站的Frame標(biāo)簽內(nèi)顯示問題访诱。其主要目的是為了防止點(diǎn)擊劫持(clickJacking)攻擊。 |
| Strict-Transport-Security | 網(wǎng)站通過HTTP Strict Transport Security通知瀏覽器韩肝，這個(gè)網(wǎng)站禁止使用HTTP方式加載，瀏覽器應(yīng)該自動(dòng)把所有嘗試使用HTTP的請(qǐng)求自動(dòng)替換為HTTPS請(qǐng)求九榔。 HSTS可以很大程度上解決SSL剝離攻擊哀峻，因?yàn)橹灰獮g覽器曾經(jīng)與服務(wù)器創(chuàng)建過一次安全連接，之后瀏覽器會(huì)強(qiáng)制使用HTTPS哲泊，即使鏈接被換成了HTTP剩蟀。 另外，如果中間人使用自己的自簽名證書來進(jìn)行攻擊切威，瀏覽器會(huì)給出警告育特，但是許多用戶會(huì)忽略警告。HSTS解決了這一問題先朦，一旦服務(wù)器發(fā)送了HSTS字段缰冤，用戶將不再允許忽略警告。 |
接下來將一些常見的進(jìn)行一個(gè)詳細(xì)描述喳魏。
-
Cache-Control
通過指定首部Cache-Control的指令棉浸，就能操作緩存的工作機(jī)制。指令的參數(shù)是可選的刺彩，多個(gè)指令之間通過“迷郑，”分隔。參數(shù)有很多這里介紹幾個(gè)常見的创倔。
no-cache
使用no-cache指令的目的是為了防止從緩存中返回過期的資源嗡害。
客戶端請(qǐng)求包含no-cache指令，表示不接收緩存過的響應(yīng)畦攘。于是中間的緩存服務(wù)器必須把請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器霸妹。
服務(wù)器響應(yīng)包含no-cache指令，表示緩存服務(wù)器不能對(duì)資源進(jìn)行緩存知押。源服務(wù)器以后也將不會(huì)再對(duì)緩存服務(wù)器請(qǐng)求中提出的資源有效性進(jìn)行確認(rèn)抑堡，禁止其對(duì)響應(yīng)資源進(jìn)行緩存操作摆出。
no-store
使用no-store指令時(shí)，暗示請(qǐng)求(和對(duì)應(yīng)的響應(yīng))或響應(yīng)中包含機(jī)密信息首妖。因此該指令規(guī)定緩存不能在本地存儲(chǔ)請(qǐng)求或響應(yīng)的任何一部分偎漫。
從字面上很容易把no-cache誤解為不緩存，但事實(shí)上no-cache代表不緩存過期的資源有缆，緩存會(huì)向源服務(wù)器進(jìn)行有效期確認(rèn)后處理資源象踊。no-store才是真正地不進(jìn)行緩存。
max-age
客戶端請(qǐng)求包含max-age指令棚壁，如果判定緩存資源的緩存時(shí)間數(shù)值比指定時(shí)間的數(shù)值更小杯矩，那么客戶端就接收緩存的資源。另外袖外，當(dāng)max-age值為0史隆，那么緩存服務(wù)器通常需要將請(qǐng)求轉(zhuǎn)發(fā)給源服務(wù)器。
服務(wù)器響應(yīng)包含max-age指令曼验，緩存服務(wù)器將不對(duì)資源的有效性再做確認(rèn)泌射，而max-age數(shù)值代表資源保存為緩存的最長(zhǎng)時(shí)間。
應(yīng)用HTTP/1.1版本的緩存服務(wù)器遇到同時(shí)存在Expires首部的鬓照，優(yōu)先處理max-age指令熔酷，忽略Expires；HTTP/1.0版本的正好相反豺裆。
private
指定private指令后拒秘，響應(yīng)只以特定的用戶作為對(duì)象，緩存服務(wù)器會(huì)對(duì)該特定用戶提供資源緩存的服務(wù)臭猜，對(duì)于其他用戶發(fā)送過來的請(qǐng)求躺酒，代理服務(wù)器則不會(huì)返回緩存。
-
Connection
Connection首部具有如下兩個(gè)作用：
- 控制不再轉(zhuǎn)發(fā)給代理的首部字段
- 管理持久連接
控制不再轉(zhuǎn)發(fā)上
Connection:不再轉(zhuǎn)發(fā)的首部字段名
管理持久連接上
HTTP/1.1版本默認(rèn)連接都是持久連接蔑歌。當(dāng)服務(wù)器想明確斷開連接時(shí)阴颖，則會(huì)使用Connection: close
HTTP/1.1之前版本的默認(rèn)連接都是非持久連接。為此丐膝，想在舊版本的HTTP協(xié)議上維持持續(xù)連接則需要使用Connection: Keep-Alive量愧。
-
Server
首部Server告知客戶端當(dāng)前服務(wù)器上安裝的HTTP服務(wù)器應(yīng)用程序的信息，不單單會(huì)標(biāo)出服務(wù)器上軟件應(yīng)用的名稱帅矗，而且還有可能包括版本號(hào)和安裝時(shí)啟用的可選項(xiàng)偎肃。
-
Set-Cookie
控制瀏覽器處理cookie的方式，其包含一些可選屬性浑此。
NAME=VALUE(必選項(xiàng))
賦予Cookie的名稱和值
expires=DATE
expires屬性指定瀏覽器可發(fā)送Cookie的有效期累颂。
當(dāng)省略時(shí)，其有效期僅限于維持瀏覽器會(huì)話(Session)時(shí)間段內(nèi)。另外一旦Cookie從服務(wù)器發(fā)送到客戶端紊馏，服務(wù)器就不存在可以顯式刪除Cookie的方法料饥，但可以通過覆蓋已過期的Cookie，實(shí)現(xiàn)對(duì)客戶端Cookie的實(shí)質(zhì)性刪除操作朱监。
path=PATH
用于指定cookie的有效URL路徑岸啡，限制指定URL可以發(fā)送該cookie，不過另有辦法可以避開這項(xiàng)限制赫编。
domain=域名
用于指定cookie的有效域巡蘸。這個(gè)域必須和收到的cookie的域相同，或者是它的父域擂送。
secure
添加該屬性時(shí)悦荒，僅在HTTPS請(qǐng)求中才可提交該cookie
HttpOnly
如果添加該屬性，將無法通過客戶端JavaScript直接訪問cookie嘹吨，可防止XSS攻擊搬味。
-
Vary
從代理服務(wù)器接收到源服務(wù)器返回包含Vary指定項(xiàng)的響應(yīng)后，若要再進(jìn)行緩存蟀拷，僅對(duì)請(qǐng)求中含有相同Vary指定首部的請(qǐng)求返回緩存碰纬。即使對(duì)相同資源發(fā)起請(qǐng)求，但由于Vary指定的首部不相同匹厘，因此必須要從源服務(wù)器重新獲取資源。
-
Host
首部Host會(huì)告知服務(wù)器脐区，請(qǐng)求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號(hào)愈诚。Host首部在HTTP/1.1規(guī)范內(nèi)是唯一一個(gè)必須包含在請(qǐng)求內(nèi)的首部字段。主要與單臺(tái)服務(wù)器分配多個(gè)域名的虛擬主機(jī)有關(guān)牛隅。
-
User-Agent
首部User-Agent會(huì)將創(chuàng)建請(qǐng)求的瀏覽器和用戶代理名稱等信息傳達(dá)給服務(wù)器炕柔。
-
Accept
Accept首部可通知服務(wù)器，用戶代理能夠處理的媒體類型及媒體類型的相對(duì)優(yōu)先級(jí)媒佣∝袄郏可使用type/subtype這種形式，一次指定多種媒體類型默伍。
若想增加優(yōu)先級(jí)欢嘿，則使用q=來表示權(quán)重，用分號(hào)(;)分隔也糊，q取值0~1炼蹦，默認(rèn)q=1.0。
-
Referer
在客戶端請(qǐng)求中插入Referer首部狸剃，可以使服務(wù)器知道客戶端是從哪里獲得其請(qǐng)求的URL的掐隐。這是一種對(duì)服務(wù)器有益的自愿行為，這樣服務(wù)器就可以更好的記錄請(qǐng)求或執(zhí)行其他任務(wù)了。
瀏覽器所做的工作相當(dāng)簡(jiǎn)單虑省，如果在主頁(yè)A上點(diǎn)擊一個(gè)鏈接匿刮，進(jìn)入主頁(yè)B，瀏覽器就會(huì)在請(qǐng)求中插入一個(gè)帶有A值得Referer首部探颈，自己輸入的URL中不會(huì)包含Referer首部熟丸。
Cookie
Cookie可以籠統(tǒng)的分為兩類，會(huì)話cookie和持久cookie膝擂，兩者區(qū)別就是過期時(shí)間虑啤。會(huì)話cookie是一種臨時(shí)cookie，他記錄了用戶訪問站點(diǎn)時(shí)的設(shè)置和偏好架馋，用戶退出瀏覽器時(shí)狞山，會(huì)話cookie就被刪除了。通常用持久cookie維護(hù)某個(gè)用戶周期性訪問的站點(diǎn)的配置文件或登錄名叉寂。
如有錯(cuò)誤萍启，歡迎指正。
