http://www.aygfsteel.com/emu/archive/2011/02/27/345262.html
這個(gè)問題不是太廣為人知，但也算不上新鮮知識了，IE6如果接收到一個(gè)gzip壓縮的http響應(yīng)，那么這個(gè)響應(yīng)中的Etag信息會被拋棄，此時(shí)只能依賴last-modified時(shí)間來設(shè)計(jì)cache策略。某些類型的Vary值據(jù)說也會導(dǎo)致相同的問題。
為了這個(gè)問題emu在http頭上動了n多手術(shù)，甚至把200響應(yīng)狀態(tài)硬生生換成206等狀態(tài)，IE6一直都非常頑固的不肯吐出If-None-Match信息。幾乎要放棄了。
丟開這個(gè)bug，我們來看問題的實(shí)質(zhì)是什么。實(shí)質(zhì)是，我們有一個(gè)叫做Etag的，響應(yīng)內(nèi)容的一個(gè)hash值，需要在響應(yīng)的時(shí)候從服務(wù)器送給瀏覽器，并且要求在瀏覽器下次請求同一個(gè)路徑的時(shí)候把這個(gè)hash值送回給服務(wù)器校驗(yàn)。http中規(guī)定了，我們可以在http header內(nèi)容中通過一個(gè)叫做Etag的header來做這個(gè)事，但是現(xiàn)在瀏覽器不給力啊，有啥別的手段可以做相同的事情呢？
答案一點(diǎn)也不難想，我們一天到晚在實(shí)現(xiàn)“
把一個(gè)值從服務(wù)器送給瀏覽器，并讓瀏覽器吧它送回服務(wù)器”這件事的時(shí)候都是用什么手段的呢？沒錯(cuò)啦，就是
cookie。而且cookie還支持path！
因此需要做的事情就是，server在發(fā)現(xiàn)User-Agent是IE6的時(shí)候，在返回gzip內(nèi)容的時(shí)候出了要送Last-Modified時(shí)間之外，不要送Etag頭了，改為返回一個(gè)set-cookie頭：
Set-Cookie: etag=hash; pagh=/mypath
服務(wù)器在下次收到請求的時(shí)候，如果收到了If-Modified-Since信息，表明客戶端有一份當(dāng)前請求的cache，就可以從cookie里面驗(yàn)證etag值來決定是否返回304拉！