将通过Imageresizer从Azure Blobstore修改过的数据/时间传递到CDN

我们刚刚将图像托管移至Azure，ImageResizer（v 4.0.5.942）由Cloudflare的CDN提供，但发现CDN在图像时保留了缓存图像在Azure blobstore上已经改变了。将通过Imageresizer从Azure Blobstore修改过的数据/时间传递到CDN

我们在我们的传出图像托管中使用了相同的CF CDN和Imageresizer，这是一个带有Imageresizer diskcaching集的iis盒子，并且没有问题。

我们Azure的imageresizer配置文件的插件部分是 -

<add name="AzureReader2" prefix="~/"connectionString= 
"DefaultEndpointsProtocol=httpsAccountName=reiwastorstagimg 
AccountKey=xyzxyxyyz"` 
checkForModifiedFiles="true" />

测试图像是通过CDN - http://azstagingimage.reiwa.com.au/listing/09/2635009-04.jpg?maxwidth=724&maxheight=543&quality=100

直接到Imaresizer应用 - http://azstagingimage3.reiwa.com.au/listing/09/2635009-04.jpg?maxwidth=724&maxheight=543&quality=100

在炳的配置包含 -

<resizer> 
    <plugins> 
    <add name="DiskCache" /> 
    </plugins> 


<diskCache autoClean="false" hashModifiedDate="true" subfolders="1024" /> 
</resizer>

我的想法是，当我们在预先打开磁盘缓存时，Imageresizer会检查原始图像的日期/时间戳，将其与其缓存版本的日期/时间进行比较，如果更改，将重新处理图像，从而更改缓存的图像日期/时间修改的邮票，然后由CDN拾取，导致重新阅读。我相信checkForModifiedFiles =“true”会导致Imageresizer返回Blob存储区，获取原始文件的修改日期并将其传递给CF CDN（或浏览器），但我们已经设置了它并没有按我们的预期行事。

有谁知道有没有办法解决这个问题，还是我需要在云中开启diskcache？

预先感谢您。 Kieron

来源

2016-11-18 Kieron Murphy

ImageResizer在v3中停止提供“原始图像”修改日期（用于已处理的请求） - 这看起来是无害的，但却造成了广泛的破坏。一些浏览器和代理不幸地比较了上次修改日期和上次获取日期。它的行为像etag会更好，但事实并非如此。最后修改必须是产生日期或广泛的副作用开始发生。

没有启用DiskCache，checkForModifiedFiles将没有多大关联。

启用磁盘缓存时，ImageResizer将根据缓存结果的时间提供稳定的修改日期/ etag。如果没有磁盘缓存，ImageResizer不会发送上次修改的日期。通常，这不会导致CDN永远不会验证，但是相反 - 太频繁的失效。

ImageResizer通常可以很好地处理IIS和ASP.NET头配置，在某些配置中，最后修改的内容始终设置为utcnow。但是这不会发生在您的服务器上。

痛苦最小的路径通常是利用缓存断路器（如& r = 31512351），或将所有blob视为不可变的。 ImageResizer用户通常无法接受无效检查的高延迟，而不可变的blob方法非常流行。

ImageResizer在使用DiskCache缓存标题时体面，但是当没有存储或保存状态的方法时 - 很难有一个解决方案不会破坏其缓存选择。

虽然ImageResizer可以做得更好。

如果你想要自定义行为，PreSendRequestHeaders是一个很容易做出改变的地方。如果你想完全控制，为你自己的类交换NoCache和ClientCache插件也很容易。

来源

2016-11-21 04:19:09

再次感谢您，我们决定采用CloudFlares API调用来使我们已更改的图像无效，同时，打开磁盘缓存以触发日期修改。 –

将通过Imageresizer从Azure Blobstore修改过的数据/时间传递到CDN

回答

相关问题