In the last post we discussed how sending Cache-friendly headers made for a much more enjoyable experience for site visitors and also helped reduce bandwith usage and lowered costs for operators.

Let’s say you are web developer showing of your l33t Photoshop skills on such a site and you upload a gif or a png called ‘myfirst.gif’. A few days or even hours later you realise that you can do some awesome kung-fu with Photoshop filters and make an even better image and you decide to replace with this new image but keep the same name ‘myfirst.gif’

Stop right there, your viewers have already picked up that image via http://myurl/myfirst.gif and with a cache-friendly header that’s going to be in their browser cache and ISP’s proxy cache for a while.
You really don’t want to tell them to reload the page to pick up the changes.

Anytime you make a fix to a content served via cache-friendly headers, save the fixed content to a new name therby generating another URI. That way you get the benefit and not experience support issues where depending on the phase of the moon people see different content.

It’s always a good idea to generate appropiate Cache-Control headers for all content, static or dynamic, Even if you don’t want it cached. Say so via HTTP headers and not via HTML meta tags. Many ISP’s support such mechanisms which may include modifying Apache configs or using .htaccess files or if you use languages such as PHP, judicious use of the header() function