Having now spent 2 days trying to track down why I had so many issues with caching images, I came to the realization that imagecache is flawed and has been from inception. A little bit of history, imagecache was an add-on module in Drupal 6.X & was later integrated into Drupal core beginning with version 7.0. While the premise of imagecache sounds great, generating images on the fly in the “styles” requested, the result was an implementation which could lead to DDOS attack. Starting with Drupal 7.20, a fix of sorts was implemented by the Drupal Security Team which added a query string to the end of an image URL for those images which can have an applied imagecace style.
For a better description of the issues with imagecache & derivative images, watch the video & read the description from Bèr Kessels who notified the Drupal community of the original vulnerability: http://berk.es/2013/03/04/drupal-imagecache-security-vulnarability-with-ddos-attack-explained/
The bottom line for me was that I needed a better fix for websites I manage. The solution implemented with Drupal 7.20 created issues with caching. Removing the itok query string didn’t remove the original issue of a potential DDOS vector. So what to do? Enter the module, Imageinfo Cache. With this module, image styles are created after an image is uploaded — a more appropriate time. Imageinfo Cache gives control back to the website maintainer to determine when/if images styles will be created & who is allowed to create these images styles on demand.
Thumbs up to this actively maintained module as it works great on the sites I manage.