原文地址：http://www.cnblogs.com/lwhkdash/archive/2012/11/04/2748291.html
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消息链上的缓存系统（比如varnish， squid，cdn等），不要缓存这个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，三个浏览器的缓存目录都找不到相关的缓存文件。