Monday, August 18, 2008

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.

The original response to the request had the ETag and looked like:

When the browser next visited the page and tried to pull the image again the browser correctly sent If-Modified-Since and If-None-Match Headers:

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.

Who Cares?

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.

The Point

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.

2 comments:

Thanks for putting together all the cache related info for MOSS. I have a weired scenario on my MOSS 2007 installation. When I make a request with If-none-match and If-not-modified, the sharepoint server responds with 200 OK, although the E-Tag and Last-Modified tiem still remains the same.This does not happen with all the documents, but for some of them it does. Do you hav an idea, what causes this behaviour on the server.Thanks a lot in advance!!

About Me

Tyler Holmes is a Solutions Architect working in Portland, Oregon. He lives mostly in the MS tech stack and is currently treading the waters of Communication/Collaboration and Business Intelligence with off the shelf/open source technologies.