当我将新版本的图像(具有相同的名称，但具有新的Last Modified属性)上传到Azure Storage时，通过URL API调用的调整大小的版本不会更新。
当直接从这个URL查看时，新图像显示:[编辑].blob.core.windows.net/xlenz/modified-test.jpg
但是当我查看调整大小的缓存版本时，我仍然得到旧版本:[编辑].com/cloud/xlenz/modified-test.jpg ?宽度= 700
Last-Modified: Thu, 08 May 2014 09:22:46 GMT
ETag: "ddf1d8129f6acf1:0"
Content-Type: image/jpeg
Cache-Control: public
请求一个新的未缓存版本的图像会显示新版本:[编辑].com/cloud/xlenz/modified-test.jpg ?宽度= 800
Last-Modified: Thu, 08 May 2014 10:12:20 GMT
ETag: "a28693ffa56acf1:0"
Content-Type: image/jpeg
Cache-Control: public
当我把一个新版本的图像直接FTP到站点时，通过URL API调用的调整大小的版本会更新:[编辑].com/modified-test.jpg ?宽度= 700
我知道问题是与DiskCache而不是AzureReader2，因为当我通过<diskCache enabled="false" />禁用DiskCache时，问题就消失了。
这是DiskCache插件的一个bug吗?DiskCache不查看Azure Blob存储中文件的最后修改日期吗?
我正在使用最新的3.4.2版本的ImageResizer, ImageResizer. plugins。AzureReader2和ImageResizer.Plugins.DiskCache.
诊断页面输出:https://gist.github.com/anonymous/e104f8127969cedf92fd
当禁用缓存时，每个请求都从Azure下载源映像的新副本。
要提供基于最后修改日期的无效，您必须在每个请求上检查Azure(或基于更多过期规则缓存元数据)。
AzureReader2不允许DiskCache访问azure blobs的修改日期，因为这会使缓存的图像访问变得非常慢。网络延迟是不容小觑的:)
当使用blob或远程存储时，最好的无效策略是根本不无效——将blob视为不可变的。这并不意味着你不能更新现有图像url的响应。它只是意味着你必须在某个地方维护一个重写表。
看看S3Reader2 (Amazon S3存储的等效插件)，我得出的结论是，它不是一个bug，而是一个缺失的功能。
S3Reader2有一个'checkForModifiedFiles'配置设置:
如果为true, S3Reader将在S3上检查更新的源文件请求缓存文件。元数据在此之后缓存一个小时最后一次访问(可由代码配置)。如果为false，则S3永远不会存在已检查缓存文件的新版本，将延迟成本降低了50%。默认为false。
这正是我在AzureReader2中所寻找的!
我在官方ImageResizer UserVoice网站上添加了作为的功能请求:http://resizer.uservoice.com/forums/108373-image-resizer/suggestions/5900800-add-checkformodifiedfiles-configuration-setting-l
请投票!
作为临时解决方案(当我们等待修复时)，我们将把当前日期添加到ImageResizer请求中，这些请求将转到每天(部分)更新的图像。
更新2015-02-26: @nathanael-jones在http://resizer.uservoice.com/forums/108373-image-resizer/suggestions/5900800-add-checkformodifiedfiles-configuration-setting-l:上写道"这个功能是完整的，并出现在V4和GitHub上的开发分支中。"
感谢投票!