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，三个浏览器的缓存目录都找不到相关的缓存文件。