HTTP中的缓存
HTTP典型應(yīng)用于能通過采用緩存技術(shù)而提高性能的分布式信息系統(tǒng)。HTTP/1.1協(xié)議包括的許多使緩存盡可能的工作的元素。因?yàn)檫@些元素與協(xié)議的其他方面有著千絲萬(wàn)縷的聯(lián)系，而且他們相互作用、影響，因此有必要單獨(dú)的來介紹基本的緩存設(shè)計(jì)。
如果緩存不能改善性能，他將一無(wú)用處。HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請(qǐng)求，同時(shí)在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路（譯注：一個(gè)請(qǐng)求會(huì)返回一個(gè)響應(yīng)，請(qǐng)求響應(yīng)這個(gè)過程就是一個(gè)回路）的數(shù)量；我們利用一個(gè)“過期（expiration）”機(jī)制來為此目的（見13.2節(jié)）。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬；我們用“驗(yàn)證（validation）”機(jī)制來為此目的。
對(duì)行為，可行性，和關(guān)閉的操作的要求放松了語(yǔ)義透明性的目的。HTTP/1.1協(xié)議允許服務(wù)器，緩存，和客戶端能顯示地降低透明性當(dāng)在必要的時(shí)候。然而，因?yàn)椴煌该鞯牟僮髂芑煜菍I(yè)的用戶，同時(shí)可能和某個(gè)服務(wù)器應(yīng)用程序不兼容（例如訂購(gòu)商品），因此此協(xié)議透明性在下面情況下才能被放松要求：
-- 只有在一個(gè)顯示的協(xié)議層的請(qǐng)求時(shí)，透明性才能被客戶端或源服務(wù)器放松
-- 當(dāng)出現(xiàn)一個(gè)對(duì)終端用戶的顯示的警告時(shí)，透明性才能被緩存或被客戶端放松
因此，HTTP/1.1協(xié)議提供這些重要的元素：
1．提供完整語(yǔ)義透明的協(xié)議特征，當(dāng)這些特征被通信的所有方需要時(shí)
2. 允許源服務(wù)器或用戶代理顯示的請(qǐng)求和控制不透明操作的協(xié)議特征
3. 允許緩存給這樣的響應(yīng)綁定警告信息的協(xié)議特征，這些響應(yīng)不能保留請(qǐng)求的語(yǔ)義透明的近似
一個(gè)基本的原則是客戶端必須能夠發(fā)現(xiàn)語(yǔ)義透明性的潛在的放松。
注意：服務(wù)器，緩存，或者客戶端的實(shí)現(xiàn)者可能會(huì)面對(duì)設(shè)計(jì)上的判斷，而這些判斷沒有顯示地在此規(guī)范里討論。如果一個(gè)判斷可能會(huì)影響語(yǔ)義透明性，那么實(shí)現(xiàn)者應(yīng)該能維持語(yǔ)義透明性，除非一個(gè)仔細(xì)的完整的分析能說明打破透明性的好處。
13.1.1緩存正確性（Cache Correctness）
一個(gè)正確的緩存必須能用最新的響應(yīng)來響應(yīng)請(qǐng)求，此響應(yīng)當(dāng)在下面的條件滿足時(shí)才適合此請(qǐng)求（見13.2.5，13.2.6，和13.12）?
此緩存響應(yīng)已被檢測(cè)與假設(shè)通過源服務(wù)器重驗(yàn)證后源服務(wù)器返回的響應(yīng)相等價(jià)。
此緩存響應(yīng)是足夠保鮮(fresh)的（見13.2節(jié)）。缺省的情況下，這意味著此響應(yīng)必須滿足客戶端，源服務(wù)器，和緩存的最嚴(yán)格的保鮮要求（見14.9節(jié)）；如果源服務(wù)器指定了保鮮壽命，這說明它是源服務(wù)器自己的保鮮要求。
由于客戶端和源服務(wù)器的最嚴(yán)格的保鮮要求，如果一個(gè)緩存的響應(yīng)不是足夠保鮮的，那么在仔細(xì)考慮的情況下，緩存可能仍然返回此緩存的響應(yīng)通過合適的Warning頭域（見13.1.5和14.46節(jié)），除非此響應(yīng)被阻止（例如：通過”no-store” cache-directive ，或者通過一個(gè)”no-cache”cache-request-directive；見14.9節(jié)）。
此緩存響應(yīng)是一個(gè)304（沒有被改變），305（代理重定向），或 錯(cuò)誤（4xx或者5xx）響應(yīng)消息。
如果緩存不能同源服務(wù)器通信，那么一個(gè)正確的緩存應(yīng)該用它緩存的響應(yīng)去響應(yīng)請(qǐng)求，如果此緩存的響應(yīng)能正確的服務(wù)于請(qǐng)求；如果不能服務(wù)器于此請(qǐng)求，那么緩存必須能返回一個(gè)錯(cuò)誤或警告指示存在通信失敗。
如果緩存從服務(wù)器端接收到一個(gè)響應(yīng)（或者是一個(gè)完整的響應(yīng)，或者一個(gè)304（沒有被改變）的響應(yīng)），此響應(yīng)應(yīng)該是正常情況下要發(fā)送到請(qǐng)求的客戶端的，并且此響應(yīng)并不是新鮮的，那么此緩存應(yīng)該把此響應(yīng)轉(zhuǎn)發(fā)給請(qǐng)求客戶端不需要添加一個(gè)新的Warning頭域（但是沒有移去已經(jīng)存在的Warning頭域）。緩存并不是簡(jiǎn)單的因?yàn)閭鬏斨许憫?yīng)變得陳舊而嘗試去重驗(yàn)證響應(yīng)；這可能會(huì)導(dǎo)致一個(gè)無(wú)限的循環(huán)。用戶代理接收一個(gè)陳舊的沒有Warning頭域的響應(yīng)應(yīng)該提示用戶一個(gè)警告信息。
13.1.2警告信息（Warnings）
無(wú)論何時(shí)，緩存返回一個(gè)響應(yīng)，此響應(yīng)既不是第一手的(first-hand)也不是足夠保鮮（在13.1.1節(jié)的條件2），那么緩存必須利用一個(gè)Warning常用頭域來警告產(chǎn)生的效果。Warning頭域和當(dāng)前定義的警告在14.46節(jié)里描述。這些警告允許客戶端去采取合適的動(dòng)作。
警告可能被用于其他的目的，和緩存相關(guān)的目的和其他的目的。警告和錯(cuò)誤狀態(tài)碼的區(qū)別在于是否是真正的失敗。
警告被賦予三位數(shù)字warn-codes。第一個(gè)數(shù)字指明：警告是否必須或不必須從緩存項(xiàng)里刪除，在一個(gè)成功的重驗(yàn)證之后。
1xx 警告描述了響應(yīng)的保鮮或重驗(yàn)證狀態(tài)信息，并且這些信息應(yīng)該在一個(gè)成功的重驗(yàn)證之后刪除。1xx警告碼可能是由緩存產(chǎn)生的，當(dāng)緩存驗(yàn)證一個(gè)緩存項(xiàng)時(shí)。此警告碼不能被客戶端產(chǎn)生。
2xx 警告描述了實(shí)體主體或?qū)嶓w頭域的某些方面的信息，這些信息不能被重驗(yàn)證修改，并且這些信息不能在一個(gè)成功重驗(yàn)證之后被刪除。
見14.46節(jié)關(guān)于警告碼的定義。
HTTP/1.0緩存將緩存所有響應(yīng)中的警告，并且不會(huì)刪除第一類警告。穿過HTTP/1.0緩存響應(yīng)中的警告會(huì)攜帶一個(gè)額外的warning-date域，這是為了防止將來的HTTP/1.1接收端信任一個(gè)錯(cuò)誤的緩存警告。
警告同樣攜帶一個(gè)警告文本。此文本可能是任何合適的自然語(yǔ)義（可能基于客戶端請(qǐng)求的Accept頭域），同時(shí)包含一個(gè)可選擇的關(guān)于何種字符集被使用的聲明。
多個(gè)警告可能會(huì)綁定一個(gè)響應(yīng)（或者被源服務(wù)器或者被一個(gè)緩存發(fā)送的），這包括多個(gè)警告可以共用一個(gè)警告碼。例如，服務(wù)器可能會(huì)以英語(yǔ)和法語(yǔ)提供相同的警告。
當(dāng)多個(gè)警告綁定一個(gè)響應(yīng)時(shí)，有時(shí)候不可能把所有的警告都展示給客戶。HTTP版本不能指定一個(gè)嚴(yán)格的優(yōu)先值去決定警告的優(yōu)先和順序顯示，但是可以探索一些方法。
13.1.3緩存控制機(jī)制 （Cache-control Mechanism）
HTTP/1.1基本的緩存機(jī)制（服務(wù)器指定過期時(shí)間和驗(yàn)證器）對(duì)緩存是隱含的指令。某些情況下，服務(wù)器或客戶端可能需要給HTTP緩存提供顯示的指令。我們利用Cache-Control頭域?yàn)榇四康摹?/span>
Cache-Control頭域允許客戶端或服務(wù)器在請(qǐng)求或響應(yīng)里傳輸多個(gè)指令。這些指令常常覆蓋缺省的緩存算法。作為一個(gè)常用規(guī)則，如果頭域值中存在一個(gè)明顯的沖突，那么最具嚴(yán)格解釋的頭域值會(huì)被應(yīng)用（也就是說，能保留語(yǔ)義透明性的值）。然而，一些情況下，cache-control指令被顯示地指定用來削弱語(yǔ)義透明性的相似性（例如，”max-stale” 或者 “public”）。
Cache-control指令在14.9節(jié)被描述。
13.1.4顯示的用戶代理警告（Explicit User Agent Warnings）
很多用戶代理允許用戶覆蓋基本緩存機(jī)制。例如，用戶代理可能允許用戶指定緩存實(shí)體（即使實(shí)體明顯是陳舊的）從來不要被驗(yàn)證。或者，用戶代理可能習(xí)慣于給任何請(qǐng)求加上“Cache-Control：max-stale=3600”。用戶代理不能缺省的執(zhí)行不透明行為，或者不能缺省的執(zhí)行導(dǎo)致非正常的無(wú)效率的緩存行為，但是可能被顯示地設(shè)置去這樣做通過一個(gè)顯示的用戶動(dòng)作。
如果用戶已經(jīng)覆蓋基本的緩存機(jī)制，那么用戶代理應(yīng)該給用戶指示何時(shí)顯示不能滿足服務(wù)器透明要求的信息（特別地，如果顯示的實(shí)體被認(rèn)為是陳舊的）。因?yàn)榇藚f(xié)議通常允許用戶代理去判定響應(yīng)是否是陳舊或不是陳舊的，所以此指示只需要當(dāng)實(shí)際發(fā)生時(shí)顯示。此指示不必是對(duì)話框；它應(yīng)該是一個(gè)圖標(biāo)（例如，一個(gè)正在腐爛的魚）或者一些其他的指示器。
如果用戶以一種方式已經(jīng)覆蓋了緩存機(jī)制，這種方式可能不正常地減少緩存效率，那么用戶代理應(yīng)該繼續(xù)指示用戶的狀態(tài)（例如，通過一個(gè)圖片顯示）以便用戶不能不注意地消費(fèi)過度的資源或者忍受過度的延遲。
13.1.5規(guī)則和警告的例外情況
在某些情況下，緩存的操作者應(yīng)該設(shè)置緩存返回陳舊的響應(yīng)，即使此響應(yīng)沒有被客戶端請(qǐng)求。這個(gè)判定本來不應(yīng)該輕易決定，但是由于某些原因可能會(huì)這樣做，特別是當(dāng)緩存和源服務(wù)器連接不好時(shí)。無(wú)能何時(shí)當(dāng)緩存會(huì)返回一個(gè)陳舊的響應(yīng)時(shí)，緩存必須給此響應(yīng)做個(gè)標(biāo)記（利用Warning頭域），因?yàn)檫@樣能使客戶端提示用戶響應(yīng)是陳舊的。
用戶代理照樣能采取步驟去獲得第一手的或保鮮的響應(yīng)。由于這個(gè)原因，如果客戶端顯示地請(qǐng)求第一手的或保鮮的響應(yīng)，緩存就不能返回一個(gè)陳舊的響應(yīng)，除非由于技術(shù)或策略方面的原因。
13.1.6由客戶控制的行為（Client-controlled Behavior）
當(dāng)源服務(wù)器是過期信息得主要來源時(shí)，有時(shí)候客戶端可能需要控制緩存去判定是否返回一個(gè)緩存響應(yīng)而不需要緩存通過服務(wù)器驗(yàn)證它。客戶端通過利用一些Cache-Control頭域來達(dá)到此目的。
客戶端的請(qǐng)求可能會(huì)指定自己愿意接受一個(gè)沒有驗(yàn)證的響應(yīng)的最大的年齡（age）；指定0值會(huì)強(qiáng)迫緩存重驗(yàn)證所有的響應(yīng)。客戶端照樣會(huì)指定在響應(yīng)過期前的最小保持時(shí)間。這些選項(xiàng)增加了對(duì)緩存行為的限制，同時(shí)這樣做并不能進(jìn)一步地放松緩存語(yǔ)義透明的近似。
客戶端可能照樣會(huì)指定它會(huì)接受陳舊響應(yīng)直到陳舊數(shù)達(dá)到最大數(shù)量。這放松了對(duì)緩存的限制，同時(shí)這可能違反了源服務(wù)器指定對(duì)語(yǔ)義透明性的限制，但是這可能支持無(wú)連接的操作或者高獲得性當(dāng)連接不好時(shí)。
13.2 過期模型 （Expiration Model）
13.2.1 服務(wù)器指定模型（Server-Specified Expiratiion）?
HTTP緩存會(huì)工作的很好，這是因?yàn)榫彺婺芡耆乇苊饪蛻舳藢?duì)源服務(wù)器的請(qǐng)求。避免對(duì)源服務(wù)器請(qǐng)求的主要機(jī)制是服務(wù)器將來會(huì)提供一個(gè)顯示過期時(shí)間（explicit expiration time），此顯示過期時(shí)間用來指示響應(yīng)可能會(huì)滿足后續(xù)的請(qǐng)求。也就是說，客戶端請(qǐng)求響應(yīng)時(shí)，緩存能返回一個(gè)保鮮（fresh）的響應(yīng)而不需要從源服務(wù)器那里獲得。
我們希望服務(wù)器給響應(yīng)設(shè)置顯示過期時(shí)間（explicit expiration time），服務(wù)器相信在過期時(shí)間之前實(shí)體不會(huì)改變。這能保持語(yǔ)義透明性（譯注：語(yǔ)義透明性情況1.3節(jié)里關(guān)于“語(yǔ)義透明”的解釋），只要服務(wù)器對(duì)過期時(shí)間仔細(xì)選擇。
過期機(jī)制只能應(yīng)用于能從緩存獲得的響應(yīng)，不能應(yīng)用于客戶端請(qǐng)求的第一手（first-hand，見1.3節(jié)術(shù)語(yǔ)）的響應(yīng)。
如果源服務(wù)器希望強(qiáng)制一個(gè)語(yǔ)義透明緩存去驗(yàn)證每個(gè)請(qǐng)求，它會(huì)使顯示過期時(shí)間（explicit expiration time）設(shè)為過去。這就是說響應(yīng)總是陳舊的，所以此緩存應(yīng)該驗(yàn)證此響應(yīng)當(dāng)緩存利用此響應(yīng)去服務(wù)于后續(xù)的請(qǐng)求時(shí)。見14.9.4節(jié)，有更多強(qiáng)迫重驗(yàn)證的方法
如果源服務(wù)器希望強(qiáng)迫任何HTTP/1.1緩存（不管此緩存是怎樣設(shè)置的）去驗(yàn)證每一個(gè)請(qǐng)求，源服務(wù)器應(yīng)該在Cache-Control頭域里指定“must-revalidate”緩存控制指令（見14.9節(jié)）。
源服務(wù)器利用Expires頭域或在Cache-Control頭域里通過max-age緩存控制指令，來指定顯示過期時(shí)間（explicit expiration time）。
過期時(shí)間不能被用于強(qiáng)制客戶代理去重新刷新它的顯示或重載資源；過期的語(yǔ)義只能應(yīng)用于緩存機(jī)制，并且這個(gè)機(jī)制值只需要檢測(cè)資源的過期狀態(tài)當(dāng)請(qǐng)求那個(gè)資源的一個(gè)新請(qǐng)求發(fā)生時(shí)。見13.13節(jié)，關(guān)于緩存和歷史機(jī)制的區(qū)別。
13.2.2 啟發(fā)式過期
因?yàn)樵捶?wù)器不能總是提供一個(gè)顯示過期時(shí)間（explicit expiration time），HTTP緩存通常會(huì)設(shè)置一個(gè)啟發(fā)式過期時(shí)間（heuristic expiration time），它采用一種算法，此算法利用其它的值（例如Last-Modified時(shí)間）去估計(jì)一個(gè)似乎合理的過期時(shí)間。HTTP/1.1規(guī)范沒有提供特定的算法，但是的確是加強(qiáng)了對(duì)這些算法結(jié)果的最壞情況的限制。因?yàn)閱l(fā)式過期時(shí)間可能會(huì)對(duì)語(yǔ)義透明性妥協(xié)，他們本應(yīng)該被謹(jǐn)慎地使用，并且我們鼓勵(lì)源服務(wù)器盡可能提供顯示過期時(shí)間。
13.2.3 年齡（Age）計(jì)算
為了了解緩存項(xiàng)（譯注：緩存項(xiàng)是用來響應(yīng)請(qǐng)求的，它包含緩存的響應(yīng)實(shí)體）是否是保鮮的（fresh），緩存需要知道其年齡是否已超過保鮮壽命（freshness lifetime）。我們?cè)?3.2.4節(jié)中討論如何計(jì)算保鮮壽命，本節(jié)討論如何計(jì)算響應(yīng)或緩存項(xiàng)的年齡。
在此討論中我們用“now”來表示主機(jī)進(jìn)行計(jì)算時(shí)時(shí)鐘的“當(dāng)前值”。使用HTTP協(xié)議的主機(jī)，特別是運(yùn)行于源服務(wù)器和緩存的主機(jī)，應(yīng)該使用NTP[28] 或其他類似協(xié)議來將其時(shí)鐘同步到一個(gè)全球性的精確時(shí)間標(biāo)準(zhǔn)上。
HTTP1.1協(xié)議要求源服務(wù)器盡可能在發(fā)送每條響應(yīng)時(shí)都附加一個(gè)Date頭域，要盡可能在每個(gè)響應(yīng)里給出響應(yīng)產(chǎn)生的時(shí)間（見14.18節(jié)）。我們利用術(shù)語(yǔ)“date_value”去表示Date頭域的值，這是一種適合于運(yùn)算操作的表示方法。
當(dāng)從緩存里獲取響應(yīng)消息時(shí)，HTTP/1.1利用Age響應(yīng)頭域來傳送響應(yīng)消息的估計(jì)年齡。Age響應(yīng)頭域值是緩存對(duì)響應(yīng)從產(chǎn)生或被重驗(yàn)證開始到現(xiàn)在的時(shí)間估計(jì)值。
實(shí)際上，年齡的值是響應(yīng)從源服務(wù)器途徑每一個(gè)緩存的逗留時(shí)間的總和，再加上響應(yīng)在網(wǎng)絡(luò)路徑上傳輸?shù)臅r(shí)間。
我們用“age_value”來表示Age頭域的值，這是一種適于算術(shù)操作的表示方法。
一個(gè)響應(yīng)的年齡(age)可以通過兩種完全不同的途徑來計(jì)算:：
如果本地時(shí)鐘與源服務(wù)器時(shí)鐘同步的相當(dāng)好，則用 now - date_value ，若結(jié)果為負(fù)，則取零。
如果途徑響應(yīng)路徑（response path）的所有緩存均遵循HTTP1.1協(xié)議，則用age_value。
如果我們有兩種獨(dú)立的方法計(jì)算響應(yīng)的年齡（譯注：注意這里是響應(yīng)的年齡），我們可以合并二者如下：
corrected_received_age = max（now – date_value，age_value）?
并且只要我們或者有同步的時(shí)鐘或者響應(yīng)途徑的所有緩存遵循HTTP/1.1，我們就能得到一個(gè)可信賴的結(jié)果。
由于網(wǎng)絡(luò)附加延時(shí)，一些重要時(shí)隙會(huì)在服務(wù)器產(chǎn)生響應(yīng)與下一個(gè)緩存或客戶端接收之間流逝。如果不經(jīng)修訂，這一延遲會(huì)帶來不正常的低年齡。
由于導(dǎo)致產(chǎn)生年齡值的請(qǐng)求（譯注：就是存在Age頭域的請(qǐng)求）是早于年齡值的產(chǎn)生，我們能校正網(wǎng)絡(luò)附加延遲通過記錄請(qǐng)求產(chǎn)生的時(shí)間。然后，當(dāng)一個(gè)年齡值被接收后，它必須被解釋成相對(duì)于請(qǐng)求產(chǎn)生的時(shí)間，而不是相對(duì)響應(yīng)接收的時(shí)間。不管有多少延遲，此算法會(huì)導(dǎo)致穩(wěn)定的結(jié)果。所以，我們計(jì)算：?
corrected_initial_age = corrected_received_age + （now - request_time）
這里“request_time”是請(qǐng)求的發(fā)送時(shí)間。
緩存收到響應(yīng)時(shí)，它計(jì)算響應(yīng)年齡的算法如下：
/*?
* age_value?
* is the value of Age: header received by the cache with this response.?
* date_value?
* is the value of the origin server's Date: header?
* request_time?
* is the （local） time when the cache made the request?
* that resulted in this cached response?
* response_time?
* is the （local） time when the cache received the response?
* now?
* is the current （local） time?
*/?
apparent_age = max（0, response_time - date_value）; //緩存收到響應(yīng)時(shí)響應(yīng)的年齡
corrected_received_age = max（apparent_age, age_value）;
response_delay = response_time - request_time;?
corrected_initial_age = corrected_received_age + response_delay;?
resident_time = now - response_time; //即收到響應(yīng)到現(xiàn)在的時(shí)間間隔
current_age = corrected_initial_age + resident_time;?
緩存項(xiàng)（cache entry）的current_age是緩存項(xiàng)從被源服務(wù)器最后驗(yàn)證開始到現(xiàn)在的時(shí)間間隔（以秒記）加上corrected_initial_age。當(dāng)從緩存項(xiàng)里產(chǎn)生一條響應(yīng)時(shí)，緩存必須在響應(yīng)里包含一個(gè)Age頭域，它的值應(yīng)該等于緩存項(xiàng)的current_age值。
Age頭域出現(xiàn)在響應(yīng)里說明響應(yīng)不是第一手的（first-hand）（譯注：第一手的說明，響應(yīng)是直接來自于源服務(wù)器到達(dá)接收端的，而不是來自于緩存里保存的副本）。然而相反的情況并不成立，因?yàn)轫憫?yīng)里缺少Age頭域并不能說明響應(yīng)是第一手的(fisrt-hand)，除非所有請(qǐng)求路徑上的緩存都遵循HTTP/1.1協(xié)議（也就是說，以前HTTP版本緩存沒有定義Age頭域）。?
13.2.4 過期計(jì)算（Expiration Calculations）
為了確定一條響應(yīng)是保鮮的（fresh）還是陳舊的（stale），我們需要將其保鮮壽命（freshness lifetime)和年齡(age)進(jìn)行比較。年齡的計(jì)算見13.2.3節(jié)，本節(jié)講解怎樣計(jì)算保鮮壽命，以及判定一個(gè)響應(yīng)是否已經(jīng)過期。在下面的討論中，數(shù)值可以用任何適于算術(shù)操作的形式表示。?
我們用術(shù)語(yǔ)“expires_value”來表明Expires頭域的值。我們用術(shù)語(yǔ)“max_age_value”來表示Cache-Control頭域里“max-age”控制指令的值（見14.9.3節(jié)）。
max-age指令優(yōu)于Expires頭域執(zhí)行，所以如果max-age出現(xiàn)在響應(yīng)里，那么定義如下：
freshness_lifetime = max_age_value?
否則，若Expires頭域出現(xiàn)在響應(yīng)里，定義如下：
freshness_lifetime = expires_value - date_value?
注意上述運(yùn)算不受時(shí)鐘誤差影響，因?yàn)樗行畔⒕鶃碜栽捶?wù)器。?
如果Expires， Cache-Control：max-age, 或 Cache-Control：s-maxage （見 14.9.3） 均未在響應(yīng)中出現(xiàn)，且響應(yīng)沒有包含對(duì)緩存的其他控制，那么緩存可以用啟發(fā)式算法計(jì)算保鮮壽命（freshness lifetime）。緩存器必須對(duì)年齡大于24小時(shí)的響應(yīng)附加113警告，如果此響應(yīng)不帶這種警告。
而且，如果響應(yīng)有最后修改時(shí)間，啟發(fā)式過期值應(yīng)不大于從那個(gè)時(shí)間開始間隔的某個(gè)分?jǐn)?shù)。典型設(shè)置為間隔的10% 。
計(jì)算響應(yīng)是否過期非常簡(jiǎn)單：
response_is_fresh = （freshness_lifetime > current_age）
13.2.5澄清過期值（Disambiguation Expiration Values）
由于過期值很容易被設(shè)置，有可能兩個(gè)緩存會(huì)包含同一資源的不同保鮮值。
如果客戶端執(zhí)行請(qǐng)求接收到一個(gè)非第一手的響應(yīng)，此響應(yīng)在此客戶端擁有的緩存里仍然是保鮮的，并且緩存里的緩存項(xiàng)里的Date頭域的值比此新響應(yīng)的Date頭域值要新，那么客戶端應(yīng)該忽略此響應(yīng)。如果這樣，它可能會(huì)重新以“Cache-Control：max-age=0”指令（見14.9節(jié)）請(qǐng)求去強(qiáng)制任何中間緩存通過源服務(wù)器對(duì)其進(jìn)行檢查。
如果緩存對(duì)有不同驗(yàn)證器（validator）的同一個(gè)表現(xiàn)形式（representation）有兩個(gè)保鮮響應(yīng)，那么緩存必須利用Date頭域值最近的響應(yīng)。這種情況可能發(fā)生由于緩存會(huì)從其他緩存得到響應(yīng)，或者由于客戶端請(qǐng)求對(duì)一個(gè)保鮮緩存項(xiàng)的重載或重驗(yàn)證（revalidation）。
13.2.6澄清多個(gè)響應(yīng)（Disambiguating Multiple Response）
因?yàn)榭蛻舳丝赡苁盏浇?jīng)多個(gè)路徑而來的響應(yīng)，所以有些響應(yīng)會(huì)經(jīng)過一些緩存，而其他的響應(yīng)會(huì)經(jīng)過其他的緩存，客戶端收到響應(yīng)的順序可能與源服務(wù)器發(fā)響應(yīng)的順序不同。我們希望客戶端利用最新的響應(yīng)，即使舊響應(yīng)仍然是保鮮的。
實(shí)體標(biāo)簽（entity tag）和過期值都不能影響響應(yīng)的順序，因?yàn)榭赡軙?huì)出現(xiàn)晚一點(diǎn)的響應(yīng)可能會(huì)故意攜帶過早的過期時(shí)間。日期值的精度被規(guī)定只有一秒。?
當(dāng)客戶端試著重新驗(yàn)證一個(gè)緩存項(xiàng)的時(shí)候（譯注：這里的客戶端應(yīng)該包含一個(gè)本地緩存），而且接收到的響應(yīng)的Date頭域晚于已存在的緩存項(xiàng)，那么客戶端應(yīng)該重新進(jìn)行無(wú)條件請(qǐng)求，并且包含
Cache-Control: max-age=0?
去強(qiáng)制任何中間緩存通過源服務(wù)器來驗(yàn)證（validate）這些中間緩存的副本，或者
Cache-Control: no-cache?
去強(qiáng)制任何中間緩存去從源服務(wù)器獲得一個(gè)新的副本。
13.3 驗(yàn)證模型（Validation Model）
當(dāng)緩存有一個(gè)舊緩存項(xiàng)并且緩存想利用此緩存項(xiàng)來作為客戶端請(qǐng)求的響應(yīng)時(shí)，緩存必須首先通過源服務(wù)器（或者可能通過一個(gè)有保鮮響應(yīng)的中間緩存）對(duì)其進(jìn)行檢驗(yàn)看看此緩存項(xiàng)是否可用。我們稱做“驗(yàn)證（validating）”此緩存項(xiàng)。因?yàn)槲覀儾幌雽?duì)完整響應(yīng)的傳輸付出太大代價(jià)，而且如果緩存項(xiàng)無(wú)效時(shí)也不會(huì)產(chǎn)生額外的回路（譯注：回路的意思，如：從請(qǐng)求到響應(yīng)就一條回路），HTTP1.1協(xié)議支持使用條件方法。.?
協(xié)議支持條件方法的關(guān)鍵特征是圍繞“緩存驗(yàn)證器（cache validator）”展開的。當(dāng)源服務(wù)器產(chǎn)成一個(gè)完整響應(yīng)時(shí)，它同時(shí)會(huì)附加一些驗(yàn)證器給響應(yīng)，這些驗(yàn)證器和緩存項(xiàng)一起保存。當(dāng)客戶端（用戶代理或緩存服務(wù)器）對(duì)對(duì)應(yīng)有緩存項(xiàng)的資源執(zhí)行條件請(qǐng)求時(shí)，客戶端包含一個(gè)相關(guān)的驗(yàn)證器（validator）在請(qǐng)求里。
服務(wù)器（譯注：服務(wù)器可能是緩存服務(wù)器）則核對(duì)請(qǐng)求里的驗(yàn)證器和當(dāng)前本地的驗(yàn)證器是否匹配，如果他們匹配（見13.3.3），則返回一個(gè)特定狀態(tài)碼（通常為304（沒有改變））的響應(yīng)并且此響應(yīng)不包含實(shí)體主體（entity body）。如果不匹配，服務(wù)器就返回完整響應(yīng)（包含實(shí)體主體）。這樣，我們就避免了傳輸完整響應(yīng)如果驗(yàn)證器匹配，同時(shí)我們也避免了額外的回路如果驗(yàn)證器不匹配。
在HTTP1.1協(xié)議中，一個(gè)條件請(qǐng)求和普通的請(qǐng)求差不多，除了條件請(qǐng)求攜帶一些特殊的頭域（這些頭域包含驗(yàn)證器），包含這些特殊的頭域隱含地表明請(qǐng)求方法（通常是GET方法）為條件請(qǐng)求方法。
協(xié)議中包括緩存驗(yàn)證條件的正和負(fù)。也就是說請(qǐng)求方法將會(huì)執(zhí)行如果驗(yàn)證器的匹配或不會(huì)執(zhí)行如果驗(yàn)證器不匹配。
注意：缺少驗(yàn)證器的響應(yīng)可能會(huì)被緩存，而且會(huì)被緩存用來為請(qǐng)求提供服務(wù)直到緩存的副本過期，除非顯示地用緩存控制指令來禁止緩存這樣做。然而，緩存不能執(zhí)行條件方法獲取資源如果它沒有此資源實(shí)體的驗(yàn)證器，那意味著緩存副本將會(huì)不可更新在它過期后。?
13.3.1最后修改日期 （Last-Modified Dates）
Last-Modifed實(shí)體頭域值經(jīng)常被用作一個(gè)緩存驗(yàn)證器。簡(jiǎn)而言之，緩存項(xiàng)被認(rèn)為是有效的如果實(shí)體自從Last-Modifed值之后沒有改變。?
13.3.2 實(shí)體標(biāo)簽緩存驗(yàn)證器（Entity Tag Cache Validators）
ETag響應(yīng)頭域值是實(shí)體標(biāo)簽，它提供了一個(gè)“不透明（opaque）的緩存驗(yàn)證器。這能得到更可靠的驗(yàn)證當(dāng)在不方便存放修改日期的情況下，當(dāng)在HTTP日期值的一秒精度不能滿足需要的情況下，或當(dāng)在源服務(wù)器希望避免使用修改日期產(chǎn)生的沖突的情況下。
實(shí)體標(biāo)簽在3.11節(jié)描述了。使用了實(shí)體標(biāo)簽的頭域在14.19，14.24，14.26和14.44節(jié)里描述了。
13.3.3 強(qiáng),弱驗(yàn)證器 （Weak and Strong Validators）
由于源服務(wù)器和緩存會(huì)比較兩個(gè)驗(yàn)證器來確定他們是否代表相同的實(shí)體，所以通常希望實(shí)體（entity，實(shí)體主體或?qū)嶓w頭域）發(fā)生任何變化時(shí)驗(yàn)證器也相應(yīng)變化，這樣的驗(yàn)證器為強(qiáng)驗(yàn)證器。.?
然而，可能存在這樣的請(qǐng)求，服務(wù)器傾向于僅在實(shí)體發(fā)生重要的語(yǔ)義變化時(shí)才改變驗(yàn)證器，而在實(shí)體的某些方面不發(fā)生重大改變時(shí)就不改變驗(yàn)證器。在資源變化時(shí)驗(yàn)證器未必變化的稱為弱驗(yàn)證器.。
實(shí)體標(biāo)簽通常是強(qiáng)驗(yàn)證器，但協(xié)議提供一種機(jī)制來使實(shí)體標(biāo)簽變成弱驗(yàn)證器。可以認(rèn)為強(qiáng)驗(yàn)證器在實(shí)體的每一字節(jié)變化時(shí)而變化，而弱驗(yàn)證器僅在實(shí)體的語(yǔ)義變化時(shí)才變化。換言之，我們能認(rèn)為強(qiáng)驗(yàn)證器是特定實(shí)體的標(biāo)識(shí)，而弱驗(yàn)證器是同一類語(yǔ)義等價(jià)實(shí)體的標(biāo)識(shí)。
注: 強(qiáng)驗(yàn)證器的例子：一個(gè)整數(shù)他會(huì)隨著每次實(shí)體發(fā)生變化而遞增。一個(gè)實(shí)體的修改時(shí)間，如果以秒為精度，能被當(dāng)作弱驗(yàn)證器，因?yàn)樵谝幻雰?nèi)資源可能改變兩次。是否支持弱驗(yàn)證器是選擇的。然而，弱驗(yàn)證器可以能高效的去緩存等效對(duì)象。
.?
客戶端產(chǎn)生請(qǐng)求并把驗(yàn)證器包含在一個(gè)驗(yàn)證頭域里的時(shí)候或在服務(wù)器比較兩個(gè)驗(yàn)證器的時(shí)候均用到驗(yàn)證器。強(qiáng)驗(yàn)證器可在任何情況下使用，而弱驗(yàn)證器僅在不依賴嚴(yán)格相等時(shí)才可用。當(dāng)客戶端產(chǎn)生條件GET請(qǐng)求來請(qǐng)求一個(gè)完整實(shí)體時(shí)，任何類型的驗(yàn)證器都可以使用。然而，子范圍（sub-range）請(qǐng)求時(shí)只能使用強(qiáng)驗(yàn)證器，因?yàn)榭蛻舳丝赡軙?huì)得到一個(gè)不一致的實(shí)體。
客戶端可以在發(fā)出簡(jiǎn)單（非子范圍）GET請(qǐng)求里既可以包含弱驗(yàn)證器也可以包含強(qiáng)驗(yàn)證器。客戶端不能利用弱驗(yàn)證器在其它的請(qǐng)求形式里。
HTTP1.1協(xié)議定義驗(yàn)證的唯一功能就是比較。有兩種驗(yàn)證器的比較方法，這依賴于是否能利用弱驗(yàn)證器進(jìn)行比較。
.?
- 強(qiáng)比較方法：在考慮相等的情況下，兩驗(yàn)證器必須完全一致，并且兩個(gè)驗(yàn)證器都是強(qiáng)驗(yàn)證器。.?
- 弱比較方法：在考慮相等的情況下，兩驗(yàn)證器必須完全一致，但至少有一個(gè)驗(yàn)證器可能在不影響結(jié)果的情況下被標(biāo)明為“weak”。
實(shí)體標(biāo)簽是強(qiáng)驗(yàn)證器除非它被顯示地標(biāo)記為弱(weak)的。3.11節(jié)給出了實(shí)體標(biāo)簽的語(yǔ)法。
最后修改時(shí)間（譯注：Last-Modifed頭域的值）被用作請(qǐng)求的驗(yàn)證器時(shí)默認(rèn)為弱驗(yàn)證器，,除非滿足下列規(guī)則才判定它是強(qiáng)驗(yàn)證器：.?
- 驗(yàn)證器被源服務(wù)器用來和當(dāng)前實(shí)體的驗(yàn)證器進(jìn)行比較并且源服務(wù)器知道相關(guān)的實(shí)體不會(huì)在當(dāng)前驗(yàn)證器函蓋的秒數(shù)內(nèi)改變兩次，
或者
- 驗(yàn)證器可能被客戶端用于If-Modified-Since 或者 If-Unmodified-Since頭域里，因?yàn)榭蛻舳擞幸粋€(gè)關(guān)于此實(shí)體的緩存項(xiàng)，并且
- 緩存項(xiàng)包含一個(gè)日期值，此日期值給出了源服務(wù)器發(fā)送源響應(yīng)（譯注：源服務(wù)器產(chǎn)生的響應(yīng)）的時(shí)間，并且
- Last-Modifed頭域值至少提前于日期值（Date頭域值）60秒。?
或者
- 驗(yàn)證器已經(jīng)被中間緩存同此實(shí)體的緩存項(xiàng)里的驗(yàn)證器比較過 ，并且
- 緩存項(xiàng)包含日期值（Date頭域值），此日期值指明了源服務(wù)器發(fā)送源響應(yīng)的時(shí)間，并且
- Last-Modifed頭域值至少提前于日期值（Date頭域值）60秒。
此種方法依賴于以下事實(shí)，如果兩個(gè)響應(yīng)被服務(wù)器在同一秒內(nèi)被發(fā)出，但這兩個(gè)響應(yīng)都有相同的最后修改（Last-Modified）時(shí)間，那么至少有一個(gè)響應(yīng)的日期值（譯注：Date頭域的值）和最后修改時(shí)間值（Last-Modifed頭域的值）是相等的。60秒的限制能保證Date和Last-Modifed頭域的值在不同時(shí)刻產(chǎn)生。一個(gè)實(shí)現(xiàn)可能會(huì)利用大于60秒的值，如果它認(rèn)為60秒太短。
如果客戶端希望執(zhí)行子范圍(sub-range)請(qǐng)求來請(qǐng)求一個(gè)只有最后修改（Last-Modifed）時(shí)間和而沒有透明驗(yàn)證器的值時(shí)，它可能會(huì)認(rèn)為只有最后修改（Last-Modified）時(shí)間是強(qiáng)的。
若緩存或源服務(wù)器收到一個(gè)條件請(qǐng)求，而不是得到完整響應(yīng)的GET請(qǐng)求時(shí)，他必須使用強(qiáng)比較方法去計(jì)算此條件。
此規(guī)定允許HTTP1.1的,緩存和客戶端安全地執(zhí)行子范圍（sub-range）請(qǐng)求來請(qǐng)求從HTTP/1.0得來的值。?
13.3.4 關(guān)于何時(shí)使用實(shí)體標(biāo)簽和最后修改時(shí)間的規(guī)則
我們對(duì)源服務(wù)器，客戶端和緩存采用一套規(guī)則和建議來規(guī)定不同的驗(yàn)證器何時(shí)應(yīng)該被使用，出
于何種目的被使用。
HTTP/1.1 源服務(wù)器：
- 應(yīng)該發(fā)送一個(gè)實(shí)體標(biāo)簽驗(yàn)證器除非源服務(wù)器產(chǎn)生這樣一個(gè)實(shí)體標(biāo)簽不可行。
- 可能會(huì)發(fā)送弱實(shí)體標(biāo)簽而不是強(qiáng)實(shí)體標(biāo)簽，如果使用弱實(shí)體標(biāo)簽?zāi)芴岣咝阅艿脑捇蛘呷绻l(fā)送一個(gè)強(qiáng)實(shí)體標(biāo)簽不可行的情況下。
- 應(yīng)該發(fā)送一個(gè)Last-Modifed值如果可行的話，除非打破語(yǔ)義透明性（這可能由利用If-Modified-Since頭域里的日期產(chǎn)生）可能會(huì)導(dǎo)致嚴(yán)重的后果。
換句話說，對(duì)http1.1源服務(wù)器來說，比較好的做法是同時(shí)發(fā)送強(qiáng)實(shí)體標(biāo)簽和Last-Modified值。.?
為了合法，強(qiáng)實(shí)體標(biāo)簽必須隨相關(guān)聯(lián)的實(shí)體值改變而改變。弱實(shí)體標(biāo)簽應(yīng)該隨相關(guān)聯(lián)的實(shí)體在語(yǔ)義上發(fā)生改變而改變。
注意：為保證語(yǔ)義透明緩存，源服務(wù)器必須避免為兩個(gè)不同的實(shí)體重復(fù)利用一個(gè)特定的強(qiáng)實(shí)體標(biāo)簽值。緩存項(xiàng)應(yīng)該能保持任意長(zhǎng)的時(shí)間，而不管過期時(shí)間（expiraton time），所以緩存可能會(huì)再去嘗試去利用在過去某一時(shí)刻獲得的驗(yàn)證器去驗(yàn)證緩存項(xiàng)。?
HTTP/1.1 客戶端：?
- 若實(shí)體標(biāo)簽被源服務(wù)器提供，HTTP/1.1客戶端必須在任何緩存條件請(qǐng)求（利用了If-Match或If-None-Match的請(qǐng)求）里利用實(shí)體標(biāo)簽.。
- 僅當(dāng)Last-Modified值被源服務(wù)器提供時(shí)，HTTP/1.1客戶端應(yīng)該在非子范圍緩存條件請(qǐng)求（利用If-Modified-Since）里利用此值。?
- 僅當(dāng)Last-Modified值被HTTP/1.0源服務(wù)器提供，HTTP/1.1客戶端可能會(huì)在子范圍緩存條件請(qǐng)求（利用了If-Unmodified-Since）里利用此值。
- 如果一個(gè)實(shí)體標(biāo)簽和Last-Modified值被源服務(wù)器提高，HTTP/1.1客戶端應(yīng)該在緩存條件請(qǐng)求里利用這兩個(gè)驗(yàn)證器。這允許HTTP/1.1和HTTP/1.1緩存能合適地進(jìn)行響應(yīng)。?
HTTP/1.1源服務(wù)器，當(dāng)接收到一個(gè)條件請(qǐng)求并且此請(qǐng)求同時(shí)包含Last-Modifed日期（例如，在If-Modified-Since，或If-Unmodified-Since頭域里）和一個(gè)或多個(gè)實(shí)體標(biāo)簽（例如在If-Match，If-None=Match，或If-Range頭域里）作為緩存驗(yàn)證器時(shí)，源服務(wù)器不能返回一個(gè)304狀態(tài)響應(yīng)（Not Modified）除非這樣做能當(dāng)當(dāng)前實(shí)體的驗(yàn)證器和請(qǐng)求里所有的條件頭域里的驗(yàn)證器一致。
HTTP/1.1緩存服務(wù)器，當(dāng)接收到一個(gè)條件請(qǐng)求并且此請(qǐng)求里同時(shí)包含Last-Modified日期和一個(gè)或多個(gè)實(shí)體標(biāo)簽作為緩存驗(yàn)證器時(shí)，它不能返回一個(gè)本地的副本給客戶端除非那個(gè)副本的驗(yàn)證器和所有請(qǐng)求里條件頭域里的驗(yàn)證器一致。
注意：這些規(guī)則背的常用的原則是HTTP/1.1服務(wù)器和客戶端應(yīng)該在請(qǐng)求和響應(yīng)里盡可能傳輸非冗余的信息。接收這些非冗余信息的HTTP/1.1系統(tǒng)將會(huì)假設(shè)它接收了驗(yàn)證器。
HTTP/1.0客戶端和緩存將會(huì)忽略實(shí)體標(biāo)簽。通常，Last-Modified值被這些系統(tǒng)接收后將會(huì)保證透明和高效的緩存行為，所以HTTP/1.1源服務(wù)器這時(shí)將會(huì)提供Last-Modified值。在這些情況下，當(dāng)HTTP/1.0系統(tǒng)利用一個(gè)Last-Modified值作為一個(gè)驗(yàn)證器可能會(huì)帶來嚴(yán)重的后果時(shí)，HTTP/1.1服務(wù)器將不會(huì)提供Last-Modified值。
13.3.5非驗(yàn)證條件（Non-validating Conditionls）
實(shí)體標(biāo)簽背后的原則是只有服務(wù)的作者才知道資源的語(yǔ)義而去選擇一個(gè)合適的緩存驗(yàn)證機(jī)制，并且任何驗(yàn)證器比較方法的標(biāo)準(zhǔn)都可能會(huì)帶來風(fēng)險(xiǎn)。所以，任何其他的頭域的比較（除了Last-Modified，為了兼容HTTP/1.0）從來不會(huì)被用于驗(yàn)證緩存項(xiàng)。
13.4 響應(yīng)的可緩存性（Response Cacheability）
除非被緩存控制（見14.9節(jié)）指令明確地限制，緩存系統(tǒng)可以將一成功的響應(yīng)作為緩存項(xiàng)，可以返回緩存項(xiàng)里的響應(yīng)副本而不需要驗(yàn)證它如果此副本是保鮮的，并且也可以在驗(yàn)證成功后返回它。如果既沒有和響應(yīng)相關(guān)的緩存驗(yàn)證器也沒有和響應(yīng)相關(guān)的顯示過期時(shí)間（explicit expiration time，譯注：見13.3.1節(jié)里關(guān)于什么是顯示過期時(shí)間的說明），我們不會(huì)認(rèn)為它是可緩存的，但是某些緩存可能會(huì)違反這個(gè)期望（例如，當(dāng)不能進(jìn)行網(wǎng)絡(luò)連接時(shí)）。客戶端能經(jīng)常發(fā)現(xiàn)從緩存里獲得的響應(yīng)，只需要通過把Date頭域值同當(dāng)前時(shí)間作比較。
注意：某些HTTP1.0緩存可能違反這一期望而不提示警告。
還有,某些情況下可能不便保留一實(shí)體,或?qū)⑵浞祷亟o后續(xù)請(qǐng)求.?
然而，在一些情況下，緩存不適合保存一個(gè)實(shí)體，或者不適合把它放于后續(xù)請(qǐng)求的響應(yīng)里。這可能因?yàn)榉?wù)作者認(rèn)為完全語(yǔ)義透明性是有必要的，或著因?yàn)榘踩碗[私的考慮。某些緩存控制指令是為了讓服務(wù)器能指明某些資源實(shí)體或其中的一部分不能被緩存。
注意在14.8節(jié)里描述了防止一個(gè)共享緩存去保存和返回一個(gè)以前請(qǐng)求的響應(yīng)，如果那個(gè)請(qǐng)求包含一個(gè)Authorization頭域。
除非緩存控制指令防止此響應(yīng)被緩存，一個(gè)接收的響應(yīng)如果它的狀態(tài)碼是200，203，206，300，301或410，那么此響應(yīng)應(yīng)該被緩存保存而且可用于后續(xù)的請(qǐng)求，但這必須受限于過期機(jī)制（expiration mechanism）。然而，緩存如果不支持Range和Content-Range頭域，那么它不能緩存206響應(yīng)（部分內(nèi)容）響應(yīng)。
接收到的響應(yīng)如果是其他的狀態(tài)碼（如，302和307），那么此響應(yīng)不能被用于服務(wù)于后續(xù)的請(qǐng)求，除非緩存控制指令或其他的頭域明確地允許它能這樣做。例如，這些頭域包含下面的頭域：Expires頭域（見14.21）；“max-age”，“s-maxage”，“must-revalidate”，“prox-revalidate”，“public”或“private”緩存控制指令（見14.9）。
13.5 從緩存里構(gòu)造響應(yīng)
緩存的目的是存儲(chǔ)請(qǐng)求的響應(yīng)信息，為了響應(yīng)將來的請(qǐng)求。在很多情況下，緩存能返回響應(yīng)的合適部分給請(qǐng)求者。然而，如果緩存擁有一個(gè)基于以前響應(yīng)的緩存項(xiàng)，它可能必須把新響應(yīng)的部分和它緩存項(xiàng)里的內(nèi)容合起來。
13.5.1End-to-end和Hop-by-hop頭域
為定義緩存和非緩存代理服務(wù)器的行為，我們將HTTP頭域分成兩類：
- end-to-end頭域，他們被傳輸給最終請(qǐng)求或響應(yīng)的接收者。響應(yīng)里end-to-end頭域必需作為緩存項(xiàng)的一部分存儲(chǔ)，并且必須在從緩存項(xiàng)形成的響應(yīng)里傳輸。
- hop-by-hop頭域，他們被只對(duì)傳輸層上的連接有意義，并且不能被緩存保存或被代理轉(zhuǎn)發(fā)。
下面的HTTP/1.1頭域是hop-by-hop頭域：
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- TE
- Trailers
- Transfer-Encoding
- Upgrade
所有其他被HTTP/1.1定義的頭域均為end-to-end頭域。
13.5.2不可更改的頭域 （Non-modifiable Headers）
HTTP1.1的某些特征，如數(shù)字認(rèn)證，基于某一些end-to-end頭域。一個(gè)透明代理不應(yīng)該改變end-to-end頭域，除非這些頭域的定義要求或允許它這樣做。
一個(gè)透明代理（譯注：代理一般是緩存，緩存可以叫緩存代理，緩存服務(wù)器，代理服務(wù)器）不能改變請(qǐng)求或響應(yīng)里的下面的頭域，而且它不能添加這些頭域到?jīng)]有這些頭域的請(qǐng)求或響應(yīng)里：
- Contents-location
- Content-MD5
- ETag
- Last-Modified
一個(gè)透明代理不能改變響應(yīng)里下面的的頭域：?
- Expires?
但它可以添加這些頭域如果響應(yīng)里沒有這些頭域的時(shí)候。如果一個(gè)Expires頭域被添加，它必須等于響應(yīng)里Date頭域的值。
一個(gè)代理（譯注：緩存就是一個(gè)代理，我們一般稱做緩存代理，或緩存服務(wù)器，或緩存代理服務(wù)器，都是一個(gè)意思）不能在消息中改變或添加下面的頭域如果此消息包含no-transform緩存控制指令，或在任何請(qǐng)求里也不能添加或改變這些頭域。
- Content-Encoding?
- Content-Range?
- Content-Type?
一個(gè)非透明代理可能會(huì)改變或添加這些頭域給一個(gè)消息如果此消息不包含no-transform緩存控制指令，但是如果代理這樣做了，它必須添加一個(gè)警告214（轉(zhuǎn)換被應(yīng)用）（見14.46節(jié)）。
警告：end-to-end頭域的不必要的改變可能會(huì)導(dǎo)致認(rèn)證機(jī)的失敗如果更強(qiáng)的認(rèn)證機(jī)制被應(yīng)用于后續(xù)的HTTP版本中。此認(rèn)證機(jī)制可能依賴于沒有在此出現(xiàn)的頭域值。
請(qǐng)求或響應(yīng)里的Content-Length頭域被添加或被刪除會(huì)根據(jù)4.4節(jié)的規(guī)則。一個(gè)透明代理必須保留實(shí)體主體的entity-length（見7.2.2），盡管它可以可能改變transfer-length（4.4節(jié)）。
13.5.3聯(lián)合頭域（Combining Headers）
當(dāng)一個(gè)緩存對(duì)服務(wù)器發(fā)出驗(yàn)證請(qǐng)求時(shí)，而且服務(wù)器提供304（沒有改變）響應(yīng)或206（部分內(nèi)容）響應(yīng)時(shí)，那么緩存將構(gòu)造一個(gè)響應(yīng)發(fā)送給請(qǐng)求客戶端。
如果狀態(tài)碼是304（沒有改變），緩存利用緩存項(xiàng)里的實(shí)體主體（entity-body）作為客戶端請(qǐng)求響應(yīng)的實(shí)體主體。如果響應(yīng)狀態(tài)碼是206（部分內(nèi)容）并且Etag或Last-Modified頭域能精確匹配，那么緩存可能把存入緩存項(xiàng)里的內(nèi)容和接收到的響應(yīng)里的新內(nèi)容合并并且利用最后合并的結(jié)果作為輸出響應(yīng)（見13.5.4）。
存儲(chǔ)于緩存項(xiàng)里端end-to-end頭域被用于構(gòu)造響應(yīng)，除了：
- 任何存儲(chǔ)的警告碼是1xx（見14.46）Warning頭域必須從緩存項(xiàng)和轉(zhuǎn)發(fā)的響應(yīng)里刪除。
- 任何存儲(chǔ)的警告碼是2xx的Warning頭域必須要在緩存項(xiàng)和轉(zhuǎn)發(fā)的響應(yīng)里保留。
- 任何在304或206響應(yīng)里的end-to-end頭域必須替換緩存項(xiàng)里相應(yīng)的頭域
除非緩存決定去刪除緩存項(xiàng)，否則它必須照樣能用接收的響應(yīng)里的相應(yīng)的end-to-end頭域去替換存儲(chǔ)在緩存項(xiàng)里的頭域，除了上面描述的Warning頭域。如果輸入響應(yīng)里的一個(gè)頭域匹配緩存項(xiàng)里多個(gè)頭域，那么所有這些舊的頭域必須被替換。
從另一方面說，輸入響應(yīng)的所有end-to-end頭域會(huì)覆蓋緩存項(xiàng)里所有相應(yīng)的end-to-end頭域（除了緩存的警告碼是1xx的Warning頭域，它將會(huì)被刪除即使沒有被覆蓋）。
注意：此規(guī)則允許源服務(wù)器去利用304（沒有改變）或一個(gè)206（部分內(nèi)容）響應(yīng)去更新任何同一實(shí)體或?qū)嶓w的子范圍的以前響應(yīng)的頭域，雖然它可能沒有意義或這樣做不正確。這條規(guī)則不允許源服務(wù)器去利用304（沒有改變）或206（部分內(nèi)容）響應(yīng)去完全地刪除一個(gè)以前響應(yīng)的頭域。
13.5.4聯(lián)合字節(jié)范圍（Combing Byte Ranges）
一條響應(yīng)可能僅傳送一個(gè)實(shí)體主體的某一部分，這是由于請(qǐng)求包含一個(gè)或多個(gè)Range指定的范圍，或者由于連接會(huì)被過早地?cái)嚅_。在幾次這樣得傳輸后，緩存可能已經(jīng)接收了同一個(gè)實(shí)體主體的多個(gè)范圍部分。
如果緩存有一個(gè)實(shí)體的非空子范圍，并且一個(gè)輸入（incoming）響應(yīng)（譯注：輸入響應(yīng)是進(jìn)入緩存的響應(yīng)，輸出響應(yīng)是從緩存出去的響應(yīng)）攜帶了另一個(gè)子范圍，那么緩存可能會(huì)把新的子范圍和已經(jīng)存在的子范圍聯(lián)合起來如果兩者遵循下面的規(guī)則：
- 輸入響應(yīng)和緩存項(xiàng)都有緩存驗(yàn)證器。
- 當(dāng)利用強(qiáng)比較方法的時(shí)候，兩個(gè)緩存驗(yàn)證器完全匹配（見13.3.3）。
如果任何一個(gè)要求不能滿足，緩存必須利用最近的部分響應(yīng)（這基于任何響應(yīng)的Date頭域值，并且會(huì)利用輸入響應(yīng)如果這些Date頭域值相等或丟失了），而且必須丟棄其他的部分信息。
13.6 緩存已經(jīng)協(xié)商過的響應(yīng)（Caching Negotiated Responses）
在Vary頭域出現(xiàn)在響應(yīng)里的時(shí)候，服務(wù)器驅(qū)動(dòng)內(nèi)容協(xié)商（12.1節(jié)）的使用會(huì)改變緩存利用響應(yīng)去響應(yīng)后續(xù)請(qǐng)求利用的條件和過程。見14.44節(jié)關(guān)于服務(wù)器利用Vary頭域的描述。
服務(wù)器應(yīng)該利用Vary頭域去通知一個(gè)緩存什么樣的請(qǐng)求頭域應(yīng)該被使用從而從一個(gè)可緩存的并受限于服務(wù)器驅(qū)動(dòng)協(xié)商的響應(yīng)的多個(gè)表現(xiàn)形式中選擇合適的表現(xiàn)形式。Vary頭域里指定的頭域被稱做選擇請(qǐng)求頭域（selecting request-header）。
當(dāng)緩存接收到一個(gè)后續(xù)的請(qǐng)求，此請(qǐng)求的URI對(duì)應(yīng)一個(gè)或多個(gè)包含了Vary頭域的緩存項(xiàng)時(shí)，此緩存不能利用這樣一個(gè)緩存項(xiàng)去構(gòu)造出一個(gè)響應(yīng)去服務(wù)于新來的請(qǐng)求，除非所有出現(xiàn)在新請(qǐng)求里的選擇請(qǐng)求頭域匹配存儲(chǔ)在源請(qǐng)求里被存儲(chǔ)的請(qǐng)求頭域。
在兩個(gè)請(qǐng)求里，我們定義這兩個(gè)選擇請(qǐng)求頭域匹配，如果并且只有第一個(gè)請(qǐng)求的選擇請(qǐng)求頭域能被轉(zhuǎn)換為第二個(gè)請(qǐng)求里的頭域通過添加或刪除線性空白（被允許出現(xiàn)在相應(yīng)的BNF里的線性空白）和/或把多個(gè)消息頭域結(jié)合成一個(gè)頭域通過4.2節(jié)里的規(guī)則。
一個(gè)Vary頭域值是“*”總是不能匹配的，并且后續(xù)那個(gè)資源的請(qǐng)求只能合適地被源服務(wù)器解析。
如果緩存項(xiàng)里的選擇請(qǐng)求頭域（selecting request-header）不能匹配新請(qǐng)求的選擇請(qǐng)求頭域，那么緩存不能利用緩存項(xiàng)去滿足請(qǐng)求除非它能以一個(gè)條件請(qǐng)求把此新請(qǐng)求接力到源服務(wù)器并且此源服務(wù)器以一個(gè)304（沒有改變）的狀態(tài)碼進(jìn)行響應(yīng)并包含一個(gè)實(shí)體標(biāo)簽或者Content-Location頭域指明將要被使用的實(shí)體。
如果一個(gè)實(shí)體標(biāo)簽被賦予一個(gè)緩存的表現(xiàn)形式，那么此轉(zhuǎn)發(fā)的請(qǐng)求將是條件的并且所有那個(gè)資源的緩存項(xiàng)的實(shí)體標(biāo)簽將會(huì)被包含于If-None-Match頭域里。這向服務(wù)器表達(dá)當(dāng)前緩存擁有的實(shí)體集，以至于如果這些實(shí)體里的任何實(shí)體匹配請(qǐng)求的實(shí)體，服務(wù)器會(huì)利用Etag頭域在304（沒有改變）響應(yīng)里去告訴緩存哪個(gè)緩存項(xiàng)是合適的。如果新響應(yīng)的實(shí)體標(biāo)簽匹配已經(jīng)存在的緩存項(xiàng)，那么新響應(yīng)應(yīng)該被利用去更新已經(jīng)存在的緩存項(xiàng)的頭域，而且此結(jié)果必須返回給客戶端。
如果任何已經(jīng)存在的緩存項(xiàng)包含只有相關(guān)實(shí)體的部分內(nèi)容，那么此實(shí)體的實(shí)體標(biāo)簽不應(yīng)該被包含在If-None-Match頭域里除非這個(gè)請(qǐng)求是為了請(qǐng)求實(shí)體的一個(gè)范圍，此范圍完全可以被緩存項(xiàng)滿足。
如果緩存接收到一個(gè)成功的響應(yīng)，此響應(yīng)的Content-Location頭域匹配于已經(jīng)存在的緩存項(xiàng)的Content-Location頭域?qū)ν徽?qǐng)求URI來說，并且此響應(yīng)的實(shí)體標(biāo)簽不同于已經(jīng)存在的緩存項(xiàng)的實(shí)體標(biāo)簽，而且此響應(yīng)的Date頭域值比已經(jīng)存在的緩存項(xiàng)更近，那么已經(jīng)存在的緩存項(xiàng)不能被返回去響應(yīng)將來的請(qǐng)求并且將會(huì)從緩存里刪除。
13.7 共享和非共享緩存 （Shared and Non-Shared Caches）
出于安全和保密考慮，有必要區(qū)分共享和非共享緩存。非共享緩存是僅供一個(gè)用戶使用的緩存，此種情況下，可用性由適當(dāng)?shù)陌踩珯C(jī)制控制。所有其它的緩存均被認(rèn)為是共享緩存。此協(xié)議的其它部分給一些對(duì)共享緩存的限制以防止隱私丟失或訪問控制的失敗。
13.8 錯(cuò)誤和不完全的響應(yīng)緩存行為
緩存收到不完整響應(yīng)（例如響應(yīng)的字節(jié)數(shù)比Content-Length頭域指定的值要小）也可以存儲(chǔ)它，但是必須把它看作部分響應(yīng)。部分相應(yīng)可以合并（見13.5.4）；合并結(jié)果可能是完整的響應(yīng)或可能仍是部分的響應(yīng)。.緩存不能把部分響應(yīng)返回給客戶端除非有明確要求可以這樣做例如利用206（部分內(nèi)容）狀態(tài)碼響應(yīng)。緩存不能使用一個(gè)200（OK）狀態(tài)碼返回一個(gè)部分響應(yīng)。
如果緩存在試圖重驗(yàn)證一個(gè)緩存項(xiàng)而收到一個(gè)5xx響應(yīng)時(shí)，它既可以將此響應(yīng)轉(zhuǎn)發(fā)給請(qǐng)求的客戶端，或者做的就像服務(wù)器不能響應(yīng)似的。在后面的情況下，它可能返回一個(gè)以前的接收的響應(yīng)除非緩存項(xiàng)包含一個(gè)“must-revalidate”緩存控制指令（見14.9節(jié)）。
13.9 GET 和 HEAD 的副作用（Side Effects of GET and HEAD）
除非源服務(wù)器明確地禁止緩存保存它們的響應(yīng)，對(duì)任何資源應(yīng)用的GET和HEAD方法不應(yīng)該有副作用，這些副作用會(huì)導(dǎo)致錯(cuò)誤的行為如果這些響應(yīng)將從緩存產(chǎn)生。他們可能會(huì)仍然有副作用，但緩存在決定緩存時(shí)不必考慮這些副作用。緩存總是期望去觀察一個(gè)源服務(wù)器對(duì)緩存的明確限制。
一個(gè)例外：有些應(yīng)用習(xí)慣于在在GETs和HEADs方法里使用查詢URLs（在rel_path_part里包含一個(gè)“?”）去執(zhí)行一個(gè)操作而帶來很大的副作用，緩存不能把此URIs的響應(yīng)看作一個(gè)保鮮的除非服務(wù)器提供一個(gè)顯示過期時(shí)間（explicit expiration time）。這意味著此URIs的以前從HTTP/1.0服務(wù)器產(chǎn)生的響應(yīng)不能來自于緩存。見9.1.1節(jié)相關(guān)的信息。
13.10 在更新或刪除后的無(wú)效性
對(duì)源服務(wù)器上的某資源執(zhí)行方法的副作用可能會(huì)使一個(gè)或多個(gè)已經(jīng)存在的緩存項(xiàng)的不透明性無(wú)效。那就是說，雖然他們可能會(huì)繼續(xù)是保鮮的，但是他們不能準(zhǔn)確的反應(yīng)出源服務(wù)器將會(huì)對(duì)這一個(gè)新的請(qǐng)求返回什么。
HTTP協(xié)議無(wú)法保證所有此類緩存項(xiàng)均被標(biāo)明無(wú)效。例如，引起源服務(wù)器上資源變化的請(qǐng)求可能不會(huì)穿過存有一個(gè)緩存項(xiàng)的代理。然而，一些規(guī)則幫助減少錯(cuò)誤行為的可能。
在此節(jié)里，短語(yǔ)“使實(shí)體無(wú)效”意味著緩存會(huì)將所有那個(gè)實(shí)體的實(shí)例從它的存儲(chǔ)里移除，或者把這些實(shí)體的實(shí)例標(biāo)記為“無(wú)效的”并且在他們可能作為后續(xù)請(qǐng)求的響應(yīng)時(shí)會(huì)被進(jìn)行重驗(yàn)證。?
一些HTTP方法必須讓緩存去使一個(gè)實(shí)體無(wú)效 。這些實(shí)體被請(qǐng)求URI指定，或在Location或在Content-Location頭域里被指定（如果出現(xiàn)的話）。這些方法是：
- PUT
- DELETE
- POST
為了防止服務(wù)器攻擊拒絕，一個(gè)基于Location或Content-Location頭域里的URI的無(wú)效性處理必須只有在host部分和請(qǐng)求URI里的host部分相同時(shí)才被執(zhí)行。?
一個(gè)緩存如果不能理解請(qǐng)求里的方法，那么它應(yīng)該使請(qǐng)求URI指定的任何實(shí)體無(wú)效。
13.11 強(qiáng)制寫通過（ Write-Through Mandatory）
所有可能對(duì)源服務(wù)器資源進(jìn)行修改的方法都要寫通過給源服務(wù)器（譯注：直接穿過緩存在服務(wù)器上修改）。這通常包括所有方法除了GET和HEAD方法。緩存在將此種請(qǐng)求轉(zhuǎn)發(fā)給服務(wù)器并獲得相應(yīng)的響應(yīng)前不能對(duì)請(qǐng)求客戶端做出響應(yīng)。 這個(gè)不能防止代理緩存（譯注：也可以叫緩存服務(wù)器，緩存）在服務(wù)器已經(jīng)發(fā)送最終回復(fù)之前發(fā)送100（繼續(xù)）響應(yīng)。
相反情況（通常叫“寫回”或“拷貝回”緩存）在HTTP1.1中是不允許的，這是由于提供一致更新非常困難，并且服務(wù)器，緩存和網(wǎng)絡(luò)的故障會(huì)出現(xiàn)在比寫回早。?
13.12 緩存替換 （Cache Replacement）
如果一個(gè)新的可緩存的響應(yīng)被緩存接收，同時(shí)對(duì)這一資源的響應(yīng)已經(jīng)在緩存里存在，那么緩存應(yīng)該利用最新的響應(yīng)去回復(fù)當(dāng)前的請(qǐng)求。緩存可能會(huì)把此新響應(yīng)放進(jìn)存儲(chǔ)里，并且如果它滿足所有其他的要求，緩存將會(huì)利用此響應(yīng)來響應(yīng)任何將來的請(qǐng)求。如果緩存想把此新的響應(yīng)加進(jìn)緩存的存儲(chǔ)，13.5.3的規(guī)則必須應(yīng)用。
說明：一個(gè)新響應(yīng)如果它的Date頭域值比已經(jīng)存在的緩存響應(yīng)的Date頭域值老，那么它是不能緩存的。
13.13 歷史列表 （History Lists）
用戶代理經(jīng)常使用歷史機(jī)制，如“Back”按鈕和歷史列表，來重新展示在一個(gè)會(huì)話里接收的一個(gè)稍早的實(shí)體。
歷史機(jī)制和緩存機(jī)制是不同。歷史機(jī)制不應(yīng)該嘗試展示一個(gè)當(dāng)前資源狀態(tài)的語(yǔ)義透明視圖。其歷史機(jī)制只是為了展示在獲得資源時(shí)看到了什么。
默認(rèn)情況，一個(gè)過期時(shí)間不會(huì)應(yīng)用于一個(gè)歷史機(jī)制。如果實(shí)體仍然在存儲(chǔ)里，歷史機(jī)制應(yīng)該顯示它即使實(shí)體過期了，除非用戶叫用戶代理去刷新過期的文檔。
這不能被解釋去防止歷史機(jī)制告訴用戶視圖可能過期了。?
注意：如果歷史機(jī)制沒必要地防止了用戶看陳舊的資源，那么這會(huì)強(qiáng)制服務(wù)作者去避免利用HTTP過期控制和緩存控制。服務(wù)作者可能會(huì)認(rèn)為這是非常重要的當(dāng)用戶沒有被呈現(xiàn)錯(cuò)誤消息或警告消息當(dāng)他們利用導(dǎo)向按鈕（如BACK按鈕）去看以前獲得的資源時(shí)。即使有時(shí)這些資源本不能被緩存保存或應(yīng)該可能會(huì)很快過期，用戶界面可能會(huì)強(qiáng)制服務(wù)作者去求助于其他防止緩存的方法（例如，一次性URLs）為了避免歷史機(jī)制功能的不合適的作用。
如果緩存不能改善性能，他將一無(wú)用處。HTTP/1.1中緩存的目的是為了在很多情況下減少發(fā)送請(qǐng)求，同時(shí)在許多情況下可以不需要發(fā)送完整響應(yīng)。前者減少了網(wǎng)絡(luò)回路（譯注：一個(gè)請(qǐng)求會(huì)返回一個(gè)響應(yīng)，請(qǐng)求響應(yīng)這個(gè)過程就是一個(gè)回路）的數(shù)量；我們利用一個(gè)“過期（expiration）”機(jī)制來為此目的（見13.2節(jié)）。后者減少了網(wǎng)絡(luò)應(yīng)用的帶寬；我們用“驗(yàn)證（validation）”機(jī)制來為此目的。
對(duì)行為，可行性，和關(guān)閉的操作的要求放松了語(yǔ)義透明性的目的。HTTP/1.1協(xié)議允許服務(wù)器，緩存，和客戶端能顯示地降低透明性當(dāng)在必要的時(shí)候。然而，因?yàn)椴煌该鞯牟僮髂芑煜菍I(yè)的用戶，同時(shí)可能和某個(gè)服務(wù)器應(yīng)用程序不兼容（例如訂購(gòu)商品），因此此協(xié)議透明性在下面情況下才能被放松要求：
-- 只有在一個(gè)顯示的協(xié)議層的請(qǐng)求時(shí)，透明性才能被客戶端或源服務(wù)器放松
-- 當(dāng)出現(xiàn)一個(gè)對(duì)終端用戶的顯示的警告時(shí)，透明性才能被緩存或被客戶端放松
因此，HTTP/1.1協(xié)議提供這些重要的元素：
1．提供完整語(yǔ)義透明的協(xié)議特征，當(dāng)這些特征被通信的所有方需要時(shí)
2. 允許源服務(wù)器或用戶代理顯示的請(qǐng)求和控制不透明操作的協(xié)議特征
3. 允許緩存給這樣的響應(yīng)綁定警告信息的協(xié)議特征，這些響應(yīng)不能保留請(qǐng)求的語(yǔ)義透明的近似
一個(gè)基本的原則是客戶端必須能夠發(fā)現(xiàn)語(yǔ)義透明性的潛在的放松。
注意：服務(wù)器，緩存，或者客戶端的實(shí)現(xiàn)者可能會(huì)面對(duì)設(shè)計(jì)上的判斷，而這些判斷沒有顯示地在此規(guī)范里討論。如果一個(gè)判斷可能會(huì)影響語(yǔ)義透明性，那么實(shí)現(xiàn)者應(yīng)該能維持語(yǔ)義透明性，除非一個(gè)仔細(xì)的完整的分析能說明打破透明性的好處。
13.1.1緩存正確性（Cache Correctness）
一個(gè)正確的緩存必須能用最新的響應(yīng)來響應(yīng)請(qǐng)求，此響應(yīng)當(dāng)在下面的條件滿足時(shí)才適合此請(qǐng)求（見13.2.5，13.2.6，和13.12）?
此緩存響應(yīng)已被檢測(cè)與假設(shè)通過源服務(wù)器重驗(yàn)證后源服務(wù)器返回的響應(yīng)相等價(jià)。
此緩存響應(yīng)是足夠保鮮(fresh)的（見13.2節(jié)）。缺省的情況下，這意味著此響應(yīng)必須滿足客戶端，源服務(wù)器，和緩存的最嚴(yán)格的保鮮要求（見14.9節(jié)）；如果源服務(wù)器指定了保鮮壽命，這說明它是源服務(wù)器自己的保鮮要求。
由于客戶端和源服務(wù)器的最嚴(yán)格的保鮮要求，如果一個(gè)緩存的響應(yīng)不是足夠保鮮的，那么在仔細(xì)考慮的情況下，緩存可能仍然返回此緩存的響應(yīng)通過合適的Warning頭域（見13.1.5和14.46節(jié)），除非此響應(yīng)被阻止（例如：通過”no-store” cache-directive ，或者通過一個(gè)”no-cache”cache-request-directive；見14.9節(jié)）。
此緩存響應(yīng)是一個(gè)304（沒有被改變），305（代理重定向），或 錯(cuò)誤（4xx或者5xx）響應(yīng)消息。
如果緩存不能同源服務(wù)器通信，那么一個(gè)正確的緩存應(yīng)該用它緩存的響應(yīng)去響應(yīng)請(qǐng)求，如果此緩存的響應(yīng)能正確的服務(wù)于請(qǐng)求；如果不能服務(wù)器于此請(qǐng)求，那么緩存必須能返回一個(gè)錯(cuò)誤或警告指示存在通信失敗。
如果緩存從服務(wù)器端接收到一個(gè)響應(yīng)（或者是一個(gè)完整的響應(yīng)，或者一個(gè)304（沒有被改變）的響應(yīng)），此響應(yīng)應(yīng)該是正常情況下要發(fā)送到請(qǐng)求的客戶端的，并且此響應(yīng)并不是新鮮的，那么此緩存應(yīng)該把此響應(yīng)轉(zhuǎn)發(fā)給請(qǐng)求客戶端不需要添加一個(gè)新的Warning頭域（但是沒有移去已經(jīng)存在的Warning頭域）。緩存并不是簡(jiǎn)單的因?yàn)閭鬏斨许憫?yīng)變得陳舊而嘗試去重驗(yàn)證響應(yīng)；這可能會(huì)導(dǎo)致一個(gè)無(wú)限的循環(huán)。用戶代理接收一個(gè)陳舊的沒有Warning頭域的響應(yīng)應(yīng)該提示用戶一個(gè)警告信息。
13.1.2警告信息（Warnings）
無(wú)論何時(shí)，緩存返回一個(gè)響應(yīng)，此響應(yīng)既不是第一手的(first-hand)也不是足夠保鮮（在13.1.1節(jié)的條件2），那么緩存必須利用一個(gè)Warning常用頭域來警告產(chǎn)生的效果。Warning頭域和當(dāng)前定義的警告在14.46節(jié)里描述。這些警告允許客戶端去采取合適的動(dòng)作。
警告可能被用于其他的目的，和緩存相關(guān)的目的和其他的目的。警告和錯(cuò)誤狀態(tài)碼的區(qū)別在于是否是真正的失敗。
警告被賦予三位數(shù)字warn-codes。第一個(gè)數(shù)字指明：警告是否必須或不必須從緩存項(xiàng)里刪除，在一個(gè)成功的重驗(yàn)證之后。
1xx 警告描述了響應(yīng)的保鮮或重驗(yàn)證狀態(tài)信息，并且這些信息應(yīng)該在一個(gè)成功的重驗(yàn)證之后刪除。1xx警告碼可能是由緩存產(chǎn)生的，當(dāng)緩存驗(yàn)證一個(gè)緩存項(xiàng)時(shí)。此警告碼不能被客戶端產(chǎn)生。
2xx 警告描述了實(shí)體主體或?qū)嶓w頭域的某些方面的信息，這些信息不能被重驗(yàn)證修改，并且這些信息不能在一個(gè)成功重驗(yàn)證之后被刪除。
見14.46節(jié)關(guān)于警告碼的定義。
HTTP/1.0緩存將緩存所有響應(yīng)中的警告，并且不會(huì)刪除第一類警告。穿過HTTP/1.0緩存響應(yīng)中的警告會(huì)攜帶一個(gè)額外的warning-date域，這是為了防止將來的HTTP/1.1接收端信任一個(gè)錯(cuò)誤的緩存警告。
警告同樣攜帶一個(gè)警告文本。此文本可能是任何合適的自然語(yǔ)義（可能基于客戶端請(qǐng)求的Accept頭域），同時(shí)包含一個(gè)可選擇的關(guān)于何種字符集被使用的聲明。
多個(gè)警告可能會(huì)綁定一個(gè)響應(yīng)（或者被源服務(wù)器或者被一個(gè)緩存發(fā)送的），這包括多個(gè)警告可以共用一個(gè)警告碼。例如，服務(wù)器可能會(huì)以英語(yǔ)和法語(yǔ)提供相同的警告。
當(dāng)多個(gè)警告綁定一個(gè)響應(yīng)時(shí)，有時(shí)候不可能把所有的警告都展示給客戶。HTTP版本不能指定一個(gè)嚴(yán)格的優(yōu)先值去決定警告的優(yōu)先和順序顯示，但是可以探索一些方法。
13.1.3緩存控制機(jī)制 （Cache-control Mechanism）
HTTP/1.1基本的緩存機(jī)制（服務(wù)器指定過期時(shí)間和驗(yàn)證器）對(duì)緩存是隱含的指令。某些情況下，服務(wù)器或客戶端可能需要給HTTP緩存提供顯示的指令。我們利用Cache-Control頭域?yàn)榇四康摹?/span>
Cache-Control頭域允許客戶端或服務(wù)器在請(qǐng)求或響應(yīng)里傳輸多個(gè)指令。這些指令常常覆蓋缺省的緩存算法。作為一個(gè)常用規(guī)則，如果頭域值中存在一個(gè)明顯的沖突，那么最具嚴(yán)格解釋的頭域值會(huì)被應(yīng)用（也就是說，能保留語(yǔ)義透明性的值）。然而，一些情況下，cache-control指令被顯示地指定用來削弱語(yǔ)義透明性的相似性（例如，”max-stale” 或者 “public”）。
Cache-control指令在14.9節(jié)被描述。
13.1.4顯示的用戶代理警告（Explicit User Agent Warnings）
很多用戶代理允許用戶覆蓋基本緩存機(jī)制。例如，用戶代理可能允許用戶指定緩存實(shí)體（即使實(shí)體明顯是陳舊的）從來不要被驗(yàn)證。或者，用戶代理可能習(xí)慣于給任何請(qǐng)求加上“Cache-Control：max-stale=3600”。用戶代理不能缺省的執(zhí)行不透明行為，或者不能缺省的執(zhí)行導(dǎo)致非正常的無(wú)效率的緩存行為，但是可能被顯示地設(shè)置去這樣做通過一個(gè)顯示的用戶動(dòng)作。
如果用戶已經(jīng)覆蓋基本的緩存機(jī)制，那么用戶代理應(yīng)該給用戶指示何時(shí)顯示不能滿足服務(wù)器透明要求的信息（特別地，如果顯示的實(shí)體被認(rèn)為是陳舊的）。因?yàn)榇藚f(xié)議通常允許用戶代理去判定響應(yīng)是否是陳舊或不是陳舊的，所以此指示只需要當(dāng)實(shí)際發(fā)生時(shí)顯示。此指示不必是對(duì)話框；它應(yīng)該是一個(gè)圖標(biāo)（例如，一個(gè)正在腐爛的魚）或者一些其他的指示器。
如果用戶以一種方式已經(jīng)覆蓋了緩存機(jī)制，這種方式可能不正常地減少緩存效率，那么用戶代理應(yīng)該繼續(xù)指示用戶的狀態(tài)（例如，通過一個(gè)圖片顯示）以便用戶不能不注意地消費(fèi)過度的資源或者忍受過度的延遲。
13.1.5規(guī)則和警告的例外情況
在某些情況下，緩存的操作者應(yīng)該設(shè)置緩存返回陳舊的響應(yīng)，即使此響應(yīng)沒有被客戶端請(qǐng)求。這個(gè)判定本來不應(yīng)該輕易決定，但是由于某些原因可能會(huì)這樣做，特別是當(dāng)緩存和源服務(wù)器連接不好時(shí)。無(wú)能何時(shí)當(dāng)緩存會(huì)返回一個(gè)陳舊的響應(yīng)時(shí)，緩存必須給此響應(yīng)做個(gè)標(biāo)記（利用Warning頭域），因?yàn)檫@樣能使客戶端提示用戶響應(yīng)是陳舊的。
用戶代理照樣能采取步驟去獲得第一手的或保鮮的響應(yīng)。由于這個(gè)原因，如果客戶端顯示地請(qǐng)求第一手的或保鮮的響應(yīng)，緩存就不能返回一個(gè)陳舊的響應(yīng)，除非由于技術(shù)或策略方面的原因。
13.1.6由客戶控制的行為（Client-controlled Behavior）
當(dāng)源服務(wù)器是過期信息得主要來源時(shí)，有時(shí)候客戶端可能需要控制緩存去判定是否返回一個(gè)緩存響應(yīng)而不需要緩存通過服務(wù)器驗(yàn)證它。客戶端通過利用一些Cache-Control頭域來達(dá)到此目的。
客戶端的請(qǐng)求可能會(huì)指定自己愿意接受一個(gè)沒有驗(yàn)證的響應(yīng)的最大的年齡（age）；指定0值會(huì)強(qiáng)迫緩存重驗(yàn)證所有的響應(yīng)。客戶端照樣會(huì)指定在響應(yīng)過期前的最小保持時(shí)間。這些選項(xiàng)增加了對(duì)緩存行為的限制，同時(shí)這樣做并不能進(jìn)一步地放松緩存語(yǔ)義透明的近似。
客戶端可能照樣會(huì)指定它會(huì)接受陳舊響應(yīng)直到陳舊數(shù)達(dá)到最大數(shù)量。這放松了對(duì)緩存的限制，同時(shí)這可能違反了源服務(wù)器指定對(duì)語(yǔ)義透明性的限制，但是這可能支持無(wú)連接的操作或者高獲得性當(dāng)連接不好時(shí)。
13.2 過期模型 （Expiration Model）
13.2.1 服務(wù)器指定模型（Server-Specified Expiratiion）?
HTTP緩存會(huì)工作的很好，這是因?yàn)榫彺婺芡耆乇苊饪蛻舳藢?duì)源服務(wù)器的請(qǐng)求。避免對(duì)源服務(wù)器請(qǐng)求的主要機(jī)制是服務(wù)器將來會(huì)提供一個(gè)顯示過期時(shí)間（explicit expiration time），此顯示過期時(shí)間用來指示響應(yīng)可能會(huì)滿足后續(xù)的請(qǐng)求。也就是說，客戶端請(qǐng)求響應(yīng)時(shí)，緩存能返回一個(gè)保鮮（fresh）的響應(yīng)而不需要從源服務(wù)器那里獲得。
我們希望服務(wù)器給響應(yīng)設(shè)置顯示過期時(shí)間（explicit expiration time），服務(wù)器相信在過期時(shí)間之前實(shí)體不會(huì)改變。這能保持語(yǔ)義透明性（譯注：語(yǔ)義透明性情況1.3節(jié)里關(guān)于“語(yǔ)義透明”的解釋），只要服務(wù)器對(duì)過期時(shí)間仔細(xì)選擇。
過期機(jī)制只能應(yīng)用于能從緩存獲得的響應(yīng)，不能應(yīng)用于客戶端請(qǐng)求的第一手（first-hand，見1.3節(jié)術(shù)語(yǔ)）的響應(yīng)。
如果源服務(wù)器希望強(qiáng)制一個(gè)語(yǔ)義透明緩存去驗(yàn)證每個(gè)請(qǐng)求，它會(huì)使顯示過期時(shí)間（explicit expiration time）設(shè)為過去。這就是說響應(yīng)總是陳舊的，所以此緩存應(yīng)該驗(yàn)證此響應(yīng)當(dāng)緩存利用此響應(yīng)去服務(wù)于后續(xù)的請(qǐng)求時(shí)。見14.9.4節(jié)，有更多強(qiáng)迫重驗(yàn)證的方法
如果源服務(wù)器希望強(qiáng)迫任何HTTP/1.1緩存（不管此緩存是怎樣設(shè)置的）去驗(yàn)證每一個(gè)請(qǐng)求，源服務(wù)器應(yīng)該在Cache-Control頭域里指定“must-revalidate”緩存控制指令（見14.9節(jié)）。
源服務(wù)器利用Expires頭域或在Cache-Control頭域里通過max-age緩存控制指令，來指定顯示過期時(shí)間（explicit expiration time）。
過期時(shí)間不能被用于強(qiáng)制客戶代理去重新刷新它的顯示或重載資源；過期的語(yǔ)義只能應(yīng)用于緩存機(jī)制，并且這個(gè)機(jī)制值只需要檢測(cè)資源的過期狀態(tài)當(dāng)請(qǐng)求那個(gè)資源的一個(gè)新請(qǐng)求發(fā)生時(shí)。見13.13節(jié)，關(guān)于緩存和歷史機(jī)制的區(qū)別。
13.2.2 啟發(fā)式過期
因?yàn)樵捶?wù)器不能總是提供一個(gè)顯示過期時(shí)間（explicit expiration time），HTTP緩存通常會(huì)設(shè)置一個(gè)啟發(fā)式過期時(shí)間（heuristic expiration time），它采用一種算法，此算法利用其它的值（例如Last-Modified時(shí)間）去估計(jì)一個(gè)似乎合理的過期時(shí)間。HTTP/1.1規(guī)范沒有提供特定的算法，但是的確是加強(qiáng)了對(duì)這些算法結(jié)果的最壞情況的限制。因?yàn)閱l(fā)式過期時(shí)間可能會(huì)對(duì)語(yǔ)義透明性妥協(xié)，他們本應(yīng)該被謹(jǐn)慎地使用，并且我們鼓勵(lì)源服務(wù)器盡可能提供顯示過期時(shí)間。
13.2.3 年齡（Age）計(jì)算
為了了解緩存項(xiàng)（譯注：緩存項(xiàng)是用來響應(yīng)請(qǐng)求的，它包含緩存的響應(yīng)實(shí)體）是否是保鮮的（fresh），緩存需要知道其年齡是否已超過保鮮壽命（freshness lifetime）。我們?cè)?3.2.4節(jié)中討論如何計(jì)算保鮮壽命，本節(jié)討論如何計(jì)算響應(yīng)或緩存項(xiàng)的年齡。
在此討論中我們用“now”來表示主機(jī)進(jìn)行計(jì)算時(shí)時(shí)鐘的“當(dāng)前值”。使用HTTP協(xié)議的主機(jī)，特別是運(yùn)行于源服務(wù)器和緩存的主機(jī)，應(yīng)該使用NTP[28] 或其他類似協(xié)議來將其時(shí)鐘同步到一個(gè)全球性的精確時(shí)間標(biāo)準(zhǔn)上。
HTTP1.1協(xié)議要求源服務(wù)器盡可能在發(fā)送每條響應(yīng)時(shí)都附加一個(gè)Date頭域，要盡可能在每個(gè)響應(yīng)里給出響應(yīng)產(chǎn)生的時(shí)間（見14.18節(jié)）。我們利用術(shù)語(yǔ)“date_value”去表示Date頭域的值，這是一種適合于運(yùn)算操作的表示方法。
當(dāng)從緩存里獲取響應(yīng)消息時(shí)，HTTP/1.1利用Age響應(yīng)頭域來傳送響應(yīng)消息的估計(jì)年齡。Age響應(yīng)頭域值是緩存對(duì)響應(yīng)從產(chǎn)生或被重驗(yàn)證開始到現(xiàn)在的時(shí)間估計(jì)值。
實(shí)際上，年齡的值是響應(yīng)從源服務(wù)器途徑每一個(gè)緩存的逗留時(shí)間的總和，再加上響應(yīng)在網(wǎng)絡(luò)路徑上傳輸?shù)臅r(shí)間。
我們用“age_value”來表示Age頭域的值，這是一種適于算術(shù)操作的表示方法。
一個(gè)響應(yīng)的年齡(age)可以通過兩種完全不同的途徑來計(jì)算:：
如果本地時(shí)鐘與源服務(wù)器時(shí)鐘同步的相當(dāng)好，則用 now - date_value ，若結(jié)果為負(fù)，則取零。
如果途徑響應(yīng)路徑（response path）的所有緩存均遵循HTTP1.1協(xié)議，則用age_value。
如果我們有兩種獨(dú)立的方法計(jì)算響應(yīng)的年齡（譯注：注意這里是響應(yīng)的年齡），我們可以合并二者如下：
corrected_received_age = max（now – date_value，age_value）?
并且只要我們或者有同步的時(shí)鐘或者響應(yīng)途徑的所有緩存遵循HTTP/1.1，我們就能得到一個(gè)可信賴的結(jié)果。
由于網(wǎng)絡(luò)附加延時(shí)，一些重要時(shí)隙會(huì)在服務(wù)器產(chǎn)生響應(yīng)與下一個(gè)緩存或客戶端接收之間流逝。如果不經(jīng)修訂，這一延遲會(huì)帶來不正常的低年齡。
由于導(dǎo)致產(chǎn)生年齡值的請(qǐng)求（譯注：就是存在Age頭域的請(qǐng)求）是早于年齡值的產(chǎn)生，我們能校正網(wǎng)絡(luò)附加延遲通過記錄請(qǐng)求產(chǎn)生的時(shí)間。然后，當(dāng)一個(gè)年齡值被接收后，它必須被解釋成相對(duì)于請(qǐng)求產(chǎn)生的時(shí)間，而不是相對(duì)響應(yīng)接收的時(shí)間。不管有多少延遲，此算法會(huì)導(dǎo)致穩(wěn)定的結(jié)果。所以，我們計(jì)算：?
corrected_initial_age = corrected_received_age + （now - request_time）
這里“request_time”是請(qǐng)求的發(fā)送時(shí)間。
緩存收到響應(yīng)時(shí)，它計(jì)算響應(yīng)年齡的算法如下：
/*?
* age_value?
* is the value of Age: header received by the cache with this response.?
* date_value?
* is the value of the origin server's Date: header?
* request_time?
* is the （local） time when the cache made the request?
* that resulted in this cached response?
* response_time?
* is the （local） time when the cache received the response?
* now?
* is the current （local） time?
*/?
apparent_age = max（0, response_time - date_value）; //緩存收到響應(yīng)時(shí)響應(yīng)的年齡
corrected_received_age = max（apparent_age, age_value）;
response_delay = response_time - request_time;?
corrected_initial_age = corrected_received_age + response_delay;?
resident_time = now - response_time; //即收到響應(yīng)到現(xiàn)在的時(shí)間間隔
current_age = corrected_initial_age + resident_time;?
緩存項(xiàng)（cache entry）的current_age是緩存項(xiàng)從被源服務(wù)器最后驗(yàn)證開始到現(xiàn)在的時(shí)間間隔（以秒記）加上corrected_initial_age。當(dāng)從緩存項(xiàng)里產(chǎn)生一條響應(yīng)時(shí)，緩存必須在響應(yīng)里包含一個(gè)Age頭域，它的值應(yīng)該等于緩存項(xiàng)的current_age值。
Age頭域出現(xiàn)在響應(yīng)里說明響應(yīng)不是第一手的（first-hand）（譯注：第一手的說明，響應(yīng)是直接來自于源服務(wù)器到達(dá)接收端的，而不是來自于緩存里保存的副本）。然而相反的情況并不成立，因?yàn)轫憫?yīng)里缺少Age頭域并不能說明響應(yīng)是第一手的(fisrt-hand)，除非所有請(qǐng)求路徑上的緩存都遵循HTTP/1.1協(xié)議（也就是說，以前HTTP版本緩存沒有定義Age頭域）。?
13.2.4 過期計(jì)算（Expiration Calculations）
為了確定一條響應(yīng)是保鮮的（fresh）還是陳舊的（stale），我們需要將其保鮮壽命（freshness lifetime)和年齡(age)進(jìn)行比較。年齡的計(jì)算見13.2.3節(jié)，本節(jié)講解怎樣計(jì)算保鮮壽命，以及判定一個(gè)響應(yīng)是否已經(jīng)過期。在下面的討論中，數(shù)值可以用任何適于算術(shù)操作的形式表示。?
我們用術(shù)語(yǔ)“expires_value”來表明Expires頭域的值。我們用術(shù)語(yǔ)“max_age_value”來表示Cache-Control頭域里“max-age”控制指令的值（見14.9.3節(jié)）。
max-age指令優(yōu)于Expires頭域執(zhí)行，所以如果max-age出現(xiàn)在響應(yīng)里，那么定義如下：
freshness_lifetime = max_age_value?
否則，若Expires頭域出現(xiàn)在響應(yīng)里，定義如下：
freshness_lifetime = expires_value - date_value?
注意上述運(yùn)算不受時(shí)鐘誤差影響，因?yàn)樗行畔⒕鶃碜栽捶?wù)器。?
如果Expires， Cache-Control：max-age, 或 Cache-Control：s-maxage （見 14.9.3） 均未在響應(yīng)中出現(xiàn)，且響應(yīng)沒有包含對(duì)緩存的其他控制，那么緩存可以用啟發(fā)式算法計(jì)算保鮮壽命（freshness lifetime）。緩存器必須對(duì)年齡大于24小時(shí)的響應(yīng)附加113警告，如果此響應(yīng)不帶這種警告。
而且，如果響應(yīng)有最后修改時(shí)間，啟發(fā)式過期值應(yīng)不大于從那個(gè)時(shí)間開始間隔的某個(gè)分?jǐn)?shù)。典型設(shè)置為間隔的10% 。
計(jì)算響應(yīng)是否過期非常簡(jiǎn)單：
response_is_fresh = （freshness_lifetime > current_age）
13.2.5澄清過期值（Disambiguation Expiration Values）
由于過期值很容易被設(shè)置，有可能兩個(gè)緩存會(huì)包含同一資源的不同保鮮值。
如果客戶端執(zhí)行請(qǐng)求接收到一個(gè)非第一手的響應(yīng)，此響應(yīng)在此客戶端擁有的緩存里仍然是保鮮的，并且緩存里的緩存項(xiàng)里的Date頭域的值比此新響應(yīng)的Date頭域值要新，那么客戶端應(yīng)該忽略此響應(yīng)。如果這樣，它可能會(huì)重新以“Cache-Control：max-age=0”指令（見14.9節(jié)）請(qǐng)求去強(qiáng)制任何中間緩存通過源服務(wù)器對(duì)其進(jìn)行檢查。
如果緩存對(duì)有不同驗(yàn)證器（validator）的同一個(gè)表現(xiàn)形式（representation）有兩個(gè)保鮮響應(yīng)，那么緩存必須利用Date頭域值最近的響應(yīng)。這種情況可能發(fā)生由于緩存會(huì)從其他緩存得到響應(yīng)，或者由于客戶端請(qǐng)求對(duì)一個(gè)保鮮緩存項(xiàng)的重載或重驗(yàn)證（revalidation）。
13.2.6澄清多個(gè)響應(yīng)（Disambiguating Multiple Response）
因?yàn)榭蛻舳丝赡苁盏浇?jīng)多個(gè)路徑而來的響應(yīng)，所以有些響應(yīng)會(huì)經(jīng)過一些緩存，而其他的響應(yīng)會(huì)經(jīng)過其他的緩存，客戶端收到響應(yīng)的順序可能與源服務(wù)器發(fā)響應(yīng)的順序不同。我們希望客戶端利用最新的響應(yīng)，即使舊響應(yīng)仍然是保鮮的。
實(shí)體標(biāo)簽（entity tag）和過期值都不能影響響應(yīng)的順序，因?yàn)榭赡軙?huì)出現(xiàn)晚一點(diǎn)的響應(yīng)可能會(huì)故意攜帶過早的過期時(shí)間。日期值的精度被規(guī)定只有一秒。?
當(dāng)客戶端試著重新驗(yàn)證一個(gè)緩存項(xiàng)的時(shí)候（譯注：這里的客戶端應(yīng)該包含一個(gè)本地緩存），而且接收到的響應(yīng)的Date頭域晚于已存在的緩存項(xiàng)，那么客戶端應(yīng)該重新進(jìn)行無(wú)條件請(qǐng)求，并且包含
Cache-Control: max-age=0?
去強(qiáng)制任何中間緩存通過源服務(wù)器來驗(yàn)證（validate）這些中間緩存的副本，或者
Cache-Control: no-cache?
去強(qiáng)制任何中間緩存去從源服務(wù)器獲得一個(gè)新的副本。
13.3 驗(yàn)證模型（Validation Model）
當(dāng)緩存有一個(gè)舊緩存項(xiàng)并且緩存想利用此緩存項(xiàng)來作為客戶端請(qǐng)求的響應(yīng)時(shí)，緩存必須首先通過源服務(wù)器（或者可能通過一個(gè)有保鮮響應(yīng)的中間緩存）對(duì)其進(jìn)行檢驗(yàn)看看此緩存項(xiàng)是否可用。我們稱做“驗(yàn)證（validating）”此緩存項(xiàng)。因?yàn)槲覀儾幌雽?duì)完整響應(yīng)的傳輸付出太大代價(jià)，而且如果緩存項(xiàng)無(wú)效時(shí)也不會(huì)產(chǎn)生額外的回路（譯注：回路的意思，如：從請(qǐng)求到響應(yīng)就一條回路），HTTP1.1協(xié)議支持使用條件方法。.?
協(xié)議支持條件方法的關(guān)鍵特征是圍繞“緩存驗(yàn)證器（cache validator）”展開的。當(dāng)源服務(wù)器產(chǎn)成一個(gè)完整響應(yīng)時(shí)，它同時(shí)會(huì)附加一些驗(yàn)證器給響應(yīng)，這些驗(yàn)證器和緩存項(xiàng)一起保存。當(dāng)客戶端（用戶代理或緩存服務(wù)器）對(duì)對(duì)應(yīng)有緩存項(xiàng)的資源執(zhí)行條件請(qǐng)求時(shí)，客戶端包含一個(gè)相關(guān)的驗(yàn)證器（validator）在請(qǐng)求里。
服務(wù)器（譯注：服務(wù)器可能是緩存服務(wù)器）則核對(duì)請(qǐng)求里的驗(yàn)證器和當(dāng)前本地的驗(yàn)證器是否匹配，如果他們匹配（見13.3.3），則返回一個(gè)特定狀態(tài)碼（通常為304（沒有改變））的響應(yīng)并且此響應(yīng)不包含實(shí)體主體（entity body）。如果不匹配，服務(wù)器就返回完整響應(yīng)（包含實(shí)體主體）。這樣，我們就避免了傳輸完整響應(yīng)如果驗(yàn)證器匹配，同時(shí)我們也避免了額外的回路如果驗(yàn)證器不匹配。
在HTTP1.1協(xié)議中，一個(gè)條件請(qǐng)求和普通的請(qǐng)求差不多，除了條件請(qǐng)求攜帶一些特殊的頭域（這些頭域包含驗(yàn)證器），包含這些特殊的頭域隱含地表明請(qǐng)求方法（通常是GET方法）為條件請(qǐng)求方法。
協(xié)議中包括緩存驗(yàn)證條件的正和負(fù)。也就是說請(qǐng)求方法將會(huì)執(zhí)行如果驗(yàn)證器的匹配或不會(huì)執(zhí)行如果驗(yàn)證器不匹配。
注意：缺少驗(yàn)證器的響應(yīng)可能會(huì)被緩存，而且會(huì)被緩存用來為請(qǐng)求提供服務(wù)直到緩存的副本過期，除非顯示地用緩存控制指令來禁止緩存這樣做。然而，緩存不能執(zhí)行條件方法獲取資源如果它沒有此資源實(shí)體的驗(yàn)證器，那意味著緩存副本將會(huì)不可更新在它過期后。?
13.3.1最后修改日期 （Last-Modified Dates）
Last-Modifed實(shí)體頭域值經(jīng)常被用作一個(gè)緩存驗(yàn)證器。簡(jiǎn)而言之，緩存項(xiàng)被認(rèn)為是有效的如果實(shí)體自從Last-Modifed值之后沒有改變。?
13.3.2 實(shí)體標(biāo)簽緩存驗(yàn)證器（Entity Tag Cache Validators）
ETag響應(yīng)頭域值是實(shí)體標(biāo)簽，它提供了一個(gè)“不透明（opaque）的緩存驗(yàn)證器。這能得到更可靠的驗(yàn)證當(dāng)在不方便存放修改日期的情況下，當(dāng)在HTTP日期值的一秒精度不能滿足需要的情況下，或當(dāng)在源服務(wù)器希望避免使用修改日期產(chǎn)生的沖突的情況下。
實(shí)體標(biāo)簽在3.11節(jié)描述了。使用了實(shí)體標(biāo)簽的頭域在14.19，14.24，14.26和14.44節(jié)里描述了。
13.3.3 強(qiáng),弱驗(yàn)證器 （Weak and Strong Validators）
由于源服務(wù)器和緩存會(huì)比較兩個(gè)驗(yàn)證器來確定他們是否代表相同的實(shí)體，所以通常希望實(shí)體（entity，實(shí)體主體或?qū)嶓w頭域）發(fā)生任何變化時(shí)驗(yàn)證器也相應(yīng)變化，這樣的驗(yàn)證器為強(qiáng)驗(yàn)證器。.?
然而，可能存在這樣的請(qǐng)求，服務(wù)器傾向于僅在實(shí)體發(fā)生重要的語(yǔ)義變化時(shí)才改變驗(yàn)證器，而在實(shí)體的某些方面不發(fā)生重大改變時(shí)就不改變驗(yàn)證器。在資源變化時(shí)驗(yàn)證器未必變化的稱為弱驗(yàn)證器.。
實(shí)體標(biāo)簽通常是強(qiáng)驗(yàn)證器，但協(xié)議提供一種機(jī)制來使實(shí)體標(biāo)簽變成弱驗(yàn)證器。可以認(rèn)為強(qiáng)驗(yàn)證器在實(shí)體的每一字節(jié)變化時(shí)而變化，而弱驗(yàn)證器僅在實(shí)體的語(yǔ)義變化時(shí)才變化。換言之，我們能認(rèn)為強(qiáng)驗(yàn)證器是特定實(shí)體的標(biāo)識(shí)，而弱驗(yàn)證器是同一類語(yǔ)義等價(jià)實(shí)體的標(biāo)識(shí)。
注: 強(qiáng)驗(yàn)證器的例子：一個(gè)整數(shù)他會(huì)隨著每次實(shí)體發(fā)生變化而遞增。一個(gè)實(shí)體的修改時(shí)間，如果以秒為精度，能被當(dāng)作弱驗(yàn)證器，因?yàn)樵谝幻雰?nèi)資源可能改變兩次。是否支持弱驗(yàn)證器是選擇的。然而，弱驗(yàn)證器可以能高效的去緩存等效對(duì)象。
.?
客戶端產(chǎn)生請(qǐng)求并把驗(yàn)證器包含在一個(gè)驗(yàn)證頭域里的時(shí)候或在服務(wù)器比較兩個(gè)驗(yàn)證器的時(shí)候均用到驗(yàn)證器。強(qiáng)驗(yàn)證器可在任何情況下使用，而弱驗(yàn)證器僅在不依賴嚴(yán)格相等時(shí)才可用。當(dāng)客戶端產(chǎn)生條件GET請(qǐng)求來請(qǐng)求一個(gè)完整實(shí)體時(shí)，任何類型的驗(yàn)證器都可以使用。然而，子范圍（sub-range）請(qǐng)求時(shí)只能使用強(qiáng)驗(yàn)證器，因?yàn)榭蛻舳丝赡軙?huì)得到一個(gè)不一致的實(shí)體。
客戶端可以在發(fā)出簡(jiǎn)單（非子范圍）GET請(qǐng)求里既可以包含弱驗(yàn)證器也可以包含強(qiáng)驗(yàn)證器。客戶端不能利用弱驗(yàn)證器在其它的請(qǐng)求形式里。
HTTP1.1協(xié)議定義驗(yàn)證的唯一功能就是比較。有兩種驗(yàn)證器的比較方法，這依賴于是否能利用弱驗(yàn)證器進(jìn)行比較。
.?
- 強(qiáng)比較方法：在考慮相等的情況下，兩驗(yàn)證器必須完全一致，并且兩個(gè)驗(yàn)證器都是強(qiáng)驗(yàn)證器。.?
- 弱比較方法：在考慮相等的情況下，兩驗(yàn)證器必須完全一致，但至少有一個(gè)驗(yàn)證器可能在不影響結(jié)果的情況下被標(biāo)明為“weak”。
實(shí)體標(biāo)簽是強(qiáng)驗(yàn)證器除非它被顯示地標(biāo)記為弱(weak)的。3.11節(jié)給出了實(shí)體標(biāo)簽的語(yǔ)法。
最后修改時(shí)間（譯注：Last-Modifed頭域的值）被用作請(qǐng)求的驗(yàn)證器時(shí)默認(rèn)為弱驗(yàn)證器，,除非滿足下列規(guī)則才判定它是強(qiáng)驗(yàn)證器：.?
- 驗(yàn)證器被源服務(wù)器用來和當(dāng)前實(shí)體的驗(yàn)證器進(jìn)行比較并且源服務(wù)器知道相關(guān)的實(shí)體不會(huì)在當(dāng)前驗(yàn)證器函蓋的秒數(shù)內(nèi)改變兩次，
或者
- 驗(yàn)證器可能被客戶端用于If-Modified-Since 或者 If-Unmodified-Since頭域里，因?yàn)榭蛻舳擞幸粋€(gè)關(guān)于此實(shí)體的緩存項(xiàng)，并且
- 緩存項(xiàng)包含一個(gè)日期值，此日期值給出了源服務(wù)器發(fā)送源響應(yīng)（譯注：源服務(wù)器產(chǎn)生的響應(yīng)）的時(shí)間，并且
- Last-Modifed頭域值至少提前于日期值（Date頭域值）60秒。?
或者
- 驗(yàn)證器已經(jīng)被中間緩存同此實(shí)體的緩存項(xiàng)里的驗(yàn)證器比較過 ，并且
- 緩存項(xiàng)包含日期值（Date頭域值），此日期值指明了源服務(wù)器發(fā)送源響應(yīng)的時(shí)間，并且
- Last-Modifed頭域值至少提前于日期值（Date頭域值）60秒。
此種方法依賴于以下事實(shí)，如果兩個(gè)響應(yīng)被服務(wù)器在同一秒內(nèi)被發(fā)出，但這兩個(gè)響應(yīng)都有相同的最后修改（Last-Modified）時(shí)間，那么至少有一個(gè)響應(yīng)的日期值（譯注：Date頭域的值）和最后修改時(shí)間值（Last-Modifed頭域的值）是相等的。60秒的限制能保證Date和Last-Modifed頭域的值在不同時(shí)刻產(chǎn)生。一個(gè)實(shí)現(xiàn)可能會(huì)利用大于60秒的值，如果它認(rèn)為60秒太短。
如果客戶端希望執(zhí)行子范圍(sub-range)請(qǐng)求來請(qǐng)求一個(gè)只有最后修改（Last-Modifed）時(shí)間和而沒有透明驗(yàn)證器的值時(shí)，它可能會(huì)認(rèn)為只有最后修改（Last-Modified）時(shí)間是強(qiáng)的。
若緩存或源服務(wù)器收到一個(gè)條件請(qǐng)求，而不是得到完整響應(yīng)的GET請(qǐng)求時(shí)，他必須使用強(qiáng)比較方法去計(jì)算此條件。
此規(guī)定允許HTTP1.1的,緩存和客戶端安全地執(zhí)行子范圍（sub-range）請(qǐng)求來請(qǐng)求從HTTP/1.0得來的值。?
13.3.4 關(guān)于何時(shí)使用實(shí)體標(biāo)簽和最后修改時(shí)間的規(guī)則
我們對(duì)源服務(wù)器，客戶端和緩存采用一套規(guī)則和建議來規(guī)定不同的驗(yàn)證器何時(shí)應(yīng)該被使用，出
于何種目的被使用。
HTTP/1.1 源服務(wù)器：
- 應(yīng)該發(fā)送一個(gè)實(shí)體標(biāo)簽驗(yàn)證器除非源服務(wù)器產(chǎn)生這樣一個(gè)實(shí)體標(biāo)簽不可行。
- 可能會(huì)發(fā)送弱實(shí)體標(biāo)簽而不是強(qiáng)實(shí)體標(biāo)簽，如果使用弱實(shí)體標(biāo)簽?zāi)芴岣咝阅艿脑捇蛘呷绻l(fā)送一個(gè)強(qiáng)實(shí)體標(biāo)簽不可行的情況下。
- 應(yīng)該發(fā)送一個(gè)Last-Modifed值如果可行的話，除非打破語(yǔ)義透明性（這可能由利用If-Modified-Since頭域里的日期產(chǎn)生）可能會(huì)導(dǎo)致嚴(yán)重的后果。
換句話說，對(duì)http1.1源服務(wù)器來說，比較好的做法是同時(shí)發(fā)送強(qiáng)實(shí)體標(biāo)簽和Last-Modified值。.?
為了合法，強(qiáng)實(shí)體標(biāo)簽必須隨相關(guān)聯(lián)的實(shí)體值改變而改變。弱實(shí)體標(biāo)簽應(yīng)該隨相關(guān)聯(lián)的實(shí)體在語(yǔ)義上發(fā)生改變而改變。
注意：為保證語(yǔ)義透明緩存，源服務(wù)器必須避免為兩個(gè)不同的實(shí)體重復(fù)利用一個(gè)特定的強(qiáng)實(shí)體標(biāo)簽值。緩存項(xiàng)應(yīng)該能保持任意長(zhǎng)的時(shí)間，而不管過期時(shí)間（expiraton time），所以緩存可能會(huì)再去嘗試去利用在過去某一時(shí)刻獲得的驗(yàn)證器去驗(yàn)證緩存項(xiàng)。?
HTTP/1.1 客戶端：?
- 若實(shí)體標(biāo)簽被源服務(wù)器提供，HTTP/1.1客戶端必須在任何緩存條件請(qǐng)求（利用了If-Match或If-None-Match的請(qǐng)求）里利用實(shí)體標(biāo)簽.。
- 僅當(dāng)Last-Modified值被源服務(wù)器提供時(shí)，HTTP/1.1客戶端應(yīng)該在非子范圍緩存條件請(qǐng)求（利用If-Modified-Since）里利用此值。?
- 僅當(dāng)Last-Modified值被HTTP/1.0源服務(wù)器提供，HTTP/1.1客戶端可能會(huì)在子范圍緩存條件請(qǐng)求（利用了If-Unmodified-Since）里利用此值。
- 如果一個(gè)實(shí)體標(biāo)簽和Last-Modified值被源服務(wù)器提高，HTTP/1.1客戶端應(yīng)該在緩存條件請(qǐng)求里利用這兩個(gè)驗(yàn)證器。這允許HTTP/1.1和HTTP/1.1緩存能合適地進(jìn)行響應(yīng)。?
HTTP/1.1源服務(wù)器，當(dāng)接收到一個(gè)條件請(qǐng)求并且此請(qǐng)求同時(shí)包含Last-Modifed日期（例如，在If-Modified-Since，或If-Unmodified-Since頭域里）和一個(gè)或多個(gè)實(shí)體標(biāo)簽（例如在If-Match，If-None=Match，或If-Range頭域里）作為緩存驗(yàn)證器時(shí)，源服務(wù)器不能返回一個(gè)304狀態(tài)響應(yīng)（Not Modified）除非這樣做能當(dāng)當(dāng)前實(shí)體的驗(yàn)證器和請(qǐng)求里所有的條件頭域里的驗(yàn)證器一致。
HTTP/1.1緩存服務(wù)器，當(dāng)接收到一個(gè)條件請(qǐng)求并且此請(qǐng)求里同時(shí)包含Last-Modified日期和一個(gè)或多個(gè)實(shí)體標(biāo)簽作為緩存驗(yàn)證器時(shí)，它不能返回一個(gè)本地的副本給客戶端除非那個(gè)副本的驗(yàn)證器和所有請(qǐng)求里條件頭域里的驗(yàn)證器一致。
注意：這些規(guī)則背的常用的原則是HTTP/1.1服務(wù)器和客戶端應(yīng)該在請(qǐng)求和響應(yīng)里盡可能傳輸非冗余的信息。接收這些非冗余信息的HTTP/1.1系統(tǒng)將會(huì)假設(shè)它接收了驗(yàn)證器。
HTTP/1.0客戶端和緩存將會(huì)忽略實(shí)體標(biāo)簽。通常，Last-Modified值被這些系統(tǒng)接收后將會(huì)保證透明和高效的緩存行為，所以HTTP/1.1源服務(wù)器這時(shí)將會(huì)提供Last-Modified值。在這些情況下，當(dāng)HTTP/1.0系統(tǒng)利用一個(gè)Last-Modified值作為一個(gè)驗(yàn)證器可能會(huì)帶來嚴(yán)重的后果時(shí)，HTTP/1.1服務(wù)器將不會(huì)提供Last-Modified值。
13.3.5非驗(yàn)證條件（Non-validating Conditionls）
實(shí)體標(biāo)簽背后的原則是只有服務(wù)的作者才知道資源的語(yǔ)義而去選擇一個(gè)合適的緩存驗(yàn)證機(jī)制，并且任何驗(yàn)證器比較方法的標(biāo)準(zhǔn)都可能會(huì)帶來風(fēng)險(xiǎn)。所以，任何其他的頭域的比較（除了Last-Modified，為了兼容HTTP/1.0）從來不會(huì)被用于驗(yàn)證緩存項(xiàng)。
13.4 響應(yīng)的可緩存性（Response Cacheability）
除非被緩存控制（見14.9節(jié)）指令明確地限制，緩存系統(tǒng)可以將一成功的響應(yīng)作為緩存項(xiàng)，可以返回緩存項(xiàng)里的響應(yīng)副本而不需要驗(yàn)證它如果此副本是保鮮的，并且也可以在驗(yàn)證成功后返回它。如果既沒有和響應(yīng)相關(guān)的緩存驗(yàn)證器也沒有和響應(yīng)相關(guān)的顯示過期時(shí)間（explicit expiration time，譯注：見13.3.1節(jié)里關(guān)于什么是顯示過期時(shí)間的說明），我們不會(huì)認(rèn)為它是可緩存的，但是某些緩存可能會(huì)違反這個(gè)期望（例如，當(dāng)不能進(jìn)行網(wǎng)絡(luò)連接時(shí)）。客戶端能經(jīng)常發(fā)現(xiàn)從緩存里獲得的響應(yīng)，只需要通過把Date頭域值同當(dāng)前時(shí)間作比較。
注意：某些HTTP1.0緩存可能違反這一期望而不提示警告。
還有,某些情況下可能不便保留一實(shí)體,或?qū)⑵浞祷亟o后續(xù)請(qǐng)求.?
然而，在一些情況下，緩存不適合保存一個(gè)實(shí)體，或者不適合把它放于后續(xù)請(qǐng)求的響應(yīng)里。這可能因?yàn)榉?wù)作者認(rèn)為完全語(yǔ)義透明性是有必要的，或著因?yàn)榘踩碗[私的考慮。某些緩存控制指令是為了讓服務(wù)器能指明某些資源實(shí)體或其中的一部分不能被緩存。
注意在14.8節(jié)里描述了防止一個(gè)共享緩存去保存和返回一個(gè)以前請(qǐng)求的響應(yīng)，如果那個(gè)請(qǐng)求包含一個(gè)Authorization頭域。
除非緩存控制指令防止此響應(yīng)被緩存，一個(gè)接收的響應(yīng)如果它的狀態(tài)碼是200，203，206，300，301或410，那么此響應(yīng)應(yīng)該被緩存保存而且可用于后續(xù)的請(qǐng)求，但這必須受限于過期機(jī)制（expiration mechanism）。然而，緩存如果不支持Range和Content-Range頭域，那么它不能緩存206響應(yīng)（部分內(nèi)容）響應(yīng)。
接收到的響應(yīng)如果是其他的狀態(tài)碼（如，302和307），那么此響應(yīng)不能被用于服務(wù)于后續(xù)的請(qǐng)求，除非緩存控制指令或其他的頭域明確地允許它能這樣做。例如，這些頭域包含下面的頭域：Expires頭域（見14.21）；“max-age”，“s-maxage”，“must-revalidate”，“prox-revalidate”，“public”或“private”緩存控制指令（見14.9）。
13.5 從緩存里構(gòu)造響應(yīng)
緩存的目的是存儲(chǔ)請(qǐng)求的響應(yīng)信息，為了響應(yīng)將來的請(qǐng)求。在很多情況下，緩存能返回響應(yīng)的合適部分給請(qǐng)求者。然而，如果緩存擁有一個(gè)基于以前響應(yīng)的緩存項(xiàng)，它可能必須把新響應(yīng)的部分和它緩存項(xiàng)里的內(nèi)容合起來。
13.5.1End-to-end和Hop-by-hop頭域
為定義緩存和非緩存代理服務(wù)器的行為，我們將HTTP頭域分成兩類：
- end-to-end頭域，他們被傳輸給最終請(qǐng)求或響應(yīng)的接收者。響應(yīng)里end-to-end頭域必需作為緩存項(xiàng)的一部分存儲(chǔ)，并且必須在從緩存項(xiàng)形成的響應(yīng)里傳輸。
- hop-by-hop頭域，他們被只對(duì)傳輸層上的連接有意義，并且不能被緩存保存或被代理轉(zhuǎn)發(fā)。
下面的HTTP/1.1頭域是hop-by-hop頭域：
- Connection
- Keep-Alive
- Proxy-Authenticate
- Proxy-Authorization
- TE
- Trailers
- Transfer-Encoding
- Upgrade
所有其他被HTTP/1.1定義的頭域均為end-to-end頭域。
13.5.2不可更改的頭域 （Non-modifiable Headers）
HTTP1.1的某些特征，如數(shù)字認(rèn)證，基于某一些end-to-end頭域。一個(gè)透明代理不應(yīng)該改變end-to-end頭域，除非這些頭域的定義要求或允許它這樣做。
一個(gè)透明代理（譯注：代理一般是緩存，緩存可以叫緩存代理，緩存服務(wù)器，代理服務(wù)器）不能改變請(qǐng)求或響應(yīng)里的下面的頭域，而且它不能添加這些頭域到?jīng)]有這些頭域的請(qǐng)求或響應(yīng)里：
- Contents-location
- Content-MD5
- ETag
- Last-Modified
一個(gè)透明代理不能改變響應(yīng)里下面的的頭域：?
- Expires?
但它可以添加這些頭域如果響應(yīng)里沒有這些頭域的時(shí)候。如果一個(gè)Expires頭域被添加，它必須等于響應(yīng)里Date頭域的值。
一個(gè)代理（譯注：緩存就是一個(gè)代理，我們一般稱做緩存代理，或緩存服務(wù)器，或緩存代理服務(wù)器，都是一個(gè)意思）不能在消息中改變或添加下面的頭域如果此消息包含no-transform緩存控制指令，或在任何請(qǐng)求里也不能添加或改變這些頭域。
- Content-Encoding?
- Content-Range?
- Content-Type?
一個(gè)非透明代理可能會(huì)改變或添加這些頭域給一個(gè)消息如果此消息不包含no-transform緩存控制指令，但是如果代理這樣做了，它必須添加一個(gè)警告214（轉(zhuǎn)換被應(yīng)用）（見14.46節(jié)）。
警告：end-to-end頭域的不必要的改變可能會(huì)導(dǎo)致認(rèn)證機(jī)的失敗如果更強(qiáng)的認(rèn)證機(jī)制被應(yīng)用于后續(xù)的HTTP版本中。此認(rèn)證機(jī)制可能依賴于沒有在此出現(xiàn)的頭域值。
請(qǐng)求或響應(yīng)里的Content-Length頭域被添加或被刪除會(huì)根據(jù)4.4節(jié)的規(guī)則。一個(gè)透明代理必須保留實(shí)體主體的entity-length（見7.2.2），盡管它可以可能改變transfer-length（4.4節(jié)）。
13.5.3聯(lián)合頭域（Combining Headers）
當(dāng)一個(gè)緩存對(duì)服務(wù)器發(fā)出驗(yàn)證請(qǐng)求時(shí)，而且服務(wù)器提供304（沒有改變）響應(yīng)或206（部分內(nèi)容）響應(yīng)時(shí)，那么緩存將構(gòu)造一個(gè)響應(yīng)發(fā)送給請(qǐng)求客戶端。
如果狀態(tài)碼是304（沒有改變），緩存利用緩存項(xiàng)里的實(shí)體主體（entity-body）作為客戶端請(qǐng)求響應(yīng)的實(shí)體主體。如果響應(yīng)狀態(tài)碼是206（部分內(nèi)容）并且Etag或Last-Modified頭域能精確匹配，那么緩存可能把存入緩存項(xiàng)里的內(nèi)容和接收到的響應(yīng)里的新內(nèi)容合并并且利用最后合并的結(jié)果作為輸出響應(yīng)（見13.5.4）。
存儲(chǔ)于緩存項(xiàng)里端end-to-end頭域被用于構(gòu)造響應(yīng)，除了：
- 任何存儲(chǔ)的警告碼是1xx（見14.46）Warning頭域必須從緩存項(xiàng)和轉(zhuǎn)發(fā)的響應(yīng)里刪除。
- 任何存儲(chǔ)的警告碼是2xx的Warning頭域必須要在緩存項(xiàng)和轉(zhuǎn)發(fā)的響應(yīng)里保留。
- 任何在304或206響應(yīng)里的end-to-end頭域必須替換緩存項(xiàng)里相應(yīng)的頭域
除非緩存決定去刪除緩存項(xiàng)，否則它必須照樣能用接收的響應(yīng)里的相應(yīng)的end-to-end頭域去替換存儲(chǔ)在緩存項(xiàng)里的頭域，除了上面描述的Warning頭域。如果輸入響應(yīng)里的一個(gè)頭域匹配緩存項(xiàng)里多個(gè)頭域，那么所有這些舊的頭域必須被替換。
從另一方面說，輸入響應(yīng)的所有end-to-end頭域會(huì)覆蓋緩存項(xiàng)里所有相應(yīng)的end-to-end頭域（除了緩存的警告碼是1xx的Warning頭域，它將會(huì)被刪除即使沒有被覆蓋）。
注意：此規(guī)則允許源服務(wù)器去利用304（沒有改變）或一個(gè)206（部分內(nèi)容）響應(yīng)去更新任何同一實(shí)體或?qū)嶓w的子范圍的以前響應(yīng)的頭域，雖然它可能沒有意義或這樣做不正確。這條規(guī)則不允許源服務(wù)器去利用304（沒有改變）或206（部分內(nèi)容）響應(yīng)去完全地刪除一個(gè)以前響應(yīng)的頭域。
13.5.4聯(lián)合字節(jié)范圍（Combing Byte Ranges）
一條響應(yīng)可能僅傳送一個(gè)實(shí)體主體的某一部分，這是由于請(qǐng)求包含一個(gè)或多個(gè)Range指定的范圍，或者由于連接會(huì)被過早地?cái)嚅_。在幾次這樣得傳輸后，緩存可能已經(jīng)接收了同一個(gè)實(shí)體主體的多個(gè)范圍部分。
如果緩存有一個(gè)實(shí)體的非空子范圍，并且一個(gè)輸入（incoming）響應(yīng)（譯注：輸入響應(yīng)是進(jìn)入緩存的響應(yīng)，輸出響應(yīng)是從緩存出去的響應(yīng)）攜帶了另一個(gè)子范圍，那么緩存可能會(huì)把新的子范圍和已經(jīng)存在的子范圍聯(lián)合起來如果兩者遵循下面的規(guī)則：
- 輸入響應(yīng)和緩存項(xiàng)都有緩存驗(yàn)證器。
- 當(dāng)利用強(qiáng)比較方法的時(shí)候，兩個(gè)緩存驗(yàn)證器完全匹配（見13.3.3）。
如果任何一個(gè)要求不能滿足，緩存必須利用最近的部分響應(yīng)（這基于任何響應(yīng)的Date頭域值，并且會(huì)利用輸入響應(yīng)如果這些Date頭域值相等或丟失了），而且必須丟棄其他的部分信息。
13.6 緩存已經(jīng)協(xié)商過的響應(yīng)（Caching Negotiated Responses）
在Vary頭域出現(xiàn)在響應(yīng)里的時(shí)候，服務(wù)器驅(qū)動(dòng)內(nèi)容協(xié)商（12.1節(jié)）的使用會(huì)改變緩存利用響應(yīng)去響應(yīng)后續(xù)請(qǐng)求利用的條件和過程。見14.44節(jié)關(guān)于服務(wù)器利用Vary頭域的描述。
服務(wù)器應(yīng)該利用Vary頭域去通知一個(gè)緩存什么樣的請(qǐng)求頭域應(yīng)該被使用從而從一個(gè)可緩存的并受限于服務(wù)器驅(qū)動(dòng)協(xié)商的響應(yīng)的多個(gè)表現(xiàn)形式中選擇合適的表現(xiàn)形式。Vary頭域里指定的頭域被稱做選擇請(qǐng)求頭域（selecting request-header）。
當(dāng)緩存接收到一個(gè)后續(xù)的請(qǐng)求，此請(qǐng)求的URI對(duì)應(yīng)一個(gè)或多個(gè)包含了Vary頭域的緩存項(xiàng)時(shí)，此緩存不能利用這樣一個(gè)緩存項(xiàng)去構(gòu)造出一個(gè)響應(yīng)去服務(wù)于新來的請(qǐng)求，除非所有出現(xiàn)在新請(qǐng)求里的選擇請(qǐng)求頭域匹配存儲(chǔ)在源請(qǐng)求里被存儲(chǔ)的請(qǐng)求頭域。
在兩個(gè)請(qǐng)求里，我們定義這兩個(gè)選擇請(qǐng)求頭域匹配，如果并且只有第一個(gè)請(qǐng)求的選擇請(qǐng)求頭域能被轉(zhuǎn)換為第二個(gè)請(qǐng)求里的頭域通過添加或刪除線性空白（被允許出現(xiàn)在相應(yīng)的BNF里的線性空白）和/或把多個(gè)消息頭域結(jié)合成一個(gè)頭域通過4.2節(jié)里的規(guī)則。
一個(gè)Vary頭域值是“*”總是不能匹配的，并且后續(xù)那個(gè)資源的請(qǐng)求只能合適地被源服務(wù)器解析。
如果緩存項(xiàng)里的選擇請(qǐng)求頭域（selecting request-header）不能匹配新請(qǐng)求的選擇請(qǐng)求頭域，那么緩存不能利用緩存項(xiàng)去滿足請(qǐng)求除非它能以一個(gè)條件請(qǐng)求把此新請(qǐng)求接力到源服務(wù)器并且此源服務(wù)器以一個(gè)304（沒有改變）的狀態(tài)碼進(jìn)行響應(yīng)并包含一個(gè)實(shí)體標(biāo)簽或者Content-Location頭域指明將要被使用的實(shí)體。
如果一個(gè)實(shí)體標(biāo)簽被賦予一個(gè)緩存的表現(xiàn)形式，那么此轉(zhuǎn)發(fā)的請(qǐng)求將是條件的并且所有那個(gè)資源的緩存項(xiàng)的實(shí)體標(biāo)簽將會(huì)被包含于If-None-Match頭域里。這向服務(wù)器表達(dá)當(dāng)前緩存擁有的實(shí)體集，以至于如果這些實(shí)體里的任何實(shí)體匹配請(qǐng)求的實(shí)體，服務(wù)器會(huì)利用Etag頭域在304（沒有改變）響應(yīng)里去告訴緩存哪個(gè)緩存項(xiàng)是合適的。如果新響應(yīng)的實(shí)體標(biāo)簽匹配已經(jīng)存在的緩存項(xiàng)，那么新響應(yīng)應(yīng)該被利用去更新已經(jīng)存在的緩存項(xiàng)的頭域，而且此結(jié)果必須返回給客戶端。
如果任何已經(jīng)存在的緩存項(xiàng)包含只有相關(guān)實(shí)體的部分內(nèi)容，那么此實(shí)體的實(shí)體標(biāo)簽不應(yīng)該被包含在If-None-Match頭域里除非這個(gè)請(qǐng)求是為了請(qǐng)求實(shí)體的一個(gè)范圍，此范圍完全可以被緩存項(xiàng)滿足。
如果緩存接收到一個(gè)成功的響應(yīng)，此響應(yīng)的Content-Location頭域匹配于已經(jīng)存在的緩存項(xiàng)的Content-Location頭域?qū)ν徽?qǐng)求URI來說，并且此響應(yīng)的實(shí)體標(biāo)簽不同于已經(jīng)存在的緩存項(xiàng)的實(shí)體標(biāo)簽，而且此響應(yīng)的Date頭域值比已經(jīng)存在的緩存項(xiàng)更近，那么已經(jīng)存在的緩存項(xiàng)不能被返回去響應(yīng)將來的請(qǐng)求并且將會(huì)從緩存里刪除。
13.7 共享和非共享緩存 （Shared and Non-Shared Caches）
出于安全和保密考慮，有必要區(qū)分共享和非共享緩存。非共享緩存是僅供一個(gè)用戶使用的緩存，此種情況下，可用性由適當(dāng)?shù)陌踩珯C(jī)制控制。所有其它的緩存均被認(rèn)為是共享緩存。此協(xié)議的其它部分給一些對(duì)共享緩存的限制以防止隱私丟失或訪問控制的失敗。
13.8 錯(cuò)誤和不完全的響應(yīng)緩存行為
緩存收到不完整響應(yīng)（例如響應(yīng)的字節(jié)數(shù)比Content-Length頭域指定的值要小）也可以存儲(chǔ)它，但是必須把它看作部分響應(yīng)。部分相應(yīng)可以合并（見13.5.4）；合并結(jié)果可能是完整的響應(yīng)或可能仍是部分的響應(yīng)。.緩存不能把部分響應(yīng)返回給客戶端除非有明確要求可以這樣做例如利用206（部分內(nèi)容）狀態(tài)碼響應(yīng)。緩存不能使用一個(gè)200（OK）狀態(tài)碼返回一個(gè)部分響應(yīng)。
如果緩存在試圖重驗(yàn)證一個(gè)緩存項(xiàng)而收到一個(gè)5xx響應(yīng)時(shí)，它既可以將此響應(yīng)轉(zhuǎn)發(fā)給請(qǐng)求的客戶端，或者做的就像服務(wù)器不能響應(yīng)似的。在后面的情況下，它可能返回一個(gè)以前的接收的響應(yīng)除非緩存項(xiàng)包含一個(gè)“must-revalidate”緩存控制指令（見14.9節(jié)）。
13.9 GET 和 HEAD 的副作用（Side Effects of GET and HEAD）
除非源服務(wù)器明確地禁止緩存保存它們的響應(yīng)，對(duì)任何資源應(yīng)用的GET和HEAD方法不應(yīng)該有副作用，這些副作用會(huì)導(dǎo)致錯(cuò)誤的行為如果這些響應(yīng)將從緩存產(chǎn)生。他們可能會(huì)仍然有副作用，但緩存在決定緩存時(shí)不必考慮這些副作用。緩存總是期望去觀察一個(gè)源服務(wù)器對(duì)緩存的明確限制。
一個(gè)例外：有些應(yīng)用習(xí)慣于在在GETs和HEADs方法里使用查詢URLs（在rel_path_part里包含一個(gè)“?”）去執(zhí)行一個(gè)操作而帶來很大的副作用，緩存不能把此URIs的響應(yīng)看作一個(gè)保鮮的除非服務(wù)器提供一個(gè)顯示過期時(shí)間（explicit expiration time）。這意味著此URIs的以前從HTTP/1.0服務(wù)器產(chǎn)生的響應(yīng)不能來自于緩存。見9.1.1節(jié)相關(guān)的信息。
13.10 在更新或刪除后的無(wú)效性
對(duì)源服務(wù)器上的某資源執(zhí)行方法的副作用可能會(huì)使一個(gè)或多個(gè)已經(jīng)存在的緩存項(xiàng)的不透明性無(wú)效。那就是說，雖然他們可能會(huì)繼續(xù)是保鮮的，但是他們不能準(zhǔn)確的反應(yīng)出源服務(wù)器將會(huì)對(duì)這一個(gè)新的請(qǐng)求返回什么。
HTTP協(xié)議無(wú)法保證所有此類緩存項(xiàng)均被標(biāo)明無(wú)效。例如，引起源服務(wù)器上資源變化的請(qǐng)求可能不會(huì)穿過存有一個(gè)緩存項(xiàng)的代理。然而，一些規(guī)則幫助減少錯(cuò)誤行為的可能。
在此節(jié)里，短語(yǔ)“使實(shí)體無(wú)效”意味著緩存會(huì)將所有那個(gè)實(shí)體的實(shí)例從它的存儲(chǔ)里移除，或者把這些實(shí)體的實(shí)例標(biāo)記為“無(wú)效的”并且在他們可能作為后續(xù)請(qǐng)求的響應(yīng)時(shí)會(huì)被進(jìn)行重驗(yàn)證。?
一些HTTP方法必須讓緩存去使一個(gè)實(shí)體無(wú)效 。這些實(shí)體被請(qǐng)求URI指定，或在Location或在Content-Location頭域里被指定（如果出現(xiàn)的話）。這些方法是：
- PUT
- DELETE
- POST
為了防止服務(wù)器攻擊拒絕，一個(gè)基于Location或Content-Location頭域里的URI的無(wú)效性處理必須只有在host部分和請(qǐng)求URI里的host部分相同時(shí)才被執(zhí)行。?
一個(gè)緩存如果不能理解請(qǐng)求里的方法，那么它應(yīng)該使請(qǐng)求URI指定的任何實(shí)體無(wú)效。
13.11 強(qiáng)制寫通過（ Write-Through Mandatory）
所有可能對(duì)源服務(wù)器資源進(jìn)行修改的方法都要寫通過給源服務(wù)器（譯注：直接穿過緩存在服務(wù)器上修改）。這通常包括所有方法除了GET和HEAD方法。緩存在將此種請(qǐng)求轉(zhuǎn)發(fā)給服務(wù)器并獲得相應(yīng)的響應(yīng)前不能對(duì)請(qǐng)求客戶端做出響應(yīng)。 這個(gè)不能防止代理緩存（譯注：也可以叫緩存服務(wù)器，緩存）在服務(wù)器已經(jīng)發(fā)送最終回復(fù)之前發(fā)送100（繼續(xù)）響應(yīng)。
相反情況（通常叫“寫回”或“拷貝回”緩存）在HTTP1.1中是不允許的，這是由于提供一致更新非常困難，并且服務(wù)器，緩存和網(wǎng)絡(luò)的故障會(huì)出現(xiàn)在比寫回早。?
13.12 緩存替換 （Cache Replacement）
如果一個(gè)新的可緩存的響應(yīng)被緩存接收，同時(shí)對(duì)這一資源的響應(yīng)已經(jīng)在緩存里存在，那么緩存應(yīng)該利用最新的響應(yīng)去回復(fù)當(dāng)前的請(qǐng)求。緩存可能會(huì)把此新響應(yīng)放進(jìn)存儲(chǔ)里，并且如果它滿足所有其他的要求，緩存將會(huì)利用此響應(yīng)來響應(yīng)任何將來的請(qǐng)求。如果緩存想把此新的響應(yīng)加進(jìn)緩存的存儲(chǔ)，13.5.3的規(guī)則必須應(yīng)用。
說明：一個(gè)新響應(yīng)如果它的Date頭域值比已經(jīng)存在的緩存響應(yīng)的Date頭域值老，那么它是不能緩存的。
13.13 歷史列表 （History Lists）
用戶代理經(jīng)常使用歷史機(jī)制，如“Back”按鈕和歷史列表，來重新展示在一個(gè)會(huì)話里接收的一個(gè)稍早的實(shí)體。
歷史機(jī)制和緩存機(jī)制是不同。歷史機(jī)制不應(yīng)該嘗試展示一個(gè)當(dāng)前資源狀態(tài)的語(yǔ)義透明視圖。其歷史機(jī)制只是為了展示在獲得資源時(shí)看到了什么。
默認(rèn)情況，一個(gè)過期時(shí)間不會(huì)應(yīng)用于一個(gè)歷史機(jī)制。如果實(shí)體仍然在存儲(chǔ)里，歷史機(jī)制應(yīng)該顯示它即使實(shí)體過期了，除非用戶叫用戶代理去刷新過期的文檔。
這不能被解釋去防止歷史機(jī)制告訴用戶視圖可能過期了。?
注意：如果歷史機(jī)制沒必要地防止了用戶看陳舊的資源，那么這會(huì)強(qiáng)制服務(wù)作者去避免利用HTTP過期控制和緩存控制。服務(wù)作者可能會(huì)認(rèn)為這是非常重要的當(dāng)用戶沒有被呈現(xiàn)錯(cuò)誤消息或警告消息當(dāng)他們利用導(dǎo)向按鈕（如BACK按鈕）去看以前獲得的資源時(shí)。即使有時(shí)這些資源本不能被緩存保存或應(yīng)該可能會(huì)很快過期，用戶界面可能會(huì)強(qiáng)制服務(wù)作者去求助于其他防止緩存的方法（例如，一次性URLs）為了避免歷史機(jī)制功能的不合適的作用。
總結(jié)
- 上一篇： 烧鹅多少钱成本，买多少钱一斤
- 下一篇： Varnish 和 Squid比较到底强