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，三個瀏覽器的緩存目錄都找不到相關的緩存文件。