將通過Imageresizer從Azure Blobstore修改過的數據/時間傳遞到CDN

Question

我們剛剛將圖像託管移至Azure，ImageResizer（v 4.0.5.942）由Cloudflare的CDN提供，但發現CDN在圖像時保留了緩存圖像在Azure blobstore上已經改變了。

我們在我們的傳出圖像託管中使用了相同的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

Answer 1

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插件也很容易。