#caching #amazon-cloudfront #cache-control
Вопрос:
Cloudfront получает обновление для запроса, который вообще не должен кэшироваться.
Его не следует кэшировать, потому что:
- Оно имеет
cache-control: max-age=0, no-store
; - Минимальный TTL равен 0; и
- Я создал несколько недействительных (вкл
/*
.), поэтому этот кэшированный ресурс не является результатом какого-либо исторического развертывания
Есть идеи, почему я получаю обновления?
Я также попытался изменить управление кэшем cache-control no-store, stale-if-error=0
, создав новую недействительность /*
, и теперь я вижу попадание в кэш (на этот раз в Firefox):
Комментарии:
1. Похоже, Cloudfront не будет уважать
no-store
по умолчанию. Смотрите документацию о том, как предотвратить кэширование определенных файлов. Как правило, для этого нет особых причин, поскольку повторная проверка гарантирует правильность файла.2. На этой странице предлагается включить «Использовать заголовки кэша источника», что звучит в точности так, как нам нужно, но этот параметр, по-видимому, доступен только в том случае, если мы используем их опцию «Устаревшие настройки кэша» в нашем поведении, но мы используем новую опцию «Политика кэша и политика запроса источника (рекомендуется)».
3. Можете ли вы использовать второе предложение на этой странице, чтобы создать поведение в консоли, отключающее кэширование для указанных объектов?
4. Нет, потому что мне нужно, чтобы он кэшировал некоторые запросы из моего источника, но не другие, поэтому мне действительно нужно, чтобы он основывал свое кэширование на
Cache-Control
директиве, которую ему дает источник. (вариант использования не так важен, но он связан с постепенной миграцией всего нашего сайта из jQuery в Next.js)5. Обратите внимание, что можно создать несколько вариантов поведения и указать , к каким ресурсам они применяются. Таким образом, вы можете установить правило, которое применяется только к определенным ресурсам, которые вы не хотите хранить.
Ответ №1:
После долгих разговоров с поддержкой они объяснили, что происходит.
Итак, если у вас есть no-store
и минимальный TTL равен 0, то CloudFront действительно не будет хранить ваши ресурсы. Однако, если ваш источник долго не отвечает (вероятно, при большой нагрузке), в то время как CloudFront ожидает ответа на запрос, если он получит другой идентичный запрос (идентичный в отношении ключа кэша), он отправит один ответ на оба запроса. Это делается для того, чтобы облегчить нагрузку на сервер. (см. документы)
Служба поддержки называла это «коллапсом», хотя я не вижу этого в документах.
Таким образом, кажется, что у вас не может быть единого поведения, обслуживающего некоторые страницы, которые должны иметь уникальный ответ на запрос при обслуживании других кэшированных страниц. Поддержка сказала:
Я только что подтвердил, что с минимальным TTL 0 и контролем кэша: без хранилища мы не можем отключить попадание в коллапс. Если вам действительно нужно полностью отключить кэш cloudfront, вы можете использовать политику кэширования CachingDisabled
Мы будем определять поведение для каждого префикса пути, для которого нам нужно кэширование. Похоже, что для нашего варианта использования не было лучшего способа, чем этот (перевод нашего веб-сайта по одной странице за раз с не кэшируемого, отображаемого на серверной части jinja2/jQuery на кэшируемый, отображаемый на стороне клиента React/Next.js).
Комментарии:
1. Это хорошо знать (относительно поведения под нагрузкой). Что касается управления кэшем, я думаю, вы хотите установить управление кэшем в источнике
max-age=0, must-revalidate, public
и убедиться, что вы также можете отправить обратно etag