Проход через данные/время, измененный от Azure Blobstore до CDN с помощью Imageresizer

Question

Мы только что переместили наш графический хостинг в Azure с Imageresizer (v 4.0.5.942), который вышел из CDN Cloudflare, но обнаружил, что CDN сохраняет кэшированное изображение, когда изображение снова изменился на Azure blobstore.

Мы использовали тот же CF CDN и Imageresizer на нашем хостинге для исходящих изображений, который был iis-боксом с набором дисков Imageresizer и не имел проблемы.

Раздел плагин наших 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

Direct в Imaresizer App - 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, что вызвало повторное чтение.

Посмотрите на документацию Imageresizer, я считаю, checkForModifiedFiles = «true» заставит Imageresizer вернуться в хранилище blob, получить исходные файлы, измененные датой, и передать их CF CDN (или браузеру), но мы установили его и это не так, как мы ожидали.

Кто-нибудь знает, есть ли способ обойти это или мне нужно также включить diskcache в облаке?

Заранее спасибо. Kieron

Answer 1

ImageResizer прекратил подавать «исходное изображение» измененную дату в v3 (для обработанных запросов) - кажется безобидным, но вызвало повсеместный полом. Некоторые браузеры и прокси, к сожалению, сравнивают последние изменения с последними датами извлечения. Было бы лучше, если бы он вел себя как этаг, но это не так. Последнее изменение должно быть датой генерации вывода или началом широкого спектра побочных эффектов.

checkForModifiedFiles не будет иметь большого значения без использования DiskCache.

Когда дисковый кэш включен, ImageResizer поддерживает стабильную измененную дату/etag, основанную на кешировании результата. Без дискового кэша ImageResizer не отправляет дату последнего изменения. Как правило, это не приводит к тому, что CDN никогда не проверяет, но скорее наоборот - слишком частое аннулирование.

ImageResizer обычно играет хорошо с конфигурацией заголовка IIS и ASP.NET, а в некоторых конфигурациях для последнего изменения всегда задано значение utcnow. Но это не происходит на вашем сервере.

Путь наименьшей боли обычно заключается в использовании кэш-выключателей (например, & r = 31512351) или лечения всех блоков как неизменяемых. Высокая латентность проверок недействительности обычно неприемлема для пользователей ImageResizer, и неизменный подход blob довольно популярен.

ImageResizer подходит для кэширования заголовков с помощью DiskCache, но когда нет хранилища или способа сохранения состояния - трудно найти решение, которое не нарушает что-либо с его выбором кеша.

ImageResizer может сделать лучше, хотя.

Если вы хотите индивидуальное поведение, PreSendRequestHeaders - это простое место для внесения изменений. Также довольно легко заменить плагины NoCache и ClientCache для ваших собственных классов, если вы хотите получить полный контроль.