request的cache-control和response cache-control不一樣點

HTTP協議中，關於一些頭域的解釋很模糊，網上的解釋有些甚至是打架的，例如cache-control:no-cache，爲了搞清這個頭，google了很多資料，但不少都是各有各說法，甚至相互矛盾。http header中cache-control無疑是很是重要的一個頭，每每涉及到性能問題，緩存，緩存代理等等都沒法避免跟cache-control打交道。固然還有其餘一些頭域如last-modified，但它們含義都很是明確，至少沒有cache-control那麼含糊。

就連瀏覽器之間，對cache-control也有不一樣的理解，致使了對這個頭的不一樣的表現。

網上不少關於cache-control的資料寫得很模糊，我以爲不少都沒有，或者多是忽略了幾個地方，使得咱們看着這些資料的時候，似懂非懂。或者做者以爲某些地方足夠容易理解，因此根本不以爲須要強調，但正是這些被忽略掉的「前提條件」令咱們即便看完資料，也很難弄懂問題。那些對cache-control進行解釋的資料一般會忽略的一些"前提條件"有這幾個：

1.cache-control是出如今response仍是request中。不少資料在解釋cache-control時候，都沒有指明是response中的cache-control（也就是由服務器應答時發送的cache-control）仍是request中的cache-control（也就是由用戶代理，一般是瀏覽器，請求資源時發送的cache-control）。

2.什麼是緩存。「緩存」一詞會有N種解釋，特別是一些翻譯自英文的資料。「緩存」能夠指緩存的對象(object)，也能夠指HTTP消息鏈上的緩存系統，例如瀏覽器的緩存系統，和代理服務器上的緩存，或者一些專爲緩存而設計的代理服務器（例如squid），也能夠是原始服務器上的緩存（例如c#的cache對象）。而另外一方面，根據語境不一樣，「緩存」也有可能指緩存的機制....N多。因此一些資料當忽略了這些，讀者看了後，舊疑問還沒搞清楚，又來了新疑問。

而說到HTTP鏈上的緩存系統，咱們通常指瀏覽器的緩存系統，和代理服務器的緩存。

我所知道的關於cache-control指令的一些狀況是：

當cache-control出如今request中:

cache-control:no-control 告訴HTTP消息鏈上的緩存系統(也就是瀏覽器的緩存和代理服務器上的緩存)，本次請求要求忽略一齊緩存，必須是原始服務器從新計算生成迴應給用戶。因此，即便瀏覽器上的本地緩存未過時，或者代理服務器上的緩存未過時，都不要將這些緩存做爲迴應。當咱們在瀏覽器中強制刷新頁面（按ctrl+F5），發送的就是這個頭（不一樣不少瀏覽器將cache-contro:no-cachel和pragam:no-cache兩個頭一塊兒發送）

pragma:no-cache：和cache-control:no-control同樣，不過出於兼容HTTP/1.0，因此有些瀏覽器會保留這個頭。注意pragma:no-cache只應該出如今Request中，代表不想獲取緩存。HTTP沒有哪條條文對Response中的pragma:no-cache進行定義，因此Response中的pragma:no-cache是無效的。

當cache-control出如今response中:

cache-control:no-control 服務器告訴HTTP消息鏈上的緩存系統，不要緩存這個response結果。其實這個不是百分百確定，並且不一樣瀏覽器好像接收到這個頭時也有不一樣反應。

當response header有cache-control:no-control時：

chrome：再訪問相同的URL時候是發出if-modified-since。這說明即便接收到cache-control:no-contro，chrome也會進行緩存。

IE9:再次訪問相同URL時，跟第一次訪問（無緩存狀況下）同樣，沒有if-modified-since，也沒有其餘緩存相關的頭域，並且緩存文件夾也沒有緩存文件。也就是說，IE9接收到cache-control:no-contro，不會將response內容緩存起來。

FF：跟IE9行爲相似

而另外，cache-control：no-store出如今response中才有意義，意思是告訴緩存系統不要緩存或者存儲response內容（不要任何形式的存儲，包括存儲在緩存文件夾中，以避免一些敏感信息外泄）。chrome,IE9,FF對這個頭的實現是同樣的。當接收到有這個頭的response，三個瀏覽器的緩存目錄都找不到相關的緩存文件。