Как сообщить облачному офису не кэшировать 302 ответа от S3-переадресаций или, как еще обходить проблему генерации кэширования этого образа

Я использую Imagine через LIIPImagineBundle для Symfony2 для создания кэшированных версий изображений, хранящихся на S3.

Кэшированные изображения хранятся в ведомом веб-разрешении S3, обслуживаемом CloudFront. Однако реализация LIIPImagineBundle по умолчанию для S3 для меня слишком медленная (проверка наличия файла на S3, а затем создание URL-адреса либо в кэшированном файле, либо в функции разрешения), поэтому я разработал свой собственный рабочий процесс:

  • Передайте клиенту URL-адрес облачного интерфейса, в котором должно существовать кэшированное изображение.
  • Клиент запрашивает изображение через URL облачной границы, если он не существует, то в ведро S3 есть правило переадресации, которое 302 перенаправляет пользователя на предполагаемый путь веб-сервера, который генерирует кэшированную версию файла и сохраняет его в соответствующем месте на S3
  • Webserve 301 перенаправляет пользователя обратно на облачный URL-адрес, где изображение теперь сохраняется, и клиент обслуживает изображение.

Это работает нормально, пока я не использую cloudfront. Проблема заключается в том, что облачный интерфейс кэширует ответ перенаправления 302 (даже если спецификация http заявляет, что он не должен). Таким образом, если я использую cloudfront, клиент отправляется в бесконечном цикле перенаправления назад и вперед от веб-сервера к облачному, и каждый последующий запрос к файлу все еще перенаправляется на веб-сервер даже после того, как файл был сгенерирован.

Если я использую S3 непосредственно вместо облачного режима, проблем нет, и это решение является прочным.

Согласно Документация Amazon. Правила перенаправления S3 не позволяют мне указывать пользовательские заголовки (устанавливать заголовки управления кешем и т.п.), и я не верьте, что CloudFront позволяет мне контролировать кэширование перенаправлений (если они хорошо скрыты). Параметры недействительности CloudFront настолько ограничены, что я не думаю, что они будут работать (может только аннулировать 3 объекта в любое время)... Я могу передать аргумент обратно в облачный режим при первом перенаправлении (с веб-сервера Imagine), чтобы исправить бесконечные перенаправлять (например, image.jpg? 1), но последующие запросы к одному и тому же объекту будут по-прежнему 302 веб-серверу, а затем 301 обратно в облачный режим, даже если он существует. Я чувствую, что должно быть элегантное решение этой проблемы, но это ускользает от меня. Любая помощь будет оценена!

Ответ 1

Я решаю эту же проблему, установив "Default TTL" в настройках "Cache Behavior" в CloudFront на 0, но все же позволяя кэшировать мои измененные изображения, установив CacheControl MetaData в файл S3 с помощью < max-age=12313213.

Таким образом, перенаправления не будут кэшироваться (по умолчанию TTL-поведение), но мои измененные изображения будут (CacheControl max-age при ударе кеша s3).

Ответ 2

Если вам действительно нужно использовать CloudFront здесь, единственное, что я могу придумать, это то, что вы не можете напрямую подвергать пользователя танцу 302, 301. Не могли бы вы представить какой-то прокси-сервер script/page на передний S3 и весь этот процесс? (или это то побеждает точку).

Итак, промаха в кеше будет выглядеть так:

  • Посетитель запрашивает прокси-страницу через Cloudfront.
  • Прокси-страница запрашивает изображение с S3
  • Страница прокси-сервера получает 302 от S3, после этого следует представить себе веб-страницу сервер
  • В идеале просто верните изображение отсюда (при одновременном обновлении S3) или следовать за 301 обратно на S3
  • Страница прокси возвращает изображение посетителю
  • Изображение кэшируется Cloudfront