Я использую 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 обратно в облачный режим, даже если он существует. Я чувствую, что должно быть элегантное решение этой проблемы, но это ускользает от меня. Любая помощь будет оценена!