IE6上Gzip+Etag问题的解决方案

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拉!

 

本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/emu/archive/2011/02/27/6210721.aspx

 

你可能感兴趣的:(cache,浏览器,IE,服务器,header,etag)