http://www.blogjava.net/emu/archive/2011/02/27/345262.html
这个问题不是太广为人知，但也算不上新鲜知识了，IE6如果接收到一个gzip压缩的http响应，那么这个响应中的Etag信息会被抛弃，此时只能依赖last-modified时间来设计cache策略。某些类型的Vary值据说也会导致相同的问题。
为了这个问题emu在http头上动了n多手术，甚至把200响应状态硬生生换成206等状态，IE6一直都非常顽固的不肯吐出If-None-Match信息。几乎要放弃了。
丢开这个bug，我们来看问题的实质是什么。实质是，我们有一个叫做Etag的，响应内容的一个hash值，需要在响应的时候从服务器送给浏览器，并且要求在浏览器下次请求同一个路径的时候把这个hash值送回给服务器校验。http中规定了，我们可以在http header内容中通过一个叫做Etag的header来做这个事，但是现在浏览器不给力啊，有啥别的手段可以做相同的事情呢？
答案一点也不难想，我们一天到晚在实现“
把一个值从服务器送给浏览器，并让浏览器吧它送回服务器”这件事的时候都是用什么手段的呢？没错啦，就是
cookie。而且cookie还支持path！
因此需要做的事情就是，server在发现User-Agent是IE6的时候，在返回gzip内容的时候出了要送Last-Modified时间之外，不要送Etag头了，改为返回一个set-cookie头：
Set-Cookie: etag=hash; pagh=/mypath
服务器在下次收到请求的时候，如果收到了If-Modified-Since信息，表明客户端有一份当前请求的cache，就可以从cookie里面验证etag值来决定是否返回304拉！