Code You Don't Have to Write
It's always a pleasant bonus when you notice that software is behaving "as it should". The other day I was running Tamper Data on a SharePoint site and I noticed that all the images being pulled from Lists had ETag HTTP headers on them! Sweet. Furthering my delight was the fact that FireFox was sending If-Modified-Since and If-None-Match Headers and making use of the cache, making for one less trip to the content database.
If you're not familiar with these headers you may want to check out this post on cache related http headers. They can come in incredibly handy in the CMS world or anytime you're persisting a lot of assets (images, stylesheets, media, etc...) to a database.
And finally SharePoint read the headers appropriately and responded with a 304 - NOT MODIFIED telling the browser to dig the image out of it's cache since it was still current. The image was not pulled from the content database.
You might wonder if any of this really matters, it's just an ASP.NET Image/Resource Handler that makes good use of headers, it's how it's supposed to work right?
Sure, but I see bad image handlers all the time. In fact when was the last time you saw an image handler written by a developer that produced ETags and inspected incoming headers to try and make use of browser cache? Trust me, it's exceedingly rare. Most image handlers are unnecessarily database heavy and make little to no use of browser cache, never mind a lack of thought towards Content-Type and Content-Disposition. I'm quite happy that I don't need to stress out about all the images and documents that inevitably get stored in SharePoint libraries.
I think it's worth mentioning that these headers exist and that even if you haven't taken the time to enable caching on your SharePoint instance you're already taking advantage of the best form of cache that exists, the kind that's both free and close to the client (the browser). All you had to do was throw the content in a SharePoint Library.