← Cloudflare Workers / workers / cache

Ограничения

На этой странице перечислены сценарии, в которых Workers Caching не применяется, а также описано, как он соотносится с другими кешами, которые вы, возможно, уже используете.

Только GET и HEAD запросы кешируются. POST, PUT, PATCH, DELETE, и другие методы всегда вызывают ваш Worker.

GET и HEAD для одного и того же URL используют одну запись кеша. HEAD запрос, поступающий при холодном кеше, преобразуется в GET внутренне, чтобы кеш заполнялся полным ресурсом. См. Ключи кеша.

Если вам нужно кэшировать ответы на неидемпотентные запросы, делайте это в Worker явно: например, преобразуйте тело запроса в синтетический URL с помощью хеширования и выполните внутренний GET подзапрос.

Запросы на обновление до WebSocket (GET с Upgrade: websocket) обходят кеш и всегда вызывают ваш Worker. Сессии WebSocket по определению имеют состояние и не являются подходящей единицей кеширования.

Только fetch() вызовы для WorkerEntrypoint проходят через Workers Caching. Пользовательские методы RPC, такие как ctx.exports.Backend.getUser(id) обходят кеш и всегда выполняют вызываемую функцию независимо от точки входа cache.enabled параметр.

Чтобы кешировать операцию, которая сейчас реализована как метод RPC, переделайте ее в fetch обработчик в своей собственной точке входа и вызвать его с fetch().

Workers Caching никогда не сохраняет перечисленные ниже ответы, даже при явном Cache-Control директивы:

• 520-526 (аварийные ответы Cloudflare) рассматриваются как временные ошибки и всегда приводят к повторному запуску Worker.
• 206 Partial Content возвращаемый вашим Worker, не сохраняется. Workers Caching ожидает, что ваш Worker вернет полный 200 ответ и самостоятельно выполняет разбиение по диапазону. Подробнее см. в Range запросы для поддерживаемого шаблона.

Workers Caching применяется только к HTTP-запросам, которые обрабатывает fetch обработчик на Точка входа Worker. Следующие типы вызовов всегда выполняются без участия кэша:

• Cron Triggers : запланированные вызовы через scheduled обработчик.
• Потребители Queue : сообщения, доставленные через queue обработчик.
• Workflows : выполнение шага Workflow.
• Tail Workers : обработчики событий трассировки.
• Durable Objects : вызовы Durable Object никогда не кешируются, независимо от обработчика или метода. Чтобы кешировать HTTP ответы Durable Object, оберните его Worker'ом с включённым кешированием. См. Кеширование ответов Durable Object.

Режима «очистки по хосту» не существует. Кеш принадлежит Worker, а не домену : хост не входит в ключ кеша, поэтому очистка по хосту не будет соответствовать ничему из того, что хранится в кеше. Используйте очистка по тегу, очистка по префиксу пути, или purgeEverything взамен.

API для предварительного заполнения кеша ответами, сформированными во время сборки, не существует. Ответ кешируется только после того, как он хотя бы один раз был отдан клиенту. Если вам нужно, чтобы предварительно отрендеренный контент был доступен уже первому запросившему, используйте Static Assets.

Лимиты размера ответа совпадают с лимитами кеша зоны Cloudflare. Лимиты по каждому плану см. в Ограничения размера для кеширования.

Ограничения на количество, длину и набор символов Cache-Tag значения такие же, как у зонального кэша Cloudflare. См. Лимиты Cache Tag с полным списком.

ctx.cache.purge() использует ту же систему ограничения частоты запросов, что и API очистки зоны. Однако, поскольку Workers Caching привязан к Worker, а не к зоне, Workers Caching всегда использует Лимиты уровня Free описанного в Доступность и ограничения, независимо от тарифного плана вашего аккаунта или зоны.

Кеширование Workers кэш вашего Worker, а не кеш вашей зоны. Настройка выполняется через сам Worker, поэтому отдельного слоя правил или параметров не требуется. Ничто из перечисленного ниже не относится к Workers Caching:

Чтобы повлиять на кеш своего Worker, измените сам Worker. Cache-Control заголовки, ctx.props, композицию service binding и ctx.cache.purge() охватывают все возможные параметры конфигурации.

Cache API представляет собой отдельное программное хранилище кеша. Оно не зависит от Workers Caching: операции с одним хранилищем не влияют на другое, и ctx.cache.purge() является тем, что аннулирует записи Workers-Caching.

Для новых Workers предпочтительнее Workers Caching. Cache API по своей природе является примитивом более низкого уровня:

• Не выполняет сквозное чтение. Ответы кэшируются только тогда, когда Worker явно вызывает put(), и каждый запрос по-прежнему выполняет ваш Worker при входе.
• Не схлопывание параллельных запросов для одного и того же ресурса. При резком всплеске трафика на новый URL ваш Worker будет вызываться один раз на каждый запрос.
• Не участвует в многоуровневое кэширование.

Workers Caching обеспечивает все три возможности автоматически. Cache API по-прежнему полезен, если нужен точный программный контроль.

Кеширование Workers это серверный кеш перед ваш Worker. Это отдельный кеш, отличный от того, что стоит перед исходящими fetch() подзапросов, которые ваш Worker делает к собственным origin. Они работают независимо друг от друга: fetch() попадание в кэш подзапроса избавляет от обращения к вашему origin, тогда как попадание в Workers Caching избавляет от запуска Worker вообще.

cf свойства у Request ведут себя по-разному в этих двух случаях:

Следующие интерфейсы находятся в разработке:

• Интерфейс Dashboard для включения кеширования без Wrangler.
• Cache Analytics в Workers Observability.