Проблемы с перенаправлением Aws S3 для запросов https на облачном фронте - PullRequest
Новая
       42

Проблемы с перенаправлением Aws S3 для запросов https на облачном фронте

0 голосов
/ 19 марта 2019

У нас есть корзина aws s3, в которой размещаются наши динамические изображения, которые будут загружаться веб-приложениями и мобильными приложениями через https и с различными размерами (url / width x height / image_name), т.е. http://test.s3.com/200x300/image.png).

Для этого мы сделали две вещи:

1- Изменение размера в реальном времени: в моем контейнере s3 есть правило перенаправления для перенаправления ошибок 404, запрашивающих несуществующие размеры изображений, на шлюз API, который вызывает функцию Lambda. Лямбда-функция извлекает исходное изображение, изменяет его размер и помещает в папку в корзине в соответствии с требуемым размером.

Мы следовали инструкциям в этой статье: https://aws.amazon.com/blogs/compute/resize-images-on-the-fly-with-amazon-s3-aws-lambda-and-amazon-api-gateway/

2- HTTPS: я создал дистрибутив облачного фронта с сертификатом SSL, и его источником является статическая конечная точка веб-сайта s3

Проблема: запрос изображения от s3 с использованием домена https облачного фронта всегда вызывает ошибку 404, которая перенаправляется моим правилом перенаправления через шлюз API, даже если этот определенный размер изображения уже существует.

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

Буду признателен за подсказку о том, что нужно сделать, чтобы лучше отладить эту проблему (и какие журналы мне нужно предоставить здесь).

Спасибо

Сари

1 Ответ

1 голос
/ 20 марта 2019

Это решение основано на том, что S3 генерирует HTTP-перенаправления для отсутствующих объектов, перенаправляя браузер на API-шлюз, чтобы изменить размер объекта ... и сохранить его по исходному URL-адресу.

Проблема двоякая:

  • Сгенерированные S3 перенаправления не включают в себя Cache-Control заголовки и
  • Поведение CloudFront по умолчанию, когда Cache-Control отсутствует в ответе, заключается в внутреннем кэшировании ответа для значения таймера, называемого Default TTL, который по умолчанию установлен на 86400 секунд (24 часа).

Проблема, которую это вызывает, заключается в том, что CloudFront запомнит исходное перенаправление и снова и снова отправит в него браузер, даже если объект теперь присутствует.

Выбор Customize вместо Use Origin Cache Headers для «Кэширования объектов», а затем установка Default TTL в 0 (все в настройках поведения CloudFront Cache) решит проблему, поскольку он настраивает CloudFront не для кэширования ответов в месте происхождения не содержит соответствующих Cache-Control заголовков.

Для дополнительной информации:

Для чего используется Cloudfront Minimum TTL? объясняет таймеры Minimum / Default / Maximum TTL и как / когда они применяются.

Настройка «Кеширования объектов» в CloudFront объясняет запутанную маркировку пользовательского интерфейса этих параметров, которая, вероятно, является задержкой со времени, когда все три таймера были настраиваемыми.

...