KARL3

Bug #409466
Comment #5

Comment 5 for bug 409466

Revision history for this message

Paul Everitt (paul-agendaless) wrote on 2009-08-11: Re: [Bug 409466] Re: Static caching bug with IE6, gzip, and Vary

Hi Duncan. Based on Shane's analysis, I think we'll close our
investigation into caching performance on IE6.

--Paul

On Aug 10, 2009, at 7:48 PM, Shane Hathaway wrote:

> I don't see a problem with IE6 anymore. My test is as follows.
>
> 1) I created a file called bugtest.html, which loads CSS from
> kdi01.sixfeetup.com.
>
> 2) I started "tcpdump -n -i wlan0 port 80", which shows all important
> HTTP traffic to/from my computer.
>
> 3) I opened bugtest.html in the ies4linux version of IE6.
>
> 4) Once the page loaded, I looked at the output of tcpdump. If any
> packets were transferred to/from kdi01.sixfeetup.com, the test failed.
> If no packets were transferred, the test passed.
>
> When the Vary header was present, the test always failed. Once I
> configured Apache to not send the Vary header to IE6, the test always
> passed. I concluded that I had fixed the bug. I confirmed this again
> today.
>
> Perhaps we're seeing a proxy issue. If the HTTP proxy replaces the
> User-Agent string, Apache might have no way to know that the client is
> running IE6.
>
> --
> Static caching bug with IE6, gzip, and Vary
> https://bugs.launchpad.net/bugs/409466
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Porting KARL to a new architecture: In Progress
>
> 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://www.fiddler2.com/fiddler/perf/aboutvary.asp
> IE6 should still allow caching for Vary: Accept-Encoding, but
> evidently in this case it doesn't. I configured Fiddler to delete
> the Vary: header from the response and IE stopped re-requesting the
> url every time.
>
> Ah, I think I see what is happening. See http://www.ilikespam.com/blog/internet-explorer-meets-the-vary-header
> 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/themedstyles.css 32,793
> public, max-age=157680000 Expires: Mon, 04 Aug 2014 08:11:58 GMT
> text/css iexplore:5348
>
> GET /static/themedstyles.css HTTP/1.1
> 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.browserid=023d21ec9e59f296a0f96cba5d8cc96ed4bafe8b!
> 300283c0374528658dc8fcc4a4bae5b6
>
> 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/r/themedstyles.css 51,840
> text/css iexplore:5348
>
> GET /static/r/themedstyles.css HTTP/1.1
> 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
> =32404064.1073916141190078000.1245942391.1245942391.1248433838.2;
> __utmz=32404064.1245942391.1.1.utmcsr=intranet.oxfam.org.uk|
> utmccn=(referral)|utmcmd=referral|utmcct=/programme/heard/overview/
> general_resources; I18N_LANGUAGE="en"; __ac="ZGJvb3RoOml0dm9kcnQ2aA
> %3D%3D"
>
> 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/css"></style>
> <style type="text/css"></style>
> <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.

Hi Duncan.  Based on Shane's analysis, I think we'll close our  
investigation into caching performance on IE6.

--Paul

On Aug 10, 2009, at 7:48 PM, Shane Hathaway wrote:

> I don't see a problem with IE6 anymore.  My test is as follows.
>
> 1) I created a file called bugtest.html, which loads CSS from
> kdi01.sixfeetup.com.
>
> 2) I started "tcpdump -n -i wlan0 port 80", which shows all important
> HTTP traffic to/from my computer.
>
> 3) I opened bugtest.html in the ies4linux version of IE6.
>
> 4) Once the page loaded, I looked at the output of tcpdump.  If any
> packets were transferred to/from kdi01.sixfeetup.com, the test failed.
> If no packets were transferred, the test passed.
>
> When the Vary header was present, the test always failed.  Once I
> configured Apache to not send the Vary header to IE6, the test always
> passed.  I concluded that I had fixed the bug.  I confirmed this again
> today.
>
> Perhaps we're seeing a proxy issue.  If the HTTP proxy replaces the
> User-Agent string, Apache might have no way to know that the client is
> running IE6.
>
> -- 
> Static caching bug with IE6, gzip, and Vary
> https://bugs.launchpad.net/bugs/409466
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in Porting KARL to a new architecture: In Progress
>
> 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://www.fiddler2.com/fiddler/perf/aboutvary.asp 
>  IE6 should still allow caching for Vary: Accept-Encoding, but  
> evidently in this case it doesn't. I configured Fiddler to delete  
> the Vary: header from the response and IE stopped re-requesting the  
> url every time.
>
> Ah, I think I see what is happening. See http://www.ilikespam.com/blog/internet-explorer-meets-the-vary-header
> 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/themedstyles.css	32,793	 
> public, max-age=157680000 Expires: Mon, 04 Aug 2014 08:11:58 GMT	 
> text/css	iexplore:5348		
>
> GET /static/themedstyles.css HTTP/1.1
> 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.browserid=023d21ec9e59f296a0f96cba5d8cc96ed4bafe8b! 
> 300283c0374528658dc8fcc4a4bae5b6
>
> 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/r/themedstyles.css	51,840		 
> text/css	iexplore:5348		
>
> GET /static/r/themedstyles.css HTTP/1.1
> 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 
> =32404064.1073916141190078000.1245942391.1245942391.1248433838.2;  
> __utmz=32404064.1245942391.1.1.utmcsr=intranet.oxfam.org.uk| 
> utmccn=(referral)|utmcmd=referral|utmcct=/programme/heard/overview/ 
> general_resources; I18N_LANGUAGE="en"; __ac="ZGJvb3RoOml0dm9kcnQ2aA 
> %3D%3D"
>
> 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/css"></style>
> <style type="text/css"></style>
> <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.