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