都晓得http的申请头和响应头都能够设置cache-control属性，它的作用是用来设置动态资源缓存的。难道他们就没有什么不一样的中央么？反正一开始我是不明确，在网上也硬是没找到答案，于是这篇文章就进去了。。。
以下是本次验证的代码：
客户端为了验证申请头cache-control的作用，所以采纳了ajax的形式来申请js。服务端次要是用来设置动态资源的缓存工夫的。咱们所说的缓存都是建设在get申请形式之上，其余形式设置的缓存临时没听说过哈
上面就是见证奇观的时刻：
场景一：当客户端、服务端都不设置cache-control的时候看看是什么状况
发现默认状况下是不会走缓存的
场景二：当服务端设置cache-control，客户端没有设置的时候看看是什么状况
发现缓存是由服务端开启的
场景三：当客户端设置cache-control，服务器端没有设置的时候看看是什么状况
发现当只有客户端开启cache-control时是不会失效的，缓存必须是由服务端开启
场景四：当客户端和服务端都设置了cache-control的时候看看是什么状况
发现30秒后缓存就生效了，而不是客户端设置的60秒，故缓存的生效工夫是由服务端设置决定的
场景五：当客户端设置不须要缓存，而服务端设置了缓存的时候看看什么状况
发现资源不再走强缓存了，而是间接向服务器发送了申请，故申请头中设置的cache-control是能够不走缓存的，cache-control: max-age=0这和按F5键是一样的成果
论断：
1、只有服务端能力开启缓存，默认是不会走缓存的
2、走了强缓存就不会再向服务端发送申请了
3、客户端的申请头中只有设置了cache-control为：’no-store’ | ‘no-cache’ | ‘max-age=0’才会失效（也就是客户端不想走强缓存的时候失效），除非后端对这个字段做非凡解决
如果有对强缓存和协商缓存不太分明的同学能够理解一下之前写过的一遍文章一文读懂http缓存（超具体）
发表回复