· 若server在响应一个资源时加入了Last-Modified字段，那么当下一次浏览器再一次向server请求该资源时（前提是浏览器中上一次的资源被缓存过了），会在请求header中包括If-Modified-Since字段，且值与server第一次响应给浏览器的Last-Modified字段一致

· 若server在响应一个资源时加入了ETag字段，那么当下一次浏览器再一次向server请求该资源时（前提是浏览器中上一次的资源被缓存过了），会在请求header中包括If-None-Match字段。且值与server第一次响应给浏览器的ETag字段一致

那么上述是遵循了Http协议的浏览器会自己主动实现的，而要实现304的功能，就须要server（比方Apache对于静态资源会自己主动实现这两个字段的响应）或者我们手动在server端编写响应的逻辑来实现。

，发送新文件并更新Last-Modified字段）

。发送新文件，并更新ETag）

1.6. Etag 主要为了解决 Last-Modified 无法解决的一些问题。

· 一些文件或许会周期性的更改，可是他的内容并不改变(只改变的改动时间)，这个时候我们并不希望client觉得这个文件被改动了，而又一次GET。

这样的情况下能够将某个能用来表明文件内容是否被更改的值（比方md5）来作为ETag

· 某些文件改动很频繁，比方在秒下面的时间内进行改动，(比方说1s内改动了N次)。If-Modified-Since能检查到的粒度是s级的，这样的改动无法推断(或者说UNIX记录MTIME仅仅能精确到秒)

· 某些server不能精确的得到文件的最后改动时间

2. 不同的页面打开方式产生的请求差别

一般我们打开（或者更新）一个页面（或者资源）有几种方式：

· 在地址栏中输入地址。然后回车

· 激活当前页面地址，然后回车

· F5刷新页面

· 单机Back/Forwardbutton

上面几种方式对资源的请求，会产生不同的结果，而且各浏览器的表现并不一致。详细的差别能够參考鸟哥的《浏览器缓存机制》

逻辑。

最后, 概括下关键的结论:

关键结论
打开新窗体	假设指定cache-control的值为private、no-cache、must-revalidate,那么打开新窗体訪问时都会又一次訪问server。而假设指定了max-age值,那么在此值内的时间里就不会又一次訪问server,比如：Cache-control: max-age=5 表示当訪问此网页后的5秒内再次訪问不会去server.
在地址栏回车	假设值为private或must-revalidate,则仅仅有第一次訪问时会訪问server,以后就不再訪问。假设值为no-cache,那么每次都会訪问。假设值为max-age,则在过期之前不会反复訪问。
按后退按扭	假设值为private、must-revalidate、max-age,则不会重訪问,而假设为no-cache,则每次都反复訪问.
按刷新按扭	不管为何值,都会反复訪问.

3. html meta法

这个好像对wechat不起作用。

4. http head 法

JSP：

response.setHeader("Pragma","No-cache");

response.setHeader("Cache-Control","no-cache");

response.setDateHeader("Expires", 0);

覆盖getLastModified方法，响应消息中无LastModified头字段

5. url 时间戳

window.location="a-intro.html?"+Math.random();

这个对wechat起作用。。

6. 引导页入口法

rdm。html

window.location="a-intro.html?"+Math.random();

</script>

7. 參考

(3 条消息) 浏览器文件缓存和304的差别？ - 知乎.htm

[转载](转)浏览器缓存和304小结_hugh_新浪博客.htm

（very detail good）浏览器缓存机制风雪之隅.htm

码农公寓

1. 缓存的一些机制

1.1. http 304

1.2. 浏览器刷新的处理机制

1.3. Expires

1.4. Cache-Control

1.5. Last-Modified/E-tag