In Internet Explorer 9 I am trying to reduce the number of network requests for our application using caching headers, but I am not seeing these take effect.
My understanding is that setting Expires and/or Cache:control: max-age should result in the content being cached and no request being sent ot the server. This is not happening. Depending on how we load/refresh the content on the page, I get a mix of 304 not-modified requests and 200 requests downloading the item again.
I am verifying this behaviour using a test page that I created. The test page is a simple jspx that includes a number of css and javascript files and contains an iframe and a number of buttons. The buttons exist to refresh the page in different ways.
I load up the page in Internet Explorer and ensure the caches are correct primed, with the right response header. I have IE configured, by default, to use the "automatically" option for "Check for newer pages of stored versions".
I have tried using both the following headers together, and each on their own:
Expires: Thu, 15 Apr 2015 20:00:00 GMT
Cache-control: max-age=290304000
However, no matter which is set I see the same behaviour in IE.
Note: I am using tomcat at the web-server, though have also been testing with WebSphere.
This is the behaviour we see for the different ways of loading the page (tomcat):
A full refresh using f5:
304 requests for css and js, but 200 for jspx
A full refresh using Enter in the address bar:
304 requests for css, js and jspx
Setting the iframe.src attribute to the same page to reload the iframe:
304 requests for css, js and jspx
Using iframe.ContentWindow.location.reload(true) to reload the iframe:
200 requests for css, a mix of 200 and 304 for js and 200 for jspx.
Using iframe.ContentWindow.location.reload() to reload the iframe:
304 requests for css and js, but 200 for jspx
Using iframe.scr = new page to switch the iframe to a new page:
304 requests for css, js and jspx
Using iframe.ContentWindow.location.assign(new page) to load a new page in the iframe:
304 requests for css, js and jspx
Using iframe.ContentWindow.location.replace() to replace the page in the iframe:
200 requests for css, js and jspx
My first question is around the 304 requests. Surely with the headers set, the content should be cached and should not be attempting a 304 request at all? Why is it? Is there another way to prevent or control this in Internet Explorer?
The second is around the consistency depending on different mechanisms used. Why does the behaviour differ? Should it not be somewhat consistent?
Any help here would be appreciated.
Thanks
Note: An example of the full set of response headers, with max-age only, is:
Response HTTP/1.1 200 OK
Server Apache-Coyote/1.1
Cache-control max-age=290304000
Accept-Ranges bytes
Last-Modified Fri, 21 Mar 2014 15:56:34 GMT
Content-Type text/css
Content-Length 33568
Date Wed, 16 Apr 2014 16:32:45 GMT
My understanding is that setting Expires and/or Cache:control: max-age should result in the content being cached and no request being sent ot the server. This is not happening. Depending on how we load/refresh the content on the page, I get a mix of 304 not-modified requests and 200 requests downloading the item again.
I am verifying this behaviour using a test page that I created. The test page is a simple jspx that includes a number of css and javascript files and contains an iframe and a number of buttons. The buttons exist to refresh the page in different ways.
I load up the page in Internet Explorer and ensure the caches are correct primed, with the right response header. I have IE configured, by default, to use the "automatically" option for "Check for newer pages of stored versions".
I have tried using both the following headers together, and each on their own:
Expires: Thu, 15 Apr 2015 20:00:00 GMT
Cache-control: max-age=290304000
However, no matter which is set I see the same behaviour in IE.
Note: I am using tomcat at the web-server, though have also been testing with WebSphere.
This is the behaviour we see for the different ways of loading the page (tomcat):
A full refresh using f5:
304 requests for css and js, but 200 for jspx
A full refresh using Enter in the address bar:
304 requests for css, js and jspx
Setting the iframe.src attribute to the same page to reload the iframe:
304 requests for css, js and jspx
Using iframe.ContentWindow.location.reload(true) to reload the iframe:
200 requests for css, a mix of 200 and 304 for js and 200 for jspx.
Using iframe.ContentWindow.location.reload() to reload the iframe:
304 requests for css and js, but 200 for jspx
Using iframe.scr = new page to switch the iframe to a new page:
304 requests for css, js and jspx
Using iframe.ContentWindow.location.assign(new page) to load a new page in the iframe:
304 requests for css, js and jspx
Using iframe.ContentWindow.location.replace() to replace the page in the iframe:
200 requests for css, js and jspx
My first question is around the 304 requests. Surely with the headers set, the content should be cached and should not be attempting a 304 request at all? Why is it? Is there another way to prevent or control this in Internet Explorer?
The second is around the consistency depending on different mechanisms used. Why does the behaviour differ? Should it not be somewhat consistent?
Any help here would be appreciated.
Thanks
Note: An example of the full set of response headers, with max-age only, is:
Response HTTP/1.1 200 OK
Server Apache-Coyote/1.1
Cache-control max-age=290304000
Accept-Ranges bytes
Last-Modified Fri, 21 Mar 2014 15:56:34 GMT
Content-Type text/css
Content-Length 33568
Date Wed, 16 Apr 2014 16:32:45 GMT