通用首部字段是請求報文和響應(yīng)報文兩方都會使用的首部策彤。

Cache-Control

通過指定首部字段 Cache-Control 的指令，被用于在 http 請求和響應(yīng)中，通過指定指令來實現(xiàn)緩存機(jī)制。緩存指令是單向的改基，這意味著在請求中設(shè)置的指令，不一定被包含在響應(yīng)中署穗。

指令的參數(shù)是可選的寥裂，多個指令之間通過“,”分隔嵌洼。首部字段 Cache-Control 的指令可用于請求及響應(yīng)時案疲。

Cache-Control: private, max-age=0, no-cache

緩存請求指令

緩存響應(yīng)指令

public 指令

當(dāng)指定使用 public 指令時，則明確表明其他用戶也可以緩存麻养。

private 指令

當(dāng)指定 private 指令后褐啡，緩存服務(wù)器只會對特定用戶提供資源緩存的服務(wù)，對于其他用戶發(fā)送過來的請求鳖昌，代理服務(wù)器則不會緩存备畦。

no-cache 指令

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

使用 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ù)值的首部字段可以使用緩存汽久。

no-store 指令

當(dāng)使用 no-store 指令時，暗示請求（和對應(yīng)的響應(yīng)）或響應(yīng)中包含機(jī)密信息踊餐。因此回窘，緩存不能在本地存儲請求或響應(yīng)的任一部分。

從字面意思上很容易把 no-cache 誤解成為不緩存市袖，但事實上 no-cache 代表不緩存過期的資源啡直，緩存會向源服務(wù)器進(jìn)行有效期確認(rèn)后處理資源，也許稱為 do-not-serve-from-cache-without-revalidation 更合適苍碟。no-store 才是真正地不進(jìn)行緩存酒觅，請注意區(qū)別理解。

s-maxage 指令

s-maxage 指令的功能和 max-age 指令的相同微峰，它們的不同點是 s-maxage 指令只適用于多用戶舷丹、公共緩存的代理服務(wù)器。也就是說蜓肆，對于同一用戶重復(fù)返回響應(yīng)的服務(wù)器來說颜凯，這個指令沒有任何作用。

另外仗扬，當(dāng)使用 s-maxage 指令后症概，則直接忽略對 Expires 首部字段及 max-age 指令的處理。

max-age 指令

當(dāng)客戶端發(fā)送的請求中包含 max-age 指令時早芭，如果判定緩存資源的緩存時間數(shù)值比指定時間的數(shù)值更小彼城，那么客戶端就接收緩存的資源。 另外，當(dāng)指定 max-age 值為 0募壕，那么緩存服務(wù)器通常需要將請求轉(zhuǎn)發(fā)給源服務(wù)器调炬。

當(dāng)服務(wù)器返回的響應(yīng)中包含 max-age 指令時，緩存服務(wù)器將不對資源的有效性再作確認(rèn)舱馅，而 max-age 數(shù)值代表資源保存為緩存的最長時 間缰泡。

應(yīng)用 HTTP/1.1 版本的緩存服務(wù)器遇到同時存在 Expires 首部字段的情況時，會優(yōu)先處理 max-age 指令代嗤，而忽略掉 Expires 首部字段匀谣。而 HTTP/1.0 版本的緩存服務(wù)器的情況卻相反，max-age 指令會被忽略掉资溃。

min-fresh 指令

min-fresh 指令要求緩存服務(wù)器返回至少還未過指定時間的緩存資源武翎。

比如，當(dāng)指定 min-fresh 為 60 秒后溶锭，過了 60 秒的資源都無法作為響應(yīng)返回了宝恶。

max-stale 指令

使用 max-stale 可指示緩存資源，即使過期也照常接收趴捅。

如果指令未指定參數(shù)值垫毙，那么無論經(jīng)過多久，客戶端都會接收響應(yīng)拱绑；如果指令中指定了具體數(shù)值综芥，那么即使過期，只要仍處于 max-stale 指定的時間內(nèi)猎拨，仍舊會被客戶端接收膀藐。

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 指令

使用 must-revalidate 指令，代理會向源服務(wù)器再次驗證即將返回的響應(yīng)緩存目前是否仍然有效痕寓。

若代理無法連通源服務(wù)器再次獲取有效資源的話傲醉，緩存必須給客戶端一條 504（Gateway Timeout）狀態(tài)碼。

另外呻率，使用 must-revalidate 指令會忽略請求的 max-stale 指令（即使已經(jīng)在首部使用了 max-stale硬毕，也不會再有效果）。

proxy-revalidate 指令

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

no-transform 指令

使用 no-transform 指令規(guī)定無論是在請求還是響應(yīng)中，緩存都不能改變實體主體的媒體類型藐守。

這樣做可防止緩存或代理壓縮圖片等類似操作挪丢。

cache-controal 擴(kuò)展

通過 cache-extension 標(biāo)記（token），可以擴(kuò)展 Cache-Control 首部字段內(nèi)的指令卢厂。

Cache-Control: private, community="UCI"

如上例乾蓬，Cache-Control 首部字段本身沒有 community 這個指令。借助 extension tokens 實現(xiàn)了該指令的添加慎恒。如果緩存服務(wù)器不能理解 community 這個新指令任内，就會直接忽略。因此融柬，extension tokens 僅對能理解它的緩存服務(wù)器來說是有意義的死嗦。

Connection

決定當(dāng)前的事務(wù)完成后，是否會關(guān)閉網(wǎng)絡(luò)連接粒氧。如果該值是“keep-alive”越除，網(wǎng)絡(luò)連接就是持久的，不會關(guān)閉外盯，使得對同一個服務(wù)器的請求可以繼續(xù)在該連接上完成摘盆。

close 指令

HTTP/1.0 請求的默認(rèn)值，表明客戶端或服務(wù)器想要關(guān)閉該網(wǎng)絡(luò)連接饱苟。

keep-alive 指令

表明客戶端想要保持該網(wǎng)絡(luò)連接打開孩擂，HTTP/1.1 的請求默認(rèn)使用一個持久連接。這個請求頭列表由頭部名組成箱熬，這些頭將被第一個非透明的代理或者代理間的緩存所移除：這些頭定義了發(fā)出者和第一個實體之間的連接类垦，而不是和目的地節(jié)點間的連接。

Date

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

HTTP/1.1 協(xié)議使用在 RFC1123 中規(guī)定的日期時間的格式护锤，如下示例：

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

HTTP/1.1 之前的 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

Pragma

Pragma 是 HTTP/1.1 之前版本的歷史遺留字段，僅作為與 HTTP/1.0 的向后兼容而定義赤炒。

規(guī)范定義的形式唯一氯析，如下所示:

Pragma: no-cache

該首部字段屬于通用首部字段，但只用在客戶端發(fā)送的請求中莺褒⊙诨海客戶端會要求所有的中間服務(wù)器不返回緩存的資源。

所有的中間服務(wù)器如果都能以 HTTP/1.1 為基準(zhǔn)遵岩，那直接采用 Cache-Control: no-cache 指定緩存的處理方式是最為理想的你辣。但要整體掌握全部中間服務(wù)器使用的 HTTP 協(xié)議版本卻是不現(xiàn)實的巡通。因此，發(fā)送的請求會同時含有下面兩個首部字段:

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

Trailer

Trailer 是一類特殊的首部字段舍哄，HTTP 協(xié)議在返回數(shù)據(jù)的時候通常是先發(fā)送 Header 信息宴凉，再發(fā)送 Body 數(shù)據(jù)，而 Trailer 會在 Body 傳輸結(jié)束后表悬，再將內(nèi)容“補(bǔ)發(fā)”給接收方弥锄。

發(fā)送方需要事先說明在報文主體后記錄了哪些首部字段，可以指定多個蟆沫，以逗號分隔籽暇。

該首部字段可應(yīng)用在 HTTP/1.1 版本分塊傳輸編碼時。

HTTP/1.1 200 OK
Content-Type: text/plain
...
Transfer-Encoding: chunked
Trailer: Expires

... 報文主體...
0
Expires: Tue, 03 Jul 2012 04:40:56 GMT

以上用例中饭庞，指定首部字段 Trailer 的值為 Expires戒悠，在報文主體之后 （分塊長度 0 之后）”補(bǔ)發(fā)”了首部字段 Expires 中的內(nèi)容。

Transfer-Encoding

首部字段 Transfer-Encoding 規(guī)定了傳輸報文主體時采用的編碼方式舟山。

HTTP/1.1 的 Transfer-Encoding 僅對分塊傳輸編碼有效救崔。

最后

我的個人主頁 里也同步進(jìn)行了更新，歡迎來逛逛捏顺。