Отключить кэш Cloudfront, если файл не найден - PullRequest
Новая
       5

Отключить кэш Cloudfront, если файл не найден

0 голосов
/ 04 апреля 2020

Я создал дистрибутив Cloudfront перед корзиной S3 с RoutingRule для перенаправления на лямбда-функцию, если запрошенный файл не найден. Я использую это для изменения размера изображений.

Требуемый поток:

  1. Запросить файл в Cloudfront
  2. Файл не найден в проверке Cloudfront S3
  3. Файл, не найденный в S3, перенаправляет на лямбда-функцию
  4. Lambda найдет исходный файл, изменит его размер и перенаправит обратно на URL-адрес Cloudfront.

Правило перенаправления установлено на веб-сайте s3: 

<RoutingRules>
  <RoutingRule>
    <Condition>
      <KeyPrefixEquals/>
      <HttpErrorCodeReturnedEquals>404</HttpErrorCodeReturnedEquals>
    </Condition>
    <Redirect>
      <Protocol>https</Protocol>
      <HostName>mylambda.execute-api.us-east-1.amazonaws.com</HostName>
      <ReplaceKeyPrefixWith>/?key=</ReplaceKeyPrefixWith>
      <HttpRedirectCode>307</HttpRedirectCode>
    </Redirect>
  </RoutingRule>
</RoutingRules>

У меня проблема с шагом 4, когда лямбда-функция перенаправляет обратно на исходный URL-адрес Cloudfront кэшировал 404? и правило маршрутизации от S3 снова перенаправляет на лямбда-функцию, вызывая al oop.

  1. Я подтвердил, что лямбда-функция сгенерировала файл.
  2. , если я сделаю недействительным файл на Cloudfront Я успешно вижу, что он работает с S3)

Я пытался добавить 0 TTL на страницу ошибки 404, но не помогло.

Custom Error Response

правило перенаправления возвращает код состояния 307 [Temporary Redirect]. Но я не знаю, как установить 0 TTL для этого. Я не смог найти эту опцию на странице пользовательского сообщения об ошибке Cloudfront.

enter image description here

Согласно этой статье . 307 кэшируется. нужно установить правило для него ... где-то.

Это дополнительный вопрос на RoutingRules на AWS S3 Stati c хостинг

I благодарю вас за помощь.

Обновление: 1. Удален RoutingRule на S3 2. Добавлен новый источник в дистрибутив Cloudfront (шлюз API)

enter image description here

теперь лямбда-функция возвращает 

    return {
        statusCode: "200",
        body: "image converted",
    };

Проверка журналов Cloudwatch. Я не вижу, чтобы лямбда-функция вызывалась и когда я go до https://myCloudfront.cloudfront.net/photos/resized/test.jpg

Я вижу только 404

enter image description here

Я также добавил пользовательскую страницу ошибок с 0 TTL для 404

хорошая новость - если я go к шлюзу API передаю ключ = / photos / resized / test.jpg, а затем go до https://my.cloudfront.net/photos/resized/test.jpg, это работает. он правильно читает изображение.

Я думаю, что проблема заключается в отказоустойчивости, которая не вызывает вызов шлюза API.

enter image description here

1 Ответ

0 голосов
/ 04 апреля 2020

Конечно, вы можете использовать триггер Lambda@Edge Origin Response, чтобы изменить ответ и установить нужный заголовок. В некотором смысле это будет «наиболее правильное» и, следовательно, «наиболее желательное» решение, но только в теоретическом смысле, поскольку оно приводит к ненужным затратам и сложности.

Значение по умолчанию TTL - это значение, которое используется CloudFront, внутренне, когда не найден заголовок ответа Cache-Control, поэтому вы можете установить его равным 0 и включить правильные заголовки Cache-Control при создании объектов S3, чтобы не использовать TTL по умолчанию, кроме перенаправления. Что мне не нравится в этом, так это то, что нет заголовка, который бы настаивал на том, чтобы браузер также не кэшировал перенаправление.

Но вам не нужно возвращать перенаправление в браузер, здесь. Вам вообще не нужно перенаправлять.

С помощью функции Cloud Front Origin Failover вы можете настроить два источника для ваших дистрибутивов - основной и дополнительный, чтобы ваш контент обслуживался из вашего вторичного источника, если CloudFront обнаруживает, что ваше основное происхождение недоступно.

https://aws.amazon.com/about-aws/whats-new/2018/11/amazon-cloudfront-announces-support-for-origin-failover/

Слово «недоступно» здесь излишне расплывчато, потому что эта функция делает больше, и она будет делать то, что вы хотите , Чтобы задать источник возникновения триггера «аварийное переключение» ...

Вы можете выбрать любую комбинацию из следующих кодов состояния: 500, 502, 503, 504, 404 или 403.

https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/high_availability_origin_failover.html#concept_origin_groups .creating

Таким образом, достаточно обычного поведения корзины, правила перенаправления не требуются.

Обратите внимание, что при такой настройке окончательный ответ Единственное, что может быть кэшировано CloudFront - независимо от того, является ли этот ответ источником первичного (S3) или вторичного (лямбда через шлюз API) - так что это устраняет проблему с кэшированием переходных ответов.

Примечание Кроме того, несмотря на использование слова «отработка отказа», CloudFront не поддерживает концептуальную модель состояния источника, поэтому каждый запрос стоит сам по себе и будет go первичному источнику, даже если другие запросы «не выполняются». «

...