304的请求机制和200有什么不一样呢？在fiddler中查看304请求的时候突然想到这个问题，就想到研究下这个304请求机制了。
我们自己在nginx上放一个文件，test.png。可以使用下面的地址进行访问：
http://test.yejianfeng.com/test.png
nginx配置文件如下：
这个的etag关闭是由于nginx默认是开启etag的，说明见ngx_http_core_module（http://nginx.org/en/docs/http/ngx_http_core_module.html）。
现在我把etag关闭了，这个test.png的HTTP请求如下：
可以看到这里的Response Header 中Last-Modified并没有设置过期，所以Last-Modified是不生效的。加上没有其他的相关缓存头，这个时候，浏览器就没有缓存这个页面了。所以呢，不管你黏贴URL，F5 还是Ctrl F5，页面进行的请求Cache-Control都是设置no-cache，所以服务端响应都是200。
下面，修改nginx配置，增加一个expires 1d：
重启nginx，HTTP请求如下：
可以看出这里的Expires比Date多一天，所以就是服务端告诉客户端，你给我在本地缓存一天吧。
那么这个时候使用F5：
返回的就是304了，这个时候，就是本地浏览器缓存了这个页面，发送条件请求给服务端，条件请求里面带一个If-Modified-Since，客户端询问服务端，这个文件浏览器这边有缓存，如果你服务端的文件在这个时间点有更改，就发送一个更改后的文件给我，没有的话就发送一个304就好。
这里还有个问题，这个Last-Modified是怎么定的呢？它就是这个文件在服务器上的最后修改时间。
图中的15:31和last-Modified的07:31中间的8个小时是时区导致的。
我们touch来修改这个文件的最后修改时间：
然后再F5下这个URL：
服务端返回200了，而且Last-Modified也修改了。这个就很好理解了。
如果我不是使用F5，而是将url直接贴到浏览器呢？这个时候，浏览器的行为就是如果本地有缓存，就使用本地的缓存，如果本地没有缓存，就请求服务端。
我们可以做的实验是这样：
1 开启fiddler
2 ctrl + F5，这个时候fiddler中多了一个200响应
3 F5，这个时候fiddler中多了一个304响应
4 打开一个新标签，在地址栏输入url：http://test.yejianfeng.com/test.png 这个时候会发现fiddler并没有任何请求
5 ctrl + F5，这个时候fiddler多一个200响应
所以这里可以验证之前的文章：HTTP缓存相关头（http://www.cnblogs.com/yjf512/p/3244882.html）里面说的三种刷新的行为。
回到缓存头，清空浏览器的缓存，把expire的设置去掉，把etag打开
第一次访问：
看到这里使用ETag了，ETag就相当于一个版本号，HTTP协议中并没有规定etag的算法，它的具体计算就依靠web服务器自身了。ETag还有普通和弱ETag的区分（http://en.wikipedia.org/wiki/HTTP_ETag）。
第二次访问的时候：
客户端发送请求中有个If-None-Match，表示客户端询问服务端，如果你这边的这个文件的tag还是XXXXX，就返回304吧，不是的话就返回200。
所以If-None-Match + ETag是可以控制文件在浏览器中的缓存的。
关于缓存的头，有些是客户端的：
Cache-Control
If-Modified-Since
If-None-Match
有些是服务端的：
Expire
Last-Modified
ETag
相关这些头的说明可以看这篇：HTTP缓存相关头（http://www.cnblogs.com/yjf512/p/3244882.html）
好了，下面说一种情景：
我们再nginx中做了一个rewrite，所有的js都重写到myjs.php这个脚本，那么问个问题，js在F5的时候会发送条件请求，这个条件请求是不是会触发php呢？
答案是会的。条件请求也是一个普通的php请求，它会在触发php的。这个时候如果你需要返回304的话，就需要你在php程序中对If-modified或者If-None-Match进行判断了。