Static caching bug with IE6, gzip, and Vary
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
KARL3 |
Invalid
|
Medium
|
Shane Hathaway |
Bug Description
Duncan Booth helped diagnose and issue we have with caching of static resources on IE6.
Below is information from his two emails.
=========== First Email ================
The karl.oxfam.org.uk URL doesn't have any headers in the response to control caching, just a last modified date. That means IE will cache it for an indeterminate time based on how long ago it was last modified (if it hasn't been modified for a long time it won't check very often). It will however request it every time IE has been restarted and the request is unconditional so the 51k is always transferred.
The kdi01.sixfeetup.com response does have caching headers, but it isn't being cached (I created an html page which just references your two urls and whenever I open that page in IE it fetches the kdi01 url but uses the karl one from cache). The response has a Vary header: according to http://
Ah, I think I see what is happening. See http://
which I think says that IE will cache content which is gzip compressed and has the Vary: Accept-Encoding header, if you aren't gzip compressing it then the presence of the Vary: header will stop it caching.
#
Result
Protocol
Host
URL
Body
Caching
Content-Type
Process
Comments
Custom
60 200 HTTP kdi01.sixfeetup.com /static/
GET /static/
Accept: */*
Accept-Language: en-gb
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6; .NET CLR 2.0.50727)
Host: kdi01.sixfeetup.com
Proxy-Connection: Keep-Alive
Cookie: repoze.
HTTP/1.1 200 OK
Via: 1.1 OXGBPXY03
Connection: Keep-Alive
Proxy-Connection: Keep-Alive
Content-Length: 32793
Expires: Mon, 04 Aug 2014 08:11:58 GMT
Date: Wed, 05 Aug 2009 08:11:58 GMT
Content-Range: bytes 0-32792/32793
Content-Type: text/css
ETag: 1249068929.0-32793
Server: Apache/2.2.3 (CentOS)
Accept-Ranges: bytes
Cache-Control: public, max-age=157680000
Last-Modified: Fri, 31 Jul 2009 19:35:29 GMT
Vary: Accept-Encoding
#
Result
Protocol
Host
URL
Body
Caching
Content-Type
Process
Comments
Custom
62 200 HTTPS karl.oxfam.org.uk /static/
GET /static/
Accept: */*
Accept-Language: en-gb
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; GTB6; .NET CLR 2.0.50727)
Host: karl.oxfam.org.uk
Connection: Keep-Alive
Cookie: __utma=
HTTP/1.1 200 OK
Server: nginx/0.5.33
Date: Wed, 05 Aug 2009 08:12:06 GMT
Content-Type: text/css
Last-Modified: Thu, 14 May 2009 20:37:42 GMT
Connection: keep-alive
Content-Length: 51840
========== Second Email ==================
You certainly should be able to repeat the tests I did (if you can bring yourself to run IE): I couldn't see any evidence that the proxy was affecting the outcome. A large part of the problem is of course that we're still stuck on IE6: IE7 doesn't solve all the caching issues but it is a lot better.
I used the following HTML file to test on IE6 with Fiddler 2.2.4.0 beta
<html>
<style type="text/
<style type="text/
<body>
Hello world
</body>
</html>
On the first visit to the page each time IE was started I saw both css files loaded, subsequent visits only re-requested the second one (putting the cursor into the address bar and hitting return is sufficient to revisit the page without flushing cache). Fiddler also has a 'filters' tab which can be used to modify the request and/or response: I used it to remove the Vary header from the response.
Changed in karl3: | |
assignee: | nobody → Shane Hathaway (shane-hathawaymix) |
Apache's mod_deflate is adding the Vary header, but as Duncan explained, IE6 doesn't cache responses with a nontrivial Vary header. I applied the workaround described here:
http:// development. lombardi. com/?p= 946
It removes the Vary header from the response when the user agent is detected as MSIE 6.