2017-01-16 7 views
0

У меня здесь немного уникальная ситуация.Остановить Cloudflare от переадресации кеширования

У нас есть домен, на котором размещены загруженные пользователем носители (на которые были применены операции с изображениями) (usermedia.com). Медиа хранится в ведро Amazon S3, а Cloudflare - перед этим ведром.

Если пользователь запрашивает изображение, он может перейти на https://usermedia.com/my-image-resize-200-200.jpg.

Если этот образ существует, то она подается, в противном случае Amazon S3 делает 302 редирект (с помощью правил маршрутизации) к https://app.com/generate/my-image-resize-200-200.jpg, который генерирует уменьшенное изображение, загружает его в S3, а затем делает другое перенаправление на https://usermedia.com/my-image-resize-200-200.jpg. На этот раз файл существует в S3 и обслуживается.

Проблема заключается в том, что у нас есть прокси-сервер Cloudflare - он перенаправляет кеширование, поэтому, если носитель не существует, Cloudflare застревает в непрерывном цикле перенаправления. Я попытался использовать перенаправление 307, но проблема не устранена.

Любые идеи, как обойти эту проблему?

+0

Вы уверены, что это CloudFlare, а не ваш браузер или Amazon, что это проблема? Я создал точную функцию на сайте, но на сервере вместо AS3. CloudFlare обрабатывает его просто отлично. Следующий вызов изображения загружает его почти мгновенно. – Jules

+0

У меня есть аналогичная настройка «перенаправить, если не найдена» с CloudFront, а не с Cloudflare, но я использую CloudFront> HAProxy (EC2)> S3. HAProxy изменяет значение 403 на 302, устанавливает 'Location:' и устанавливает 'Cache-Control: no-cache, no-store' для решения этой проблемы ... местоположение фактически не изменилось, за исключением того, что строка запроса добавлена ​​для указания размера действие и HAProxy отправляет их на сервер resizer. Тогда resizer фактически сохраняет значение S3, но не перенаправляет - он просто возвращает изображение, чтобы избежать возможных проблем с последовательностью S3. Но я вернусь к своим заметкам о правилах переадресации. –

+0

@Jules делает хороший момент. S3 в конечном итоге согласуется с созданием нового объекта при одном условии: если вы уже делали 'GET' до того, как объект был создан, - и вы сделали это по дизайну. –

ответ

0

У меня есть точная настройка и некоторая проблема. Я узнал, что проблема действительно в том, что clouldflare. Когда изображение не существует, S3 возвращает 307, указывающий на конечную точку resizer, проблема заключается в том, что облачное приложение добавляет заголовок кэша (например: cache-control: public, max-age = 691200), потому что, возможно, у вас есть на кешировании установите опцию «Срок действия кеша браузера», поэтому, когда браузер получит ответ, он будет кэшировать его (поскольку заголовок управления кешем присутствует), поэтому следующий запрос будет отправлен из кеша браузера.

UPDATE:

Быстрое решение может быть простым. В cloudflare установите время ожидания кэша браузера, чтобы «уважать существующие заголовки», таким образом, облако не будет добавлять заголовки, которые делают кеш браузера ответом. Если вы все еще хотите, чтобы изображения локально кэшировать, просто установите заголовок Cache-Control непосредственно на изображении S3 при его создании из сценария изменения размера

S3.putObject({ 
    Body: buffer, 
    Bucket: BUCKET, 
    ContentType: 'image/jpeg', 
    CacheControl: 'max-age=604800', 
    Key: finalKey, 
}) 

Если у вас есть другие активы (например, CSS или JavaScript, и т.д.), вы может также установить заголовок CacheControl для них, а также из консоли aws, или, если у вас есть их в некоторой папке, скажем, «foo», вы можете перейти в Cloudflare, создать правило страницы и указать, чтобы установить TTL для браузера для всех файлов в папке «foo».

Я знаю, что это поздний ответ, но надеюсь, чтобы помочь людям с той же проблемой в будущем

Смежные вопросы