January 4, 2012
We recently noticed some odd behavior with the Google Chrome and Internet Explorer web browsers, where we'd alter a resource like an image or SWF file, and although we would see the changes fine here, they wouldn't show up to anyone else for what looked like a random amount of time. Mozilla Firefox would also always see the changes, which made it even odder !
Now we've got to the bottom of it, read on to see how we fixed it and what we traced the problem down to.
Firstly, a brief summary of how web browsers work with respect to caching, skipping over some of the techy details :-)
When an image is requested the first time by a web browser, the server sends back some extra information as well as the image itself. These headers have many jobs, but the job we're interested in is to do with the browser's cache.
Because it is (relatively) expensive to request every image on a web page every time it's needed, all web browsers keep a copy, and try to make as good a job of reusing the copy as they can. Of course, there has to be a way for this cached copy to be replaced by any updated version on the server, and there are a whole host of headers used for this purpose.
What Firefox seems to do is that if it's told the server knows the last modified time and content (last-modified and etag for the real techies) it will always go back to the server and ask the server to do a quick check for changes (if-modified-since and if-none-match). If the content hasn't changed then the server quickly replies (with a 302 HTTP code) otherwise it sends back the new image (with a 200 HTTP code) and Firefox updates it's cache and it all starts again for the next request.
Now, as it happens, IE does something a bit different, as does Chrome, but we'll focus on IE because the same fix applies there too. What IE does is say to itself 'the server can tell me if this image changes, and last I saw it had been modified in the past, so I wont check again for now'. In fact, IE wont check with the server again until IE is restarted.
This means you can make as many changes as you like to the image, but IE simply will not see them unless drastic action is taken.
The way to convince IE (and Chrome) to do the right thing and always check back with the server in case the image has changed is to send an extra header, called 'Expires'. This changes IE's thought process to be more like 'the server can tell me if this image changes, and when it was modified, but it also says my copy of it must be checked before I reuse it'.
And, as it turns out, the default for our web server wasn't to send the Expires header. This is fairly logical, when you think about how Expires was meant to be used.The idea was that you'd be able to say 'this image can be used for the next 6 months, but this HTML page can only be cached for the next 5 minutes'. This was so things like static back ground images would not be re-requested by web browsers as often as continually updating news pages, for instance. But a lot of the time people will be visiting our client's site's for the first time, so this longer term cache doesn't get a chance to come in to play, so we never really missed it.
So, we're now sending out this header for some of our content to see if it works as well as it seems to in our testing.
If you are on our beta program, for instance, the files are delivered with this new header to make sure you always have the very latest version of our application, without having to download all its files every time, giving you the best of both worlds.
There's a small downside to doing so, because it'll use a bit more bandwidth, take a little longer, and place a small extra load on our servers. But if it works well, it'll be worth it.
Posted by Tom Chiverton
Building campaigns around annual events is a great idea for content for consumer emails. Valentine’s…
February 13, 2015
It is not often you get the gatekeepers of leading ISP’s in a room together…
February 10, 2015