http://www.aygfsteel.com/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拉！