讀《圖解HTTP》記錄

上一篇 讀書筆記_圖解HTTP(二) 簡單HTTP協(xié)議及HTTP報文內(nèi)的HTTP信息

web服務(wù)器

http通信時酷师，除了客戶端和服務(wù)器之外箍镜，還有一些用于通信數(shù)據(jù)轉(zhuǎn)發(fā)的程序坛掠，例如代理瓣窄、網(wǎng)關(guān)溢吻、隧道乌庶。它們可以配合服務(wù)器工作从诲。
這些應(yīng)用程序和服務(wù)器可以將請求轉(zhuǎn)發(fā)給通信線路上的下一站服務(wù)器左痢，并且能接收從那臺服務(wù)器發(fā)送的響應(yīng)再轉(zhuǎn)發(fā)給客戶端。

代理

代理是一種有轉(zhuǎn)發(fā)功能的應(yīng)用程序系洛，它扮演了位于服務(wù)器和客戶端“中間人”的角色俊性，接收客戶端發(fā)送的請求并轉(zhuǎn)發(fā)給服務(wù)器，同時也接收服務(wù)器返回的響應(yīng)并轉(zhuǎn)發(fā)給客戶端描扯。

代理服務(wù)器的基本行為就是接收客戶端的請求后轉(zhuǎn)發(fā)給其他服務(wù)器定页。代理不改變請求的URI，會直接發(fā)送給前方持有資源的目標(biāo)服務(wù)器荆烈。
持有資源實(shí)體的源服務(wù)器返回的響應(yīng)經(jīng)過代理服務(wù)器再傳給客戶端拯勉。

代理服務(wù)器

使用代理服務(wù)器的理由：利用緩存技術(shù)減少網(wǎng)絡(luò)帶寬的流量，組織內(nèi)部針對特定網(wǎng)站的訪問控制等

代理的分類

代理有多種使用方法憔购，按兩種基準(zhǔn)分類宫峦。一是 是否使用緩存，另一種是 是否會修改報文玫鸟。

• 緩存代理
  代理轉(zhuǎn)發(fā)響應(yīng)時导绷，緩存代理會預(yù)先將資源的副本保存在代理服務(wù)器上。當(dāng)代理服務(wù)再次接收到對相同資源的請求時屎飘，就可以不從源服務(wù)器那里獲取資源妥曲，而是將之前緩存的資源作為響應(yīng)返回。
• 透明代理
  轉(zhuǎn)發(fā)請求或響應(yīng)時钦购，不對報文做任何加工的代理類型被稱為透明代理檐盟。反之，對報文內(nèi)容進(jìn)行加工的代理被稱為非透明代理押桃。

網(wǎng)關(guān)

網(wǎng)關(guān)是轉(zhuǎn)發(fā)其他服務(wù)器通信數(shù)據(jù)的服務(wù)器葵萎，接收從客戶端發(fā)來的請求時，他會像自己擁有資源的源服務(wù)器一樣對請求進(jìn)行處理唱凯。有時客戶端可能都不會察覺羡忘，自己的通信目標(biāo)是一個網(wǎng)關(guān)。

網(wǎng)關(guān)

網(wǎng)關(guān)的工作機(jī)制和代理十分相似磕昼。而網(wǎng)關(guān)能使通信線路上的服務(wù)器提供非Http協(xié)議服務(wù)卷雕。

利用網(wǎng)關(guān)能提升通信的安全性，因為可以在客戶端與網(wǎng)關(guān)之間的通信線路上加密以確保連接的安全票从。比如漫雕，網(wǎng)關(guān)可以連接數(shù)據(jù)庫滨嘱，使用sql語句查詢數(shù)據(jù)。另外蝎亚，在Web購物網(wǎng)站上進(jìn)行信用卡結(jié)算時九孩，網(wǎng)關(guān)可以和信用阿卡結(jié)算系統(tǒng)聯(lián)動先馆。

隧道

隧道是在相隔甚遠(yuǎn)的客戶端和服務(wù)器兩者之間進(jìn)行中轉(zhuǎn)发框，并保持雙方通信連接的應(yīng)用程序。

隧道

隧道可按要求建立一條與其他服務(wù)器的通信線路煤墙，屆時使用SSL等加密手段進(jìn)行通信梅惯。隧道的目的是確保客戶端能與服務(wù)器進(jìn)行安全的通信仿野。
隧道本身不會去解析HTTP請求铣减。請求將保持原樣中轉(zhuǎn)給之后的服務(wù)器。隧道會在通信雙方斷開連接時結(jié)束脚作。隧道本身是透明的葫哗，客戶端不用在意隧道的存在。

保存資源的緩存

緩存是指代理服務(wù)器或客戶端本地磁盤內(nèi)保存的資源副本球涛。利用緩存可減少對源服務(wù)器的訪問劣针，因此節(jié)省了通信流量和通信時間。
緩存服務(wù)器是代理服務(wù)器的一種亿扁，并歸類在緩存代理類型中捺典。

緩存服務(wù)器

緩存服務(wù)器會因為客戶端的要求棚辽、緩存的有效期等因素库快，向源服務(wù)器確認(rèn)資源的有效性渴杆。若判斷緩存失效申鱼，緩存服務(wù)器將會再次從 源服務(wù)器上取“新”資源锨推。

緩存的有效期

客戶端中同樣有緩存芒帕，客戶端緩存稱為臨時網(wǎng)絡(luò)文件伦吠。瀏覽器緩存如果有效根暑，就不必去服務(wù)器請求相同資源了毒涧，可以直接在本地緩存內(nèi)讀取贮预。
客戶端緩存和服務(wù)器緩存一樣，當(dāng)判定緩存過期后链嘀，會向源服務(wù)器確認(rèn)資源的有效性萌狂。如果判斷瀏覽器緩存失效，會再次請求新資源怀泊。

客戶端緩存

Http首部

通用首部字段

請求報文和響應(yīng)報文兩方都會使用的首部茫藏。

1霹琼、Cache-Control 緩存工作機(jī)制

通過指定首部字段Cache-Control的指令务傲，就能操作緩存的工作機(jī)制凉当。
指令的參數(shù)是可選的，多個指令之間通過“售葡，”分隔看杭。首部字段Cache-Control的指令可用于請求及響應(yīng)。
例：Cache-Control: private, max-age=0, no-cache

緩存請求指令

緩存響應(yīng)指令

表示是否能緩存的命令

• public 指令

Cache-Control: public

當(dāng)使用public指令時挟伙，則明確表明其他用戶也可以利用緩存楼雹。

• private 指令

Cache-Control:private

當(dāng)指定private指令后，響應(yīng)只以特定的用戶作為對象尖阔，這與public指令的行為相反贮缅。
緩存服務(wù)器會對該特定用戶提供資源緩存的服務(wù)，對其他用戶發(fā)送過來的請求介却，代理服務(wù)器則不會返回緩存谴供。

private 指令和public 指令正好相反，舉個栗子解釋上邊的齿坷。
我和小A是鄰居桂肌，我們倆用同一個網(wǎng)關(guān)。我喜歡體育永淌，他喜歡音樂崎场。這時候我登錄后通過網(wǎng)絡(luò)去請求數(shù)據(jù)，返回給我的都是和體育相關(guān)的數(shù)據(jù)仰禀。他登錄后去網(wǎng)絡(luò)請求數(shù)據(jù)照雁，返回的都是音樂相關(guān)的數(shù)據(jù)。這樣是正確的答恶，因為這時候服務(wù)器返回的緩存指令可能是private,告訴中間的網(wǎng)關(guān)饺蚊，或者緩存服務(wù)器不要緩存。但是如果使用public指令悬嗓，返回的可能緩存過的數(shù)據(jù)了污呼，這樣就是不對的了。

• no-cache指令

  
  
  no-cache

Cache-Control: no-cache

使用no-cache指令的目的是為了防止從緩存中返回過期的資源包竹。
客戶端發(fā)送的請求中如果包含no-cache指令燕酷，則表示客戶端將不會接收緩存過的響應(yīng)。于是周瞎，“中間”的緩存服務(wù)器必須從客戶端請求轉(zhuǎn)發(fā)給源服務(wù)器苗缩。
如果服務(wù)器返回的響應(yīng)中包含no-cache指令，那么緩存服務(wù)器不能對資源進(jìn)行緩存声诸。源服務(wù)器以后也將不會再對緩存服務(wù)器請求中提出的資源有效性進(jìn)行確認(rèn)酱讶，且禁止其對響應(yīng)資源進(jìn)行緩存操作。

Cache-Control:no-cache=Location

由服務(wù)器返回的響應(yīng)中彼乌，如果報文首部字段Cache-control中對no-cache字段名具體指定參數(shù)值泻肯，那么客戶端在接收到這個被指定參數(shù)值的首部字段對應(yīng)的響應(yīng)報文后渊迁，就不能使用緩存。就是說灶挟，無參數(shù)值的首部字段可以使用緩存琉朽。只能在響應(yīng)指令中指定該參數(shù)。

控制可執(zhí)行緩存的對象的指令

• no-store指令

Cache-Control:no-store

使用no-store指令時稚铣，暗示請求和響應(yīng)中包含機(jī)密信息箱叁。因此，該指令緩存不能在本地存儲請求或者響應(yīng)的任一部分榛泛。

指定緩存期限和認(rèn)證的指令

• s-maxage 指令

Cache-Control:s-maxage=604800(s)

s-maxage指令的功能和max-age指令的相同蝌蹂，他們的不同點(diǎn)是max-age指令只適用于供多位用戶使用的公共緩存服務(wù)器噩斟。也就是說曹锨，對于向同一用戶重復(fù)返回響應(yīng)的服務(wù)器來說，這個指令沒有任何作用剃允。
另外沛简，當(dāng)使用s-maxage指令后，則直接忽略對Expires首部字段以及max-age指令的處理斥废。

• max-age 指令

  
  
  max-age

Cache-control:max-age=604800(s)

客戶端：客戶端發(fā)送的請求中包含max-age指令椒楣，如果判定混村資源的緩存時間數(shù)值比指定時間的數(shù)值更小，那客戶端就接受緩存的資源牡肉。另外捧灰，當(dāng)指定max-age值為0，那么緩存服務(wù)器通常需要將請求轉(zhuǎn)發(fā)給源服務(wù)器统锤。
服務(wù)器：返回的響應(yīng)中包含max-age時毛俏，緩存服務(wù)器將不對資源的有效性再做確認(rèn)，而max-age的數(shù)值代碼資源保存為緩存的最大時間饲窿。

在http1.1版本中煌寇，同時存在Expires首部字段，會優(yōu)先處理max-age指令逾雄，忽略Expires首部字段阀溶。http1.0相反，max-age會被忽略掉鸦泳。

• min-fresh指令

  
  
  min-fresh

Cache-Control: min-fresh=60（單位：秒）

min-fresh 指令要求緩存服務(wù)器返回至少還未過指定時間的緩存資源银锻。
比如，當(dāng)指定min-fresh為60s后做鹰，過了60s的資源都無法作為響應(yīng)返回了击纬。

• max-stale指令

Cache-Control:max-stale=3600(s)

使用max-stale可指示緩存資源，即使過期也照常接收誊垢。
如果指令中未指定參數(shù)值掉弛，那么無論經(jīng)過多久症见，客戶端都會接收響應(yīng)；如果指令中指定了具體數(shù)值殃饿，那么即使過期谋作，只要仍處于max-stale指定的時間內(nèi)，仍會被客戶端接收乎芳。

• only-if-cached指令

Cache-Control:only-if-cached

使用only-if-cached指令表示客戶端僅在緩存服務(wù)器本地緩存目標(biāo)資源的情況下才會要求其返回遵蚜。換言之，該指令要求緩存服務(wù)器不重新加載響應(yīng)奈惑，也不會再次確認(rèn)資源有效性吭净。若發(fā)生請求緩存服務(wù)器的本地緩存無響應(yīng)，則返回狀態(tài)碼504 Gateway Timeout.

• must-revalidate 指令

Cache-Control:must-revalidate

代理會向源服務(wù)器再次驗證即將返回到額相應(yīng)緩存目前是否仍然有效肴甸。
若代理無法連通源服務(wù)器再次獲取有效資源的話寂殉，緩存必須給客戶端一條504狀態(tài)碼。
另外原在，使用該指令會忽略請求的max-stale指令(即使已經(jīng)在首部使用了max-stale友扰，也不會再有效果)。

• proxy-revalidate 指令

Cache-Control:proxy-revalidate

proxy-revalidate 指令要求所有的緩存服務(wù)器在接收到客戶端帶有該指令的請求返回響應(yīng)之前庶柿，必須再次驗證緩存的有效性村怪。

• no-transform 指令

Cache-Control:no-transform

使用no-transform指令規(guī)定無論是在請求還是響應(yīng)中，緩存都不能改變實(shí)體主體的媒體類型浮庐。
這樣做可以飯知緩存或代理壓縮圖片等類似操作甚负。

Cache-Control擴(kuò)展

• cache-extension token

Cache-Control:private,community="UCI"

通過cache-extension 標(biāo)記(token)，可以擴(kuò)展Cache-Control首部字段的指令审残。
如上例梭域，Cache-Control首部字段本身沒有community這個指令。借助extension tokens實(shí)現(xiàn)了該指令的添加维苔。如果緩存服務(wù)器不能理解community這個新指令碰辅，就會直接忽略。因此介时，extension tokens僅對能理解它的緩存服務(wù)器來說是有意義的没宾。

2、Connection

Connection首部字段具備如下兩個作用

• 控制不再轉(zhuǎn)發(fā)給代理的首部字段

Connection:不在轉(zhuǎn)發(fā)的首部字段名

在客戶端發(fā)送請求和服務(wù)器返回響應(yīng)內(nèi)沸柔，使用Connection首部字段循衰，可控制不再轉(zhuǎn)發(fā)給代理的首部字段（即Hop-by-hop首部）。

Connection1

• 管理持久連接

Connection:close

http1.1版本的默認(rèn)鏈接都是持久連接褐澎。為此会钝，客戶端會在持久連接上連續(xù)發(fā)送請求。當(dāng)服務(wù)器想明確斷開連接時，則指定Connection首部字段的值為Close迁酸。

Connection2

Connection:Keep-Alive

http1.1之前的所有http版本默認(rèn)的連接方式都是非持久連接先鱼。為此，如果想在舊版本的http協(xié)議上維持 持續(xù)連接奸鬓，則需要指定Connection首部字段的值為Keep-Alive焙畔。

Connection

如上圖1客戶端發(fā)送請求給服務(wù)器時，服務(wù)器會像上圖2那樣加上首部字段Keep-Alive及首部字段Connection后返回響應(yīng)串远。

3宏多、Date

首部字段Date表明創(chuàng)建HTTP報文的日期和時間

Date

Http1.1協(xié)議使用在RFC1123中規(guī)定的日期時間的格式，如下：

Date:Tue, 03 Jul 2012 04:40:59 GMT

之前的http協(xié)議版本中使用在RFC850中定義的格式澡罚，如下所示伸但。

Date： Tue, 03-Jul-12 04:40:59 GMT

除此之外，還有一種格式留搔。它與 C 標(biāo)準(zhǔn)庫內(nèi)的 asctime() 函數(shù)的輸出 格式一致更胖。

Date: Tue Jul 03 04:40:59 2012

4、Pragma

pragma是Http1.1之前版本的歷史遺留字段催式，僅作為與http1.0的向后兼容而定義函喉。規(guī)范定義的形式唯一，如下：

Pragma:no-cache

該首部字段屬于通用首部字段荣月，但只用在客戶端發(fā)送請求中∈岜校客戶端會要求所有的中間服務(wù)器不返回緩存的資源哺窄。

Pragma

所有的中間服務(wù)器如果都能以http1.1為基準(zhǔn)，那么直接采用Cache-Control:no-cache指定緩存的處理方式最為理想账锹。但是要整體掌握全部中間服務(wù)器使用的http協(xié)議版本確實(shí)不現(xiàn)實(shí)的萌业。要兼容http1.1之前版本。因此奸柬，發(fā)送的請求會同時含有下面量子首部字段生年。

Cache-Control:no-cache
Pragma:no-cache

5、Trailer

Trailer

首部字段Trailer會事先說明在報文主體后記錄了哪些首部字段廓奕。該首部字段可應(yīng)用在http1.1版本分塊傳輸編碼時抱婉。

HTTP/1.1 200 OK 
Date: Tue, 03 Jul 2012 04:40:56 GMT 
Content-Type: text/html 
... 
Transfer-Encoding: chunked 
Trailer: Expires 
...(報文主體)... 
0 
Expires: Tue, 28 Sep 2004 23:59:59 GMT 

以上用例中，指定首部字段Trailer的值為Expires,在報文主體之后(分塊長度0之后)出現(xiàn)了首部字段Expires桌粉。

6蒸绩、Transfer-Encoding

Transfer-Encoding

首部字段Transfer-Encoding規(guī)定了傳輸報文主體時采用的編碼方式。
Http1.1的傳輸編碼方式僅對分塊傳輸編碼有效铃肯。

HTTP/1.1 200 OK 
Date: Tue, 03 Jul 2012 04:40:56 GMT 
Cache-Control: public, max-age=604800 
Content-Type: text/javascript; charset=utf-8 
Expires: Tue, 10 Jul 2012 04:40:56 GMT 
X-Frame-Options: DENY 
X-XSS-Protection: 1; mode=block 
Content-Encoding: gzip 
Transfer-Encoding: chunked 
Connection: keep-alive 
cf0    ←16進(jìn)制(10進(jìn)制為3312) 
...3312字節(jié)分塊數(shù)據(jù)... 
392    ←16進(jìn)制(10進(jìn)制為914) 
...914字節(jié)分塊數(shù)據(jù)... 
0 

以上用例中患亿，在首部字段Transfer-Encoding中指定，有效使用分塊傳輸編碼押逼，且分別被分成3312字節(jié)和914字節(jié)大小的分塊數(shù)據(jù)步藕。

7惦界、Upgrade

首部字段Upgrade用于檢測Http協(xié)議以及其他協(xié)議是否可用于更高版本進(jìn)行通信，其參數(shù)值可以用來指定一個完全不同的通信協(xié)議咙冗。

Upgrade

上圖用例中表锻，首部字段Upgrade指定的值為TLS1.0,請注意此處兩個字段首部字段的對應(yīng)關(guān)系，Connection的值被指定為Upgrade乞娄。Upgrade首部字段產(chǎn)生作用的Upgrade對象僅限于客戶端和鄰接服務(wù)器之間瞬逊。因此，使用首部字段Upgrade時仪或，還需要額外指定Connection:Upgrade.
對于附有首部字段Upgrade的請求确镊，服務(wù)器可用101 Switching Protocols狀態(tài)碼作為響應(yīng)返回。

8范删、Via

使用首部字段Via是為了追蹤客戶端和服務(wù)器之間的請求和響應(yīng)報文的傳輸路徑蕾域。

報文經(jīng)過代理或者網(wǎng)關(guān)時，回現(xiàn)在首部字段Via中附加該服務(wù)器的信息到旦，然后再進(jìn)行轉(zhuǎn)發(fā)旨巷。這種做法和traceroute及電子郵件的Received首部的工作機(jī)制很類似。

首部字段Via不僅用于追蹤報文的轉(zhuǎn)發(fā)添忘，還可避免請求回環(huán)的發(fā)生采呐，所以必須在經(jīng)過代理時附加該首部字段內(nèi)容。

Via

上圖用例中搁骑，在經(jīng)過代理服務(wù)器A時斧吐，Via首部附加了“1.0 gw。hackr.jp(Squid/3.1)”這樣的字符串仲器。行頭的1.0是指接收到請求的服務(wù)器上應(yīng)用的Http協(xié)議版本煤率。在接下來經(jīng)過代理服務(wù)器B時也是在Via中添加服務(wù)器信息。

Via首部是為了追蹤傳輸路徑乏冀，所以經(jīng)常會和TRACE方法一起使用蝶糯。比如，代理服務(wù)器接收到TRACE方法發(fā)送過來的請求(其中Max-Forwards:0)時辆沦，代理服務(wù)器就不能再轉(zhuǎn)發(fā)該請求了昼捍。這種情況下，代理服務(wù)器會將自身的信息附加到Via首部后众辨，返回該請求的響應(yīng)端三。

9、Warning

Http1.1 的Warning首部是從Http1.0的響應(yīng)首部(Retry-After)演變過來的鹃彻。該首部通常會告知用戶一些與緩存相關(guān)的問題的警告郊闯。

Warning ： 113 gw.hackr.jp:8080  "Heuristic expiration" Tue, 03 Jul 2012 04:40:56 GMT 

Warning 首部的格式如下。

Warning: [警告碼][警告的主機(jī):端口號]“[警告內(nèi)容]”([日期時間])

Http1.1中定義了7中警告。警告碼對應(yīng)的警告內(nèi)容僅推薦參考团赁。另外育拨，警告嗎具備擴(kuò)展性，今后有可能追加新的警告碼欢摄。

• Http1.1警告碼

請求首部字段

請求首部字段是從客戶端往服務(wù)器端發(fā)送請求報文所使用的字段熬丧，用于補(bǔ)充請求的附加信息、客戶端信息怀挠、對相應(yīng)內(nèi)容相關(guān)的優(yōu)先級等內(nèi)容析蝴。

請求首部字段

1、Accept

Accept

Accept：text/html,application/xhtml+xml,application/xml

Accept首部字段可通知服務(wù)器绿淋，用戶代理能夠處理的媒體類型以及媒體類型的相對優(yōu)先級闷畸。可使用type/subtype這種形式吞滞，一次指定多種媒體類型佑菩。

例子：

• 文本文件

text/html，text/plain,text/css...
application/xhtml+xml,application/xml...

• 圖片文件

image/jpeg,image/gif,image/png...

• 視頻文件

video/mpeg,video/quicktime...

• 應(yīng)用程序使用的二進(jìn)制文件

application/octet-stream,application/zip...

比如裁赠，如果瀏覽器不支持PNG圖片的顯示殿漠，那Accpet就不指定image/png，而指定可處理的image/gif和image/jpeg等圖片類型佩捞。

若想要給顯示的媒體類型增加優(yōu)先級绞幌，則使用q=來額外便是權(quán)重值,用分號（;）來進(jìn)行分隔。權(quán)重值q的范圍是0~1（可精確到小數(shù)點(diǎn)后3位）失尖，且1為最大值啊奄。不指定權(quán)重時，默認(rèn)權(quán)重為q=1.0掀潮。

2、Accept-Charset

Accept-Charset

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

Accept-Charset首部字段可用來通知服務(wù)器用戶代理支持的字符集及字符集的相對優(yōu)先順序琼富。另外仪吧，可一次性只當(dāng)多種字符集。與首部字段Accept相同的是可使用權(quán)重P值表示相對優(yōu)先級鞠眉。
該首部字段應(yīng)用于內(nèi)容協(xié)商機(jī)制的服務(wù)器驅(qū)動協(xié)商薯鼠。

3、Accept-Encoding

Accept-Encoding

Accept-Encoding:gzip,deflate

Accept-Encoding首部字段用來告知服務(wù)器用戶代理支持的內(nèi)容編碼以及內(nèi)容編碼的優(yōu)先級順序械蹋〕龌剩可一次性指定多種內(nèi)容編碼。
內(nèi)容編碼類型

• gzip
  由文件壓縮程序 gzip(GNU zip)生成的編碼格式(RFC1952)哗戈，采用Lempel-Ziv算法(LZ77)及32位循環(huán)冗余校驗郊艘。
• compress
  由UNIX文件壓縮程序compress生成的編碼格式，菜用Lempel-Ziv-Welch算法。
• deflate
  組合使用zlib格式及由deflate壓縮算法生成的編碼格式纱注。
• identity
  不執(zhí)行壓縮或者不會變化的默認(rèn)編碼格式

4畏浆、Accept-Language

Accept-Language

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

首部字段Accept-Language用來告知服務(wù)器用戶代理能夠處理的自然語言集(指中文或英文等),以及自然語言集的相對優(yōu)先級∧可一次指定多種自然語言集刻获。

和Accept首部字段一樣，按權(quán)重值q來表示相對優(yōu)先級瞎嬉。在上述圖中蝎毡，客戶端在服務(wù)器有中文版資源的情況下，會請求其返回中文版對應(yīng)的響應(yīng)氧枣，沒有中文版時沐兵，則請求返回英文版響應(yīng)。

5挑胸、Authorization

Authorization

Authorization:Basic dwxxxxxxxxxxxxxxxxxxxxxxxxx==

首部字段Authorization是用來告知服務(wù)器痒筒，用戶代理的認(rèn)證信息(證書值).通常，想要通過服務(wù)器認(rèn)證的用戶代理會在接收到返回的401狀態(tài)碼響應(yīng)后茬贵，把首部字段Authorization加入到請求中簿透。共用緩存在接收到含有Authorization首部字段的請求時的操作處理會略有差異。

6解藻、Expect

Expect

Expect: 100-continue

客戶端使用首部字段Expect來告知服務(wù)器老充，期望出現(xiàn)的某種特定行為。因為服務(wù)器無法理解客戶端的期望作出回應(yīng)而發(fā)生錯誤時螟左，則返回狀態(tài)碼417 Expectation Failed啡浊。
客戶端也可以利用該首部字段，寫明所期望的擴(kuò)展胶背。雖然http1.1規(guī)范只定義了100-continue(狀態(tài)碼100 Continue之意)巷嚣。
等待狀態(tài)碼100響應(yīng)的客戶端在發(fā)生請求時，需要指定Expect:100-continue钳吟。

7廷粒、From

From

首部字段From用來告知服務(wù)器使用用戶代理的用戶的電子郵件地址。通常红且，其使用目的就是為了顯示搜索引擎等用戶代理的負(fù)責(zé)人的電子郵件聯(lián)系方式喇勋。使用代理時碉熄，應(yīng)盡可能包含F(xiàn)rom首部字段(但可能會因為代理不同生蚁，將電子郵件地址記錄在User-Agent首部字段內(nèi)).

8档悠、Host

Host

圖：虛擬主機(jī)運(yùn)行在同一ip上，使用Host字段加以區(qū)分壁酬。

Host：www.hackr.jp

注意：這個字段是用來確定在目標(biāo)服務(wù)器上的子服務(wù)器的次酌，不是用來在網(wǎng)絡(luò)上找主機(jī)的恨课。

首部字段Host會告知服務(wù)器，請求的資源所處的互聯(lián)網(wǎng)主機(jī)名和端口號和措。Host首部字段在Http1.1規(guī)范內(nèi)是唯一一個必須包含在請求內(nèi)的首部字段庄呈。

首部字段Host和以單臺服務(wù)器分配多個域名的虛擬主機(jī)的工作機(jī)制有很密切的關(guān)聯(lián)，這是首部字段Host必須存在的意義派阱。

請求被發(fā)送至服務(wù)器時诬留，請求中的主機(jī)名會用IP地址直接解決。但如果這時贫母，享用的額IP地址下部署運(yùn)行著多個域名文兑，那么服務(wù)器就會無法理解究竟是哪個域名對應(yīng)的請求。因此腺劣，就需要使用首部字段Host來明確指出請求的主機(jī)名绿贞。若服務(wù)器未設(shè)置主機(jī)名，那直接發(fā)送一個空值即可橘原。如下所示籍铁。

Host：

9、If-Match

If-Match1.png

附帶條件請求
形如if-xxx這種樣式的請求首部字段趾断，都可稱為條件請求拒名。服務(wù)器接收到附帶條件的請求后，只有判斷指定條件為真時芋酌，才會執(zhí)行請求增显。

If-Match2.png

圖：只有當(dāng)If-Match的字段值跟ETag值匹配一致時，服務(wù)器才會接受請求

If-Match:"123456"

首部字段If-Match脐帝，屬附帶條件之一同云，他會告知服務(wù)器匹配資源所用的實(shí)體標(biāo)記(ETag)值。這時的服務(wù)器無法使用弱ETag值堵腹。

服務(wù)器會對比If-Match的字段值和資源的ETag值炸站，僅當(dāng)兩者一致時，才會執(zhí)行請求疚顷。反之武契，則返回狀態(tài)碼412 Precondition Failed的響應(yīng)。
還可以使用星號(*) 指定If-Match的字段值荡含。針對這種情況，服務(wù)器將會忽略ETag的值届垫，只要資源存在就處理請求释液。

10、If-Modified-Since

If-Modified-Since

圖：如果在If-Modified-Since字段指定的日期時間之后装处，資源發(fā)生了更新误债，服務(wù)器會接受請求

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

首部字段 If-Modified-Since,屬于附帶條件之一浸船，它會告知服務(wù)器若If-Modified-Since字段值早于資源的更新時間，則希望能處理該請求寝蹈。而在指定If-Modified-Since字段值的日期時間之后李命，如果請求的資源都沒有更新，則返回狀態(tài)碼304 Not Modified的響應(yīng)箫老。

If-Modified-Since用于確認(rèn)代理或客戶端擁有的本地資源的有效性封字。獲取資源的更新日期時間∷ｗ蓿可通過確認(rèn)首部字段Last-Modified來確定阔籽。

11、If-None-Match

If-None-Match

首部字段If-None-Match屬于附帶條件之一牲蜀。它和If-Match作用相反笆制，用于指定If-None-Match字段值的實(shí)體標(biāo)記(ETag)值與請求資源的ETag不一致時，它就告知服務(wù)器處理該請求涣达。

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

12匆篓、If-Range

If-Range

If-Range屬于附帶條件之一。它告知服務(wù)器若指定的If-Range字段值和請求資源的ETag值或時間相一致時林螃，則作為范圍請求處理奕删。反之返回全體資源。

If-Range1

下面我們思考一下不使用首部字段If-Range發(fā)送請求的情況疗认。服務(wù)器端的資源如果更新完残，那客戶端持有資源中的一部分也會隨之無效，當(dāng)然横漏，范圍請求作為前提是無效的谨设。這時，服務(wù)器會暫且以無狀態(tài)碼412Precondition Failed作為響應(yīng)返回缎浇，其目的是催促客戶端再次發(fā)送請求扎拣。這樣一來，與使用首部字段If-Range比起來素跺，就需要花費(fèi)兩倍的時間二蓝。

13、If-Unmodified-Since

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

首部字段If-Unmodified-Since和首部字段If-Modified-Since的作用相反指厌。它用來告知服務(wù)器刊愚，指定的請求資源止只有在字段值內(nèi)指定的日期時間之后，未發(fā)生更新的情況下踩验，才能處理請求鸥诽。如果在指定時間日期之后發(fā)生了更新商玫，則以412 Precondition Failed 作為響應(yīng)返回。

14牡借、Max-Forwards

通過TRACE方法或OPTIONS方法拳昌，發(fā)送包含首部字段Max-Forwards的請求時，該字段以十進(jìn)制整數(shù)形式指定可經(jīng)過的服務(wù)器最大數(shù)目钠龙。服務(wù)器在往下一個服務(wù)器轉(zhuǎn)發(fā)請求之前炬藤，Max-Forwards的值-1后重新賦值。當(dāng)服務(wù)器收到的Max-Forwards的值為0的請求時俊鱼，則不再進(jìn)行轉(zhuǎn)發(fā)刻像，而是直接返回響應(yīng)。

Max-Forwards

使用Http協(xié)議通信時并闲，請求可能會經(jīng)過代理等墮胎服務(wù)器细睡。途中，如果代理服務(wù)器由于某些原因?qū)е抡埱筠D(zhuǎn)發(fā)失敗帝火，客戶端也就等不到服務(wù)器的響應(yīng)了溜徙。對此，我們無從可知犀填。

可以靈活使用首部字段Max-Forwards蠢壹，針對以上問題產(chǎn)生的原因展開調(diào)查。由于當(dāng)Max-Forwards字段值為0時九巡，服務(wù)器會立即返回響應(yīng)图贸，由此，我們至少可以對以那臺服務(wù)器為終點(diǎn)的傳輸路徑的通信狀況有所把握冕广。

Max-Forwards

圖：代理服務(wù)器B到源服務(wù)器的請求失敗了疏日，但是客戶端不知道

Max-Forwards

圖：由于未知原因，導(dǎo)致請求陷入代理之間的循環(huán)撒汉，但是客戶端不知道

15沟优、Proxy-Authorization

Proxy-Authorization:Basic dGlwoxxxxxxxxxxxx

接收到從代理服務(wù)器發(fā)來的認(rèn)證質(zhì)詢時，客戶端會發(fā)送包含首部字段的Proxy-Authorization的請求睬辐，以告知服務(wù)器認(rèn)證所需要的信息挠阁。
這個行為是與客戶端和服務(wù)器之間的Http訪問認(rèn)證相類似的，不同之處在于溯饵，認(rèn)證行為發(fā)生在客戶端與代理服務(wù)器之間侵俗。客戶端與服務(wù)器之間的認(rèn)證丰刊，使用首部字段Authorization可起到相同作用坡慌。

16、Range

Range: bytes=5001-10000

對于只需獲取部分資源的范圍請求藻三，包含首部字段Range即可告知服務(wù)器資源的指定范圍洪橘。上面的示例表示請求獲取從5001字節(jié)至10000字節(jié)的資源。

接收到附帶Range首部字段請求的服務(wù)器棵帽，會在處理請求之后返回狀態(tài)碼為206 Partial Content 的響應(yīng)熄求。無法處理該范圍請求時，則會返回狀態(tài)碼200 OK的響應(yīng)以及全部資源逗概。

17弟晚、Referer

Referer

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

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

客戶端一般會發(fā)送Referer首部字段給服務(wù)器逾苫。但當(dāng)直接在瀏覽器地址欄輸入URI卿城，或處于安全性的考慮時，也可以不發(fā)送該首部字段铅搓。

因為原始資源的URI中查詢字符串可能會含有ID和密碼等保密信息瑟押，要是寫進(jìn)Referer轉(zhuǎn)發(fā)給其他服務(wù)器，則可能導(dǎo)致保密信息的泄露星掰。

另外多望，Referer的正確拼寫應(yīng)該是Referrer,但是大家一直沿用這個錯誤的拼寫。

18氢烘、TE

TE: gzip怀偷，deflate;q=0.5

首部字段TE會告知服務(wù)器客戶端能處理的傳輸編碼方式以及優(yōu)先級。他和首部字段Accept-Encoding的功能很像播玖，但是用于傳輸編碼椎工。
首部字段TE除制定傳輸編碼之外，還可以指定伴隨trailer字段的分塊傳輸編碼的方式蜀踏。應(yīng)用后者時维蒙，只需要吧trailers賦值給該字段值。

TE:trailers

19脓斩、User-Agent

User-Agent

圖：User-Agent用于傳達(dá)瀏覽器的種類

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

首部字段User-Agent會創(chuàng)建請求的瀏覽器和用戶代理名稱等信息傳遞給服務(wù)器木西。
由網(wǎng)絡(luò)爬蟲發(fā)起請求時，有可能會在字段內(nèi)添加爬蟲者的電子郵箱地址随静。此外八千，如果請求經(jīng)過代理，那么中安靜也可能背添加代理服務(wù)器的名稱燎猛。

響應(yīng)首部字段

響應(yīng)首部字段是由服務(wù)器端向客戶端返回響應(yīng)報文中使用的字段恋捆，用于補(bǔ)充響應(yīng)的附加信息、服務(wù)器信息重绷，以及對客戶端的附加請求等信息沸停。

1、Accept-Ranges

Accept-Ranges

Accept-Ranges:bytes

首部字段Accept-Ranges 是用來告知客戶端昭卓，服務(wù)器是否能處理范圍請求愤钾，以指定獲取服務(wù)器端某個部分的資源瘟滨。
可指定的字段值有兩種，可處理范圍請求時指定位bytes,反之則指定為none能颁。

2杂瘸、Age

Age

Age:600

首部字段Age能告知客戶端，源服務(wù)器在多久前創(chuàng)建了響應(yīng)伙菊。字段值單位為秒败玉。

若創(chuàng)建該響應(yīng)的服務(wù)器是緩存服務(wù)器，Age值是指緩存后響應(yīng)再次發(fā)起認(rèn)證到認(rèn)證完成的時間值镜硕。代理創(chuàng)建響應(yīng)時必須加上首部字段Age运翼。

3、ETag

ETag

ETag:"82e22293907ce725faf67773957acd12"

首部字段ETag能告知客戶端實(shí)體標(biāo)識兴枯。它是一種可將資源以字符串形式做唯一性標(biāo)識的方式血淌。服務(wù)器會為每一份資源分配對應(yīng)的ETag值。
另外念恍，當(dāng)資源更新時六剥，ETag值也需要更新。生成ETag值時峰伙，并沒有統(tǒng)一的算法規(guī)則疗疟，而僅僅是由服務(wù)器來分配。

ETag

資源被緩存時瞳氓，就會被分配唯一性標(biāo)識策彤。例如，當(dāng)使用中文版瀏覽器訪問時匣摘，就會返回中文版對應(yīng)的資源店诗，而使用英文版的瀏覽器訪問時，則會返回英文版對應(yīng)的資源音榜。兩者的URI相同庞瘸，所以僅憑URI指定緩存的資源是相當(dāng)困難的。若在下載過程中出現(xiàn)中斷赠叼、再連接的情況擦囊，都會依照ETag值來指定資源。

• 強(qiáng)ETag值和弱ETag值
  強(qiáng)ETag值嘴办，不論實(shí)體發(fā)生多么細(xì)微的變化瞬场，都會改變其值。

ETag："usagi-1234"

弱ETag值
弱ETag值只會用于提示資源是否相同涧郊。只有資源發(fā)生了根本變化贯被，產(chǎn)生差異時才會改變ETag值。這時，會在字段值最開始處附加W/.

ETag： W/"usagi-1234"

4彤灶、Location

Location

Location:http://www.xxxx.xx/index.html

使用首部字段Location可以將響應(yīng)接收方經(jīng)導(dǎo)至某個與請求URI位置不同的資源看幼。
基本上，該字段會配合3xx:Redirection的響應(yīng)枢希，提供重定向的URI桌吃。
幾乎所有的瀏覽器在接收到包含首部字段Location的響應(yīng)后，都會強(qiáng)制性地嘗試對已提示的重定向資源的訪問苞轿。

5、Proxy-Authenticate

Proxy-Authenticate: Base realm="Usagidesign Auth"

首部字段Proxy-Authenticate會把代理服務(wù)器所要求的認(rèn)證信息發(fā)送給客戶端逗物。
它與客戶端和服務(wù)器之間的Http訪問認(rèn)證的行為相似搬卒，不同之處在于其認(rèn)證行為是客戶端和代理服務(wù)器之間進(jìn)行的。而客戶端與服務(wù)器之間進(jìn)行認(rèn)證時翎卓，首部字段WWW-Authorization有著相同的作用契邀。

6、Retry-After

Retry-After

Retry-After:120

首部字段Retry-Afer告知客戶端應(yīng)該在多久之后再次發(fā)送請求失暴。主要配合狀態(tài)碼503 Service Unavailable響應(yīng)坯门，或者3xx Redirect響應(yīng)一起使用。
字段值可以指定為具體日期時間(Wed, 04 Jul 2012 06：34：24 GMT 等格式)或者創(chuàng)建響應(yīng)后的秒數(shù)逗扒。

7古戴、Server

server

Server:Apache/2.2.17(Unix)

首部字段Server會告知客戶端當(dāng)前服務(wù)器上安裝的Http服務(wù)器應(yīng)用程序的信息。不單單會標(biāo)出服務(wù)器上的軟件應(yīng)用名稱矩肩，還有可能包含版本號和安裝時啟動的可選項现恼。

Server:Apache/2.2.6(Unix) PHP/5.2.5

8、Vary

Vary

圖：當(dāng)代理服務(wù)器接收到帶有Vary首部字段指定獲取資源的請求時黍檩，如果使用的Accept-Language字段的值相同叉袍，那么就直接從緩存返回響應(yīng)。反之刽酱，則需要先從源服務(wù)器端獲取資源后才能作為響應(yīng)返回喳逛。

Vary：Accept-Language

首部字段Vary可對緩存進(jìn)行控制。源服務(wù)器會向代理服務(wù)器傳達(dá)關(guān)于本地緩存使用方法的命令棵里。

從代理服務(wù)器接收到源服務(wù)器返回包含Vary指定項的響應(yīng)后润文，若再進(jìn)行緩存，僅對請求中含有Vary指定首部字段的請求返回緩存衍慎。即使對相同資源發(fā)起請求转唉，但由于Vary指定的首部字段不相同，因此也必須要從源服務(wù)器上重新獲取資源稳捆。

9赠法、WWW-Authenticate

WWW-Authenticate: Basic realm="Usagidesign Auth"

首部字段WWW-Authenticate 用于Http訪問認(rèn)證。它會告知客戶端適用于訪問請求URI所指定資源的認(rèn)證方案(Basic 或 Digest)和帶參數(shù)提示的質(zhì)詢(challenge)。狀態(tài)碼401Unauthorized響應(yīng)中砖织，肯定帶有首部字段WWW-Authenticate款侵。
上述示例中，realm字段的字符串是為了辨別請求URI指定資源所受到的保護(hù)策略侧纯。

實(shí)體首部字段

實(shí)體首部字段是包含在請求報文和響應(yīng)報文中的實(shí)體部分所使用的首部新锈，用于不中內(nèi)容夫人更新時間等與實(shí)體相關(guān)的信息

實(shí)體首部

圖：在請求和響應(yīng)兩方的http報文中都含有與實(shí)體相關(guān)的首部字段

1、Allow

Allow

Allow:GET,HEAD

首部字段Allow用于通知客戶端能夠支持Request-URI指定資源的所有http方法眶熬。當(dāng)服務(wù)器接收到不支持http方法時妹笆，會以狀態(tài)碼405 Method Not Allowed作為響應(yīng)返回。與此同時娜氏，還會把所有能支持的http方法寫入首部字段Allow返回拳缠。

2、Content-Encoding

Content-Encoding:gzip

首部字段Content-Encoding會告知客戶端 服務(wù)器對實(shí)體的主體部分選用的內(nèi)容編碼方式贸弥。內(nèi)容編碼是指在不丟失實(shí)體信息的前提下所進(jìn)行的壓縮窟坐。

Content-Encoding

主要采用下邊四種內(nèi)容編碼的方式

• gzip
• compres
• deflate
• identity

3、Content-Language

Content-Language:zh-CN

首部字段Content-Language會告知客戶端绵疲，實(shí)體主體使用的自然語言(指中文或者英文等語言)

4哲鸳、Content-Length

Content-Length:15000

首部字段Content-Length表明了實(shí)體主體部分的大小(單位字節(jié))。對實(shí)體主體進(jìn)行內(nèi)容編碼傳輸時盔憨，不能再使用Content-Length首部字段徙菠。

5、Content-Location

Content-Location:http://www.xxx.xx/index.html

首部字段Content-Location 給出與報文主體部分相對應(yīng)的URI般渡。和首部字段Location不同懒豹，Content-Location表示的是報文主體返回資源對應(yīng)的URI。

比如驯用，對于使用首部字段Accept-Language的服務(wù)器驅(qū)動類型請求脸秽，當(dāng)返回的頁面內(nèi)容與實(shí)際請求的對象不同時，首部字段Content-Location內(nèi)會寫明URI蝴乔。(訪問http://www.xx.jp/返回的對象卻是http://www.xx.jp/index.html等類似情況)

6记餐、Content-MD5

Content-MD5

圖：客戶端會對接收的報文執(zhí)行相同的MD5算法，然后與首部字段Content-MD5的字段值比較

Content-MD5:OGFkZDUwNGVhNGY3N2MxMDIwZmQ4NTBmY2IyTY==

首部字段Content-MD5是一串由MD5算法生成的值,其目的在于檢查報文主體在傳輸過程中是否保持完整薇正，以及確認(rèn)傳輸?shù)竭_(dá)片酝。

對報文主體執(zhí)行MD5算法獲得的128位二進(jìn)制數(shù)，再通過Base64編碼后將結(jié)果寫入Content-MD5字段值挖腰。由于Http首部無法記錄二進(jìn)制值雕沿，所以要通過Base64編碼處理。為確保報文的有效性猴仑，作為接收方的客戶端會對報文主體再執(zhí)行一次相同的MD5算法审轮。計算出的值與字段值比較后，即可判斷出報文主體的準(zhǔn)確性。

采用這種方法疾渣，對內(nèi)容上的偶發(fā)性改變時無從查證的篡诽，也無法檢測出惡意篡改，那么同時意味著Content-MD5也可重新計算然后被篡改榴捡。所以處于接收階段的客戶端是無法意識到報文主體以及首部字段Content-MD5是已經(jīng)被篡改過的杈女。

7、Content-Range

Content-Range

Content-Range:bytes 5001-10000/10000

針對范圍請請求吊圾，返回響應(yīng)時使用的首部字段Content-Range,能告知客戶端作為響應(yīng)返回的實(shí)體的哪個部分符合范圍請求达椰。字段值以字節(jié)為單位，單表當(dāng)前發(fā)送部分以及整體實(shí)體大小项乒。

8砰碴、Content-Type

Content-Type:text/html;charset:UTF-8

首部字段Content-Type說明了實(shí)體主體內(nèi)對象的媒體類型。和首部字段Accept一樣板丽，字段值用type/subtype形式賦值。

9趁尼、Expires

Expires

Expires:Wed, 04 Jul 2012 08:26:05 GMT

首部字段Expires會將資源失效的日期告知客戶端埃碱。緩存服務(wù)器在接收到含有首部字段Expires的響應(yīng)后，會以緩存來應(yīng)答請求酥泞，在Expires字段指定的時間之前砚殿，緩存的副本會一直被保存。當(dāng)超過指定的時間之后芝囤，緩存服務(wù)器在請求發(fā)送過來時似炎，會轉(zhuǎn)向源服務(wù)器請求資源。

源服務(wù)器不希望緩存服務(wù)器對資源緩存時悯姊，最好在Expires字段內(nèi)寫入與首部字段Date相同的時間值羡藐。

但是，當(dāng)首部字段Cache-Control有指定max-age指令時悯许，比起首部字段Expires仆嗦，會優(yōu)先處理max-age指令。

10先壕、Last-Modified

Last-Modified

Last-Modified: Wed, 23 May 2012 09:59:55 GMT

首部字段Last-Modified指明資源最終修改的時間瘩扼。一般來說，這個值就是Request-URI指定資源被修改的時間垃僚。但類似使用CGI腳本進(jìn)行動態(tài)數(shù)據(jù)處理時集绰，該值有可能會變成數(shù)據(jù)最終修改時的時間。

為Cookie服務(wù)的首部字段

管理服務(wù)器與客戶端之間狀態(tài)的Cookie谆棺，雖然沒有被編入標(biāo)準(zhǔn)化Http/1.1的RFC2616中栽燕，但在Web網(wǎng)站方面得到了廣泛的應(yīng)用。

Cookie的工作機(jī)制是用戶識別及狀態(tài)管理。Web網(wǎng)站為了管理用戶的狀態(tài)會通過Web瀏覽器纫谅，把一些數(shù)據(jù)臨時寫入用戶的計算機(jī)內(nèi)炫贤。接著但用戶訪問該Web網(wǎng)站時，可通過通信方式取回之前發(fā)放的Cookie付秕。

調(diào)用Cookie時兰珍，由于可校驗Cookie的有效期，以及發(fā)送方的域询吴、路徑掠河、協(xié)議等信息，所以正規(guī)發(fā)布的Cookie內(nèi)的數(shù)據(jù)不會因來自其他Web站點(diǎn)和攻擊者的攻擊而泄露猛计。

至2013年5月唠摹，Cookie的規(guī)范標(biāo)準(zhǔn)文檔有以下4種，

• 由網(wǎng)景公司頒布的規(guī)格標(biāo)準(zhǔn)
  網(wǎng)景通信公司設(shè)計并發(fā)布了Cookie,并指定相關(guān)的規(guī)格標(biāo)準(zhǔn)奉瘤。1994年前后勾拉，Cookie真是應(yīng)用在網(wǎng)景瀏覽器中。目前最為普及的Cookie方式也是以此為基準(zhǔn)的盗温。
• RFE2109
  某企業(yè)嘗試以獨(dú)立技術(shù)對Cookie規(guī)格進(jìn)行標(biāo)準(zhǔn)化統(tǒng)籌藕赞。原本的意圖是想和網(wǎng)景公司制定的標(biāo)準(zhǔn)交互應(yīng)用，可惜發(fā)生了微妙的差異÷艟郑現(xiàn)在該標(biāo)準(zhǔn)已經(jīng)淡出了人們的視線斧蜕。
• RFC2965
  為終結(jié)Internet Explorer瀏覽器與Netscape Navigator的標(biāo)準(zhǔn)化差異而導(dǎo)致的瀏覽器戰(zhàn)爭，RFC2965內(nèi)定義了新的HTTP首部SetCookie2和Cookie2砚偶。事實(shí)上批销，他們幾乎沒怎么投入使用。
• RFC6265
  將網(wǎng)景公司指定的標(biāo)準(zhǔn)作為業(yè)界事實(shí)標(biāo)準(zhǔn)(De facto standard)染坯，重新定義Cookie標(biāo)準(zhǔn)后的產(chǎn)物均芽。

目前使用最為廣泛的Cookie標(biāo)準(zhǔn)卻不是RFC中定義的任何一個。而是在網(wǎng)景公司制定的標(biāo)準(zhǔn)上進(jìn)行擴(kuò)張后的產(chǎn)物酒请。

這里說明一下最為廣泛普及的標(biāo)準(zhǔn)骡技。

• 為Cookie服務(wù)的首部字段
  | 首部字段名 | 說明 | 首部類型 |
  | ---------- | ------------------------------ | ------------ |
  | Set-Cookie | 開始狀態(tài)管理所使用的Cookie信息 | 響應(yīng)首部字段 |
  | Cookie | 服務(wù)器接收到的Cookie信息 | 請求首部字段 |

1、SetCookie

Set-Cookie: status=enable; expires=Tue, 05 Jul 2011 07:26:31 GMT; 

當(dāng)服務(wù)器準(zhǔn)備開始管理客戶端的狀態(tài)時羞反，會實(shí)現(xiàn)告知各種信息布朦。
下邊列舉SetCookie的字段值

• expires 屬性
  Cookie的expires屬性指定瀏覽器可發(fā)送Cookie的有效期昼窗。
  當(dāng)省略expires屬性時是趴，其有效期僅限于維持瀏覽器會話(session)時間段內(nèi)。這通常限于瀏覽器應(yīng)用程序被關(guān)閉之前澄惊。

另外唆途，一單Cookie從服務(wù)器發(fā)送至客戶端富雅，服務(wù)器端就不存在可以顯式刪除Cookie的方法。但是可以通過覆蓋已過期的Cookie肛搬，實(shí)現(xiàn)對客戶端Cookie的實(shí)質(zhì)性刪除操作没佑。

• path屬性
  Cookie的path屬性可用于限制指定Cookie的發(fā)送范圍的文件目錄。不過另有辦法可避免這項限制温赔，看來對其作為安全機(jī)制的效果不能抱有期待蛤奢。
• domain屬性
  通過Cookie的domain屬性指定的域名可以做到與結(jié)尾匹配一致。比如陶贼，當(dāng)指定example.com后啤贩，除example.com外，wwww.example.com或者wwww2.example.com等都可以發(fā)送Cookie.

因此拜秧，除了針對具體指定的多個域名Cookie之外痹屹，不指定domain屬性顯得更安全。

• secure屬性
  Cookie的secure屬性用于限制Web頁面僅在Https安全連接時枉氮，才可以發(fā)送Cookie志衍。
  發(fā)送Cookie時，指定secure屬性的方法如下所示聊替。

Set-Cookie:name=value;secure

以上例子僅當(dāng)在https://www.xxx.com/（HTTPS）安全連接的情況下才會進(jìn)行Cookie的回收足画。也就是說，即使域名相同，http://www.xxx.com/（HTTP）也不會發(fā)生Cookie回收行為盗似。

當(dāng)省略secure屬性時牡彻，不論是HTTP,還是HTTPS,都會對Cookie進(jìn)行回收。

• HttpOnly屬性
  Cookie的HttpOnly屬性是Cookie的擴(kuò)展功能羡亩，它使用JavaScript腳本無法獲得Cookie。其主要目的為反之跨站腳本攻擊（Cross-sitescripting,XSS）對Cookie的信息竊取。
  發(fā)送指定HttpOnly屬性的Cookie的方法如下所示爷速。

Set-Cookie:name=value;HttpOnly

通過上述設(shè)置，通過從Web頁面內(nèi)還可以對Cookie進(jìn)行讀取操作霞怀。但是用JavaScript的document.cookie就無法讀取附加HttpOnly屬性后的Cookie的內(nèi)容了惫东。因此，也就無法在XSS中利用JavaScript劫持Cookie了毙石。

雖然是獨(dú)立的擴(kuò)展功能廉沮，但I(xiàn)nternet Explorer6 SP1以上版本等當(dāng)下的主流瀏覽器都已經(jīng)支持?jǐn)U展了。另外徐矩，該擴(kuò)張并非是位了反之XSS而開發(fā)的滞时。

Cookie

Cookie:status=enable

首部字段Cookie會告知服務(wù)器，但客戶端想獲得Http狀態(tài)管理支持時滤灯，就會在請求中包含從服務(wù)器接收到的Cookie坪稽。接收到多克Cookie時曼玩，同樣可以以多個Cookie形式發(fā)送。

其他首部字段

Http首部字段是可以自行擴(kuò)展的窒百。所以在Web服務(wù)器和瀏覽器的應(yīng)用上黍判，會出現(xiàn)各種非標(biāo)準(zhǔn)的首部字段。如下所示篙梢。

• X-Frame-Options
• X-XSS-Protection
• DNT
• P3P

1顷帖、X-Frame-Options

X-Frame-Options:DENY

首部字段X-Frame-Options屬于Http響應(yīng)首部，用于控制網(wǎng)站內(nèi)容在其他Web網(wǎng)站的Frame標(biāo)簽內(nèi)的顯示問題庭猩。其主要目的是位了反之點(diǎn)擊劫持(clickjacking)攻擊窟她。
首部字段X-Frame-Options有以下兩個可指定的字段值。

• DENY:拒絕
• SAMEORIGIN:僅在同源域名下的頁面匹配時許可蔼水。（比如震糖，當(dāng)指定http://www.xxx.jp/sample.html頁面為SAMEORIGIN時，那么趴腋，xxx.jp上所有的頁面的frame都被允許可加載該頁面吊说，而example.com等其他域名的頁面就不行了）

2、X-XSS-Protection

X-XSS-Protection:1

首部字段X-XSS-Protection屬于Http響應(yīng)首部优炬，它是針對跨站腳本攻擊（XSS）的一種對策颁井，用于控制瀏覽器XSS防護(hù)機(jī)制的開關(guān)。

首部字段X-XSS-Protection可指定的字段值如下蠢护。

• 0：將XSS過濾設(shè)置成無效狀態(tài)
• 1：將XSS過濾設(shè)置成有效狀態(tài)

3雅宾、DNT

DNT:1

首部字段DNT屬于Http請求首部，其中DNT是 Do Not Track 的簡稱葵硕，意為拒絕個人信息被收集眉抬，是表示拒絕被精準(zhǔn)廣告追蹤的一種方法。
首部字段DNT可指定的字段值如下懈凹。

• 0：同意被追蹤
• 1：拒絕被追蹤
  由于首部字段 DNT的功能具備有效性蜀变，所以Web服務(wù)器需要對DNT做對應(yīng)的支持。

4介评、P3P

P3P: CP="CAO DSP LAW CURa ADMa DEVa TAIa PSAa PSDa IVAa IVDa OUR BUS 

首部字段 P3P 屬于 HTTP 相應(yīng)首部库北，通過利用 P3P（The Platform for Privacy Preferences，在線隱私偏好平臺）技術(shù)们陆，可以讓 Web 網(wǎng)站上 的個人隱私變成一種僅供程序可理解的形式寒瓦，以達(dá)到保護(hù)用戶隱私的 目的。
要進(jìn)行 P3P 的設(shè)定坪仇，需按以下操作步驟進(jìn)行孵构。
步驟 1：創(chuàng)建 P3P 隱私
步驟 2：創(chuàng)建 P3P 隱私對照文件后，保存命名在 /w3c/p3p.xml
步驟 3：從 P3P 隱私中新建 Compact policies 后烟很，輸出到 HTTP 響應(yīng) 中

下一篇 讀書筆記_圖解HTTP(四) HTTPS